一. kubernetes 是什么

1. 基础架构图

kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：

• 自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器
• 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整
• 服务发现：服务可以通过自动发现的形式找到它所依赖的服务
• 负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
• 版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
• 存储编排：可以根据容器自身的需求自动创建存储卷

在架构图中，我们把服务分为运行在工作节点上的服务和组成在集群级别控制板的服务
Kubernetes主要由以下几个核心组件组成：

 1. etcd 保存整个集群的状态
 2. apiserver 提供了资源的唯一入口，并提供认证、授权、访问控制、API注册和发现等
 3. controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
 4. scheduler 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上
 5. kubelet 负责维护容器的生命周期，同时也负责Volume(CVI)和网络（CNI）的管理
 6. Container runtime 负责镜像的管理以及Pod和容器的真正运行(CRI)
 7. kube-poxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡
 
除了核心组件，还有一些推荐的组件：

 8. kube-dns 负责为整个集群提供DNS服务
 9. Ingress Controller 为服务提供外网入口
 10. Heapster 提供资源监控
 11. Dashboard 提供 GUIFederation 提供跨可用区的集群
 12. Fluentd-elasticsearch 提供集群日志采集，存储与查询

通过举例说明上图各组件的作用及它们之间的联系

假设整个 kubernetes cluster(集群) 是一个集团，Control Plan 就是公司总部，Node 就是分公司，这其中 Controller manager 就是这个总公司的领导人（决策者）。

假设有一天 Controller manager （公司领导）计划开发游戏的项目，这个时候就会通知 api server （领导助理），api server 将得到的信息记录到 etcd （资料库），然后 api server （领导助理）再通知 scheduler （总经理），这个项目就由总经理决定分配给哪个分公司（node) 去做。

根据每个分公司（node）的具体情况，将项目分下去，然后通知对应分公司的 kubelet （经理），去负责管理这个项目，然后每个项目组又有一个 kube-proxy （经理助理），他们负责每个 node （分公司）和公司总部之间的联系，同时也负责每个 node （分公司）之间的联系。

假设有一天总公司领导想要知道游戏项目是在哪家分公司做的，或者其他 node （分公司）想要参观游戏项目，这个时候就可以通过 kube-proxy 获取这些信息。

2. kubernetes 各组件介绍

2.1 master 组件

Master

集群的"大脑"，Kubernetes里的Master指的是集群控制节点，负责整个集群的管理和控制，基本上接收Kubernetes的所有控制命令，master负责具体的执行过程。master相当于Kubernetes集群的大脑，非常重要（高可用部署建议用3台服务器）。一旦master宕机或者不可用，那么对集群内容器应用的管理都将失效。

运行在master上的组件：

1️⃣ Kubernetes API Server(kube-apiserver)

Kubernetes API，集群的统一入口，各组件协调者，以HTTP API提供接口服务，Kubernetes里所有资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。

2️⃣ Kubernetes Controller Ｍanager(kube-controller-manager)

Kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的大总管

3️⃣ kube-scheduler

负责资源调度（Pod调度）的进程

2.2 Node 组件

Node

具体"干活"的，工作负载节点，在Kubernetes集群中除了master节点外的机器被称为Node。每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他Node节点上。

Node节点可以在运行期间动态增加到Kubernetes集群中

运行在Node上的组件：

1️⃣ kubelet

kubelet是Master在Node节点上的Agent，负责与master节点的apiserver进行通信，管理本机运行容器的生命周期，负责Pod对应容器的创建、启停等任务。同时与Master密切协作，实现集群管理的基本功能，获取Node节点上Pod的运行状态等

2️⃣ kube-proxy

在Node节点上实现Pod网络代理，实现Kubernetes Service的通信和负载均衡机制的重要组件。

3️⃣ docker

Docker引擎，负责本机的容器的创建和管理工作

2.3 其他 kubernetes 概念

1️⃣ Etcd

Etcd是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为Etcd数据提供备份计划。Etcd是一个高可用的键值存储系统

2️⃣ Replication Controller

简称RC,RC是Kubernetes系统中的核心概念之一。它能够保证Pod持续运行，并且在任何时候都有指定数量的Pod副本，在此基础上提供一些高级特性，比如滚动升级和弹性伸缩

在我们定义了一个RC并将其提交到Kubernetes集群中后，Master上的Controller Manager组件就会得到通知，定期巡检系统中当前存活的目标Pod,并确保目标Pod实例的数量刚好等于此RC的期望值，如果有过多的Pod副本在运行，系统就会停掉一些Pod,过少则会再创建一些Pod。相比传统的IT环境，如果程序意外挂掉，需要手工重启，但是在k8s通过RC，就大大减少这些手工运维工作。

3️⃣ ReplicaSet

ReplicaSet 实现了 Pod 的多副本管理。使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，所以我们通常不需要直接使用 ReplicaSet。

1. Replication Controller由于与Kubernetes代码中的模块Replication Controller同名，并且“Replication Controller”无法准确表达它的本意，所以在Kubernetes1.2中，升级为另外一个新概念——Replica Set,官方解释为“下一代的RC”
2. 我们很少单独使用Replica Set,它主要被Deployment这个更高层的资源对象所使用。

4️⃣ Deployment

应用管理者，是用于部署应用的对象, Deployment 内部使用了 Replica Set 来实现的，我们可以把 Deployment 看做 RC 的一次升级。

创建 Deployment 对象后，master 会根据 Deployment 对象的配置文件去描述应用，应用名称，使用的镜像名称，需要几个实例，多少内存，多少CPU资源

5️⃣ Pod

Pod 是一组容器（当然也可以只有一个）容器本身就是一个小盒子了，Pod 相当于在容器上又包了一层小盒子。Pod 是 Kubernetes 的最小调度单位。

1. Pod 中的容器共享数据卷 volume
2. Pod 中的容器共享 IP 地址和端口

6️⃣ Service

Service 是一组逻辑 pod 的抽象，为一组pod提供统一入口，用户只需与 service 打交道，service 提供 DNS 解析名称，负责追踪pod 动态变化并更新转发表，通过负载均衡算法最终将流量转发到后端的 pod。Kubernetes 里的每个 Service 其实也可以理解为我们的微服务架构中的一个微服务。

1. Service 负责服务发现，找到每个 Pod ,不管 Deployment 的 Pod 有多少个，不管它是更新，销毁还是重建，Service 总是能发现并维护好它的ip列表。
2. kube-proxy 是 kubernetes 核心组件，运行在集群中每一个节点上，负责监控集群中 service、endpoint 变更，维护各个节点上的转发规则，是实现 servcie 功能的核心部件。

Service 对外提供多种入口：

• ClusterIP：Service 在集群内的唯一 ip 地址，虚拟的 IP，只能在 Kubernetes 集群里访问。通过 ClusterIP，负载均衡的访问后端的Pod
• NodeIP+NodePort：Service 会在集群的每个 Node 上都启动一个端口，通过 NodeIP:NodePort 访问后端的 Pod

7️⃣ Label

标签，一个Label是一个key=value的键值对。Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label

8️⃣ Volume

Volume(存储卷)Volume是Pod中能够被多个容器共享的磁盘目录。我们知道，默认情况下Docker容器中的数据都是非持久化的，在容器消亡后数据也会消失。因此Docker提供了Volume机制以便实现数据的持久化。Kubernetes中Volume的概念与Docker中的Volume类似，但不完全相同。

Kubernetes提供了非常丰富的Volume类型:

1. emptyDir：临时空间，Pod分配到Node时创建，无须指定宿主主机上对应的目录，在Kubernetes会自动分配当前Node的一个目录，当Pod被移除时，emptyDir中的数据也会永久删除。
2. hostPath：为Pod挂载宿主主机上的文件或目录。用于数据永久保存。在不同的Node上具有相同配置的Pod,可能会因为宿主机上的目录和文件不同而导致Volume上的目录和文件的访问结果不一致。
3. gcePersistentDisk：使用谷歌公有云提供的永久磁盘。数据永久保存。
4. NFS：NFS 是 Network File System 的缩写，即网络文件系统。Kubernetes 中通过简单地配置就可以挂载 NFS 到 Pod 中，而 NFS 中的数据是可以永久保存的，同时 NFS 支持同时写操作。k8s挂载NFS

Persistent Volume:简称PV,就是网盘，网络存储，不属于任何Node,但可以在每个Node上访问。

9️⃣ Namespace

命名空间，Namespace在很多情况下用于实现多租户的资源隔离。Namespace通过集群内部的资源对象"分配"到不同的Namespace中，形成逻辑上纷纷组的不同项目，便于不同的分组共享使用整个集群的资源的同时还能被分别管理。

🔟 ConfigMap

ConfigMap顾名思义，是用于保存配置数据的键值对，可以用来保存单个属性，也可以保存配置文件。就是为了让镜像 和 配置文件解耦，以便实现镜像的可移植性和可复用性，因为一个configMap其实就是一系列配置信息的集合，将来可直接注入到Pod中的容器使用，而注入方式有两种，一种将configMap做为存储卷，一种是将configMap通过env中configMapKeyRef注入到容器中

• 参考资料

https://blog.csdn.net/qq_21187515/article/details/101290820

https://blog.51cto.com/yylinfan/2112806