控制器

 ReplicaSet、Deployment、StatefulSet 和 DaemonSet 都是 Kubernetes 中的控制器对象,用于管理 Pod 的创建、扩展、缩减和更新等操作。

一、Deployment

适用无状态服务应用部署;Deployment 是在 ReplicaSet 的基础上提供了更高级功能的控制器。它提供了滚动更新和回滚功能

在这里插入图片描述

1、配置文件
apiVersion: apps/v1 # deployment api 版本
kind: Deployment # 资源类型为 deployment
metadata: # 元信息
  labels: # 标签
    app: nginx-deploy # 具体的 key: value 配置形式
  name: nginx-deploy # deployment 的名字
  namespace: default # 所在的命名空间
spec:
  replicas: 3 # 期望副本数,最终运行的副本数
  revisionHistoryLimit: 10 # 进行滚动更新后,保留的历史版本数
  selector: # 选择器,用于找到匹配的 ReplicaSet(RS)
    matchLabels: # 按照标签匹配
      app: nginx-deploy # 匹配的标签key/value
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时,允许超过期望副本数的额外副本个数或比例,
      maxUnavailable: 25% # 进行滚动更新时,不可用的最大副本个数或比例
    type: RollingUpdate # 更新类型,采用滚动更新
  template: # pod 模板
    metadata: # pod 的元信息
      labels: # pod 的标签
        app: nginx-deploy
    spec: # pod 期望信息
      containers: # pod 的容器
      - image: nginx:1.7.9 # 镜像
        imagePullPolicy: IfNotPresent # 拉取策略
        name: nginx # 容器名称
      restartPolicy: Always # 重启策略
      terminationGracePeriodSeconds: 30 # 删除操作最多宽限多长时间

关于期望副本数replicas、maxSurgemaxUnavailable:

  1. replicas:期望副本数;
  2. maxSurge:允许超过期望副本数的额外副本数,绝对数值或百分比。例如,如果 maxSurge 设置为 1,那么在滚动更新期间,可以将副本数量增加到期望副本数加上1;
  3. maxUnavailable:不可用的最大副本数。绝对数值或百分比。例如,如果 maxUnavailable 设置为 1,那么在滚动更新期间,最多允许有一个副本不可用;

举例:

spec:
  replicas: 3 # 期望副本数
  ...
  strategy:
    rollingUpdate: 
      maxSurge: 1 # 进行滚动更新时,允许超过期望副本数的额外副本个数或比例
      maxUnavailable:1 # 进行滚动更新时,不可用的最大副本个数或比例
    type: RollingUpdate # 更新类型,采用滚动更新

 在此情况下,Kubernetes会根据maxSurge的值先增加1个额外的副本,使得总共有4个副本。然后再逐个替换旧的副本,直到所有旧副本被替换为止。这样可以保证在更新过程中至少有3个可用的副本。

 然而,由于Deployment的replicas值是3,Kubernetes会自动将副本数量调整回到3个。它会逐个替换旧的副本,直到满足replicas定义的副本数为止。这样确保了最终运行的副本数与replicas的值保持一致。

2、创建/查看
# 创建一个 deployment(nginx-deploy)
[root@k8s-master ~]# kubectl create deploy nginx-deploy --image=nginx:1.7.9
deployment.apps/nginx-deploy created
# 或执行 "kubectl create -f xxx.yaml --record"
# --record 会在 annotation 中记录当前命令创建或升级了资源,后续可以查看做过哪些变动操作

# 查看部署信息
[root@k8s-master ~]# kubectl get deployments --show-labels
NAME           READY   UP-TO-DATE   AVAILABLE   AGE     LABELS
nginx-deploy   1/1     1            1           7h22m   app=nginx-deploy

# 查看 rs
[root@k8s-master ~]# kubectl get rs --show-labels
NAME                      DESIRED   CURRENT   READY   AGE    LABELS
nginx-deploy-78d8bf4fd7   1         1         1       4h2m   app=nginx-deploy,pod-template-hash=78d8bf4fd7

# 查看 pod 以及展示标签,可以看到是关联的哪个 rs
[root@k8s-master ~]# kubectl get pod --show-labels
NAME                            READY   STATUS    RESTARTS   AGE    LABELS
nginx-deploy-78d8bf4fd7-d9sb4   1/1     Running   0          4h3m   app=nginx-deploy,pod-template-hash=78d8bf4fd7

通过 NMAE 标签,可以看出:deployment > ReplicaSet(RS)> pod

3、滚动更新
...
spec:
  ...
  strategy: # 更新策略
    rollingUpdate: # 滚动更新配置
      maxSurge: 25% # 进行滚动更新时,允许超过期望副本数的额外副本个数或比例,
      maxUnavailable: 25% # 进行滚动更新时,不可用的最大副本个数或比例
    type: RollingUpdate # 更新类型,采用滚动更新

 只有修改了 deployment 配置文件中的 template 中的属性后,才会触发更新操作。

# 修改 nginx 版本号
[root@k8s-master ~]# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

# 或者 通过 kubectl edit 进行修改
[root@k8s-master ~]# kubectl edit deployment/nginx-deployment 
 
# 检查Deployment的滚动更新状态
[root@k8s-master ~]# kubectl rollout status deploy <deployment_name>

# 查看部署描述,最后展示发生的事件列表也可以看到滚动更新过程
[root@k8s-master ~]# kubectl describe deploy <deployment_name>

# 获取部署信息,UP-TO-DATE 表示已经有多少副本达到了配置中要求的数目
[root@k8s-master ~]# kubectl get deployments 
NAME           READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deploy   1/1     1            1           7h5m

# 可以看到增加了一个新的 rs
[root@k8s-master ~]# kubectl get rs --show-labels
NAME                      DESIRED   CURRENT   READY   AGE
nginx-deploy-754898b577   1         1         1       31m     app=nginx-deploy,pod-template-hash=754898b577
nginx-deploy-78d8bf4fd7   0         0         0       7h21m   app=nginx-deploy,pod-template-hash=78d8bf4fd7

# 可以看到所有 pod 关联的 rs 变成了新的
[root@k8s-master ~]# kubectl get pods --show-labels
NAME                            READY   STATUS    RESTARTS   AGE   LABELS
nginx-deploy-754898b577-gfpjh   1/1     Running   0          19m   app=nginx-deploy,pod-template-hash=754898b577

多个滚动更新并行:
 假设当前有 5 个 nginx:1.7.9 版本,要将版本更新为 1.9.1,当更新成功第三个以后,马上又将期望更新的版本改为 1.9.2,那么此时会立马删除之前的三个,并且立马开启更新 1.9.2 的任务。

4、回滚

 默认情况下,kubernetes会在系统中保存前两次的Deployment的rollout历史记录,以便随时回退(可以修改revision history limit来更改保存的revision数)。

 可以通过设置 .spec.revisonHistoryLimit 的值来指定 deployment 保留多少 revison,如果设置为 0,则不允许 deployment 回退了。

# 获取 revison 的历史列表
kubectl rollout history deployment/nginx-deploy

# 可以查看对应版本详细信息
kubectl rollout history deployment/nginx-deploy --revision=2 

# 回退到上一个版本
kubectl rollout undo deployment/nginx-deploy 

# 回退到指定的 revision 版本
kubectl rollout undo deployment/nginx-deploy --to-revision=2

# 查看
kubectl get deployment
kubectl describe deployment 
5、扩容/缩容

1、通过 kubectl scale 命令的replicas参数可以进行自动扩容/缩容
2、通过 kube edit 编辑 replcas 的值也可以实现扩容/缩容

[root@k8s-master ~]# kubectl scale --replicas=6 deploy [deployName]

[root@k8s-master ~]# kubectl edit deploy [deployName]

扩容/缩容只是直接创建/删除副本数,没有更新 pod 的 template 因此不会创建新的 rs。

6、暂停/恢复滚动更新

 由于每次对 pod template 中的信息发生修改后,都会触发更新 deployment 操作 。
 如果频繁修改信息,就会产生多次更新,同时会产生多个 rs 和多个历史版本(rollout history)而实际上只需要执行最后一次更新即可,当出现此类情况时就可以暂停 deployment 的滚动更新。

# 暂停滚动更新
kubectl rollout pause deploy <name>

# 恢复滚动更新
kubectl rollout resume deploy <name>

二、StatefulSet

专门针对有状态服务进行部署的一个控制器;它与 ReplicaSet 类似,但是在创建和管理 Pod 副本时保持每个 Pod 的标识和稳定的网络身份。StatefulSet 适用于需要持久化存储和稳定网络标识的应用,如数据库或有序队列。

1、配置文件
# “---” 表示yaml文件中嵌套了其他的yaml配置文件
---
apiVersion: v1
kind: Service
metadata:
  name: nginx # Service 对象的名字
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web # StatefulSet 对象的名字
spec:
  serviceName: "nginx" # 使用哪个 Service 来管理 dns
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports: # 容器内部要暴露的端口
        - containerPort: 80 # 暴露的端口号
          name: web # 该端口配置的名字
        volumeMounts: # 加载数据卷
        - name: www # 指定加载哪个数据卷
          mountPath: /usr/share/nginx/html # 加载到容器中的哪个目录
  volumeClaimTemplates: # 数据卷模板
  - metadata: # 数据卷描述
      name: www # 数据卷的名称
      annotations: # 数据卷注释
        volume.alpha.kubernetes.io/storage-class: anything
    spec: # 数据卷的规约
      accessModes: [ "ReadWriteOnce" ] # 访问模式
      resources:
        requests:
          storage: 1Gi # 需要 1G 的存储资源
2、创建/查看
[root@k8s-master ~]# kubectl create -f xx.yaml

# 查看 service 和 statefulset 缩写:sts
[root@k8s-master ~]# kubectl get service nginx
[root@k8s-master ~]# kubectl get statefulset web

# 查看 PVC 信息
[root@k8s-master ~]# kubectl get pvc

# 查看创建的 pod,这些 pod 是有序的
[root@k8s-master ~]# kubectl get pods -l app=nginx

# 查看这些 pod 的 dns
# 运行一个 pod,基础镜像为 busybox 工具包,利用里面的 nslookup 可以看到 dns 信息
[root@k8s-master ~]# kubectl run -i --tty --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh
# 容器中执行:nslookup web-0.nginx
3、扩容/缩容

两种方式:

# 第一种:scale
[root@k8s-master ~]# kubectl scale statefulset web --replicas=5

# 第二种:通过 patch 更新配置文件
[root@k8s-master ~]# kubectl patch statefulset web -p '{"spec":{"replicas":3}}'
4、更新策略

 对于 StatefulSet 控制器,默认情况下使用的是 RollingUpdate 策略,即滚动更新策略,一次只更新一个Pod,确保在更新过程中应用保持可用性。

4.1、RollingUpdate

 StatefulSet 的滚动更新策略,同样是修改 pod template 属性后触发更新,但是由于 pod 是有序的,在 StatefulSet 中更新时是基于 pod 的顺序倒序更新的。

...
spec:
  updateStrategy:
    rollingUpdate:
      partition: [n] # 只会更新那些序号(web-n) >= n 的 pod
    type: RollingUpdate

  partition 默认为 0 ,即全部更新;如果 partition 设置为 3,那么此时滚动更新时,只会更新那些 podName 序号 >= 3 的 pod。

 利用该机制,可以通过控制 partition 的值,来决定只更新其中一部分 pod,确认没有问题后再逐渐增大更新的 pod 数量,最终实现全部 pod 更新。

# 镜像更新
[root@k8s-master ~]# kubectl patch sts web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:1.9.1"}]'

# 或通过 edit 更新
[root@k8s-master ~]# kubectl edit sts web

[root@k8s-master ~]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
web-0   1/1     Running   0          16m
web-1   1/1     Running   0          17m

# 获取 revison 的历史列表
[root@k8s-master ~]# kubectl rollout history sts web

# 可以查看对应版本详细信息:可以观察到有序的更新
[root@k8s-master ~]# kubectl rollout history sts web --revision=2 
4.2、OnDelete

 只有在 pod 被删除时会进行更新操作。

...
spec:
  updateStrategy:
    type: OnDelete
5、删除
# 【级联删除】删除statefulset时会同时删除pods
kubectl delete statefulset web

# 【非级联删除】删除 sts 时不会删除 pods
# 注意:删除sts后,pods就没人管了,之后再删除pod不会重建的
kubectl deelte sts web --cascade=false

# 之后删除service
kubectl delete service nginx

# sts删除后,PVC还会保留着,数据不再使用的话也需要删除
kubectl delete pvc www-web-0 www-web-1

三、DaemonSet

 DaemonSet 保证在每个 Node 上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:

  • 日志收集,比如 fluentd,logstash 等
  • 系统监控,比如 Prometheus Node Exporter,collectd,New Relic agent,Ganglia gmond 等
  • 系统程序,比如 kube-proxy, kube-dns, glusterd, ceph 等
1、配置文件
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      app: logging
  template:
    metadata:
      labels:
        app: logging
        id: fluentd
      name: fluentd
    spec:
      nodeSelector: 
        svc_type: microsvc
      containers:
      - name: fluentd-es
        image: agilestacks/fluentd-elasticsearch:v1.3.0
        env:
         - name: FLUENTD_ARGS
           value: -qq
        volumeMounts: # 加载数据卷,避免数据丢失
         - name: containers # 数据卷名字
           mountPath: /var/lib/docker/containers # 将数据卷挂载到容器内的哪个目录
         - name: varlog
           mountPath: /varlog
      volumes: # 定义数据卷
         - hostPath: # 数据卷类型;主机路径的模式,也就是与node的共享目录
             path: /var/lib/docker/containers # node中的共享目录
           name: containers
         - hostPath:
             path: /var/log
           name: varlog
2、指定 Node 节点

没有指定 node 节点时,系统会为每个非 master 节点部署。

DaemonSet 会忽略 Node 的 unschedulable 状态,有两种方式来指定 Pod 只运行在指定的 Node 节点上:

  • nodeSelector:只调度到匹配指定 label 的 Node 上
  • nodeAffinity:功能更丰富的 Node 选择器,比如支持集合操作
  • podAffinity:调度到满足条件的 Pod 所在的 Node 上
2.1、nodeSelector

 只调度到匹配指定标签的 Node 上;

# 给 node1 打上标签
kubectl label nodes k8s-node1 svc_type=microsvc

# 查看节点标签
kubectl get no --show-labels

# 然后再 daemonset 配置中设置 nodeSelector
spec:
  template:
    spec:
      nodeSelector:
        svc_type: microsvc
2.2、nodeAffinity

nodeAffinity 目前支持两种:requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution,分别代表必须满足条件和优选条件。

比如下面的例子代表调度到包含标签 wolfcode.cn/framework-name 并且值为 spring 或 springboot 的 Node 上,并且优选还带有标签 another-node-label-key=another-node-label-value 的Node。

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: wolfcode.cn/framework-name
            operator: In
            values:
            - spring
            - springboot
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: pauseyyf/pause
2.3、podAffinity

podAffinity 基于 Pod 的标签来选择 Node,仅调度到满足条件Pod 所在的 Node 上,支持 podAffinity 和 podAntiAffinity。这个功能比较绕,以下面的例子为例:

  • 如果一个 “Node 所在空间中包含至少一个带有 auth=oauth2 标签且运行中的 Pod”,那么可以调度到该 Node
  • 不调度到 “包含至少一个带有 auth=jwt 标签且运行中 Pod”的 Node 上
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: auth
            operator: In
            values:
            - oauth2
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: auth
              operator: In
              values:
              - jwt
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: pauseyyf/pause
3、更新

 默认使用 RollingUpdate,不建议使用 RollingUpdate,建议使用 OnDelete 模式,这样避免频繁更新 ds;

四、HPA 自动扩/缩容

通过监控 pod 的 cpu、内存使用率或自定义指标进行自动的扩容或缩容 pod 的数量。

 通常用于 Deployment;不适用于无法扩/缩容的对象,如 DaemonSet。

  • 控制管理器每隔30s(可以通过–horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
  • 支持三种metrics类型
    • 预定义metrics(比如Pod的CPU)以利用率的方式计算
    • 自定义的Pod metrics,以原始值(raw value)的方式计算
    • 自定义的object metrics
  • 支持两种metrics查询方式:Heapster和自定义的REST API
  • 支持多metrics
1、开启指标服务

 用于之后查看资源的cpu、内存的指标。

# 下载 metrics-server 组件配置文件
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml -O metrics-server-components.yaml

# 修改镜像地址为国内的地址
sed -i 's/k8s.gcr.io\/metrics-server/registry.cn-hangzhou.aliyuncs.com\/google_containers/g' metrics-server-components.yaml

# 修改容器的 tls 配置:不验证 tls,在 containers 的 args 参数中增加 “--kubelet-insecure-tls” 参数

# 安装组件
kubectl apply -f metrics-server-components.yaml

# 查看 pod 状态
kubectl get pods --all-namespaces | grep metrics

# 查看 pods 资源使用情况
kubectl top pods
2、cpu、内存指标监控

 实现 cpu 或内存的监控,首先有个前提条件是该对象必须配置了 resources.requests.cpuresources.requests.memory 才可以,然后配置当 cpu、memory 达到上述配置的百分比后进行扩容或缩容。

创建一个 HPA:

  1. 先准备一个好一个有做资源限制的 deployment
  2. 执行命令 kubectl autoscale deploy nginx-deploy --cpu-percent=20 --min=2 --max=5cpu利用率达到20%左右,进行扩容,上限为5个;利用率降到20%以下时,进行缩容,最低降为2个
  3. 通过 kubectl get hpa 可以获取 HPA 信息
# 测试:找到对应服务的 service,编写循环测试脚本提升内存与 cpu 负载
while true; do wget -q -O- http://<ip:port> > /dev/null ; done
# 可以通过多台机器执行上述命令,增加负载,当超过负载后可以查看 pods 的扩容情况 

# 查看 pods 资源使用情况
kubectl top pods

# 扩容测试完成后,再关闭循环执行的指令,让 cpu 占用率降下来,然后过 5 分钟后查看自动缩容情况
3、自定义 metrics
  • 控制管理器开启–horizontal-pod-autoscaler-use-rest-clients
  • 控制管理器的–apiserver指向API Server Aggregator
  • 在API Server Aggregator中注册自定义的metrics API

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐