资深架构师谈云原生生态的基石Kubernetes

Posted 2021-04-16 CSDN

谈到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（服务网格）、服务发现、分布式追踪、监控、安全等各个领域的解决方案。

01

Kubernetes架构

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

 

 

图1

 

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

 

• etcd：协同存储，负责保存整个集群的状态，通常会部署奇数个节点以保证高可用性。

•  API：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。

• controller manager：负责维护集群的状态，执行故障检测、自动扩展、滚动更新等操作。

• Scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。

• Kubelet：作为工作节点负责维护容器的生命周期，同时也负责对容器存储接口（CSI）和容器网络接口（CNI）进行管理。

• 容器运行时（对应图1中的Docker）：负责镜像管理，实现Pod和容器的真正运行。

• Proxy：负责提供集群内部的服务发现和负载均衡。

 

除了核心组件，Kubernetes中还有一些推荐使用的插件，其中有的已经成为CNCF中的托管项目，具体如下。

• CoreDNS：负责为整个集群提供DNS服务。

• Ingress Controller：负责为服务提供外网入口。

• Prometheus：负责资源监控。

• Dashboard：负责提供GUI。

• Federation：负责提供跨可用区的集群。

 

02

分层设计理念及架构模型

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

 

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

 

• 核心层：Kubernetes的核心，负责对外提供API构建高层应用，对内提供插件式应用执行环境。 

• 应用层：负责部署和路由，可部署的应用包括无状态应用、有状态应用、批处理任务、集群应用等，路由的类型主要有服务发现、DNS解析等。 

• 管理层：负责自动化（如自动扩展、动态部署等），以及策略（RBAC、ResourceQuota、NetworkPolicy等）管理。

图2

• 接口层：主要包括kubectl命令行工具、客户端SDK等用于客户端操作的库，以及集群联邦等实用工具。
  

• 云原生生态系统：接口层之上的负责容器集群管理调度的生态系统，该系统可以划分为两个范畴。

• Kubernetes内部：包括CRI（容器运行时接口）、CNI（容器网络接口）、CSI（容器存储接口）、镜像仓库、云供应商、身份供应商等。

 

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

 

03

设计哲学

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

 

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

 

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

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

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

 

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

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

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

本文经授权摘自《未来架构：从服务化到云原生》

 

《未来架构：从服务化到云原生》

书籍详情可点击封面查看

扫码一键购买

此书由一线资深架构师（张亮、吴晟、敖小剑、宋净超）合力撰写，技术圈众大咖联合力荐！凝聚从服务化到云原生的前沿架构认知，更是对未来互联网技术走向的深邃洞察！

编辑推荐：

1、大咖云集：本书由多位资深一线计术人员执笔，集大家之所长，为读者呈现了一段十分立体的架构发展史。同时，本书受到技术圈多位知名大咖联袂力荐，足见内容之精绝！

2、概念领先一代：本书对快速演进中的云原生数据架构、典型分布式数据库中间件进行了剖析，重点介绍Service Mesh等新兴概念，创新性地提出了Database Mesh的理念，深度揭秘Apache项目——ShardingSphere！精彩内容层出不穷，知识概念全然领先一代！

3、情怀感人：作者将自己十几年的功力投入开源，毫不吝啬地在书中分享经典Apache开源项目的成长之路，同样热爱的开源的朋友们，让我们一起为中国开源贡献力量吧！

适读人群：云计算从业人员；架构师；关注分布式、Java、Mesos、任务调度的程序员

扫码一键购买