k8s

k8s 中 Pod 的控制器

k8s 中 Pod 都有那些控制器

Posted by liz on September 30, 2022

k8s 中 Pod 的控制器

前言

Pod 是 Kubernetes 集群中能够被创建和管理的最小部署单元。所以需要有工具去操作和管理它们的生命周期,这里就需要用到控制器了。

Pod 控制器由 master 的 kube-controller-manager 组件提供，常见的此类控制器有 Replication Controller、ReplicaSet、Deployment、DaemonSet、StatefulSet、Job 和 CronJob 等，它们分别以不同的方式管理 Pod 资源对象。

Replication Controller

RC 是 k8s 集群中最早的保证 Pod 高可用的 API 对象。它的作用就是保证集群中有指定数目的 pod 运行。

当前运行的 pod 数目少于指定的数目，RC 就会启动新的 pod 副本，保证运行 pod 数量等于指定数目。

当前运行的 pod 数目大于指定的数目，RC 就会杀死多余的 pod 副本。

直接上栗子

cat <<EOF >./pod-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
EOF

在新版的 Kubernetes 中建议使用 ReplicaSet (RS)来取代 ReplicationController。

ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，但 ReplicaSet 支持集合式 selector。

关于 ReplicationController 这里也不展开讨论了，主要看下 ReplicaSet。

ReplicaSet

RS 是新一代 RC，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持支持集合式 selector。

副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。

下面看下 Deployment 中是如何使用 ReplicaSet 的。

Deployment

一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力,每一个 Deployment 都对应集群中的一次部署。

一般使用 Deployment 来管理 RS，可以用来创建一个新的服务，更新一个新的服务，也可以用来滚动升级一个服务。

滚动升级一个服务，滚动升级一个服务，实际是创建一个新的 RS，然后逐渐将新 RS 中副本数增加到理想状态，将旧 RS 中的副本数减小到 0 的复合操作；这样一个复合操作用一个 RS 是不太好描述的，所以用一个更通用的 Deployment 来描述。

举个栗子

cat <<EOF >./nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels: # 这里定义需要管理的 pod，通过 Pod 的标签进行匹配
      app: nginx
  template:
    metadata:
      labels: # 运行的 pod 的标签
        app: nginx
    spec:
      containers: # pod 中运行的容器
      - name: nginx
        image: nginx:1.14.2 
        ports:
        - containerPort: 80
EOF

部署

$ kubectl apply -f nginx-deployment.yaml -n study-k8s
deployment.apps/nginx-deployment created

$ study-k8s kubectl describe deployment nginx-deployment -n study-k8s
Name:                   nginx-deployment
Namespace:              study-k8s
CreationTimestamp:      Mon, 26 Sep 2022 09:06:16 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               3 desired | 3 updated | 3 total | 1 available | 2 unavailable
StrategyType:           RollingUpdate # 默认是滚动更新  
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge  # 滚动更新的策略，最大 25% 不可用，最大 25% 增加
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.14.2
    Port:         80/TCP
    Host Port:    0/TCP
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      False   MinimumReplicasUnavailable
  Progressing    True    ReplicaSetUpdated
OldReplicaSets:  <none>
NewReplicaSet:   nginx-deployment-66b6c48dd5 (3/3 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  3s    deployment-controller  Scaled up replica set nginx-deployment-66b6c48dd5 to 3

可以看到 Deployment 中默认的更新方式滚动更新，并且默认的滚动更新的策略是 最大 25% 不可用，最大 25% 增加。

更新 Deployment

1、直接更新

$ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.20.1 -n study-k8s

# 或者  

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.20.1 -n study-k8s

2、对 Deployment 执行 edit 操作

$ kubectl get deployment -n study-k8s
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           18m

$ kubectl edit deployment -n study-k8s
# 修改对应的镜像版本，保存即可  

    spec:
      containers:
      - image: nginx:1.20.3
        imagePullPolicy: IfNotPresent
        name: nginx

3、直接编辑部署的 YAML 文件，然后重新 Apply

$ kubectl apply -f nginx-deployment.yaml -n study-k8s
deployment.apps/nginx-deployment configured

$ kubectl get pods -n study-k8s
NAME                                READY   STATUS              RESTARTS   AGE
nginx-deployment-6bcf8f4884-dxxxg   1/1     Running             0          38s
nginx-deployment-6bcf8f4884-plbkh   0/1     ContainerCreating   0          13s
nginx-deployment-cc4b758d6-lzlxl    1/1     Running             0          7m25s
nginx-deployment-cc4b758d6-r5rkb    1/1     Running             0          7m11s

回滚 deployment

了解了如何更新 deployment，那么当部署出现问题，如果回滚呢，下面来详细介绍下

查看之前部署的版本

$ kubectl rollout history deployment/nginx-deployment -n study-k8s
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         <none>
4         <none>
5         <none>
6         <none>
7         image updated to 1.21.1

REVISION:就是之前部署的版本信息；

CHANGE-CAUSE：变动的备注信息。

$ kubectl apply -f nginx-deployment.yaml -n study-k8s --record

加上 --record，或者每次部署完之后，使用

$ kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.21.1" -n study-k8s

CHANGE-CAUSE 信息就会被记录

查看历史版本的详细详细

$ kubectl rollout history deployment/nginx-deployment --revision=6 -n study-k8s
deployment.apps/nginx-deployment with revision #6
Pod Template:
  Labels:	app=nginx
	pod-template-hash=d985dd8bf
  Containers:
   nginx:
    Image:	nginx:1.20.3
    Port:	80/TCP
    Host Port:	0/TCP
    Environment:	<none>
    Mounts:	<none>
  Volumes:	<none>

回滚

# 回滚到上一个版本
$ kubectl rollout undo deployment/nginx-deployment -n study-k8s

# 回滚到指定的版本
$ kubectl rollout undo deployment/nginx-deployment --to-revision=5 -n study-k8s

缩放 Deployment

$ kubectl scale deployment/nginx-deployment --replicas=10 -n study-k8s

$  kubectl get pods -n study-k8s
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-66b6c48dd5-5scbj   1/1     Running   0          44s
nginx-deployment-66b6c48dd5-7nmtp   1/1     Running   0          44s
nginx-deployment-66b6c48dd5-f5xsg   1/1     Running   0          12m
nginx-deployment-66b6c48dd5-fnpnb   1/1     Running   0          12m
nginx-deployment-66b6c48dd5-gg4ng   1/1     Running   0          44s
nginx-deployment-66b6c48dd5-qd5z7   1/1     Running   0          44s
nginx-deployment-66b6c48dd5-qqh4m   1/1     Running   0          44s
nginx-deployment-66b6c48dd5-xww49   1/1     Running   0          44s
nginx-deployment-66b6c48dd5-zndlh   1/1     Running   0          44s
nginx-deployment-66b6c48dd5-zp45g   1/1     Running   0          12m

关于使用 deployment 实现 k8s 中的几种部署策略，可参见Kubernetes 部署策略详解

StatefulSet

StatefulSet 用来管理有状态的应用。

在 Pods 管理的基础上，保证 Pods 的顺序和一致性。与 Deployment一样，StatefulSet 也是使用容器的 Spec 来创建Pod，与之不同 StatefulSet 创建的 Pods 在生命周期中会保持持久的标记（例如Pod Name）。

StatefulSet 适用于具有以下特点的应用：

1、稳定的、唯一的网络标识符；

2、稳定的、持久的存储；

3、有序的、优雅的部署和扩缩；

4、有序的、自动的滚动更新。

那么什么是有状态服务什么是无状态服务呢？

无状态服务

无状态服务不会在本地存储持久化数据。多个服务实例对于同一个用户请求的响应结果是完全一致的。这种多服务实例之间是没有依赖关系,比如web应用,在k8s控制器 中动态启停无状态服务的pod并不会对其它的pod产生影响。

有状态服务

有状态服务需要在本地存储持久化数据，典型的是分布式数据库的应用,分布式节点实例之间有依赖的拓扑关系。

比如,主从关系。 如果 K8S 停止分布式集群中任 一实例 pod，就可能会导致数据丢失或者集群的 crash。

来个栗子

cat <<EOF >./pod-statefulSet.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 必须匹配 .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # 默认值是 1
  template:
    metadata:
      labels:
        app: nginx # 必须匹配 .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx:1.14.2 
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
EOF

DaemonSet

DaemonSet：主要是用来保证集群中的每个节点只运行一个 Pod，且保证只有一个 Pod，这非常适合一些系统层面的应用，例如日志收集、资源监控等，这类应用需要每个节点都运行，且不需要太多实例，一个比较好的例子就是 Kubernetes 的 kube-proxy。

当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。

DaemonSet 的应用场景：

1、在每个节点上运行集群守护进程；

2、在每个节点上运行日志收集守护进程；

3、在每个节点上运行监控守护进程。

来个栗子

cat <<EOF >./nginx-daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx-daemonset
spec:
  selector:
    matchLabels:
      app: nginx-daemonset
  template:
    metadata:
      labels:
        app: nginx-daemonset
    spec:
      containers:
      - name: nginx-daemonset
        image: nginx:alpine
        resources:
          limits:
            cpu: 250m
            memory: 512Mi
          requests:
            cpu: 250m
            memory: 512Mi
      imagePullSecrets:
      - name: default-secret
EOF

这样就能在每个节点中部署一个 Pod 了，不过 DaemonSet 也支持通过 label 来选择部署的目标节点

cat <<EOF >./nginx-daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-daemonset
  labels:
    app: nginx-daemonset
spec:
  selector:
    matchLabels:
      app: nginx-daemonset
  template:
    metadata:
      labels:
        app: nginx-daemonset
    spec:
      nodeSelector: # 节点选择，当节点拥有nodeName=node7时才在节点上创建Pod
        nodeName: node7
      containers:
      - name: nginx-daemonset
        image: nginx:alpine
        resources:
          limits:
            cpu: 250m
            memory: 512Mi
          requests:
            cpu: 250m
            memory: 512Mi
      imagePullSecrets:
      - name: default-secret
EOF

Job 和 CronJob

Job 和 CronJob 是负责处理定时任务的。

两者的区别主要在于：

Job 负责处理一次性的定时任务，即仅需执行一次的任务；

CronJob 是基于时间的 Job，就类似于 Linux 系统的 crontab 文件中的一行，在指定的时间周期运行指定的 Job。

首先来创建一个 Job

cat <<EOF >./job-demo.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  template:
    metadata:
      name: job-demo
    spec:
      restartPolicy: Never
      containers:
      - name: counter
        image: busybox
        command:
        - "bin/sh"
        - "-c"
        - "echo hello"  
EOF

运行

$ kubectl apply -f job-demo.yaml

$ kubectl get pods
NAME             READY   STATUS      RESTARTS   AGE
job-demo-8qrd9   0/1     Completed   0          40s
$ study-k8s kubectl get job
NAME       COMPLETIONS   DURATION   AGE
job-demo   1/1           36s        45s
$ kubectl logs -f job-demo-8qrd9
hello

再来看下 CronJob

cat <<EOF >./cronJob-demo.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox:1.28
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo Hello
          restartPolicy: OnFailure
EOF

通过 kubectl get jobs --watch 就能查看 CronJob 的调度

$ kubectl get jobs --watch
NAME               COMPLETIONS   DURATION   AGE
hello-1664449860   1/1           2s         4s
hello-1664449920   0/1                      0s
hello-1664449920   0/1           0s         0s
hello-1664449920   1/1           2s         2s

总结

关于 pod 中的几个控制器最常用的就是 Deployment 和 ReplicaSet；

使用 Deployment 来管理 RS，来实现服务的部署，更新和滚动升级；

StatefulSet 主要用来管理无状态应用；

DaemonSet：主要是用来保证集群中的每个节点只运行一个 Pod，且保证只有一个 Pod，这非常适合一些系统层面的应用，例如日志收集、资源监控等，这类应用需要每个节点都运行，且不需要太多实例，一个比较好的例子就是 Kubernetes 的 kube-proxy；

Job 和 CronJob 是负责处理定时任务的；

Job 负责处理一次性的定时任务，即仅需执行一次的任务；

CronJob 是基于时间的 Job，就类似于 Linux 系统的 crontab 文件中的一行，在指定的时间周期运行指定的 Job。

参考

【Deployments】https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/
【Kubernetes 部署策略详解】https://www.qikqiak.com/post/k8s-deployment-strategies/
【StatefulSet 和 Deployment 区别及选择方式】https://blog.csdn.net/nickDaDa/article/details/90401635
【K8S: 有状态 vs 无状态服务】https://zhuanlan.zhihu.com/p/390440336
【StatefulSet】https://support.huaweicloud.com/basics-cce/kubernetes_0015.html

CATALOG
    FEATURED TAGS
    pgsql go PostgreSQL docker k8s etcd raft 设计模式 算法 消息队列 Redis plan tcp/ip MySQL MongoDB 架构
    FRIENDS