kubernetes（k8s）五种类型资源控制器

资源控制器

一、资源控制器概述

Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为
控制器又被称为工作负载，pod通过控制器实现应用的运维，比如伸缩、升级等

1、控制器的类型

1> deployment：   适合无状态的服务部署

2> StatefullSet： 适合有状态的服务部署

3> DaemonSet：    一次部署，所有的node节点都会部署，例如一些典型的应用场景：
    运行集群存储 daemon，例如在每个Node上运行 glusterd、ceph
    在每个Node上运行日志收集 daemon，例如 fluentd、 logstash
    在每个Node上运行监控 daemon，例如 Prometheus Node Exporter

4> Job：         一次性的执行任务

5> Cronjob：      周期性的执行任务

6> ReplicationController 和 ReplicaSet

7>Horizontal Pod Autoscaler

二、资源控制器的作用及使用

【Deployment】

适合部署无状态的应用服务，用来管理pod和replicaset，具有上线部署、副本设定、滚动更新、回滚等功能，还可提供声明式更新
例如只更新一个新的Image

1、Deployment的概述

#deployment的引用
  Deployment为Pod和Replica Set提供了一个声明式定义(declarative) 方法， 用来替代以前的Replication Controller来方便的管理应用，Deployment 主要功能是保证有足够的 Pod 正常对外提供服务


#应用场景：
			1>定义Deployment来创建Pod和ReplicaSet
			2>滚动升级和回滚应用
			3>扩容和缩容
			4>暂停和继续Deployment
			
声明式（deployment）: apply(优)	create
命令式（rs):			create(优)	apply

2、Deployment控制器的测试使用

编写配置清单：Deployment-nginx.yaml

#编写配置清单：
[root@m01 /mnt]# cat deployment-nginx.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx     #Deployment 的名称
  labels:
    app: nginx
spec:
  replicas: 3       # 创建 Pod 的副本数
  selector:         #定义 Deployment 如何找到要管理的 Pod，与 template 的 label（标签）对应
    matchLabels:
      app: nginx
  template:          #字段包含以下字段：
    metadata:
      labels:
        app: nginx    #使用 label（标签）标记 Pod
    spec:             #表示 Pod 运行一个名字为 nginx 的容器
      containers:
      - name: nginx
        image: nginx:1.15       #表示 Pod 运行一个名字为 nginx 的容器
        ports:                  #容器用于发送和接收流量的端口
        - containerPort: 80





#创建pod
[root@m01 /mnt]# kubectl create -f deployment-nginx.yaml 
deployment.apps/deployment-nginx created

#查看pod（已创建三个副本）
[root@m01 /mnt]# kubectl get deployments.apps
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
deployment-nginx   3/3     3            3           19h

[root@m01 /mnt]# kubectl get pods
NAME                                READY   STATUS    RESTARTS   AGE
deployment-nginx-746ccc65d8-bst5k   1/1     Running   0          9s
deployment-nginx-746ccc65d8-fm8vk   1/1     Running   0          9s
deployment-nginx-746ccc65d8-ghz9h   1/1     Running   0          9s





#查看所有类型的pod资源
[root@m01 /mnt]# kubectl get all
NAME                                    READY   STATUS    RESTARTS   AGE
pod/deployment-nginx-746ccc65d8-bst5k   1/1     Running   0          2m14s
pod/deployment-nginx-746ccc65d8-fm8vk   1/1     Running   0          2m14s
pod/deployment-nginx-746ccc65d8-ghz9h   1/1     Running   0          2m14s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/deployment-nginx   3/3     3            3           2m14s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/deployment-nginx-746ccc65d8   3         3         3       2m14s

#删除所有pod
[root@m01 /mnt]# kubectl delete pods --all
pod "deployment-nginx-746ccc65d8-bst5k" deleted
pod "deployment-nginx-746ccc65d8-fm8vk" deleted
pod "deployment-nginx-746ccc65d8-ghz9h" deleted






#更新资源清单
[root@m01 /mnt]# kubectl apply -f deployment-nginx.yaml 
deployment.apps/deployment-nginx configured



#设定记录更新记录
[root@m01 /mnt]# kubectl apply -f deployment-nginx.yaml --record 
.......
...
deployment.apps/deployment-nginx configured



#查看回滚记录
[root@m01 /mnt]# kubectl rollout history deployment deployment-nginx 
deployment.apps/deployment-nginx 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=deployment-nginx.yaml --record=true
2         kubectl apply --filename=deployment-nginx.yaml --record=true

3、Deployment（查看详细信息）

查看两种方式：describe或者edit

#使用describe
[root@m01 /mnt]#  kubectl describe deploy deployment-nginx    #两种方式都可以查看pod的更详细的信息，包括各种类型的名称、资源、事件等
Name:                   deployment-nginx
Namespace:              hzl
CreationTimestamp:      Fri, 06 Aug 2021 00:48:05 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
.......
....






#使用edit查看资源清单
[root@m01 /mnt]# kubectl edit deploy deployment-nginx 

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2021-08-05T16:48:05Z"
  generation: 1
  labels:
    app: nginx
  name: deployment-nginx
  namespace: hzl
  resourceVersion: "285090"
  uid: fe610527-f936-4170-adff-478178035fda
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:           #此段解释的是滚动更新机制
      maxSurge: 25%          #25%指的是pod数量的百分比，最多可以扩容125%'
      maxUnavailable: 25%    #25%指的是pod数量的百分比，最多可以缩容75%
    type: RollingUpdate
  ......
  ....

4、更新

一般对应用程序升级或者版本迭代时，会通过 Deployment 对 Pod 进行滚动更新。

#设置更新（设定更新的版本）
[root@m01 /mnt]# kubectl set image deployment deployment-nginx nginx=nginx=:1.15
deployment.apps/deployment-nginx image updated
[root@m01 /mnt]# kubectl get pods      #后端pod已经开始更新
NAME                                READY   STATUS             RESTARTS   AGE
deployment-nginx-6dfc86465-mtxq4    0/1     InvalidImageName   0          20s
deployment-nginx-75b69bd684-fn6jc   1/1     Running            0          10m
deployment-nginx-75b69bd684-hw77k   1/1     Running            0          10m
deployment-nginx-75b69bd684-l664f   1/1     Running            0          10m

5、回滚

当新版本不稳定时，可以对其进行回滚操作，默认情况下，所有 Deployment 的 rollout 历史都保留在系统中， 可以随时回滚

#查看构建历史
[root@m01 /mnt]# kubectl rollout history deployment deployment-nginx 
deployment.apps/deployment-nginx 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=deployment-nginx.yaml --record=true
2         kubectl apply --filename=deployment-nginx.yaml --record=true
3         kubectl apply --filename=deployment-nginx.yaml --record=true



#回滚上一个版本（开始回滚）
[root@m01 /mnt]# kubectl rollout undo deployment deployment-nginx 
deployment.apps/deployment-nginx rolled back



#查看构建历史（发现历史 2 被删除，新增了历史 4）
[root@m01 /mnt]# kubectl rollout history deployment deployment-nginx 
deployment.apps/deployment-nginx 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=deployment-nginx.yaml --record=true
3         kubectl apply --filename=deployment-nginx.yaml --record=true
4         kubectl apply --filename=deployment-nginx.yaml --record=true




#回滚至指定的版本（回滚到1版本）
[root@m01 /mnt]# kubectl rollout undo deployment deployment-nginx --to-revision=1
deployment.apps/deployment-nginx rolled back
#查看
[root@m01 /mnt]# kubectl rollout history deployment deployment-nginx 
deployment.apps/deployment-nginx 
REVISION  CHANGE-CAUSE
3         kubectl apply --filename=deployment-nginx.yaml --record=true
4         kubectl apply --filename=deployment-nginx.yaml --record=true
5         kubectl apply --filename=deployment-nginx.yaml --record=true

6、扩容

K8S 中支持横向扩容的方法

#方式一：scale
[root@m01 /mnt]# kubectl scale deployment deployment-nginx --replicas=4
deployment.apps/deployment-nginx scaled
[root@m01 /mnt]# kubectl get -f deployment-nginx.yaml      #查看已扩建至4个
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
deployment-nginx   4/4     4            4           19h



#方式二：patch
[root@m01 /mnt]# kubectl patch deployments.apps deployment-nginx -p '{"spec": {"replicas": 3}}'
deployment.apps/deployment-nginx patched
[root@m01 /mnt]# kubectl get -f deployment-nginx.yaml       #查看已改变至三个
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
deployment-nginx   3/3     3            3           19h

暂停部署与取消暂停部署

#暂停部署：pause
[root@m01 /mnt]# # kubectl rollout pause deployment deployment-nginx.yaml 

#取消暂停部署
[root@m01 /mnt]# kubectl rollout resume deployment deployment-nginx deployment.apps/deployment-nginx  resumed

#查看详情
[root@m01 /mnt]# kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
deployment-nginx-746ccc65d8-55w6x   1/1     Running   0          15m   10.244.2.18   nod02   <none>           <none>
deployment-nginx-746ccc65d8-gbrsh   1/1     Running   0          15m   10.244.2.19   nod02   <none>           <none>
deployment-nginx-746ccc65d8-nfkl4   1/1     Running   0          15m   10.244.2.20   nod02   <none>           <none>

【SatefulSet】

StatefulSet 是用来管理 有状态服务，为了解决有状态服务的问题，而 Deployment 和 ReplicaSet 更适用于无状态服务的部署

1、SatefulSet概述

1》适合部署有状态应用，解决Pod的独立生命周期，保持Pod启动顺序和唯一性，
2》稳定，唯一的网络标识符，持久存储（例如：etcd配置文件，节点地址发生变化，将无法使用）
3》有序，优雅的部署和扩展、删除和终止（例如：mysql主从关系，先启动主，再启动从）
4》有序，滚动更新

StatefulSet作为Controller为Pod提供唯一的标识， 它可以保证部署和scale的顺序
StatefulSet是为了解决有状态服务的问题(对应Deployments和Replica Sets是为无状态服务而设计)

#其应用场景：(数据库)
	稳定的持久化存储， 即Pod重新调度后还是能访问到相同的持久化数据， 基于PVC来实现
    稳定的网络标志， 即Pod重新调度后其Pod Name和HostName不变， 基于Headless Service(即没有ip地址和端口的ClusterIP) 来实现
	有序部暑， 有序扩展， 即Pod是有顺序的， 在部若或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1， 在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态) ， 基于initcontainers来实现
    有序收缩，有序删除(即从N-1到0)

#无状态服务的特点：
1）deployment 认为所有的pod都是一样的
2）不用考虑顺序的要求
3）不用考虑在哪个node节点上运行
4）可以随意扩容和缩容



#有状态服务的特点：
1）实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
2）实例之间不对等的关系，以及依靠外部存储的应用

常规的service服务和无头服务的区别

service：         一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现
Headless service：   无头服务，不需要cluster-IP，直接绑定具体的Pod的IP，无头服务经常用于statefulset的有状态部署

2、SatefulSet的应用场景

#StatefulSet 应用场景：

    稳定的、唯一的网络标识符。
    稳定的、持久的存储。
    有序的、优雅的部署和缩放。
    有序的、自动的滚动更新。

【Job】

Job 负载批处理任务，仅执行一次的任务，它能够保证批处理任务的一个或者多个 Pod 成功执行结束

1、Job特点

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

jop的测试使用

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

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

apiVersion: batch/v1
kind: Job      
metadata:
  name: pc-job
  namespace: dev
spec:
  manualSelector: true
  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 $i;sleep 3;done"]


# 创建job
[root@master ~]# kubectl create -f pc-job.yaml
job.batch/pc-job created

# 查看job
[root@master ~]# 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@master ~]# 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@master ~]# 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

# 删除job
[root@master ~]# kubectl delete -f pc-job.yaml
job.batch "pc-job" deleted

【CronJob】

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

1、CronJob的资源清单文件

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

#重点解释的选项：
schedule: cron表达式，用于指定任务的执行时间
	*/1    *      *    *     *
	<分钟> <小时> <日> <月份> <星期>

    分钟 值从 0 到 59.
    小时 值从 0 到 23.
    日 值从 1 到 31.
    月 值从 1 到 12.
    星期 值从 0 到 6, 0 代表星期日
    多个时间可以用逗号隔开； 范围可以用连字符给出；*可以作为通配符； /表示每...
concurrencyPolicy:
	Allow:   允许Jobs并发运行(默认)
	Forbid:  禁止并发运行，如果上一次运行尚未完成，则跳过下一次运行
	Replace: 替换，取消当前正在运行的作业并用新作业替换它

2、cronjob的使用

#创建pc-cronjob.yam
apiVersion: batch/v1beta1
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 i in 9 8 7 6 5 4 3 2 1; do echo $i;sleep 3;done"]


# 创建cronjob
[root@master ~]# kubectl create -f pc-cronjob.yaml
cronjob.batch/pc-cronjob created

# 查看cronjob
[root@master ~]# kubectl get cronjobs -n dev
NAME         SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
pc-cronjob   */1 * * * *   False     0        <none>          6s

# 查看job
[root@master ~]# 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@master ~]# 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


# 删除cronjob
[root@master ~]# kubectl  delete -f pc-cronjob.yaml
cronjob.batch "pc-cronjob" deleted

【DaemonSet】(DS)

1、简述ds

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

2、DaemonSet控制器的特点

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

3、DaemonSet的资源清单文件

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




# 创建daemonset
[root@master ~]# kubectl create -f  pc-daemonset.yaml
daemonset.apps/pc-daemonset created

# 查看daemonset
[root@master ~]#  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@master ~]#  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      

# 删除daemonset
[root@master ~]# kubectl delete -f pc-daemonset.yaml
daemonset.apps "pc-daemonset" deleted

【Horizontal Pod Autoscaler】(HPA)

1、 HPA的概述

我们已经可以实现通过手工执行kubectl scale命令实现Pod扩容或缩容，但是这显然不符合Kubernetes的定位目标–自动化、智能化。 Kubernetes期望可以实现通过监测Pod的使用情况，实现pod数量的自动调整，于是就产生了Horizontal Pod Autoscaler（HPA）这种控制器

HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理

2、 HPA测试

#安装metrics-server
(metrics-server可以用来收集集群中的资源使用情况)
# 安装git
[root@master ~]# yum install git -y
# 获取metrics-server, 注意使用的版本
[root@master ~]# git clone -b v0.3.6 https://github.com/kubernetes-incubator/metrics-server
# 修改deployment, 注意修改的是镜像和初始化参数
[root@master ~]# cd /root/metrics-server/deploy/1.8+/
[root@master 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
````
![在这里插入图片描述](https://img-blog.csdnimg.cn/ab15975bcb004912bd30940eca148770.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl81NTk3Mjc4MQ==,size_16,color_FFFFFF,t_70)`````bash
# 安装metrics-server
[root@master 1.8+]# kubectl apply -f ./

# 查看pod运行情况
[root@master 1.8+]# kubectl get pod -n kube-system
metrics-server-6b976979db-2xwbj   1/1     Running   0          90s

# 使用kubectl top node 查看资源使用情况
[root@master 1.8+]# kubectl top node
NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
master   98m          4%     1067Mi          62%
node1    27m          1%     727Mi           42%
node2    34m          1%     800Mi           46%
[root@master 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安装完成

#准备deployment和servie(为了操作简单,直接使用命令)
# 创建deployment 
[root@master 1.8+]# kubectl run nginx --image=nginx:latest --requests=cpu=100m -n dev
# 创建service
[root@master 1.8+]# kubectl expose deployment nginx --type=NodePort --port=80 -n dev

# 查看
[root@master 1.8+]# kubectl get deployment,pod,svc -n dev
NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx   1/1     1            1           47s

NAME                         READY   STATUS    RESTARTS   AGE
pod/nginx-7df9756ccc-bh8dr   1/1     Running   0          47s

NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/nginx   NodePort   10.109.57.248   <none>        80:31136/TCP   35s

部署HPA

#创建资源清单pc-hpa.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: pc-hpa
  namespace: dev
spec:
  minReplicas: 1  #最小pod数量
  maxReplicas: 10 #最大pod数量
  targetCPUUtilizationPercentage: 3 # CPU使用率指标
  scaleTargetRef:   # 指定要控制的nginx信息
    apiVersion: apps/v1
    kind: Deployment  
    name: nginx

# 创建hpa
[root@master 1.8+]# kubectl create -f pc-hpa.yaml
horizontalpodautoscaler.autoscaling/pc-hpa created

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

测试：

1）hpa变化
(使用压测工具对service地址进行压测，然后通过控制台查看hpa和pod的变化)
[root@master ~]# 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


2）deployment变化
[root@master ~]# 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

3）`pod变化`
[root@master ~]# 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