pod的创建方式

在k8s中，可以将pod的创建方式分为2类

自主式pod：由k8s直接创建出来的pod，这种pod删除之后就没有了，也不会重建

kubectl run mynginx --image=nginx

控制器创建的pod：通过控制器创建的pod，这种pod删除了之后会自动重建；

kubectl create deployment mynginx --image=nginx:1.17.1

什么是pod控制器

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

控制器的种类

在kubernetes有很多种类型的pod控制器，每种都有自己的使用场景

ReplicationController：比较原始的pod控制器，已经被废弃，由ReplicaSet替代
ReplicaSet：保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级
Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本
Horizontal Pod Autoscaler：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务
Job：它创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务
Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行，可以理解为是定时任务；
StatefulSet：管理有状态应用

1、ReplicaSet

简称为RS，主要的作用是保证一定数量的pod能够正常运行，它会持续监听这些pod的运行状态，提供了以下功能

自愈能力：
- 重启：当某节点中的pod运行过程中出现问题导致无法启动时，k8s会不断重启，直到可用状态为止
- 故障转移：当正在运行中pod所在的节点发生故障或者宕机时，k8s会选择集群中另一个可用节点，将pod运行到可用节点上；
pod数量的扩缩容：pod副本的扩容和缩容
镜像升降级：支持镜像版本的升级和降级；

配置模板

rs的所有配置如下

apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: rs
spec: # 详情描述replicas: 3 # 副本数量selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则，key就是label的key，values的值是个数组，意思是标签值必须是此数组中的其中一个才能匹配上；- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:  # 这里的标签必须和上面的matchLabels一致，将他们关联起来app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80

1、创建一个ReplicaSet

新建一个文件 rs.yaml，内容如下

apiVersion: apps/v1
kind: ReplicaSet    # pod控制器
metadata:      # 元数据name: pc-replicaset    # 名字namespace: dev      # 名称空间
spec:replicas: 3     # 副本数selector:     # 选择器，通过它指定该控制器管理哪些podmatchLabels:   # Labels匹配规则app: nginx-podtemplate:     # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1

运行

kubectl create -f rs.yaml

获取replicaset

kubectl get replicaset  -n dev

2、扩缩容

刚刚我们已经用第一种方式创建了一个replicaSet，现在就基于原来的rs进行扩容，原来的副本数量是3个，现在我们将其扩到6个，做法也很简单，运行编辑命令
第一种方式: scale

# 使用scale命令实现扩缩容，后面`--replicas=n`直接指定目标数量即可
kubectl scale rs pc-replicaset  --replicas=2 -n dev

第二种方式：使用edit命令编辑rs

# 这种方式相当于使用vi编辑修改yaml配置的内容，进去后将replicas的值改为1，保存后自动生效
kubectl edit rs pc-replicaset -n dev

3、镜像版本变更

第一种方式：scale

kubectl scale rs pc-replicaset  nginx=nginx:1.71.2 -n dev

第二种方式：edit

# 这种方式相当于使用vi编辑修改yaml配置的内容，进去后将nginx的值改为nginx:1.71.2，保存后自动生效
kubectl edit rs pc-replicaset -n dev

4、删除rs

# 第一种方式
kubectl delete -f rs.yaml# 第二种方式 ,如果想要只删rs，但不删除pod，可在删除时加上`--cascade=false`参数（不推荐）
kubectl delete rs pc-replicaset -n dev --cascade=false

2、Deployment

k8s v1.2版本后加入Deployment；这种控制器不直接控制pod，而是通过管理ReplicaSet来间接管理pod；也就是Deployment管理ReplicaSet，ReplicaSet管理pod；所以 Deployment 比 ReplicaSet 功能更加强大
当我们创建了一个Deployment之后，也会自动创建一个ReplicaSet

功能

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

配置模板

新建文件

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: deploy
spec: # 详情描述replicas: 3 # 副本数量revisionHistoryLimit: 3 # 保留历史版本的数量，默认10，内部通过保留rs来实现paused: false # 暂停部署，默认是falseprogressDeadlineSeconds: 600 # 部署超时时间（s），默认是600strategy: # 策略type: RollingUpdate # 滚动更新策略rollingUpdate: # 滚动更新maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80

1、创建和删除Deployment

创建pc-deployment.yaml，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:name: pc-deploymentnamespace: dev
spec: replicas: 3selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1

创建和查看

# 创建deployment，--record=true 表示记录整个deployment更新过程
[root@k8s-master01 ~]# kubectl create -f pc-deployment.yaml --record=true
deployment.apps/pc-deployment created# 查看deployment
# READY 可用的/总数
# UP-TO-DATE 最新版本的pod的数量
# AVAILABLE  当前可用的pod的数量
[root@k8s-master01 ~]# kubectl get deploy pc-deployment -n dev
NAME            READY   UP-TO-DATE   AVAILABLE   AGE
pc-deployment   3/3     3            3           15s# 查看rs
# 发现rs的名称是在原来deployment的名字后面添加了一个10位数的随机串
[root@k8s-master01 ~]# kubectl get rs -n dev
NAME                       DESIRED   CURRENT   READY   AGE
pc-deployment-6696798b78   3         3         3       23s# 查看pod
[root@k8s-master01 ~]# kubectl get pods -n dev
NAME                             READY   STATUS    RESTARTS   AGE
pc-deployment-6696798b78-d2c8n   1/1     Running   0          107s
pc-deployment-6696798b78-smpvp   1/1     Running   0          107s
pc-deployment-6696798b78-wvjd8   1/1     Running   0          107s

删除deployment

#  删除deployment，其下的rs和pod也将被删除
kubectl delete -f pc-deployment.yaml

2、扩缩容

deployment的扩缩容和 ReplicaSet 的扩缩容一样，只需要将rs或者replicaSet改为deployment即可，具体请参考上面的 ReplicaSet 扩缩容

3、镜像更新

刚刚在创建时加上了--record=true参数，所以在一旦进行了镜像更新，就会新建出一个pod出来，将老的old-pod上的容器全删除，然后在新的new-pod上在新建对应数量的容器，此时old-pod是不会删除的，因为这个old-pod是要进行回退的；

镜像更新策略有2种

滚动更新（RollingUpdate）：（默认值），杀死一部分，就启动一部分，在更新过程中，存在两个版本Pod
重建更新（Recreate）：在创建出新的Pod之前会先杀掉所有已存在的Pod

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

重建更新

编辑pc-deployment.yaml,在spec节点下添加更新策略

spec:strategy: # 策略type: Recreate # 重建更新

创建deploy进行验证

# 变更镜像
[root@k8s-master01 ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.2 -n dev
deployment.apps/pc-deployment image updated# 观察升级过程
[root@k8s-master01 ~]#  kubectl get pods -n dev -w
NAME                             READY   STATUS    RESTARTS   AGE
pc-deployment-5d89bdfbf9-65qcw   1/1     Running   0          31s
pc-deployment-5d89bdfbf9-w5nzv   1/1     Running   0          31s
pc-deployment-5d89bdfbf9-xpt7w   1/1     Running   0          31spc-deployment-5d89bdfbf9-xpt7w   1/1     Terminating   0          41s
pc-deployment-5d89bdfbf9-65qcw   1/1     Terminating   0          41s
pc-deployment-5d89bdfbf9-w5nzv   1/1     Terminating   0          41spc-deployment-675d469f8b-grn8z   0/1     Pending       0          0s
pc-deployment-675d469f8b-hbl4v   0/1     Pending       0          0s
pc-deployment-675d469f8b-67nz2   0/1     Pending       0          0spc-deployment-675d469f8b-grn8z   0/1     ContainerCreating   0          0s
pc-deployment-675d469f8b-hbl4v   0/1     ContainerCreating   0          0s
pc-deployment-675d469f8b-67nz2   0/1     ContainerCreating   0          0spc-deployment-675d469f8b-grn8z   1/1     Running             0          1s
pc-deployment-675d469f8b-67nz2   1/1     Running             0          1s
pc-deployment-675d469f8b-hbl4v   1/1     Running             0          2s

滚动更新

编辑pc-deployment.yaml,在spec节点下添加更新策略

spec:strategy: # 策略type: RollingUpdate # 滚动更新策略rollingUpdate:maxSurge: 25% maxUnavailable: 25%

创建deploy进行验证

# 变更镜像
[root@k8s-master01 ~]# kubectl set image deployment pc-deployment nginx=nginx:1.17.3 -n dev
deployment.apps/pc-deployment image updated# 观察升级过程
[root@k8s-master01 ~]# kubectl get pods -n dev -w
NAME                           READY   STATUS    RESTARTS   AGE
pc-deployment-c848d767-8rbzt   1/1     Running   0          31m
pc-deployment-c848d767-h4p68   1/1     Running   0          31m
pc-deployment-c848d767-hlmz4   1/1     Running   0          31m
pc-deployment-c848d767-rrqcn   1/1     Running   0          31mpc-deployment-966bf7f44-226rx   0/1     Pending             0          0s
pc-deployment-966bf7f44-226rx   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-226rx   1/1     Running             0          1s
pc-deployment-c848d767-h4p68    0/1     Terminating         0          34mpc-deployment-966bf7f44-cnd44   0/1     Pending             0          0s
pc-deployment-966bf7f44-cnd44   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-cnd44   1/1     Running             0          2s
pc-deployment-c848d767-hlmz4    0/1     Terminating         0          34mpc-deployment-966bf7f44-px48p   0/1     Pending             0          0s
pc-deployment-966bf7f44-px48p   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-px48p   1/1     Running             0          0s
pc-deployment-c848d767-8rbzt    0/1     Terminating         0          34mpc-deployment-966bf7f44-dkmqp   0/1     Pending             0          0s
pc-deployment-966bf7f44-dkmqp   0/1     ContainerCreating   0          0s
pc-deployment-966bf7f44-dkmqp   1/1     Running             0          2s
pc-deployment-c848d767-rrqcn    0/1     Terminating         0          34m# 至此，新版本的pod创建完毕，就版本的pod销毁完毕
# 中间过程是滚动进行的，也就是边销毁边创建

4、版本回退

更新

回退

在回退时会将new-pod上的容器全部删除，在将old-pod上恢复原来的容器；

回退命令

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

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

用法

# 查看当前升级版本的状态
kubectl rollout status deploy pc-deployment -n dev# 查看升级历史记录
kubectl rollout history deploy pc-deployment -n dev# 版本回滚
# 这里直接使用--to-revision=1回滚到了1版本， 如果省略这个选项，就是回退到上个版本
kubectl rollout undo deployment pc-deployment --to-revision=1 -n dev

金丝雀发布

Deployment控制器支持控制更新过程中的控制，如“暂停(pause)”或“继续(resume)”更新操作。

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

金丝雀发布不是自动完成的，需要人为手动去操作，才能达到金丝雀发布的标准；

# 更新deployment的版本，并配置暂停deployment
kubectl set image deploy pc-deployment nginx=nginx:1.17.4 -n dev && kubectl rollout pause deployment pc-deployment  -n dev# 观察更新状态
kubectl rollout status deploy pc-deployment -n dev　# 监控更新的过程
kubectl get rs -n dev -o wide# 确保更新的pod没问题了，继续更新
kubectl rollout resume deploy pc-deployment -n dev# 如果有问题，就回退到上个版本回退到上个版本
kubectl rollout undo deployment pc-deployment -n dev

Horizontal Pod Autoscaler

简称HPA，使用deployment可以手动调整pod的数量来实现扩容和缩容；但是这显然不符合k8s的自动化的定位，k8s期望可以通过检测pod的使用情况，实现pod数量自动调整，于是就有了HPA控制器；

HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。比如说我指定了一个规则：当我的cpu利用率达到90%或者内存使用率到达80%的时候，就需要进行调整pod的副本数量，每次添加n个pod副本；

其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析ReplicaSet控制器的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，也就是HPA管理Deployment，Deployment管理ReplicaSet，ReplicaSet管理pod，这是HPA的实现原理。

1、安装metrics-server

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

# 安装git
[root@k8s-master01 ~]# yum install git -y
# 获取metrics-server, 注意使用的版本
[root@k8s-master01 ~]# git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 修改deployment, 注意修改的是镜像和初始化参数
[root@k8s-master01 ~]# cd /root/metrics-server/deploy/1.8+/
[root@k8s-master01 1.8+]# vim metrics-server-deployment.yaml
按图中添加下面选项
hostNetwork: true
image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
args:
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

2、安装metrics-server

[root@k8s-master01 1.8+]# kubectl apply -f ./

3、查看pod运行情况

[root@k8s-master01 1.8+]# kubectl get pod -n kube-system
metrics-server-6b976979db-2xwbj   1/1     Running   0          90s

4、使用kubectl top node 查看资源使用情况

[root@k8s-master01 1.8+]# kubectl top node
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
k8s-master01   289m         14%    1582Mi          54%
k8s-node01     81m          4%     1195Mi          40%
k8s-node02     72m          3%     1211Mi          41%
[root@k8s-master01 1.8+]# kubectl top pod -n kube-system
NAME                              CPU(cores)   MEMORY(bytes)
coredns-6955765f44-7ptsb          3m           9Mi
coredns-6955765f44-vcwr5          3m           8Mi
etcd-master                       14m          145Mi
...
# 至此,metrics-server安装完成

5、准备deployment和servie

创建pc-hpa-pod.yaml文件，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:name: nginxnamespace: dev
spec:strategy: # 策略type: RollingUpdate # 滚动更新策略replicas: 1selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1resources: # 资源配额limits:  # 限制资源（上限）cpu: "1" # CPU限制，单位是core数requests: # 请求资源（下限）cpu: "100m"  # CPU限制，单位是core数

创建deployment

[root@k8s-master01 1.8+]# kubectl run nginx --image=nginx:1.17.1 --requests=cpu=100m -n dev

6、创建service

[root@k8s-master01 1.8+]# kubectl expose deployment nginx --type=NodePort --port=80 -n dev

7、查看

[root@k8s-master01 1.8+]# kubectl get deployment,pod,svc -n dev
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx   1/1     1            1           47sNAME                         READY   STATUS    RESTARTS   AGE
pod/nginx-7df9756ccc-bh8dr   1/1     Running   0          47sNAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/nginx   NodePort   10.101.18.29   <none>        80:31830/TCP   35s

8、部署HPA

创建pc-hpa.yaml文件，内容如下：

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:name: pc-hpanamespace: dev
spec:minReplicas: 1  #最小pod数量maxReplicas: 10 #最大pod数量 ，pod数量会在1~10之间自动伸缩targetCPUUtilizationPercentage: 3 # CPU使用率指标，如果cpu使用率达到3%就会进行扩容；为了测试方便，将这个数值调小一些scaleTargetRef:   # 指定要控制的nginx信息apiVersion:  /v1kind: Deploymentname: nginx

创建hpa

[root@k8s-master01 1.8+]# kubectl create -f pc-hpa.yaml
horizontalpodautoscaler.autoscaling/pc-hpa created

查看hpa

[root@k8s-master01 1.8+]# kubectl get hpa -n dev
NAME     REFERENCE          TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
pc-hpa   Deployment/nginx   0%/3%     1         10        1          62s

9、测试

使用压测工具对service地址192.168.5.4:31830进行压测，然后通过控制台查看hpa和pod的变化

hpa变化

[root@k8s-master01 ~]# kubectl get hpa -n dev -w
NAME   REFERENCE      TARGETS  MINPODS  MAXPODS  REPLICAS  AGE
pc-hpa  Deployment/nginx  0%/3%   1     10     1      4m11s
pc-hpa  Deployment/nginx  0%/3%   1     10     1      5m19s
pc-hpa  Deployment/nginx  22%/3%   1     10     1      6m50s
pc-hpa  Deployment/nginx  22%/3%   1     10     4      7m5s
pc-hpa  Deployment/nginx  22%/3%   1     10     8      7m21s
pc-hpa  Deployment/nginx  6%/3%   1     10     8      7m51s
pc-hpa  Deployment/nginx  0%/3%   1     10     8      9m6s
pc-hpa  Deployment/nginx  0%/3%   1     10     8      13m
pc-hpa  Deployment/nginx  0%/3%   1     10     1      14m

deployment变化

[root@k8s-master01 ~]# kubectl get deployment -n dev -w
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           11m
nginx   1/4     1            1           13m
nginx   1/4     1            1           13m
nginx   1/4     1            1           13m
nginx   1/4     4            1           13m
nginx   1/8     4            1           14m
nginx   1/8     4            1           14m
nginx   1/8     4            1           14m
nginx   1/8     8            1           14m
nginx   2/8     8            2           14m
nginx   3/8     8            3           14m
nginx   4/8     8            4           14m
nginx   5/8     8            5           14m
nginx   6/8     8            6           14m
nginx   7/8     8            7           14m
nginx   8/8     8            8           15m
nginx   8/1     8            8           20m
nginx   8/1     8            8           20m
nginx   1/1     1            1           20m

pod变化

[root@k8s-master01 ~]# kubectl get pods -n dev -w
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7df9756ccc-bh8dr   1/1     Running   0          11m
nginx-7df9756ccc-cpgrv   0/1     Pending   0          0s
nginx-7df9756ccc-8zhwk   0/1     Pending   0          0s
nginx-7df9756ccc-rr9bn   0/1     Pending   0          0s
nginx-7df9756ccc-cpgrv   0/1     ContainerCreating   0          0s
nginx-7df9756ccc-8zhwk   0/1     ContainerCreating   0          0s
nginx-7df9756ccc-rr9bn   0/1     ContainerCreating   0          0s
nginx-7df9756ccc-m9gsj   0/1     Pending             0          0s
nginx-7df9756ccc-g56qb   0/1     Pending             0          0s
nginx-7df9756ccc-sl9c6   0/1     Pending             0          0s
nginx-7df9756ccc-fgst7   0/1     Pending             0          0s
nginx-7df9756ccc-g56qb   0/1     ContainerCreating   0          0s
nginx-7df9756ccc-m9gsj   0/1     ContainerCreating   0          0s
nginx-7df9756ccc-sl9c6   0/1     ContainerCreating   0          0s
nginx-7df9756ccc-fgst7   0/1     ContainerCreating   0          0s
nginx-7df9756ccc-8zhwk   1/1     Running             0          19s
nginx-7df9756ccc-rr9bn   1/1     Running             0          30s
nginx-7df9756ccc-m9gsj   1/1     Running             0          21s
nginx-7df9756ccc-cpgrv   1/1     Running             0          47s
nginx-7df9756ccc-sl9c6   1/1     Running             0          33s
nginx-7df9756ccc-g56qb   1/1     Running             0          48s
nginx-7df9756ccc-fgst7   1/1     Running             0          66s
nginx-7df9756ccc-fgst7   1/1     Terminating         0          6m50s
nginx-7df9756ccc-8zhwk   1/1     Terminating         0          7m5s
nginx-7df9756ccc-cpgrv   1/1     Terminating         0          7m5s
nginx-7df9756ccc-g56qb   1/1     Terminating         0          6m50s
nginx-7df9756ccc-rr9bn   1/1     Terminating         0          7m5s
nginx-7df9756ccc-m9gsj   1/1     Terminating         0          6m50s
nginx-7df9756ccc-sl9c6   1/1     Terminating         0          6m50s

DaemonSet

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

DaemonSet控制器的特点：

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

配置模板

apiVersion: apps/v1 # 版本号
kind: DaemonSet # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: daemonset
spec: # 详情描述revisionHistoryLimit: 3 # 保留历史版本updateStrategy: # 更新策略type: RollingUpdate # 滚动更新策略rollingUpdate: # 滚动更新maxUnavailable: 1 # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数selector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: nginx-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [nginx-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1ports:- containerPort: 80

1、创建ds

创建pc-daemonset.yaml，内容如下：

apiVersion: apps/v1
kind: DaemonSet
metadata:name: pc-daemonsetnamespace: dev
spec: selector:matchLabels:app: nginx-podtemplate:metadata:labels:app: nginx-podspec:containers:- name: nginximage: nginx:1.17.1

运行

# 创建daemonset
[root@k8s-master01 ~]# kubectl create -f  pc-daemonset.yaml
daemonset.apps/pc-daemonset created# 查看daemonset
[root@k8s-master01 ~]#  kubectl get ds -n dev -o wide
NAME        DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE   AGE   CONTAINERS   IMAGES
pc-daemonset   2        2        2      2           2        24s   nginx        nginx:1.17.1   # 查看pod,发现在每个Node上都运行一个pod
[root@k8s-master01 ~]#  kubectl get pods -n dev -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE
pc-daemonset-9bck8   1/1     Running   0          37s   10.244.1.43   node1
pc-daemonset-k224w   1/1     Running   0          37s   10.244.2.74   node2

2、删除daemonset

[root@k8s-master01 ~]# kubectl delete -f pc-daemonset.yaml
daemonset.apps "pc-daemonset" deleted

Job

主要用于负责**批量处理一次性(每个任务仅运行一次就结束)**任务。当然，你也可以运行多次，配置好即可，Job特点如下：

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

配置模板

apiVersion: batch/v1 # 版本号
kind: Job # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: job
spec: # 详情描述completions: 1 # 指定job需要成功运行Pods的次数。默认值: 1parallelism: 1 # 指定job在任一时刻应该并发运行Pods的数量。默认值: 1activeDeadlineSeconds: 30 # 指定job可运行的时间期限，超过时间还未结束，系统将会尝试进行终止。backoffLimit: 6 # 指定job失败后进行重试的次数。默认是6manualSelector: true # 是否可以使用selector选择器选择pod，默认是falseselector: # 选择器，通过它指定该控制器管理哪些podmatchLabels:      # Labels匹配规则app: counter-podmatchExpressions: # Expressions匹配规则- {key: app, operator: In, values: [counter-pod]}template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本metadata:labels:app: counter-podspec:restartPolicy: Never # 重启策略只能设置为Never或者OnFailurecontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 2;done"]

关于重启策略设置的说明：（这里只能设置为Never或者OnFailure）

如果指定为OnFailure，则job会在pod出现故障时重启容器，而不是创建pod，failed次数不变
如果指定为Never，则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，failed次数加1
如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了，当然不对，所以不能设置为Always

1、创建一个job

创建pc-job.yaml，内容如下：

apiVersion: batch/v1
kind: Job
metadata:name: pc-jobnamespace: dev
spec:manualSelector: trueselector:matchLabels:app: counter-podtemplate:metadata:labels:app: counter-podspec:restartPolicy: Nevercontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

创建

# 创建job
[root@k8s-master01 ~]# kubectl create -f pc-job.yaml
job.batch/pc-job created# 查看job
[root@k8s-master01 ~]# kubectl get job -n dev -o wide  -w
NAME     COMPLETIONS   DURATION   AGE   CONTAINERS   IMAGES         SELECTOR
pc-job   0/1           21s        21s   counter      busybox:1.30   app=counter-pod
pc-job   1/1           31s        79s   counter      busybox:1.30   app=counter-pod# 通过观察pod状态可以看到，pod在运行完毕任务后，就会变成Completed状态
[root@k8s-master01 ~]# kubectl get pods -n dev -w
NAME           READY   STATUS     RESTARTS      AGE
pc-job-rxg96   1/1     Running     0            29s
pc-job-rxg96   0/1     Completed   0            33s# 接下来，调整下pod运行的总数量和并行数量 即：在spec下设置下面两个选项
#  completions: 6 # 指定job需要成功运行Pods的次数为6
#  parallelism: 3 # 指定job并发运行Pods的数量为3
#  然后重新运行job，观察效果，此时会发现，job会每次运行3个pod，总共执行了6个pod
[root@k8s-master01 ~]# kubectl get pods -n dev -w
NAME           READY   STATUS    RESTARTS   AGE
pc-job-684ft   1/1     Running   0          5s
pc-job-jhj49   1/1     Running   0          5s
pc-job-pfcvh   1/1     Running   0          5s
pc-job-684ft   0/1     Completed   0          11s
pc-job-v7rhr   0/1     Pending     0          0s
pc-job-v7rhr   0/1     Pending     0          0s
pc-job-v7rhr   0/1     ContainerCreating   0          0s
pc-job-jhj49   0/1     Completed           0          11s
pc-job-fhwf7   0/1     Pending             0          0s
pc-job-fhwf7   0/1     Pending             0          0s
pc-job-pfcvh   0/1     Completed           0          11s
pc-job-5vg2j   0/1     Pending             0          0s
pc-job-fhwf7   0/1     ContainerCreating   0          0s
pc-job-5vg2j   0/1     Pending             0          0s
pc-job-5vg2j   0/1     ContainerCreating   0          0s
pc-job-fhwf7   1/1     Running             0          2s
pc-job-v7rhr   1/1     Running             0          2s
pc-job-5vg2j   1/1     Running             0          3s
pc-job-fhwf7   0/1     Completed           0          12s
pc-job-v7rhr   0/1     Completed           0          12s
pc-job-5vg2j   0/1     Completed           0          12s

2、删除

# 删除job
kubectl delete -f pc-job.yaml

CronJob

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

配置模板

apiVersion: batch/v1beta1 # 版本号
kind: CronJob # 类型
metadata: # 元数据name: # rs名称 namespace: # 所属命名空间 labels: #标签controller: cronjob
spec: # 详情描述schedule: # cron格式的作业调度运行时间点,用于控制任务在什么时间执行concurrencyPolicy: # 并发执行策略，用于定义前一次作业运行尚未完成时是否以及如何运行后一次的作业failedJobHistoryLimit: # 为失败的任务执行保留的历史记录数，默认为1successfulJobHistoryLimit: # 为成功的任务执行保留的历史记录数，默认为3startingDeadlineSeconds: # 启动作业错误的超时时长jobTemplate: # job控制器模板，用于为cronjob控制器生成job对象;下面其实就是job的定义metadata:spec:completions: 1parallelism: 1activeDeadlineSeconds: 30backoffLimit: 6manualSelector: trueselector:matchLabels:app: counter-podmatchExpressions: 规则- {key: app, operator: In, values: [counter-pod]}template:metadata:labels:app: counter-podspec:restartPolicy: Never containers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 20;done"]

cron表达式写法

需要重点解释的几个选项：
schedule: cron表达式，用于指定任务的执行时间*/1    *      *    *     *<分钟> <小时> <日> <月份> <星期>分钟 值从 0 到 59.小时 值从 0 到 23.日 值从 1 到 31.月 值从 1 到 12.星期 值从 0 到 6, 0 代表星期日多个时间可以用逗号隔开； 范围可以用连字符给出；*可以作为通配符； /表示每... 例如1 * * * *  // 每个小时的第一分钟执行*/1 * * * *  // 每分钟都执行
concurrencyPolicy:Allow:   允许Jobs并发运行(默认)Forbid:  禁止并发运行，如果上一次运行尚未完成，则跳过下一次运行Replace: 替换，取消当前正在运行的作业并用新作业替换它

1、创建cronJob

创建pc-cronjob.yaml，内容如下：

apiVersion: batch/v1beta1
kind: CronJob
metadata:name: pc-cronjobnamespace: devlabels:controller: cronjob
spec:schedule: "*/1 * * * *" # 每分钟执行一次jobTemplate:metadata:spec:template:spec:restartPolicy: Nevercontainers:- name: counterimage: busybox:1.30command: ["bin/sh","-c","for i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]

运行

# 创建cronjob
[root@k8s-master01 ~]# kubectl create -f pc-cronjob.yaml
cronjob.batch/pc-cronjob created# 查看cronjob
[root@k8s-master01 ~]# kubectl get cronjobs -n dev
NAME         SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
pc-cronjob   */1 * * * *   False     0        <none>          6s# 查看job
[root@k8s-master01 ~]# kubectl get jobs -n dev
NAME                    COMPLETIONS   DURATION   AGE
pc-cronjob-1592587800   1/1           28s        3m26s
pc-cronjob-1592587860   1/1           28s        2m26s
pc-cronjob-1592587920   1/1           28s        86s# 查看pod
[root@k8s-master01 ~]# kubectl get pods -n dev
pc-cronjob-1592587800-x4tsm   0/1     Completed   0          2m24s
pc-cronjob-1592587860-r5gv4   0/1     Completed   0          84s
pc-cronjob-1592587920-9dxxq   1/1     Running     0          24s

2、删除cronjob

kubectl  delete -f pc-cronjob.yaml

pod调度

什么是调度

默认情况下，一个pod在哪个node节点上运行，是通过scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的；

调度规则

但是在实际使用中，我们想控制某些pod定向到达某个节点上，应该怎么做呢？其实k8s提供了四类调度规则

调度方式	描述
自动调度	通过scheduler组件采用相应的算法计算得出运行在哪个节点上
定向调度	运行到指定的node节点上，通过NodeName、NodeSelector实现
亲和性调度	跟谁关系好就调度到哪个节点上 1、nodeAffinity ：节点亲和性，调度到关系好的节点上 2、podAffinity：pod亲和性，调度到关系好的pod所在的节点上 3、PodAntAffinity：pod反清河行，调度到关系差的那个pod所在的节点上
污点（容忍）调度	污点是站在node的角度上的，比如果nodeA有一个污点，大家都别来，此时nodeA会拒绝master调度过来的pod

定向调度

指的是利用在pod上声明nodeName或nodeSelector的方式将pod调度到指定的pod节点上，因为这种定向调度是强制性的，所以如果node节点不存在的话，也会向上面进行调度，只不过pod会运行失败；

1、定向调度-> nodeName

nodeName 是将pod强制调度到指定名称的node节点上，这种方式跳过了scheduler的调度逻辑，直接将pod调度到指定名称的节点上，配置文件内容如下

apiVersion: v1  # 版本号
kind: Pod  # 资源类型
metadata: name: pod-namenamespace: dev
spec: containers: - image: nginx:1.17.1name: nginx-containernodeName: node1  # 调度到node1节点上

2、定向调度 -> NodeSelector

NodeSelector是将pod调度到添加了指定label标签的node节点上，它是通过k8s的label-selector机制实现的，也就是说，在创建pod之前，会由scheduler用matchNodeSelecto调度策略进行label标签的匹配，找出目标node，然后在将pod调度到目标node；

要实验NodeSelector，首先得给node节点加上label标签

kubectl label nodes node1 nodetag=node1

配置文件内容如下

apiVersion: v1  # 版本号
kind: Pod  # 资源类型
metadata: name: pod-namenamespace: dev
spec: containers: - image: nginx:1.17.1name: nginx-containernodeSelector: nodetag: node1  # 调度到具有nodetag=node1标签的节点上

k8s pod控制器使用以及详解相关推荐

k8s kubectl create命令使用详解
k8s kubectl create命令使用详解 Create a resource by filename or stdin 摘要 Create a resource by filename or ...
k8s kubectl run命令使用详解
k8s kubectl run命令使用详解在集群上运行指定镜像. 摘要创建并运行一个指定的可复制的镜像. 创建一个deployment或者job来管理创建的容器. kubectl run NAME ...
k8s kubectl expose命令使用详解
k8s kubectl expose命令使用详解 Take a replication controller, service, deployment or pod and expose it as ...
k8s——pod控制器
k8s--pod控制器 Pod控制器介绍 Pod控制器及其功用 pod控制器有多种类型 Pod与控制器之间的关系 Pod控制器种类及yaml格式 Deployment StatefulSet Daem ...
域控制器的深度详解！
域控制器的深度详解! 参考链接:https://www.youcheyihou.com/news/595827 汽车智能网联化带来信息流大量增加,汽车电子电气(EE)架构将迎来升级,如同中国古代历史社 ...
k8s pod控制器详解（ReplicaSet、Deployment、Horizontal Pod Autoscaler）
一.Pod控制器介绍 Pod是kubernetes的最小管理单元,在kubernetes中,按照pod的创建方式可以将其分为两类: 自主式pod:kubernetes直接创建出来的Pod,这种pod删 ...
k8s的yaml文件配置详解（三）
k8s的服务资源文件配置详解注:本文章只作配置项解释,请灵活运用 --- #Service kind: Service apiVersion: v1 metadata: name: service ...
Kubernetes（k8s）权限管理RBAC详解
文章目录一.简介二.用户分类三.K8s角色&角色绑定(以ServiceAccount展开讲解) 1)授权介绍 2)角色(Role和ClusterRole) 3)角色绑定(RoleBind ...
k8s的自定义资源代码生成详解
为什么下这篇文章呢,在代码生成这一块跌了两次跟头,说白了只知道照抄,并不知道里面到底是干什么的,要做到知其然并知其所以然,也是为以后在自动生成代码的时候做一个参考. 生成的项目目录结构如下 . ├── ...

k8s pod控制器使用以及详解

pod的创建方式

什么是pod控制器

控制器的种类

1、ReplicaSet

配置模板

1、创建一个ReplicaSet

2、扩缩容

3、镜像版本变更

4、删除rs

2、Deployment

功能

配置模板

1、创建和删除Deployment

2、扩缩容

3、镜像更新

4、版本回退

金丝雀发布

Horizontal Pod Autoscaler

1、安装metrics-server

2、安装metrics-server

3、查看pod运行情况

4、使用kubectl top node 查看资源使用情况

5、 准备deployment和servie

6、创建service

7、查看

8、 部署HPA

9、 测试

DaemonSet

配置模板

1、创建ds

2、删除daemonset

Job

配置模板

1、创建一个job

2、删除

CronJob

配置模板

1、创建cronJob

2、删除cronjob

pod调度

什么是调度

调度规则

定向调度

1、定向调度-> nodeName

2、定向调度 -> NodeSelector

k8s pod控制器使用以及详解相关推荐

最新文章

热门文章

5、准备deployment和servie

8、部署HPA

9、测试