cncfstack 新 文章上线：
-
书名：《云原生解决方案》
-
访问：文章底部"阅读原文"或访问域名
云原生计算是云计算发展新的里程碑阶段，是当今与未来很长一段时间中 IT 发展的技术基础。但当我们初次接触到云原生技术栈时，特别是云原生全景图（Cloud Native Landscape），会看到大量的开源技术与云原生生态，会感叹他的宏大与复杂，也会困惑于该从哪里开始。
当我们在了解和学习云原生技术时，特别是当我们要进行云原生实践时，该如何把握重点逐步的深入实践呢？与其摸着石头过河自行实践探索，倒不如以开放的心态先来了解下其他团队的实践经验，交流、学习、总结、优化改进一套符合自身业务发展的云原生实践之路。
根据多年的经验与项目实践，我认为云原生的实践大致分为七个主要里程碑阶段，由浅入深分别是：容器云、可观测性、研发效能、分布式与微服务、有状态服务、安全、生态 ，为便于后文介绍，该七个阶段定义为"云原生最佳七步实践"。本文主要描述容器云阶段，其他阶段会在后续的文章中逐步介绍。
云原生实践的第一步是要建设企业的云原生容器云平台，它是整个云原生实践的基础也是是核心。上图描述了容器云平台的核心能力与推荐的技术选型。
一、基础设施
在进行容器云平台建设时，需要根据企业实际现状来评估基础设施，更多的是合理的复用和管理当前已有的基础设施，并对后续发展演进进行合理的规划。基础设施在评估时一般会考虑计算、存储、网络以及安全的问题，可能会涉及到公有云、私有云、混合云等云平台资源，以及未加入到云的物理机器资源、网络设备资源、终端设备等资源。
在基础设施中最常见的是机器资源，它是所有软件服务运行的核心载体。企业在进行云原生实践前可能已经在云计算阶段发展了很长一段时间，无论是公有云还是自建的私有云，那必不可少的一种机器资源是"虚拟化"的虚拟机；但是在云原生场景下，由于隔离、调度的最小单位是容器，使用物理机器能够带来更好的性能和资源利用率，虚拟机带来的隔离收益已经越来越低；因此建议是直接使用物理服务器来运行容器，而不是再分配的虚拟机中运行。当然，企业的现状（资源、流程、规范、利益等）并不一定能立马基于物理服务器进行实践，但应该将它作为一个长期演进的目标。
基础网络涉及到物理环境且同样被云原生场景作为基础依赖，一般不需要对其进行特殊改造，即使有网络层的需求也是通过软件方式实现。安全层面面临新的挑战，由于云原生的实践产生了新的安全问题，云原生生态也同样提供的应对之法，这在"云原生最佳七步实践"的安全阶段会进行详细的介绍。其他如计算、存储等都可以在云原生的实践中进行拓展和增强。
容器云在大多数企业中也是定位 IaaS 基础设施，并不需要在概念上严格的将容器云与基础设施区分。
二、容器编排调度
容器是一种和虚拟机类似，但又不一样的一种管理单位。容器是由镜像运行起来的服务，镜像将应用程序运行的环境依赖进行打包，以便容器能够在不同的节点上运行产生相同的预期结果，这种特性使其成为了最小可调度管理单元。在 Kuberentes 中容器的运行和管理工具是容器运行时，容器运行时提供了容器镜像的传输（镜像的上传和下载）、镜像存储（将镜像解压后按照 OCI 的标准在文件系统上管理相关文件）、容器运行、容器状态监视以及基础的存储管理和网络管理能力。
Docker 是容器标准化产物，基本成为了容器代名词，在 Kuberentes 的容器运行时选择中仍然是主导地位。基于 Docker 的 Libcontainer 剥离出来的 Containerd 项目在 Kuberentes 中能够提供比 Docker 更短的管理路径，以及轻量化带来的更加安全等特性，使其逐渐成为 Kuberentes 推荐的容器运行时。由于历史的发展与商业的竞争，很多优秀的容器运行时被开发和开放开源出来，这其中 Cri-O 就是其中的娇娇者，也是推荐的选择之一。
容器作为可编排和调度的最小单元，需要一种工具或平台来执行编排和调度，来让容器产生规模化的生产价值。早期的三剑客 Kubernetes、Mesos 和 Swarm 都能够提供容器编排调度能力，在历史激烈竞争的洪流中，Mesos 和 Swarm 已退出了历史的舞台，独尊 Kuberentes 。
Kubernetes 是云原生时代的分布式操作系统，是云原生的核心也是容器云的核心。Kubernetes 以 Etcd 为存储提供了对容器的容器管理、调度管理、编排管理、配置管理、资源管理、弹性伸缩、负载均衡、故障自愈、健康检查、密钥管理、滚动更新、自动部署等基础核心功能，也提供可扩展的接口来满足各种不同的业务场景。
三、扩展能力
Kubernetes 提供核心基础的容器管理能力，更多场景功能由运行在 Kuberentes 中的服务提供。在建设容器云平台时，一般情况下建议同时进行网络管理建设、域名解析、流量代理以及 PVC 存储的基础能力建设，其他能力可以在后续持续建设。
Kubernetes 的网络管理主要提供了网段的分配管理、 IP 地址的分配管理、多节点与服务的网络连接以及网络访问策略管理的能力。目前主流推荐的网络方案主要有 Calico、Flannel 和 Cilium 三种，Calico 适合在大规模复杂的网络场景，Flannel 功能相对 Calico 要简单但能提供较好网络性能，Cilium 是目前社区火热的一种网络解决方案。业务方可以根据实际业务场景进行网络方案的选择，但如果不好区分三者的差异时，推荐默认就用 Calico 方案，至少当前不会是个错误的选择。
DNS 是 Kuberentes 集群中比较重要能力之一，提供域名解析、DNS 代理、Kuberentes 资源名称解析以及服务发现的能力，推荐使用 CoreDNS 作为集群的 DNS 服务器。除与传统的 DNS 服务器（如：bind）一致的域名解析和DNS 代理外，CoreDNS 还可以在 Kuberentes 中将 Kubernetes Service 的域名解析成 ClusterIP，还支持 Headless 类型的 Service 将服务名解析成多个后端 PodIP 列表并提供负载均衡的轮询能力，也可以将 Statefulset 类型的工作负载提供实例名称到 PodIP 解析的能力，以及动态检测后端记录变动调整解析结果的能力。基于动态检测的能力，衍生出服务注册发现的场景能力，这给"云原生最佳七步实践"的分布式与微服务阶段提供全新的解决方案。
容器运行程序的目的是让程序产生服务能力，部分容器是提供的是任务执行或计算的能力（如：Job、CronJob），但大部分任然是以工作负载的形式对外提供服务。在 Kuberentes 集群内提供服务一般是通过 Kuberentes 的 Service 类型资源暴露，但是将能力暴露到集群外部时一般需要通过网关代理，Ingress Nginx 是最常用的七层代理网关。Ingress Nginx 能够动态检测集群中 Ingress 类型的资源并生效，同时提供负载均衡和动态后端更新的能力。
给 Kuberentes 集群提供 PVC 存储的能力在容器云平台建设早期不是必须的。我们在前面建设的 Kuberentes 集群和相关能力基本能够满足容器化的实践要求，对于业务系统使用的存储可以通过网络的方式提供，如 MySQL、对象存储等。不建议在一开始就建设 PVC 存储的理由是靠谱的网络存储系统管理可能比建设容器云平台还复杂，而且使用的场景并非必须依赖，即投入与产出不匹配。当然，如果有专业的存储团队提供支持，也是可以同时进行能力建设。
其他扩展能力与容器云基础能力关联不大，不在这里发散性讨论，根据实际业务需求部署的服务就是对容器云能力的扩展。
四、云管层
**为了更好的使用和管理 Kuberentes，建设统一的云管平台成为重要的选择。**容器云管理平台提供了基于 Web 管理能力，具有多租户的隔离能力，可以实现在企业内统一管理。容器云管理平台还能提供主机管理能力，以及 Kuberentes 集群的安装部署、变更升级、纳管多套 Kuberentes 集群的能力。提供统一的监控告警能力，以及将容器云相关的能力以 OpenAPI 接口暴露给其他系统使用，如"云原生最佳七步实践"的研发效能阶段中持续集成与部署的对接集成。
容器云核心管理的是容器，而容器是基于镜像运行的，因此镜像的管理也是容器云平台的重要能力之一。并非所有的企业网络能够方便的访问互联网上镜像仓库，如 Docker Hub 或 Google 的 Gcr ，因此建设企业私有的镜像仓库成为提效的重要一步。推荐基于 Harbor 或 Dragonfly 来搭建企业私有的镜像仓库，他们能够提供企业私有的集中镜像存储中心，并提供安全的扫描能力。
容器云平台建设应用中心可以帮助企业资产积累沉淀，可以快速交付应用。应用中心提供从应用定义、应用打包、应用发布（应用市场）到应用部署的生命周期管理能力，可以使用 Helm Chart 的方式进行云原生应用的标准化管理，也可以快速复用开源社区的优秀应用。
五、业务层
在企业中业务系统直接面向客户提供服务，是真正能够创建价值或者利润的主体，一切应该以服务好业务为主要目标。在进行云原生实践，建设容器云平台的目的也是为了更好的帮助业务创造价值，技术演进与降本增效反而是次要考虑的问题，切不可本末倒置。
在容器云上运行的服务大致分为两种，其一就是业务系统，其二就是围绕业务系统进行的相关建设，比如本文的容器云平台提供了业务系统运行的基础环境，以及后续阶段会介绍的为监控业务状态建设的可观性平台，为提升业务系统研发效率的研发效能平台，为保证业务系统稳定的分布式与微服务平台，为业务系统提供稳定数据管理的有状态服务管理，以及保证业务系统的安全建设等等，这在后续的文章中会与大家一一分享我的经验与理解。