谈到Kubernetes就不得不谈到容器。几年前容器技术大热，现在基本归于平淡，之前大家提到的容器通常是指Docker容器，甚至很多人认为容器就等同于Docker，还有很多人像操作虚拟机一样使用容器。

Kubernetes是Google基于其内部使用的Borg改造而成的一个通用容器编排调度器，于2014年被发布到开源社区，并于2015年被捐赠给Linux基金会下属的云原生计算基金会（CNCF），Kubernetes也是GIFEE（Google Infrastructure For Everyone Else）中的一员，GIFEE中的其他成员还有HDFS、HBase、ZooKeeper等。

CNCF中托管的项目一般会遵循一套完善的成长流程，毕竟经过沙盒、孵化和毕业这三个阶段。Kubernetes是CNCF托管的所有项目中第一个成功毕业的项目，整个CNCF技术栈都是围绕它而建立的。Kubernetes是云原生项目中最重要的组件，其目标不仅仅是成为一个编排系统，更是为用户提供一个规范，让用户可以描述集群的架构，定义服务的最终状态，并让系统自动维持在这个状态。

现如今，云服务已经可以为我们提供非常稳定的基础设施了，但是业务上云却成了一个难题。Kubernetes的出现与其说是为了提供最初的容器编排解决方案，倒不如说是为了解决应用上云（即实现云原生应用）这个难题。CNCF中托管的一系列项目致力于对云原生应用的整个生命周期进行管理，通过开源软件为用户提供部署平台、日志收集、Service Mesh（服务网格）、服务发现、分布式追踪、监控、安全等各个领域的解决方案。

1. Kubernetes架构

谈到云计算就必然谈到分布式，Kubernetes作为云原生计算的基础组件，本身也采用了分布式架构。图7-1展示了Kubernetes的架构。

图7-1 Kubernetes的架构

Kubernetes主要由以下几个核心组件构成。

etcd：协同存储，负责保存整个集群的状态，通常会部署奇数个节点以保证高可用性。
API：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。
controller manager：负责维护集群的状态，执行故障检测、自动扩展、滚动更新等操作。
Scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。
Kubelet：作为工作节点负责维护容器的生命周期，同时也负责对容器存储接口（CSI）和容器网络接口（CNI）进行管理。
容器运行时（对应图7-1中的Docker）：负责镜像管理，实现Pod和容器的真正运行。
Proxy：负责提供集群内部的服务发现和负载均衡。
除了核心组件，Kubernetes中还有一些推荐使用的插件，其中有的已经成为CNCF中的托管项目，具体如下。
CoreDNS：负责为整个集群提供DNS服务。
Ingress Controller：负责为服务提供外网入口。
Prometheus：负责资源监控。
Dashboard：负责提供GUI。
Federation：负责提供跨可用区的集群。

2.分层设计理念及架构模型

Kubernetes的架构设计理念与Linux的分层架构设计理念类似，图7-2展示了Kubernetes分层架构模型。

如图7-2所示，Kubernetes分层架构中包含以下几部分。

核心层：Kubernetes的核心，负责对外提供API构建高层应用，对内提供插件式应用执行环境。
应用层：负责部署和路由，可部署的应用包括无状态应用、有状态应用、批处理任务、集群应用等，路由的类型主要有服务发现、DNS解析等。
管理层：负责自动化（如自动扩展、动态部署等），以及策略（RBAC、ResourceQuota、NetworkPolicy等）管理。

图7-2 Kubernetes分层架构模型

接口层：主要包括kubectl命令行工具、客户端SDK等用于客户端操作的库，以及集群联邦等实用工具。
云原生生态系统：接口层之上的负责容器集群管理调度的生态系统，该系统可以划分为两个范畴。
Kubernetes内部：包括CRI（容器运行时接口）、CNI（容器网络接口）、CSI（容器存储接口）、镜像仓库、云供应商、身份供应商等。

整个云原生的生态都是以Kubernetes为基石构建的，Kubernetes自诞生以来便迅速发展，正在向原有的非云原生领域扩张。

3.设计哲学

Kubernetes之所以能够如此快速地发展，不仅是因为其背后有Google公司的大力支持和繁荣社区的全力协助，更是因为它本身蕴含着优秀的设计哲学。Kubernetes并未采用常见的命令式设计模式，而是采用了声明式设计模式。

由于云原生应用程序是面向在云环境中运行的应用程序而设计的，因此，云原生应用及其基础设施，与传统应用的交互方式并不相同。在云原生应用程序中，与任何事物进行通信都是通过网络实现的，用户编写YAML格式的应用程序编排文件，然后Kubernetes将其转换为JSON格式，并通过RESTful HTTP的方式与API Server进行通信。Kubernetes组件本身则通过gRPC进行通信。

传统的应用程序通常通过消息队列、共享存储或触发shell命令的本地脚本来自动执行任务，通过对发生的事件做出响应（例如，用户点击【提交】按钮或是运行部署脚本）来完成交互。

Kubernetes的控制器一直监听API Server。一旦发现有应用状态变更，就会声明一个新的状态，并相信API Server和kubelet会进行必要的操作来调整应用状态，直至与声明的状态一致为止。

声明式通信规范了通信模型，一系列API声明规范了应用程序的部署原语，并且将功能实现从应用程序中转移到了远程API或服务端点上，从而让应用程序达到预期状态。这样有助于简化应用程序，并使它们的行为更具可预测性。

运行云原生应用程序的基础设施与传统应用程序的基础设施不同。基础设施不仅仅提供了应用运行所需的资源，还承担了许多对应用程序进行生命周期管理时的责任。

Kubernetes优秀的分布式架构设计，给用户提供了众多可扩展的接口，可以让用户很方便地扩展自己的运行时、网络和存储插件，同时还可以让用户通过CRD管理自己的分布式应用。采用CRD声明式配置方式时，用户可以利用Kubernetes的原语快速编排出一个云原生应用。

云原生应用程序通过将应用分解为更小的服务来降低代码复杂性，并且可以借助统一的日志、监控、审计平台加强应用程序的可观察性，Kubernetes仅实现了应用程序的部署和资源调度，因此还需要一些新的工具来自动管理激增的服务和应用生命周期中的其他阶段，例如，使用Ballerina、Pulumi这样的云原生编程语言便可以简化基于Kubernetes平台的微服务应用的集成。

相关文章：
架构新纪元（一）：从分布式架构到云原生架构
 架构新纪元（二）：什么是云原生？
架构新纪元（三）：云原生的生态圈
 架构新纪元（四）：观察分布式服务

本文节选自图书《未来架构：从服务化到云原生》。本书对快速演进中的云原生数据架构、典型分布式数据库中间件进行了剖析，重点介绍 Service Mesh 等新兴概念，创新性地提出了 Database Mesh 的理念，深度揭秘 Apache 项目——ShardingSphere。

购买链接： https://u.jd.com/sbmG4Y

作者简介：
张亮
京东数科数据研发负责人，Apache ShardingSphere 发起人兼 PPMC 成员。热爱分享，拥抱开源，主张代码优雅化，擅长以 Java 为主的分布式架构以及以 Kubernetes 和 Mesos 为主的云平台的构建。ShardingSphere 已进入 Apache 软件基金会，是京东集团首个进入 Apache 的开源项目，也是 Apache 首个分布式数据库中间件。

吴晟
Apache SkyWalking 创始人及 PPMC 成员，Apache ShardingSphere 原型作者及 PPMC 成员，Apache Zipkin 贡献者，Apache 孵化器导师，CNCF 基金会 OpenTracing 标准化委员会成员，W3C Trace Context 规范贡献者。擅长分布式架构、性能监控与诊断、分布式追踪、云原生监控等领域。

敖小剑
具有十七年软件开发经验，资深码农，微服务专家，Cloud Native 拥护者，敏捷实践者，Service Mesh 布道师，ServiceMesher 中文社区联合创始人。专注于基础架构建设，对微服务、云计算等相关技术有着深入研究和独到见解。

宋净超
蚂蚁金服云原生布道师，ServiceMesher 中文社区联合创始人，Kubernetes 社区成员，Istio 社区成员，《Cloud Native Go》《Python 云原生》《云原生 Java》等图书译者。

创作场景

架构新纪元（五）：云原生生态的基石 Kubernetes