2.2　什么是Kubernetes

在2.1节我们了解了什么是容器云，那么我们用什么技术手段来实现容器云呢？简单来说，Docker+Kubernetes就是当前最流行的实现容器云的组合方式。

2.2.1　Kubernetes的基本介绍

维基百科对Kubernetes的解释是：Kubernetes（常简称为K8s）是用于自动部署、扩展和管理容器化应用程序的开源系统。该系统由Google设计并捐赠给云原生基金会（Cloud Native Computing Foundation，简称CNCF，现在隶属于Linux基金会）使用。

如果你之前了解过OpenStack，应该知道可以用OpenStack管理虚拟机资源。那么管理容器是否有对应的开源平台呢？有的，就是Kubernetes。当然，Kubernetes火爆之前也出现过其他管理平台，比如Docker推出的Swarm、Apache推出的Mesos。这和OpenStack推出的时候情况相似，当时与OpenStack竞争市场的有CloudStack、OpenNebula、EasyStack等。不过，最终还是OpenStack胜出了。Kubernetes也是如此，虽然晚推出一步，但是在Google的支持下发展得很快。

1.Kubernetes的诞生历史

Kubernetes的Logo是一个蓝色的船舵，如图2-3所示。希腊语Kubernetes的意思是“舵手”或“驾驶员”。

图2-3　Kubernetes的Logo

早在2000年左右，Google内部就开始了容器技术的管理，当时算是Google内部的顶级技术和机密技术。随着近几年容器技术的飞速发展，Google开源了沉淀十几年的技术，顺势成为容器编排领域的龙头。

Google内部的这项容器技术名叫Borg。未开源时，Kubernetes的代号是Seven，即《星际迷航》中的Borg（博格人，该系列剧中最大的反派，通过“同化”来繁衍）。

选择Kubernetes这个名字的原因之一是船舵有7个轮辐，代表着这个项目最初的名称“Project Seven of Nine”。

以下是Kubernetes各版本的发行时间。

●2015年06月11日，Kubernetes 1.0发布

●2015年09月26日，Kubernetes 1.1发布

●2016年05月17日，Kubernetes 1.2发布

●2016年06月02日，Kubernetes 1.3发布

●2016年09月27日，Kubernetes 1.4发布

●2016年11月13日，Kubernetes 1.5发布

●2017年05月29日，Kubernetes 1.6发布

●2017年06月29日，Kubernetes 1.7发布

●2017年09月28日，Kubernetes 1.8发布

●2017年12月15日，Kubernetes 1.9发布

●2018年03月26日，Kubernetes 1.10发布

●2018年06月27日，Kubernetes 1.11发布

●2018年09月27日，Kubernetes 1.12发布

●2018年12月03日，Kubernetes 1.13发布

●2019年03月26日，Kubernetes 1.14发布

●2019年06月20日，Kubernetes 1.15发布

●2019年09月19日，Kubernetes 1.16发布

●2019年11月10日，Kubernetes 1.17发布

●2020年03月26日，Kubernetes 1.18发布

●2020年08月27日，Kubernetes 1.19发布

我们可以看到最新的Kubernetes版本是1.19，从1.10版开始，基本上是每三四个月更新一次。

2.Kubernetes的生态发展

CNCF于2017年宣布了首批Kubernetes认证服务提供商（KCSP），包含IBM、华为、Mirantis、inwinSTACK等，如图2-4所示。

图2-4　CNCF Kubernetes认证服务提供商

这些都是国内外知名IT科技公司，以前对Swarm很依赖的公司后来也纷纷投向Kubernetes，下面的技术新闻也说明了Kubernetes日益受欢迎。

1）化敌为友，Docker宣布拥抱Kubernetes。

2）Twitter宣布抛弃Mesos，全面转向Kubernetes。

3）eBay宣布拥抱容器，将全面整合Kubernetes和OpenStack。

4）红帽与三大云巨头合作打造Kubernetes Operators中心。

5）Mirantis推出基于OpenStack和Kubernetes的边缘计算平台。

如今CNCF每年都会举办云原生技术盛会（KubeCon+CloudNativeCon）。每年都吸引众多参与者，众多技术大佬和开发者都会在大会上分享最新的容器、区块链、AI、IoT等技术动态。这个大会目前是分区域举办的，国内大会去年和今年都在上海举行。

2.2.2　Kubernetes的技术架构

1.Kubernetes的基本组成

Kubernetes是分布式架构，由多个组件组成。我们还需要了解这些组件之间的关联，这一点非常重要。

（1）Pod

Pod这个单词有“豆荚”之意，可以把它联想成一个微型的小空间。前面我们提到过Kubernetes是容器资源管理调度平台，它本身不会创建运行时容器（真正创建容器的是Docker），只负责管理容器资源。那么管理容器资源，总要在最底层有个归纳收整容器的机制（把容器想象成豆子，Pod就是包住它们的豆荚）。这个Pod就是Kubernetes里最小的管理单元，里面存放着一组有关联关系的容器，这组容器一起共用相同的网络和存储资源。

（2）node

node就是节点的意思，因为Kubernetes是分布式架构，所以Kubernetes一样有主节点（master）和从节点（slave）。主节点可以理解为Kubernetes的核心大脑，里面运行着API Server、Scheduler、Replication Controller等关键服务。Kubernetes的从节点一般叫作work节点，里面运行着一个或者多个Pod、kubelet、kube-proxy。如果接触过OpenStack，就更容易理解Kubernetes中node的角色了，在OpenStack里有控制节点和计算节点，控制节点对应主节点，计算节点对应从节点。

（3）Cluster

Cluster就是集群的意思，分布式系统必然少不了集群的概念。一个或多个master+一个或多个slave就组成了集群。集群是一个逻辑概念，一般会根据资源、地域、业务等几个维度进行划分。

（4）Etcd

集群运行当中必然会产生一些数据，比如Kubernetes的一些状态信息。这些状态信息需要持久化存储在一个数据库中，Etcd就提供了这个功能。Etcd是一个开源的、分布式的键值对数据存储系统，同时它提供共享配置和服务的注册发现功能。

（5）API Server

API Server运行在主节点里面，它提供了Kubernetes各类资源对象的CURD及HTTP REST接口，我们可以把它理解为Kubernetes的神经系统。集群内部组件需要通过它进行交互通信，然后它会把交互的信息持久化到Etcd里。假如我们要命令或者自己开发程序操作Kubernetes，就需要跟API Server打交道。

（6）Scheduler

Scheduler英文直译就是调度的意思。在分布式计算系统里面，调度是非常重要的，因为我们要合理地划分有限的资源池。学习调度可以从两方面入手，我们可以简单地了解它的规则、流程，或者深入学习它的算法。

学习Kubernetes先要了解它的调度规则和流程，总体来讲有两点，一个是预选调度过程，另外一个是确定最优节点。预选调度过程是遍历所有目标节点，筛选出符合要求的候选节点。Kubernetes内置了多种预选策略供用户选择。确定最优节点是在预选调度过程的基础上，采用优选策略计算出每个候选节点的积分，积分最高者胜出。后续我们会详细讲解Scheduler的策略，以帮助我们对资源进行规划和把控。

（7）Replication Controller

Replication Controller简称RC，是Kubernetes里非常重要的一个概念，使用Kubernetes时经常会用到。Replication是复制、副本的意思，Controller是控制器，连起来就是“副本控制器”。在Kubernetes里，我们对Pod进行创建、控制、管理等操作都不是直接进行的（不像管理虚拟机那样）。我们要通过各种控制器来实现操作，其中RC就是控制器的一种（还有后面将提到的ReplicaSet）。

那么，这里说的控制器到底是控制Pod什么呢？一般来说，我们可以通过RC来控制Pod的数量，确保Pod以指定的副本数运行。比如RC里设置Pod的运行数量是4个，那么如果集群里只有3个，RC会自动创建出一个Pod来；如果集群里有5个Pod，多了一个，RC也会把多余的一个Pod回收；除此之外，假如4个Pod当中有一个容器因为异常而退出，RC也会自动创建出一个正常的容器。确保Pod的数量、健康、弹性伸缩、平滑升级是RC的主要功能。RC机制是Kubernetes里一个重要的设计理念，有了它才能实现Kubernetes的高可用、自愈、弹性伸缩等强大功能。

（8）ReplicaSet

ReplicaSet简称RS，可译为副本集。在新版本的Kubernetes里，官方建议使用ReplicaSet替代Replication Controller。RS跟RC都属于控制器，没有本质区别，可以理解为RS是RC的升级版，唯一的区别在于RS支持集合式标签选择器，而RC只支持等式标签选择器（集合式就是标签可以有多个值，等式就只能选择一个值或者不选）。

（9）Deployment

现在我们已经知道RC和RS控制器的作用了，那么如何操作它们呢？答案是通过Deployment，Deployment的中文意思为部署、调度，通过Deployment我们能操作RC和RS，你可以简单地理解为它是一种通过yml文件的声明，在Deployment文件里可以定义Pod的数量、更新方式、使用的镜像、资源限制等。但需要注意的是，一定要编写正确格式的Deployment yml文件，不然部署会失败。

（10）Label

Label就是标签，标签有什么作用呢？很简单，标签用来区分某种事物。在Kubernetes里，资源对象分很多种，前面提到的Pod、node、RC都可以用Label来打上标签。打上标签后，用户就可以更好地区分和使用这些资源了。另外，Label是以key/values（键/值对）的形式存在的。用户可以对某项资源（比如一个Pod）打上多个Label，另外，一个Label也可以同时添加到多个资源上。

（11）Selector

Selector是标签选择器。前面讲Label的时候我们提到Kubernetes里面有很多资源，而且各种资源都能打上标签。所以一个集群里，会有很多标签。标签一多，必然要有一种机制进行管理和筛选，Selector就是起这个作用的。通过标签筛选，我们能快速找到想要的资源对象。

（12）Kubelet

Kubelet运行在work节点上，它是work节点的关键服务，负责与master节点沟通。master里的apiserver会发送Pod的一些配置信息到work节点里，由Kubelet负责接收。同时，Kubelet还会定期向master汇报work节点的使用情况，比如节点的资源使用情况、容器的状态等。

（13）Kube-proxy

Kube-proxy也运行在work节点上，因为带有proxy字眼，我们可以很快联想到它跟代理、转发、规则等方面有关。是的，它的作用就是生成iptables和ipvs规则，处理一些访问流量相关的转发。

（14）Service

Service在Kubernetes里是后端服务的一种体现。我们前面提到过，Pod是一个或者多个有关联关系的容器，这些容器生成的服务就是通过Service对外提供的。举个例子，假如A服务运行3个Pod，B服务怎么访问A服务的Pod呢？通过IP肯定不行，因为Pod的IP重启之后会改变。这时候只要通过Selector把Service跟A服务的Pod绑定就可以了，无论A服务的Pod如何变化，对B服务来说只要访问Service即可。另外，前面提到的Kube-proxy主要是负责Service的实现。

（15）KubeDNS

看到DNS你就应该知道这个组件是做什么用的。是的，KubeDNS就是Kubernetes内部的域名解析器。Kubernetes内部有域名需要解析吗？是的，有。我们简单地将DNS解析理解为把域名和实际的IP对应上，那么在Kubernetes里KubeDNS的作用就是把Service和IP对应上，我们直接使用服务名来做交互，而不用关心它的实际IP地址。

（16）Ingress

Ingress直译为中文是“入口”。很明显，Kubernetes创造这个机制是为了让外部能很好地访问Kubernetes所提供的服务。可是上面的Service不就是提供服务的吗？为何还要用Ingress？这个问题问得好！Ingress是从Kubernetes的1.1版本开始添加的，你可以理解为它就是一种“转发规则”，而且Ingress的后端是一个或者多个Service。前面提到过，Service的后端是一组Pod，假如Pod A提供Service A，Pod B提供Service B，这两个Service又是由同一组业务支撑的，如果没有Ingress，Service A和Service B就只能单独直接暴露给外部，并且做不了业务关联。有了Ingress，就能提供一个全局的负载均衡器，站在多个Service的前端，扮演“智能路由”的角色，把不同的HTTP/HTTPS请求转发到对应的Service上。

（17）Ingress controller

Ingress是一种规则，由Ingress controller控制和使用，主要作用就是解析Ingress的转发规则。一旦Ingress里面的规则有改动，Ingress controller也会及时更新，然后根据这些最新的规则把请求转发到指定的Service上。

（18）Kubectl

一套集群做相关管理和操作，我们能想到的最基本的方式就是命令。Kubectl是运行Kubernetes集群命令的管理工具。想运维操作集群，直接执行Kubectl--help命令就可以了。

（19）Dashboard

这是Kubernetes的控制面板Web UI界面。它是一个独立的组件，集合了所有命令行可以操作的命令。搭建好Kubernetes后，可以选择安装或不安装Dashboard。

2.Kubernetes架构组件的关联关系

上面我们分别讲解了Kubernetes各个组件的作用和概念，这里用图2-5来更加形象地表示各个组件的关系。

图2-5　Kubernetes组件的关联关系

1）外网进入Kubernetes集群要先通过一道防火墙。

2）紧接着通过Ingress controller，它负责运行Ingress的转发规则，让请求转发到对应的Service上（图里直接到Kubelet-proxy），前面提到过Service的实现靠的是Kubelet-proxy。

3）接着Kubelet-proxy把流量分发在对应的Pod上。

4）每个work节点里面都运行着关键的Kubelet服务，它负责与master节点的沟通，把work节点的资源使用情况、容器状态同步给APIServer。

5）master节点的APIServer是很重要的服务，从图2-5中我们可以看到控制器、调度、ETCD等都需要跟APIServer交互。由此可见，我们在运维Kubernetes集群的时候，APIServer服务的稳定性要加固保障，保证APIServer服务的高可用性。

2.2.3　Kubernetes解决了什么

1.技术角度

Kubernetes无疑让PaaS平台更加完善，它与Docker相配合让容器云落地更容易。同时，Kubernetes也推动了云原生、SOA等技术理念和架构的演进。

从Kubernetes运用这方面来说，它可以达成以下目标。

1）跨多台主机进行容器编排（容器资源集中式管理）。

2）更加充分地利用硬件，最大限度地运用企业现有的IT资源（成本最大化）。

3）有效管理和控制应用的部署与更新，并实现自动化操作（CICD，蓝绿发布快捷高效）。

4）挂载和增加存储，用于运行有状态的应用。

5）快速、按需扩展容器化应用及其资源（易操作）。

6）对服务进行声明式管理，保证所部署的应用始终按照部署的方式运行（易管理）。

7）利用自动布局、自动重启、自动复制以及自动扩展功能，对应用实施状况进行检查和自我修复（自愈能力非常强）。

2.商业角度

技术的更新必然会带动IT生产力的提高。Kubernetes出现后，各种PaaS云平台、创业公司和产品相继出现，各大云厂商相继推出基于Kubernetes的容器云产品。Kubernetes是趋势，自然能直接或者间接地带来很大的商业价值。

本节我们一起了解了Kubernetes的基本概念及发展现状，对Kubernetes整体架构组件有了一定的认识。Kubernetes是容器云平台，其平台涉及系统、网络、存储等各方面的知识，在下一节我们将详细介绍新手需要掌握的知识点。