Kubernetes(K8S)之学废了（六）:Pod控制器详解

Pod控制器详解

---

一、pod简介

在kubernetes中，按照pod的创建方式可以将其分为两类：

自主式pod： kubernetes直接创建出来的pod，这种podi除后就没有了，也不会重建
控制器创建的pod：通过控制器创建的pod，这种pod删除了之后还会自动重建

什么是Pod控制器

Pod控制器是管理pod的中间层，使用了pod控制器之后，我们只需要告诉pod控制器，想要多少个什么样的pod就可以了。它就会创建出满足条件的pod并确保每—个pod处于用户期望的状态，如果pod在运行中出现故障，控制器会基于指定策略重启动或者重建pod。

kubernetes中，有很多类型的pod控制器，每种都有自己的适合的场景，常见的有下面这些：

• ReplicationController：比较原始的pod控制器，已经被废弃，由Replicaset替代
• Replicaset：保证指定数量的pod运行，并支持pod数量变更，镜像版本变更
• Deployment：通过控制Replicaset来控制pod，并支持滚动升级、版本回退
• Horizontal Pod Autoscaler：可以根据集群负载自动调整Pod的数量，实现削峰填谷
• Daemonset：在集群中的指定Node上都运行一个副本，一般用于守护进程类的任务
• Job：它创建出来的pod只要完成任务就立即退出，用于执行一次性任务
• Cronjob：它创建的pod会周期性的执行，用于执行周期性任务
• Statefulset:用于管理有状态应用

二、 Replicaset(rs)

Replicaset的主要作用是保证一定数量的pod能够正常运行，它会持续监听这些pod的运行状态， 一旦pod发生 故障，就会重启或重建。同时它还支持对pod数量的扩縮容和版本镜像的升级。

配置文件编写

pc-replicaset.yml

apiVersion: apps/v1 
kind: ReplicaSet 
metadata: 
	name: pc-replicaset 
	namespace: dev 
spec: 
	replicas: 3 
	selector: 
		matchlabels: 
			app: nginx-pod 
	template: 
		metadata: 
			labels: 
				app: nginx-pod 
		spec: 
			containers: 
				name: nginx 
				image: nginx:1.17.1

#创建rs
kubectl create -f pc-replicaset.yml
#查看rs
kubectl get rs pc-replicaset -n dev -o wide

扩缩容

方法一：edit

方法二：scale

镜像版本的升降级

方法一：edit
也是可以直接使用edit命令编辑，修改镜像包的版本号 后保存就可以了

方法二：set

kubectl set image rs pc-replicaset nginx=nginx:1.17.2 -n dev
# 注意第一个nginx是容器名

删除Replicaset

方法一：会先将replicas数量调整为0，然后删除pod,最后再删除Replicaset

kubectl delete rs pc-replicaset -n dev

方法二：首选

kubectl delete -f  pc-replicaset.yml

三、Deployment(Deploy)

为了更好的解决服务编排的问题，kubernetes在V1.2版本开始，引l入了Deployment控制器。值得一提的是， 这种控制器并不直接管理pod，而是通过管理Replicaset来间接管理Pod，即：Deployment管理ReplicaSet, Replicaset管理Pod。 所以DeploymentttReplicaset功能更加强大。

Deployment主要功能有下面几个：

• 支持Replicaset的所有功能
• 支持发布的停止、继续
• 支持版本滚动更新和版本回退

Deployment的资源清单文件：

编写yml文件，创建deployment

apiVersion: apps/v1 
kind: Deployment 
metadata: 
	name: pc-deployment 
	namespace: dev 
spec: 
	replicas: 3 
	selector: 
		matchlabels: 
			app: nginx-pod 
template: 
	metadata: 
	labels: 
		app: nginx-pod 
	spec: 
		containers: 
		  - name: nginx 
			image: nginx:1.17.1

创建deploymet,查看deploy

UP-TO-DATE: 最新版本的pod数量
AVAILABEL:当前可用的pod数量
kubectl create -f pc-deployment.yml --record=true 记录每次版本的变化

查看rs,会发现rs名字在depoly名字后面加了随机数

kubectl get rs -n dev -o wide

查看pod,会发现 ，pod名字是在rs名字后面跟了随机串

kubectl get pods -n dev -o wide

扩缩容

#方法一：scale
kubectl scale deploy pc-deployment --repicas=5 -n dev
#方法二：edit
kubectl edit deploy pc-deployment -n dev

升级策略

镜像更新 Deployment支持两种镜像更新的策略：重建更新 和 滚动更新(默认），可以通过 strategy 选项进行配置

strategy：指定新的Pod替换旧的Pod的策略，支持两个属性：
    type：指定策略类型，支持两种策略
            Recreate：在创建出新的Pod之前会先杀掉所有己存在的Pod
            RollingUpdate：滚动更新，就是杀死一部分，就启动一部分，在更新过程中，存在两个版本Pod
    rollingupdate：当type为Rollingupdatee生效，用于为Rollingupdate设置参数，支持两个属性：
             maxUnavailable：用来指定在升级过程中不可用Pod的最大数量，默认为25%。
             maxSurge：用来指定在升级过程中可以超过期望的Pod的最大数量，默认为25%。

重建更新

策略一：重建更新
1.编辑pc-deployment.yaml，在spec节点下添加更新策略

apiVersion: apps/v1 
kind: Deployment 
metadata: 
	name: pc-deployment 
	namespace: dev 
spec: 
	strategy：#策略
		type：Recreate #重建更新策略
	replicas: 3 
	selector: 
		matchlabels: 
			app: nginx-pod 
template: 
	metadata: 
	labels: 
		app: nginx-pod 
	spec: 
		containers: 
		  - name: nginx 
			image: nginx:1.17.1

2.让修改的文件生效

kubectl apply -f pc-deployment.yaml

3.升级nginx版本

kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev

4.查看pod运行情况。可以看到旧的pod马上就删除了

kubectl get pods -n dev -w

滚动更新

策略二：滚动更新
1.编辑pc-deployment.yaml，在spec节点下添加更新策略

apiVersion: apps/v1 
kind: Deployment 
metadata: 
	name: pc-deployment 
	namespace: dev 
spec: 
	strategy：#策略
		type：RollingUpdate #重建更新策略
		rollingUpdate:
			maxUnavailable:25%
			minSurge:
	replicas: 3 
	selector: 
		matchlabels: 
			app: nginx-pod 
template: 
	metadata: 
	labels: 
		app: nginx-pod 
	spec: 
		containers: 
		  - name: nginx 
			image: nginx:1.17.1

2.让修改的文件生效

kubectl apply -f pc-deployment.yaml

3.升级nginx版本

kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev

4.查看pod运行情况。可以看到 先起了三个新的pod，启成功一个 就删掉一个

kubectl get pods -n dev -w

镜像更新中rs的变化：

1.停掉之前的pod

kubectl delete -f pc-deployment.yaml

2.重新创建pod

# --record 参数会记录整个deployment的更新过程
kubectl create -t pc-deployment.yaml --record

3.查看deploy,rs,pod创建是否成功

kubectl get deploy,rs,pod -n dev

创建完成

4.另外启动两个窗口，监听rs和pod

kubectl get pod -n dev
kubectl get rs -n dev

5.第一个窗口中，进行镜像升级

kubectl set image deploy pc-deployment nginx=nginx:1.17.2 -n dev

6.查看rs，可以发现旧的 rs依旧存在，只是pod数量变为了0，而后又新产生了一个rs,pod数量为3
其实这也就是deployment能够进行版本回退的奥妙所在

kubectl get rs -n dev

版本回退

deployment支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能，下面具体来看：

kubectl rollout： 版本升级相关功能，支持下面的选项：

• status 显示当前升级状态
• history 显示升级历史记录
• pause 暂停版本升级过程
• resume 继续己经香停的版本升级过程
• restart 重启版本升级过程
• undo 回滚到上一级版本（可以使用-to-revision回滚到指定版本）

#查看当前升级版本的状态 
  kubectl rollout status deploy pc-deployment -n dev 
  #deployment "pc-deployment" successfully rolled out 
 # 查看升级历史记录 
 kubectl rollout history deploy pc-deployment -n dev #deployment. apps/pc-deployment REVISION CHANGE-CAUSE 
#1 kubectl create --filename=pc-deployment.yaml--record=true 
#2 kubectl create --filename=pc-deployment.yaml--record=true 
#3 kubectl create --filename=pc-deployment.yaml--record=true 
 #可以发现有三次版本记录，说明完成过两次升级

实际操作

金丝雀发布

https://www.bilibili.com/video/BV1Qv41167ck?p=52

Deployment支持更新过程中的控制，如“暂停(pausey或“继续(resumey更新操作。 比如有一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧 的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

四、Horizontal Pod Autoscaler（HPA）

在前面，我们可以通过手工执行 Fubectl scale 命令实现Pod扩容， 但是这显然不特合
    Kubernetes的定位目标–自动化、智能化。 Kubernetes期望可以通过监测Pod的使用情况，实现pod数量的自动调整，于是就产生了HPA这种控制器。
    HPA可以获取每个pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现 pod的数量的调整。
    其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追家分析目标pod的负载变化情况，来确定是否需要针对性地调整目标pod的副本数。

1.安装metrics-server

mertics-server可以收集集群中资源的使用情况

#获取metrics-server，注意使用的版本 ,建议使用0.3.6，其他版本可能配置不一样
 git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
#修改deployment，注意修除的是锁絛和初始化参数 
 cd /root/metrics-server/deploy/1.8+/ 
 vim metrics-server-deployment.yaml 
# 按照图中添加下面选项 
   hostNetwork: true 
   registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
   \- --kubelet-insecure-tls 
   \- --kubelet-preferred-addresstypes=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

1.1安装metrics-server

# 要metrics-server/deploy/1.8+/ 目录下
kubectl apply -f ./

1.2 查看pod运行情况

kubectl get pods -n kube-system # 可以看到metrics-server以pod的形式运行起来了

1.3 查看metrics-server资源使用情况,要稍微等待一会才会看到数据

kubectl top node
kubectl top pod -n kube-system

2.准备deployment和 service

# 创建deployment 
 kubectl run nqinx --image=nginx:1.17.1--requests=cpu=100m-ndev 
# 创建service
 kubect1 expose dep}oyment nginx--type-NodePort --port=80 -n dev 
# 查看
 kubectl get deployment, pod, svc -n dev

3部署HPA

3.1 创建pc-hpa.yml

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
	name: pc-hpa 
	namespace: dev 
spec: 
	minReplicas: 1 #最小pod数量 
	maxReplicas: 10 #最大pod数量 
	targetCPuUtilizationPercentage：3 #CPU使用率指标 就指3%
	scaleTargetRef：#指定要控制的nginx信息 
		apiVersion: apps/v1 
		kind: Deployment 
		name: nginx

3.2 创建

kubectl create -f pc-hpa.yml
# 查看hpa
kubectl get hpa -n dev

3.3 测试，增加nginx的压力

• 使用工具对http://192.168.100.100: 3034 增压
• 打开三个终端 ，分别查看deploy pod pha情况
• 在不断增压的情况下cpu使用率大于3%，就会自动增加pod数量
• 一旦停止加压，不会马上就减低pod数量，因为需要监控一段时间，怕cpu使用率突然又增上去
  

五、DaemonSet（DS）

Daemonset类型的控制器可以保证集群中的每一台（或指定）节点上都运行- 个副本， 一般适用于日志收隻 节点监控等场景。也就是说，如果 一个pod提供的功能是节点级别的（每个节点都需要且只需要一个），那么这类 Pod就适合使用Daemonset类型的控制器创建

Daemonset控制器的特点：

• 每当向集群中添加一个节点时，指定的 pod 副本也将添加到该节点上
• 当节点从集群中移除时，pod也就被垃圾回收了

Daemonset的资源清单文件

创建pc-daemonset.yml**

apiVersion: apps/vl 
kind: DaemonSet 
metadata: 
	name: pc-daemonset 
	namespace: dev 
spec: 
	selector: 
		matchlabels: 
			app: nginx-pod 
	template: 
		metadata: 
			labels: 
				app: nginx-pod 
		spec: 
			containers: 
				- name: nginx 
				  image: nginx:1.17.1

创建ds

kubectl create -f pc-daemonset.yml

查看ds

kubectl get ds -n dev
kubectl get pod -n dev -o wide # 会发现两个节点上都有 pc-daemonset-xxxx pod

删除daemonset

kubectl delete -f pc-daemonset.yml 

六、Job

Job主要负责批量处理（一次性要处理指定任务数量）短暂的一次性（一个任务只运行一次就结束）任务，Job特点：

• 当job创建的pod执行成功完成时，job会记录成功结束的pod数量
• 当成功执行的pod达到指定的数量时，job将完成执行

job资源清单文件

创建pc-job-pod.yml

apiVersion: batch/v1 
kind: Job 
metadata: 
	name: pc-job 
	namespace: dev 
spec: 
	manualSelector: true
	 complet ions：6 #指定iob需要成功运行Pods的次数。默认：1 
	 parallelism: 3 #指定job在任一时刻应该并发运行Pods的数量。默认值1
	selector: 
		matchlabels: 
			app: counter-pod 
	template: 
		metadata: 
			labels: 
				app: counter-pod 
		spec: 
			restartPolicy: Never 
			containers: 
				- name: counter 
				  image: busybox:1.30 
				  command: [ "bin/sh"."-c","for i in 9 8 7 6 5 4 3 2 1: do echo Si:sleep 3:done"] 

创建pod

kubectl create -f pc-job-pod.ymal

查看pod,会发现job每次运行三个pod,总共运行6个pod

kubectl get pod -n dev -o wide -w

删除pod

kubectl delete -f pc-job-pod.ymal

七、CronJob(CJ)

Cronjob控制器以Job控制品资源为其管控对象，并借助它管理pod资源对象，Job控制品定义的作业任务在其控 制器资源创建之后便会立即执行，但Cronob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运 行时间点及重复运行的方式。也就是说， ** Cronjob可以在特定的时间点(反复的法运行job任务**。

cronjob资源清单


创建pod.yml

apiVersion: batch/vibetal 
kind: CronJob 
metadata: 
	name: pc-cronjob 
	namespace: dev 
	labels: 
		controller: cronjob 
spec: 
	schedule: "*/1 * * * *"
	jobTemplate: 
		metadata: 
		spec: 
			template: 
				spec: 
					restartPolicy: Never 
					containers: 
					 - name: counter 
					   image: busybox:1.30 
					   command: ("bin/sh","-c", "for 1 in 9 8 7 6 5 4 3 2 1; do echo Si;sleep 3; done"]

kubectl get job -n dev -w
kubectl get cj -n dev  -w