Kubernetes是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。Kubernetes是Google公司开源的容器编排与调度管理框架。

本章主要涉及到的知识点有：

l Kubernetes基础组件：了解KubernetesApiServer、Controller manager、Scheduler、Kubelet、Kube-proxy等基础组件。

l Kubernetes基础概念：了解Kubernetes Pod、Volume、Service、StatefulSet、API访问控制等对象资源 。

l Kubectl命令：了解kubectl命令的常规操作

注意：本章应用实例都是运行在现有有Kubernetes集群平台。

本节首先介绍Kubernetes集群中的节点主要分为两类：Master和Node。其中下面介绍的ApiServer、Controller manager、Scheduler基础组件是工作在Master节点上，Kubelet、Kube-proxy基础组件则是工作在Node节点上。

Kube-apiserver组件是负责Kubernetes的“资源组，资源版本，资源对象”以RESTful的风格的形式对外提供服务。该组件是Kubernetes系统集群中所有组件沟通的桥梁。下面在创建Pod资源对象时，所有Kubernetes组件都需要与kube-apiserver组件进行交互。

Kubernetes API Server的功能：

提供了REST API接口（包括认证授权、数据校验以及集群状态变更）。

提供其他模块之间的数据教育和通信枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）。

是资源配置控制的入口。

拥有完备的集群安全认证机制。

Kubernetes Pod资源对象创建流程如图2-1所示：

Kubernetes Pod资源对象创建流程：

（1）用户使用kubectl发起创建Pod请求。

（2）kubectl 向APIServer发起创建Pod请求。

（3）APIServer验证请求通过后持久化到Etcd集群中。

（4）Etcd集群返回资源对象是否存在，确定是够允许创建。

（5）APIServer基于Watch机制通知kube-sheduler。

（6）kube-sheduler根据调度算法为pod选取最佳节点，并通知APIServer。

（7）将Pod调度到的最佳节点持久化到Etcd集群里。

（8）APIServer通知最佳节点上的kubelet拉起Pod。

（9）最佳节点的kubelet与docker runtime交互创建容器。

（10）最佳节点上的kubelet向APIServer上报Pod的状态。

（11）APIServer将容器Pod状态持久化保存到Etcd集群中。

注意：这边的Pod资源对象将在下节详细阐述。

Controller Manager组件是Kubernetes系统的管理控制中心，它主要负责整个集群内Node、Pod的副本数、服务端点(EndPoint)、命名空间（NameSpace）、服务账号（ServiceAccount）、Token控制器的管理。

例如：当Node1宕机时，Controller Manager通过API Server接口实时监控整个集群的每个资源对象当前的状态，当发生故障导致整个系统状态发生变化时，Controller Manager组件会尝试修复。

Kube-controller-manager控制器包括：

1. Node Controller

Node Controller负载发现，管理和监控集群中的各个Node节点。Kubelet在启动的时候会向APIServer注册节点信息，并定时向APIServer发送节点信息。APIServer将节点信息持久化到Etcd集群。信息包括：节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本。

2. Replication Controller

Replication Controller与Deployment的主要职责都是为了保证Pod的数量/健康，在业

务高峰/低峰的时候，两者都可以通过调整Pod的数量来保证业务的合理资源匹配。同时，

配置相应的监控功能，或者两者相关联的Pod的整体资源使用状况，做到自动伸缩。两者在滚动升级的功能上也是通过逐步替换的策略，以保证整体系统的稳定性，当开始升级的时候发现Pod拉不起来，就能快速的发现并解决问题，从而避免问题的扩大。

Deployment继承了Replication Controller的全部功能，但是又具备了Replication Controller的特性：

事件和状态的查看：kubectl get deploy -n ***#查看**namespace下的deploy

kubectl describe deploy/*** -n *** #查看***namespace下的deploy的具体时间以及状态

回滚：升级Pod镜像或者相关参数的时候，可以操作镜像版本号来回滚。

多种升级方案：可以设置最大不可用的Pod数量，最小升级间隔时间。

3. Endpoints Controller

阐述到Endpoint就会讲到Service、Endpoint、Pod三者的关系：

Endpoint表示一个Service对应的所有Pod副本的访问地址（kubectl get ep -n **#可以查看到**命名空间下的ep信息），而Endpoints Controller负责生成和维护所有Endpoint对象的控制器，它负责监听Service与对应Pod副本的变化。

如果监测到Service被删除，则删除和该Service同名的Endpoint对象；

如果监测到新的Service被创建或修改，则根据该Service信息获取相关的Pod列表，然后创建或更新Service对应的Endpoint对象。

如果监测到Pod事件，则更新它对应的Service的Endpoints对象。

kube-scheduler组件是Kubernetes系统的核心组件之一，主要负责整个集群Pod资源对象的调度，根据内置或扩展的调度算法（预选与优选调度算法），将未调度的Pod资源对象调度到最优的Node(工作)节点上，从而更加合理，更加充分地利用集群的资源。

kube-scheduler内置调度的算法：

1. 预选调度算法

检查节点是否符合运行“待调度Pod资源对象”的条件，如果符合条件，则将其加入可用节点列表。

2. 优选调度算法

为每一个可用节点计算出一个最终分数，kube-scheduler调度器会将分数最高的节点作为最优运行“待调度Pod资源对象”的节点。

例如：资源越丰富、负载越小的Node节点评分越高也越容易被调度到。

注意：具体的策略以及实例会在第12章Kubernetes资源限制与扩容缩容这一章详解

Etcd是Kubernetes系统中最重要的数据中心，它保存着集群的所有数据。Etcd是一个高可用的key/value存储系统，主要用于配置中心和服务发现。

Etcd集群存储着Kubernetes系统的集群状态和元数据，其中包括所有Kubernetes资源对象信息，资源对象状态，集群节点信息等。

ETCD是一个高可用的key/value存储系统，与同类别的Zookeeper相比：

简单：支持curl方式api(http json)

安全：支持ssl clinet证书认证

高速：单实例1000/s写操作

可靠：使用Raft算法实现分布式

经典应用场景：Kubernetes集群存储

Kubernetes系统使用Etcd作为其集群的唯一存储，Etcd在生产环境中是以集群的形式来部署。

注意：Etcd集群高可用部署可见第5章Kubernetes高可用集群搭建。

2.1.5 Kubernetes组件之Kubelet

Kubelet组件是Kubernetes系统中重要的节点代理服务，它运行在每一个Node（工作）节点上，承担着周期性执行Pod创建、健康监测、上报Pod状态给其他Kubernetes系统组件等主要使命。

Kubelet核心功能模块：

PLEG:

PLEG全称为PodLifecycleEvent,Pleg会一直调用container runtime获取本节点的Pods，之后比较本模块中之前缓存的pods信息，对比最新的pods中的容器状态是否发生改变，当状态发生变化的时候，就会生成一个eventRecord事件，输出到eventChannel中，syncPod模块会接收到eventChannel中的event事件，来触发Pod同步处理过程，调用contaiener runtime来重建Pod，保证Pod工作正常。

cAdvisor:

cAdvisor集成在Kubelet中，起到收集本Node的节点和启动的容器的监控信息的作用，启动一个Http Server服务，对外接收RESTAPI请求，cAvisor模块提供了interface接口，可以通过interface接口获取到node节点信息，本地文件系统的状态等信息，该接口被imageManager、OOMWatcher、containerManager等使用。

ProbeManager:

探针管理，依赖于statusManager、livenessManager、containerRefManager,实现Pod的健康检查的功能。当前支持两种类型的探针：LivenessProbe（判断是否存活）和ReadinessProbe（判断是否启动完成）。

2.1.6 Kubernetes组件之Kube-proxy

kube-proxy是kubernetes系统中重要的代理服务，它运行在每一个Node(工作)节点上，承担着定义好service的请求转发到后端的Pod上。

kube-proxy支持三种工作模式：

UerSpace模式（如图2-2所示）：

这种模式，kube-proxy会监视Kubernetes Master节点对Service对象和Endpointes对象的添加和移除操作。对每个Service，它会在本地Node上打开一个端口（随机选择）。任何连接到“代理端口”的请求，都会被代理到Service的后端Pods中的某个上面取，具体使用哪个后端Pod.是由kube-proxy基于SessionAffinity（会话保持）来确定的。最后，它配置iptables规则，捕获到达该Service的clusterIP(虚拟IP)和Port的请求，并重定向到代理端口，代理端口再代理请求到后端Pod.

默认情况下，用户空间模式下的kube-proxy通过轮转算法选择后端。

Iptables模式（如图2-3所示）：

这种模式，kube-proxy会监视kubernetes Master节点对Service对象和Endpoints对象的添加和移除。对每个Service,它会配置iptables规则，从而捕获到达该Service的clusterIP和端口的请求，进而将请求重定向到Service的一组后端中的某个Pod上面。对每个Endpoints对象，它也会配置iptables规则，这个规则会选择一个后端组合。默认的策略是，kube-proxy在iptables模式下随机选择一个后端。使用iptables处理流量具有较低的系统开销，因为流量由Linux netfilter处理，而无需在用户空间和内核空间之间切换。这种方法比较可靠。

如果kube-proxy在iptables模式下运行，并且所选的第一Pod没有响应，则连接失败。

这与用户空间模式不同：在这种情况下，kube-proxy讲检测到与第一个Pod的连接已失败，并会自动使用其他后端Pod重试。您可以使用Pod探针验证后端Pod可以正常工作，以便iptables模式下的kube-proxy仅看到测试正常的后端。这样做意味着您避免将流量通过kube-proxy发送到已知失败的Pod.

IPVS模式（如图2-4所示）：

kubernetes自1.9-alpha版本引入了IPVS代理模式，自1.11版本开始成为默认设置。客户端IP请求时到达内核空间时，根据ipvs的规则直接分发到各pod上。kube-proxy会监视Kubernetes Service对象和Endpoints，调用netlink接口以相应地创建ipvs规则并定期与Kubernetes Service对象和Endpoints对象同步ipvs规则，以确保ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端Pod。与iptables类似，ipvs基于netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs为负载均衡算法提供了更多选项，例如：

rr：轮询调度

lc：最小连接数

dh：目标哈希

sh：源哈希

sed：最短期望延迟

nq：不排队调度

注意：启用IPVS内核模块可见第5章Kubernetes高可用集群搭建。

Pod是可以创建和管理Kubernetes系统的最小部署单元。一个Pod可以理解成Kubernetes集群中运行的一个进程。

Pod可以分享两种资源：

网络：每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部容器可以使用Localhost互相通信。

注意：详细的Pod网络阐述与原理可见第4章 kubernetes的网络基础与网络实现。

2.2.2 Kubernetes Volume资源对象

Volume是Kubernetes系统中对于存储类型的概述，其声明周期比Pod中运行的任何容器要持久，当pod整体被删除不存在时，Volume也将消失。

Kubernetes支持多种类型的Volume,Pod可以同时使用任意类型/数量的Volume。

内部实现中，一个Volume只是一个目录，目录中可能有一些数据，pod的容器可以访问这些数据。至于这个目录是如何产生的、支持它的介质、其中的数据内容是什么，这些都由使用的特定Volume类型来决定。要使用Volume，pod需要指定Volume的类型和内容（spec.volumes字段），和映射到容器的位置（spec.containers.volumeMounts字段）。

Volume 类型：emptyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、nfs等类型。

常用的有emptyDir、hostPath、nfs类型。下面分别列出这三种类型的资源对象的定义文件。

emptyDir示例：

01 apiVersion: v1

02 kind: Pod

03 metadata:

04 name: test-pd

05 spec:

06 containers:

07 - image: registry.cn-shanghai.aliyuncs.com/test-webserver#使用这个测试镜像

08 name: test-container

09 volumeMounts:

10 - mountPath: /cache #将test-container Pod容器里的/cache目录的文件映射

11 name: cache-volume#将映射的资源创建名称

12 volumes:

13 - name: cache-volume#引用资源对象名称

14 emptyDir: {} #指定资源类型这一类型数据将不被保留及Pod被销毁即数据则不被保留

hostPath示例：

01 apiVersion: v1

02 kind: Pod

03 metadata:

04 name: appname

05 spec:

06 containers:

07 - image: registry.cn-shanghai.aliyuncs.com/appname#使用这个测试镜像

08 name: appname

09 volumeMounts:

10 - mountPath: /opt/app/logs #将appnamePod容器里的/opt/app/logs目录的文件映射

11 name: k8slog-APPNAME#将映射的资源创建名称

12 volumes:

13 - name: k8slog-APPNAME#引用资源对象名称

14 hostPath: #指定资源类型为hostPath就会将Pod里目录为/opt/app/logs映射到/data/logs/

15 path: /data/logs/

NFS示例：

01 apiVersion: apps/v1

02 kind: Deployment

03 metadata:

04 name: test

05 namespace: ** #指定命名空间

06 labels:

07 app: test

08 spec:

09 replicas: 1

10 selector:

11 matchLabels:

12 app: test

13 template:

14 metadata:

15 labels:

16 app: test

17 spec:

18 containers:

19 - name: test

20 image: xxx

21 ports:

22 - containerPort: 8080 #容器里面用的是8080端口

23 env:

24 - name: SPRING_DATASOURCE_USERNAME

25 value: 'root'

26 volumeMounts:

27 - name: nfs-volume #设置的名称，和下面的name要一样的

28 mountPath: /home/uploads #需要挂载的目录

29 subPath: test #卷的子目录，也就是在nfs服务目录里生成这个子目录

30 volumes:

31 - name: nfs-volume #这个卷的名称，和上面的name要一样的

32 nfs: #nfs即网络文件系统，Kubernetes一般将数据持久化到nfs上，就是支持同时的写

33 server: 192.168.1.2 #nfs服务器的ip或者域名

34 path: "/data" #nfs服务配置的挂载目录

35 .....

以上讲了几种主流的kubernetes挂载存储模式，下面要引申出Kubernetes存储管理的概念。kubernetes提供了两个API资源：PersistentVolume(PV)和PersistentVolumeClaim（PVC）

PV是集群中由管理员的一段网络存储。它是集群中的资源，就像节点是集群资源一样。概括来讲，PV就是对Volumes存储的一个抽象API，或者说将其资源对象化。

而PVC是对PV的一个声明文件，他声明了请求pv资源的大小以及访问方式。

PV的类型也是跟Volume存储的类型是一样的，PV卷节点状态：

Available：资源违背使用，时刻准备着。

Bound:卷已经被绑定

Released: PVC被删除，卷处于释放状态，但是未被集群回收。

Faild:卷自动回收失败。

PVC示例：

01 apiVersion: v1

02 kind: PersistentVolume #声明是类型是pv资源对象

03 metadata:

04 name: pvtest1

05 labels:

06 name: pvtest1

07 spec:

08 nfs:

09 path: /data/volumes/v1 #卷的目录

10 server: nfs** #nfs服务器地址

11 accessModes: ["ReadWriteMany","ReadWriteOnce"] #声明访问模式

12 capacity:

13 storage: 2Gi #声明nfs容量

2.2.3 Kubernetes Service资源对象

Service资源对象是Kubernetes抽象出来的一种RESI对象，它是访问一组Pod的策略，下面给出最简单的示例：

有匹配的Service:

01 apiVersion: v1

02 kind: Service #定义好是Service资源

03 metadata:

04 name: my-service #定义这service 名称为my-service

05 spec:

06 selector:

07 app: MyApp #匹配pod组为MyApp

08 ports:

09 - protocol: TCP

10 port: 80

11 targetPort: 9376

无匹配的Service：

01 apiVersion: v1

02 kind: Service #定义好是Service资源

03 metadata:

04 name: my-service #定义这service 名称为my-service

05 spec:

06 ports:

07 - protocol: TCP

08 port: 80

09 targetPort: 9376

由于此服务没有匹配规则，所以不会自动创建EP对象，可以手动添加EP对象，将服务手动映射到运行该发的网络地址和端口：

01 apiVersion: v1

02 kind: Endpoints

03 metadata:

04 name: my-service

05 subsets:

06 - addresses:

07 - ip: 192.0.2.42

08 ports:

09 - port: 9376

2.2.4 Kubernetes StatefulSets资源对象

StatefulSet字面上的意思是有状态的集合，就是管理所有有状态服务的资源对象，如：mysql MongoDB集群。

StatefulSets示例：

01 apiVersion: v1

02 kind: Service

03 metadata:

04 name: nginx

05 labels:

06 app: nginx

07 spec:

08 ports:

09 - port: 80

10 name: web

11 clusterIP: None

12 selector:

13 app: nginx

14 apiVersion: apps/v1

15 kind: StatefulSety

16 metadata:

17 name: web

18 spec:

19 selector:

20 matchLabels:

21 app: nginx # 已经匹配到nginx的lables

22 serviceName: "nginx" #声明它属于哪个Headless Service.

23 replicas: 3 # pod 是三个

24 template:

25 metadata:

26 labels:

27 app: nginx # 已经匹配nginx labels

28 spec:

29 terminationGracePeriodSeconds: 10

30 containers:

31 - name: nginx

32 image: k8s.gcr.io/nginx-slim:0.8

33 ports:

34 - containerPort: 80

35 name: web

36 volumeMounts:

37 - name: www

38 mountPath: /usr/share/nginx/html

39 volumeClaimTemplates: #可看作pvc的模板

40 - metadata:

41 name: www

42 spec:

43 accessModes: [ "ReadWriteOnce" ]

44 storageClassName: "gluster-heketi" #存储类名，改为集群中已存在的

45 resources:

46 requests:

47 storage: 1Gi

为什么需要headless service无头服务？

在Deployment时，每一个Pod名称都是没有顺序的，因此Pod名称是无序的，但是Statefulset中要求必须是有序，每一个pod不能被随意取代，pod重建后pod名称还是一样的。而pod IP是变化的所以只能用Pod名称来识别。pod名称是pod唯一性的标识，必须持久稳定有效。这个时候要用到无头服务，它可以给每个Pod一个唯一的名称。

对于有状态的副本集都会用到持久存储，对于分布系统来讲，它的最大特点是数据是不一样的，所以各个节点不能使用同一存储卷，每个节点有自己的专用存储，数据是相同的，因为是基于模板来的,而statefulset中每个Pod都要自已的专有存储卷，所以statefulset的存储卷就不能再用Pod模板来创建了，于是statefulSet使用volumeClaimTemplate，称为卷申请模板，它会为每个Pod生成不同的pvc，并绑定pv， 从而实现各pod有专用存储。这就是为什么要用volumeClaimTemplate的原因。

2.2.5 Kubernetes API访问控制

Kubernetes API访问的方式有两种：kubectl命令行和client-go。

kubectl在维护Kubernetes系统集群时，kubectl是最常见的工具之一。kubectl主要的工作就是向Kubeernetes API Server发起请求，操作kubernetes集群的资源，从而控制集群。

client-go是从kubernetes的代码中单独抽离出来的包，并作为官方提供的GO语言的客户端发挥作用。在大部分基于Kubernetes做二次开发的程序中，建议通过client-go来实现与Kubernetes APIServer的交互过程。其实Kubernetes的核心组件（kube-scheduler、kube-controller-manager等）都通过client-go与Kubeernetes API Server进行交互。

注意：详细的client-go 请见第15章Kubernetes源码分析。

Kubernetes API访问控制提供了3中安全权限控制：

q 认证：针对请求的认证，确认是否具有访问kubernetes集群的权限。

q 授权：针对资源的授权，确认是否对资源具有相关权限。

q 准入控制器：在认证和授权后，对象被持久化之前，拦截kube-apiserver的请求，拦截后的请求进入准入控制器中处理，对请求的资源进行自定义（校验，修改或拒绝）等操作。

Kubernetes在开启HTTPS服务后，所有的请求都需要经过认证。kube-apiserver支持多种认证机制，当客户端发起一个请求，经过认证阶段是，只要有一个认证通过就认证成功。认证成功后就会进入授权验证，如果认证失败就会返回http401状态码（一般是在系统日志里面可以查询到）。

Kube-apiserver提供了9中认证机制：Basic auth（静态密码文件）、X509 ClientCA(客户端证书认证)、TokenAuth（静态token文件）、Bootstrap token、Anonymous(匿名)、Webhook token、ServiceAccout、Request header。

kube-apiserver目前提供了6种授权机制：

q AlwaysAllow:允许所有请求。结合其他的授权方式可以看做为黑名单机制。

q AlwayDeny:阻止所有请求。结合其他的授权方式可以看做为白名单机制。

q ABAC:基于属性的访问控制。

q Webhook:基于Webhook的一种HTTP协议回调，可进行远程授权管理。

q RBAC:基于角色的访问控制。K8s集群当中主要的就是这种基于角色的访问控制。

q Node:节点授权，专门授权给Kubelet发出的API请求。

2.3.1 Kubectl概述

你可以使用kubectl命令行工具管理Kubernetes集群。Kubectl在$HOME/.kube目录中查找一个名为config的配置文件。你可以通过设置KUBECONFLG环境变量或设置--kubeconfig参数来指定其它kubeconfig文件。

2.3.2 Kubectl常用命令详解

Kubectl常用命令大致可以分为下面几大类（如图2-5 kubectl常用命令分类所示）

声明式资源管理：

Kubectl apply -f deploy-goweb.yaml# -f参数后面跟yaml/json这样的资源配置文件

命令式资源管理：

Kubectl create deployment my-app --images=busybox #创建一个名为my-app镜像使用busybox的Pod

kubectl expose svc nginx --port=80 --target-port=8000# 创建个名为nginx的svc

Kubectl scale --replicas=3 -f foo.yaml #将foo.yaml中描述的对象扩展为3个

Kubectl annotate pods foo description =”my test” #给foo的Pod组添加description=”my test”的备注

Kubectl label --overwrite pods foo status=unhealthy #增加status=unhealthy标签，如有则覆盖

Kubectl delete -f ***.yaml #删除***配置文件对应的资源对象

Kubectl delete pod,service baz foo -n *** #删除***命名空间下名字为baz/foo等Pod和service

Kubectl delete pods,service -l name=mytest -n *** #删除***命名空间下标签为mytest Pod组和service

Kubectl delete pod foo --grace-period=o --force#强制删除pod,在各种原因pod一直terminate不掉的时候

资源查看：

Kubectl get service -n ** #列出**命名空间下所有的service资源

Kubectl get pod --all-namespaces #列出集群中所有命名空间下面的所有Pod

Kubectl get pod -n *** -o wide #列出***命名空间下的pod 所在node节点以及pod的ip

Kubectl describe nodes node1#查看节点node1的详细信息

Kubectl describe pod test-pod -n ** #查看**命名空间下的test-pod的详细信息

容器管理：

Kubectl logs -f test-pod -n ** #跟踪查看**命名空间下的test-pod的日志

Kubectl logs test-pod -- since-time=2021-02-18T15:00:00Z#输出指定时间戳日志

Kubectl logs test-pod --since=1h #指定时间段输出日志，单位s/m/h

Kubectl exec test-pod ls -n **#对**命名空间下的test-pod执行ls命令

Kubectl exec -it nginx-74f7d876cd-czn7d bash #进入pod的shell

Kubectl cp /tmp/test_dir test-pod:/tmp/test_dir #拷贝本地文件到Pod里

Kubectl cp test-pod:/tmp/foo /tmp/bar /tmp -n ** #指定的命名空间下Pod的/tmp/foo文件拷贝到/tmp

集群管理：

Kubectl cluster-info #查看master和集群服务的地址

Kubectl cluster-info dump #查看集群详细日志

Kubectl version #查看Kubernetes集群和客户端版本

Kubectl cordon node1#标记node1为unschedulable，禁止Pod调度到node1上。注意现在跑在这个节点上的Pod还是在这个节点上继续运行，不会被调度

Kubectl uncordon node1#与cordon相反，标记node1允许被调度

Kubectl drain node1--ignore-daemonsets --force ==delete-local-data#将node1上面的Pod平缓过度到其他node节点上，同时标记node1为unschedulable（忽略daemonset 部署的pod）