Kubernetes 有如下几个核心的功能：

服务的发现与负载的均衡；

容器的自动装箱，我们也会把它叫做 scheduling，就是“调度”，把一个容器放到一个集群的某一个机器上，Kubernetes 会帮助我们去做存储的编排，让存储的声明周期与容器的生命周期能有一个连接；

Kubernetes 会帮助我们去做自动化的容器的恢复。在一个集群中，经常会出现宿主机的问题或者说是 OS 的问题，导致容器本身的不可用，Kubernetes 会自动地对这些不可用的容器进行恢复；

Kubernetes 会帮助我们去做应用的自动发布与应用的回滚，以及与应用相关的配置密文的管理；

对于 job 类型任务，Kubernetes 可以去做批量的执行；

为了让这个集群、这个应用更富有弹性，Kubernetes 也支持水平的伸缩。

Kubernetes 特点

可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

可扩展: 模块化, 插件化, 可挂载, 可组合

自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

Kubernetes 的架构

KubernetesKubernetes 是典型的中控分布式架构（Central control distributed architecture）Master 作为中央的管控节点，会去与 Node 进行一个连接。下面分别列举 Master、Node 的组件。所有 UI 的、clients、这些 user 侧的组件，只会和 Master 进行连接，把希望的状态或者想执行的命令下发给 Master，Master 会把这些命令或者状态下发给相应的节点，进行最终的执行。

Kubernetes 的架构：Master

Master组件提供集群的管理控制中心，可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器。

etcd：是一个分布式的一个存储系统，提供高可用性、严格数据一致性的非关系型数据库，API Server 中所需要的这些原信息都被放置在 etcd 中，etcd 本身是一个高可用系统，通过 etcd 保证整个 Kubernetes 的 Master 组件的高可用性。具有共享配置、服务发现、分布式等特点。常被用于构建服务发现系统。

kube-apiserver：任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行，依靠 CA 认证体系提供身份认证、授权、鉴权等访问控制功能，统称 3A（Authenkube-apiservertication、Authorization、Admission）Kubernetes 中所有的组件都会和 API Server 进行连接，组件与组件之间一般不进行独立的连接，都依赖于 API Server 进行消息的传送；

kube-scheduler：资源调度器，按照预设的策略将 Pod 调度到目的（最佳）Node 上启动。

Controller：是控制器，它用来完成对集群状态的一些管理。比如刚刚我们提到的两个例子之中，第一个自动对容器进行修复、第二个自动进行水平扩张，都是由 Kubernetes 中的 Controller 来进行完成的；

Controller又分为运行管理控制器（kube-controller-manager）和云控制器管理器负责（cloud-controller-manager）与底层云提供商的平台交互

• kube-controller-manager：运行管理控制器、中央控制管理器，Cluster 的核心管理模块，负责整个 Cluster 的 “运”（e.g. 故障检测、弹性扩展、滚动更新，etc.）kube-controller-manager控制器包括：

1. 节点（Node）控制器。
2. 副本（Replication）控制器：负责维护系统中每个副本中的pod。
3. 端点（Endpoints）控制器：填充Endpoints对象（即连接Services＆Pods）。
4. Service Account和Token控制器：为新的Namespace 创建默认帐户访问API Token。

• cloud-controller-manager：云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的，目前还是Alpha的功能。

  云控制器管理器仅运行云提供商特定的（controller loops）控制器循环。可以通过将--cloud-provider flag设置为external启动kube-controller-manager ，来禁用控制器循环。cloud-controller-manager 具体功能：

1. 节点（Node）控制器
2. 路由（Route）控制器
3. Service控制器
4. 卷（Volume）控制器

插件 addons：插件（addon）是实现集群pod和Services功能的 。Pod由Deployments，ReplicationController等进行管理。Namespace 插件对象是在kube-system Namespace中创建。

DNS：虽然不严格要求使用插件，但Kubernetes集群都应该具有集群 DNS。

群集 DNS是一个DNS服务器，能够为 Kubernetes services提供 DNS记录。

由Kubernetes启动的容器自动将这个DNS服务器包含在他们的DNS searches中。

Kubernetes 的架构：Node

Kubernetes 的 Node 是真正运行业务负载的，每个业务负载会以 Pod 的形式运行。等一下我会介绍一下 Pod 的概念。一个 Pod 中运行的一个或者多个容器，真正去运行这些 Pod 的组件的是叫做 kubelet，也就是 Node 上最为关键的组件，它通过 API Server 接收到所需要 Pod 运行的状态，然后提交到我们下面画的这个 Container Runtime 组件中。

kubelet：维护 Container 的生命周期，同时也负责存储（CSI）和网络（CNI）的管理。

kube-proxy：为 Service 提供 Cluster 内部的服务发现和负载均衡功能。

Container runtime：负责镜像管理以及 Pod 和 Container 的运行（CRI）

docker：docker用于运行容器。

supervisord：supervisord是一个轻量级的监控系统，用于保障kubelet和docker运行。

Kubernetes 的核心概念与它的 API

第一个概念：Pod

Pod 是 Kubernetes 的一个最小调度以及资源单元。用户可以通过 Kubernetes 的 Pod API 生产一个 Pod，让 Kubernetes 对这个 Pod 进行调度，也就是把它放在某一个 Kubernetes 管理的节点上运行起来。一个 Pod 简单来说是对一组容器的抽象，它里面会包含一个或多个容器。

在 Pod 里面，我们也可以去定义容器所需要运行的方式。比如说运行容器的 Command，以及运行容器的环境变量等等。Pod 这个抽象也给这些容器提供了一个共享的运行环境，它们会共享同一个网络环境，这些容器可以用 localhost 来进行直接的连接。而 Pod 与 Pod 之间，是互相有 isolation 隔离的。

为什么要引入 Pod 逻辑对象？

可管理性：有些容器天生就是需要紧密联系，一起工作的。例如：微服务中的 Side Car 模式，Pod 中的一个 ContainerA 提供业务，另一个 ContainerB 专门负责对 ContainerA 进行收集、监控日志和流量信息；又例如：ContainerA 作为 File Puller 定期从外部拉取最新的文件，将其存放到共享 Volume 中，ContainerB 作为 Web Server 直接从 Volume 读取文件，两个 Containers 紧密合作；Pod 将 Containers 封装到一个部署单元中，k8s 以 Pod 为最小单位进行调度、扩展、资源分配、管理生命周期。

通信和资源共享：Pod 中的所有 Containers 使用同一个 network namespace，即 Containers 具有相同的 IP 地址和 Port 空间，它们互相之间可以直接用 localhost 进行通信。同样的，这些容器也会共享存储，当 k8s 挂载 Volume 到 Pod，本质上是将 Volume 挂载到 Pod 中的每一个 Container。

第二个概念：Volume

Volume 就是卷的概念，它是用来管理 Kubernetes 存储的，是用来声明在 Pod 中的容器可以访问文件目录的，一个卷可以被挂载在 Pod 中一个或者多个容器的指定路径下面。

而 Volume 本身是一个抽象的概念，一个 Volume 可以去支持多种的后端的存储。比如说 Kubernetes 的 Volume 就支持了很多存储插件，它可以支持本地的存储，可以支持分布式的存储，比如说像 ceph，GlusterFS ；它也可以支持云存储，比如说阿里云上的云盘、AWS 上的云盘、Google 上的云盘等等。

第三个概念：Deployment

Deployment 是在 Pod 这个抽象上更为上层的一个抽象，它可以定义一组 Pod 的副本数目、以及这个 Pod 的版本。一般大家用 Deployment 这个抽象来做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元。

Kubernetes 是通过 Controller，也就是我们刚才提到的控制器去维护 Deployment 中 Pod 的数目，它也会去帮助 Deployment 自动恢复失败的 Pod。

比如说我可以定义一个 Deployment，这个 Deployment 里面需要两个 Pod，当一个 Pod 失败的时候，控制器就会监测到，它重新把 Deployment 中的 Pod 数目从一个恢复到两个，通过再去新生成一个 Pod。通过控制器，我们也会帮助完成发布的策略。比如说进行滚动升级，进行重新生成的升级，或者进行版本的回滚。

第四个概念：Service

Service 提供了一个或者多个 Pod 实例的稳定访问地址。

比如在上面的例子中，我们看到：一个 Deployment 可能有两个甚至更多个完全相同的 Pod。对于一个外部的用户来讲，访问哪个 Pod 其实都是一样的，所以它希望做一次负载均衡，在做负载均衡的同时，我只想访问某一个固定的 VIP，也就是 Virtual IP 地址，而不希望得知每一个具体的 Pod 的 IP 地址。

我们刚才提到，这个 pod 本身可能 terminal go（终止），如果一个 Pod 失败了，可能会换成另外一个新的。对一个外部用户来讲，提供了多个具体的 Pod 地址，这个用户要不停地去更新 Pod 地址，当这个 Pod 再失败重启之后，我们希望有一个抽象，把所有 Pod 的访问能力抽象成一个第三方的一个 IP 地址，实现这个的 Kubernetes 的抽象就叫 Service。

实现 Service 有多种方式，Kubernetes 支持 Cluster IP，上面我们讲过的 kuber-proxy 的组网，它也支持 nodePort、 LoadBalancer 等其他的一些访问的能力。

第五个概念：Namespace

Namespace 是用来做一个集群内部的逻辑隔离的，它包括鉴权、资源管理等。Kubernetes 的每个资源，比如刚才讲的 Pod、Deployment、Service 都属于一个 Namespace，同一个 Namespace 中的资源需要命名的唯一性，不同的 Namespace 中的资源可以重名。

Namespace 一个用例，比如像在阿里巴巴，我们内部会有很多个 business units，在每一个 business units 之间，希望有一个视图上的隔离，并且在鉴权上也不一样，在 cuda 上面也不一样，我们就会用 Namespace 来去给每一个 BU 提供一个他所看到的这么一个看到的隔离的机制

Kubernetes 的术语词典

Controller：Pod 的控制器，k8s 提供了多种控制器来对 Pod 进行管理，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，以满足不同的业务需求。

Deployment：负责 Pod 的部署，并维护部署拓扑（e.g. 创建、监控、自修复 Pod），保证 Pod 按照期望的状态运行。

ReplicaSet：负责 Pod 的多副本管理，使用 Deployment 的同时会自动创建 ReplicaSet，也就是说 Deployment 实际是通过 ReplicaSet 来管理 Pod 多副本的，通常不需要直接使用 ReplicaSet。

DaemonSet：用于每个 Nodes 都运行且只运行一个 Pod 副本的场景。通常用于运行 daemon 服务进程。

StatefuleSet：保证 Pod 的所有副本的名称在其整个生命周期中是不变的。一般的，当 Pod 因为故障需要删除并重新启动时，它的名称是会发生变化的。StatefuleSet 还可以保证 Pod 的副本按照固定的顺序启动、更新或者删除。

Job：特殊的任务控制器，用于 App 运行结束就可以立即删除 Pod 的场景。

Service：用于定义外界访问一组特定 Pod 的方式。是一个北向提供外部访问方式（e.g. ClusterIP、NodePort、LoadBalancer），南向通过 Label 和 Selectors 来匹配 Pods 的 逻辑对象，还可以为 Pods 提供了负载均衡。

Namespace：k8s 实现多租户的方式，将一个物理 Cluster 从逻辑上划分成多个虚拟 Cluster，每个虚拟 Cluster 就是一个 Namespace，不同 Namespace 间的资源完全隔离。

• default Namespace：默认的 Namespace，如果创建任意资源时 不特别指定，就会将资源放到这个 namespace 下。
• kube-system Namespace：k8s 自己创建的系统资源将放到这个 namespace 下

Cluster： 是一个被 k8s 协调的高可用集群，作为 k8s 集群的根操作对象，将多台计算节点（Master/Node）连接成一个工作整体，是计算、存储和网络资源的集合。

Master：下属于 Cluster，充当集群中的中央控制角色，负责管理、协调集群中的所有活动（e.g. scheduler app、维护 app 状态机、 弹性扩展 apps、发布 app 更新 etc.）。

Node：下属于 Cluster，作为集群中的 Worker，受 Master 指使。是 Containers 及其 runtime 引擎的允许载体。

Pod： 是一个抽象而统一的概念，屏蔽底层异构 Container Runtime 技术实现。k8s 的最小工作单元，是 Containers 的 “Container”。

Container：下属于 Pod，是真正意义上的、常规的容器。

Kubernetes 的 API

下面我们介绍一下 Kubernetes 的 API 的基础知识。从 high-level 上看，Kubernetes API 是由 HTTP+JSON 组成的：用户访问的方式是 HTTP，访问的 API 中 content 的内容是 JSON 格式的。

Kubernetes 的 kubectl 也就是 command tool，Kubernetes UI，或者有时候用 curl，直接与 Kubernetes 进行沟通，都是使用 HTTP + JSON 这种形式。

下面有个例子：比如说，对于这个 Pod 类型的资源，它的 HTTP 访问的路径，就是 API，然后是 apiVesion: V1, 之后是相应的 Namespaces，以及 Pods 资源，最终是 Podname，也就是 Pod 的名字。

如果我们去提交一个 Pod，或者 get 一个 Pod 的时候，它的 content 内容都是用 JSON 或者是 YAML 表达的。上图中有个 yaml 的例子，在这个 yaml file 中，对 Pod 资源的描述也分为几个部分。

第一个部分，一般来讲会是 API 的 version。比如在这个例子中是 V1，它也会描述我在操作哪个资源；比如说我的 kind 如果是 pod，在 Metadata 中，就写上这个 Pod 的名字；比如说 nginx，我们也会给它打一些 label，我们等下会讲到 label 的概念。在 Metadata 中，有时候也会去写 annotation，也就是对资源的额外的一些用户层次的描述。

比较重要的一个部分叫做 Spec，Spec 也就是我们希望 Pod 达到的一个预期的状态。比如说它内部需要有哪些 container 被运行；比如说这里面有一个 nginx 的 container，它的 image 是什么？它暴露的 port 是什么？

当我们从 Kubernetes API 中去获取这个资源的时候，一般来讲在 Spec 下面会有一个项目叫 status，它表达了这个资源当前的状态；比如说一个 Pod 的状态可能是正在被调度、或者是已经 running、或者是已经被 terminates，就是被执行完毕了。

刚刚在 API 之中，我们讲了一个比较有意思的 metadata 叫做“label”，这个 label 可以是一组 KeyValuePair。

比如下图的第一个 pod 中，label 就可能是一个 color 等于 red，即它的颜色是红颜色。当然你也可以加其他 label，比如说 size: big 就是大小，定义为大的，它可以是一组 label。

这些 label 是可以被 selector，也就是选择器所查询的。这个能力实际上跟我们的 sql 类型的 select 语句是非常相似的，比如下图中的三个 Pod 资源中，我们就可以进行 select。name color 等于 red，就是它的颜色是红色的，我们也可以看到，只有两个被选中了，因为只有他们的 label 是红色的，另外一个 label 中写的 color 等于 yellow，也就是它的颜色是黄色，是不会被选中的。

 

通过 label，kubernetes 的 API 层就可以对这些资源进行一个筛选，那这些筛选也是 kubernetes 对资源的集合所表达默认的一种方式。

例如说，我们刚刚介绍的 Deployment，它可能是代表一组的 Pod，它是一组 Pod 的抽象，一组 Pod 就是通过 label selector 来表达的。当然我们刚才讲到说 service 对应的一组 Pod，就是一个 service 要对应一个或者多个的 Pod，来对它们进行统一的访问，这个描述也是通过 label selector 来进行 select 选取的一组 Pod。

所以可以看到 label 是一个非常核心的 kubernetes API 的概念，我们在接下来的课程中也会着重地去讲解和介绍 label 这个概念，以及如何更好地去使用它。

五、以一个 demo 结尾

最后一部分，我想以一个例子来结束，让大家跟我一起来尝试一个 kubernetes，在尝试 Kubernetes 之前，我希望大家能在本机上安装一下 Kubernetes，安装一个 Kubernetes 沙箱环境。

安装这个沙箱环境，主要有三个步骤：

• 首先需要安装一个虚拟机，来在虚拟机中启动 Kubernetes。我们会推荐大家利用 virtualbox 来作为虚拟机的运行环境；

安装 VirtualBox： https://www.virtualbox.org/wiki/Downloads

• 其次我们需要在虚拟机中启动 Kubernetes，Kubernetes 有一个非常有意思的项目，叫 minikube，也就是启动一个最小的 local 的 Kubernetes 的一个环境。

minikube 我们推荐使用下面写到的阿里云的版本，它和官方 minikube 的主要区别就是把 minikube 中所需要的 Google 上的依赖换成国内访问比较快的一些镜像，这样就方便了大家的安装工作；

安装 MiniKube（中国版）: https://yq.aliyun.com/articles/221687

• 最后在安装完 virtualbox 和 minikube 之后，大家可以对 minikube 进行启动，也就是下面这个命令。

启动命令：minikube start —vm-driver virtualbox

如果大家不是 Mac 系统，其他操作系统请访问下面这个链接，查看其它操作系统如何安装 minikube 沙箱环境。

https://kubernetes.io/docs/tasks/tools/install-minikube/

当大家安装好之后，我会跟大家一起做一个例子，来做三件事情：

1. 提交一个 nginx deployment；

kubectl apply  -f  https://k8s.io/examples/application/deployment.yaml

1. 升级 nginx deployment；

kubectl apply -f  https://k8s.io/examples/application/deployment-update.yaml

1. 扩容 nginx deployment。

kubectl apply -f  https://k8s.io/examples/application/deployment-update.yaml

第一步，我们提交一个 nginx 的 Deployment，然后对这个 Deployment 进行一次版本升级，也就是改变它中间 Pod 的版本。最后我们也会尝试对 nginx 进行一次扩容，进行一次水平的伸缩，下面就让大家一起跟我来尝试这三个操作吧。

首先，我们先看一下 minikube 的 status，可以看到 kubelet master 和 kubectl 都是配置好的。

 

下一步我们利用 kubectl 来看一下这个集群中节选的状态，可以看到这个master 的节点已经是running状态：

我们就以这个为节点，下面我们尝试去看一下现在集群中 Deployment 这个资源：

可以看到集群中没有任何的 Deployment，我们可以利用 watch 这个语义去看集群中 Deployment 这个资源的变化情况。

下面我们去做刚才想要的三个操作：第一个操作是去创建一个 Deployment。可以看到下面第一个图，这是一个 API 的 content，它的 kind 是 Deployment，name 是 nginx-deployment, 有图中它的 replicas 数目是2，它的镜像版本是 1.7.9。

![](https://img2018.cnblogs.com/blog/1411156/201909/1411156-20190919143310619-331641224.png)![](https://img2018.cnblogs.com/blog/1411156/201909/1411156-20190919143311058-1668787295.png)

我们下面还是回到 kubectl 这个 commnd 来执行这次 Deployment 的真正的操作。我们可以看到一个简单的操作，就会去让 Deployment 不停地生成副本。

Deployment 副本数目是 2 个，下面也可以 describe 一下现在的 Deployment 的状态。我们知道之前是没有这个 Deployment 的，现在我们去 describe 这个 nginx-deployment。

下图中可以看到：有一个 nginx-deployment 已经被生成了，它的 replicas 数目也是我们想要的、selector 也是我们想要的、它的 image 的版本也是 1.7.9。还可以看到，里面的 deployment-controller 这种版本控制器也是在管理它的生成。

下面我们去升级这个 Deployment 版本，首先下载另外一个 yaml 文件 deployment-update.yaml，可以看到这里面的 image 本身的版本号从 1.7.9 升级到 1.8。

接下来我们重新 apply 新的 deployment-update 这个 yaml 文件。

可以看到，在另一边的屏幕上显示出了这个 Deployment 升级的一些操作，最终它的 up-to-date 值从 0 变成了 2，也就是说所有的容器都是最新版本的，所有的 Pod 都是最新版本的。我们也可以 discribe 具体去看一下是不是所有 Pod 的版本都被更新了，可以看到这个 image 的版本由 1.7.9 真正更新到了 1.8。

最后，我们也可以看到  controller 又执行了几次新的操作，这个控制器维护了整个 Deployment 和 Pod 状态。

最后我们演示一下给 Deployment 做水平扩张，下载另一个 yaml 文件 deployment-scale.yaml，这里面的 replicas 数目已经从 2 改成了 4。

 

回到最开始的窗口，用 kubectl 去 apply 这个新的 deployment-scale.yaml 文件，在另外一个窗口上可以看到，当我们执行了 deployment-scale 操作之后，它的容器 Pod 数目从 2 变成了 4。我们可以再一次 describ 一下当前集群中的 deployment 的情况，可以看到它的 replicas 的数目从 2 变到了 4，同时也可以看到 controller 又做了几次新的操作，这个 scale up 成功了。

 

最后，让我们利用 delete 操作把我们刚才生成的 Deployment 给删除掉。kubectl delete deployment，也是刚才我们本身的 deployment name，当我们把它删除掉之后，我们今天所有的操作就完成了。

我们再去重新 get 这个 Deployment，也会显示这个资源不再存在，这个集群又回到了最开始干净的状态。