k8s POD控制器

POD控制器

Pod控制器，又称为工作负载（workload），是Kubernetes中用于实现管理Pod的中间层，它确保Pod资源符合预期的状态。当Pod资源出现故障时，Pod控制器会尝试进行重启，若根据重启策略无效，则会重新新建Pod资源。以下是Pod控制器的详细介绍：

一、Pod控制器的作用

1.1. 确保Pod副本数量：

Pod控制器代用户创建指定数量的Pod副本，并确保这些副本数量符合预期状态。

1.2. 自动恢复：

当Pod资源出现故障时，控制器会根据定义的策略重新编排Pod，确保应用的持续运行。

1.3. 扩缩容：

支持滚动式自动扩容和缩容功能，根据应用需求调整Pod数量。

1.4. 更新和回滚：

对于某些控制器（如Deployment），支持应用的滚动更新和版本回退。

二、常见的Pod控制器类型

2.1 ReplicaSet/ReplicationController

作用：用于保证Pod的副本数量维持在用户指定的数量。它支持Pod数量的扩缩Pod模板的更新，但不涉及应用状态的管理。
组件：主要由用户期望的Pod副本数量、标签选择器（用于判断哪个Pod归自理）和Pod资源模板组成。
特点：帮助用户管理无状态的Pod资源，精确反应用户定义的目标数量ReplicaSet不是直接使用的控制器，而是通常通过Deployment来间接管理。

2.1.1 ReplicationController(RC)

apiVersion: v1
kind: ReplicationController
metadata:
 name: rc-demo
spec: # rc期望
 replicas: 3 # 定义当前pod副本数量
 selector: # pod选择器
  app: rc-demo # 选择符合选择器标签的pod
 template: # 模版
  metadata:
   labels:
    app: rc-demo
  spec: # 容器期望
   containers:
   - name: rc-demo-container
     image: wangyanglinux/myapp:v1.0
     env: #环境变量
     - name: GET_HOSTS_FROM
       value: dns
     - name: zhangsan
       value: "123"
     ports:
     - containerPort: 80

[root@master 5]# kubectl get rc
NAME      DESIRED   CURRENT   READY   AGE
rc-demo   3         3         3       25s

[root@master 5]# kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
rc-demo-9rw48   1/1     Running   0          21s
rc-demo-hxtj8   1/1     Running   0          21s
rc-demo-v687d   1/1     Running   0          21s

[root@master 5]# kubectl label pod rc-demo-nrkvf version=v1
pod/rc-demo-nrkvf labeled
[root@master 5]# kubectl get pod --show-labels
NAME            READY   STATUS    RESTARTS   AGE     LABELS
rc-demo-9rw48   1/1     Running   0          5m38s   app=rc-demo
rc-demo-hxtj8   1/1     Running   0          5m38s   app=rc-demo
rc-demo-nrkvf   1/1     Running   0          4m17s   app=rc-demo,version=v1

[root@master 5]# kubectl label pod rc-demo-nrkvf app=test --overwrite
pod/rc-demo-nrkvf labeled

[root@master 5]# kubectl get pod --show-labels
NAME            READY   STATUS    RESTARTS   AGE     LABELS
rc-demo-9rw48   1/1     Running   0          6m35s   app=rc-demo
rc-demo-hxtj8   1/1     Running   0          6m35s   app=rc-demo
rc-demo-nrkvf   1/1     Running   0          5m14s   app=test,version=v1
rc-demo-sbhb2   1/1     Running   0          9s      app=rc-demo


# 调整副本数量
[root@master 5]# kubectl scale rc rc-demo --replicas=10
replicationcontroller/rc-demo scaled
[root@master 5]# kubectl get pod --show-labels
NAME            READY   STATUS    RESTARTS   AGE    LABELS
rc-demo-98w2k   1/1     Running   0          10s    app=rc-demo
rc-demo-9rw48   1/1     Running   0          13m    app=rc-demo
rc-demo-cdvrq   1/1     Running   0          10s    app=rc-demo
rc-demo-cf42f   1/1     Running   0          10s    app=rc-demo
rc-demo-dgj5p   1/1     Running   0          10s    app=rc-demo
rc-demo-f2g6k   1/1     Running   0          10s    app=rc-demo
rc-demo-hxtj8   1/1     Running   0          13m    app=rc-demo
rc-demo-n2fp8   1/1     Running   0          10s    app=rc-demo
rc-demo-nrkvf   1/1     Running   0          12m    app=test,version=v1
rc-demo-nw2h9   1/1     Running   0          10s    app=rc-demo
rc-demo-sbhb2   1/1     Running   0          7m2s   app=rc-demo

[root@master 5]# kubectl label pod rc-demo-nrkvf app=rc-demo --overwrite
pod/rc-demo-nrkvf labeled
[root@master 5]# kubectl get pod --show-labels
NAME            READY   STATUS    RESTARTS   AGE     LABELS
rc-demo-98w2k   1/1     Running   0          41s     app=rc-demo
rc-demo-9rw48   1/1     Running   0          13m     app=rc-demo
rc-demo-cdvrq   1/1     Running   0          41s     app=rc-demo
rc-demo-cf42f   1/1     Running   0          41s     app=rc-demo
rc-demo-dgj5p   1/1     Running   0          41s     app=rc-demo
rc-demo-f2g6k   1/1     Running   0          41s     app=rc-demo
rc-demo-hxtj8   1/1     Running   0          13m     app=rc-demo
rc-demo-n2fp8   1/1     Running   0          41s     app=rc-demo
rc-demo-nrkvf   1/1     Running   0          12m     app=re-demo,version=v1
rc-demo-nw2h9   1/1     Running   0          41s     app=rc-demo
rc-demo-sbhb2   1/1     Running   0          7m33s   app=rc-demo

2.1.2 ReplicaSet(RS)

ReplicaSet的匹配运算符主要包括以下几种，这些运算符用于在Pod模板的标签选择器（selector）中指定选择Pod的规则：

2.1.2.1 matchLabels：

通过直接指定键值对来选择Pod。只有当Pod的标签与matchLabels中定义的标签完全匹配时，该Pod才会被选中。
示例：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: rs-ml-demo
spec:
 replicas: 3
 selector:
  matchLabels: # 匹配标签
   app: rs-ml-demo #matchLabels与pod标签做子集关系匹配
   domian: Noziroh
 template:
  metadata:
   labels:
    app: rs-ml-demo
    domian: Noziroh
    version: v1
  spec:
   containers:
   - name: rs-ml-demo-container
     image: wangyanglinux/myapp:v1.0
     env:
     - name: GET_HOSTS_FROM
       value: dns
     ports:
     - containerPort: 80

[root@master 5]# kubectl get pod
NAME               READY   STATUS    RESTARTS   AGE
rc-demo-9rw48      1/1     Running   0          23m
rc-demo-hxtj8      1/1     Running   0          23m
rc-demo-nrkvf      1/1     Running   0          22m
rs-ml-demo-fm427   1/1     Running   0          20s
rs-ml-demo-kzjph   1/1     Running   0          20s
rs-ml-demo-v6nbn   1/1     Running   0          20s

2.1.2.2 matchExpressions：

提供了一种更灵活的方式来选择Pod，支持使用更复杂的逻辑条件（如AND、OR、NOT等，尽管直接通过matchExpressions实现复杂的逻辑组合需要多个表达式）。
每个matchExpressions条目可以包含key、operator和values三个字段。
key：要匹配的标签的键。
operator：比较运算符，用于定义如何匹配标签的值。常见的运算符包括In（值在列表中）、NotIn（值不在列表中）、Exists（标签存在）、DoesNotExist（标签不存在）。
values：一个值列表，当operator为In或NotIn时使用。
matchExpressions字段是一个列表，其中每个条目都定义了一个匹配条件。每个条件都由key、operator和values三个字段组成：

key：要匹配的标签的键。

operator：一个字符串，指定了与values数组中的值进行比较的运算符。常见的运算符包括：

• In：标签的值必须存在于values数组中。
• NotIn：标签的值不能存在于values数组中。
• Exists：Pod必须拥有该标签，但不对标签的值进行验证。
• DoesNotExist：Pod不能拥有该标签。

values：一个字符串数组，当operator为In或NotIn时，用于与Pod标签的值进行比较。对于Exists和DoesNotExist运算符，该字段将被忽略。

下面是一个使用matchExpressions的ReplicaSet示例：

apiVersion: apps/v1  
kind: ReplicaSet  
metadata:  
  name: my-replicaset  
spec:  
  replicas: 3  
  selector:  
    matchExpressions:  
    - key: app  
      operator: In  
      values:  
      - my-app  
    - key: environment  
      operator: NotIn  
      values:  
      - prod  
  template:  
    metadata:  
      labels:  
        app: my-app  
        environment: staging  
    spec:  
      containers:  
      - name: my-container  

        image: my-image:latest

在这个例子中，ReplicaSet my-replicaset 将选择所有标签为app: my-app且标签environment的值不是prod的Pod。这意味着，只有那些同时拥有app: my-app标签且environment标签的值不是prod（例如，environment: staging）的Pod才会被my-replicaset管理。

exist
示例：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: rs-me-exists-demo
spec:
 selector:
  matchExpressions:
   - key: app
     operator: Exists # 只要存在标签名为app即可
 template:
  metadata:
    labels:
     app: spring-k8s
  spec:
   containers:
    - name: rs-me-exists-demo-container
      image: wangyanglinux/myapp:v1.0
      ports:
      - containerPort: 80


[root@master 5]# kubectl create -f 02_rs.yaml 
replicaset.apps/rs-me-exists-demo created

[root@master 5]# kubectl get rs
NAME                DESIRED   CURRENT   READY   AGE
rs-me-exists-demo   1         1         1       10s

[root@master 5]# kubectl label pod rs-me-exists-demo-nhr89 app=Noziroh --overwrite
pod/rs-me-exists-demo-nhr89 labeled
rs-me-exists-demo-nhr89   1/1     Running   0          2m15s   app=Noziroh

in示例

apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: rs-me-in-demo
spec:
 selector:
  matchExpressions:
   - key: app
     operator: In
     values:
     - spring-k8s
     - hahahah
 template:
  metadata:
   labels:
     app: sg-k8s
  spec:
   containers:
    - name: rs-me-in-demo-container
      image: wangyanglinux/myapp:v1.0
      ports:
      - containerPort: 80


[root@master 5]# kubectl create -f 02_rs_in.yaml 
The ReplicaSet "rs-me-in-demo" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"sg-k8s"}: `selector` does not match template `labels`
#app: sg-k8s 属于matchExpressions app:[spring-k8s,hahahah] 所以无法创建

#修改yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
 name: rs-me-in-demo
spec:
 selector:
  matchExpressions:
   - key: app
     operator: In
     values:
     - spring-k8s
     - hahahah
     - sg-k8s
 template:
  metadata:
   labels:
     app: sg-k8s
  spec:
   containers:
    - name: rs-me-in-demo-container
      image: wangyanglinux/myapp:v1.0
      ports:
      - containerPort: 80

[root@master 5]# kubectl create -f 02_rs_in.yaml 
replicaset.apps/rs-me-in-demo created

删除rc rs 创建的pod

[root@master 5]# kubectl delete rc --all
replicationcontroller "rc-demo" deleted
[root@master 5]# kubectl delete rs --all
replicaset.apps "rs-me-exists-demo" deleted
replicaset.apps "rs-me-in-demo" deleted
replicaset.apps "rs-ml-demo" deleted

注意：

在实际使用中，matchLabels和matchExpressions可以单独使用，也可以组合使用（但通常不建议这样做，因为这可能会增加配置的复杂性并导致意外的选择结果）。
matchLabels提供了一种简单直观的方式来选择Pod，而matchExpressions则提供了更强大的灵活性和表达能力。
在定义ReplicaSet时，选择器的目的是确保ReplicaSet能够正确地识别和管理它应该负责的Pod。因此，在配置选择器时，需要确保它能够准确地匹配到目标Pod，以避免出现Pod丢失或ReplicaSet无正确管理Pod的情况。

2.2 Deployment

声明式定义

• 作用：工作在ReplicaSet之上，用于管理无状态应用。它提供了应用的声明能力，允许用户定义应用的期望状态，并自动处理Pod的创建、更新和删除。
• 功能：支持滚动更新和版本回退，还提供了事件和状态查看、暂停和继续部能。

常用命令

1. 创建Deployment

使用kubectl create命令：可以直接通过命令行创建Deployment，指定容器镜像、副本数量等参数。

kubectl create deployment my-deployment --image=nginx:latest --replicas=3

这个命令会创建一个名为my-deployment的Deployment，使用nginx:latest镜像，并设置副本数量为3。

使用YAML文件：更常见的做法是先编写一个YAML文件定义Deployment，然后使用kubectl apply命令应用这个文件。

kubectl apply -f my-deployment.yaml

2. 查看Deployment

列出所有Deployments：

kubectl get deployments

这个命令会列出当前命名空间下的所有Deployments。

查看特定Deployment的详细信息：

kubectl describe deployment my-deployment

这个命令会显示名为my-deployment的Deployment的详细信息，包括Pod模板、副本数量、事件等。

3. 更新Deployment

更改副本数量：

kubectl scale deployment my-deployment --replicas=5

这个命令会将my-deployment的副本数量更改为5。

更新容器镜像：

kubectl set image deployment my-deployment my-container=nginx:1.19.2

这个命令会将my-deployment中名为my-container的容器的镜像更新为nginx:1.19.2。

4. 滚动更新和回滚

滚动更新：默认情况下，通过更改Deployment的Pod模板（如镜像版本）并重新应用，Kubernetes会执行滚动更新。

回滚到上一个版本：

kubectl rollout undo deployment my-deployment

这个命令会将my-deployment回滚到上一个版本。

查看更新历史：

kubectl rollout history deployment my-deployment

这个命令会显示my-deployment的更新历史。

回滚到指定版本：

kubectl rollout undo deployment my-deployment --to-revision=N

其中N是想要回滚到的版本号（从kubectl rollout history命令中获取）。

暂停和恢复滚动更新

# 暂停滚动更新  
kubectl rollout pause deployment/<deployment-name>  
  
# 恢复滚动更新  
kubectl rollout resume deployment/<deployment-name>

更新策略

在Kubernetes（k8s）中，Deployment的更新策略是管理Pod版本升级和回滚的重要机制。主要的更新策略包括滚动更新（RollingUpdate）和重建（Recreate），每种策略都有其适用场景和配置方式。

1. 滚动更新（RollingUpdate）

滚动更新是Kubernetes Deployment的默认更新策略。在滚动更新过程中，Deployment控制器会逐步地将新版本的Pod逐个替换旧版本的Pod，从而确保在升级过程中始终有一定数量的可用Pod服务于客户端请求，实现平滑的服务过渡。

关键参数：

• maxSurge：表示在滚动更新过程中，可以超出期望副本数的最大Pod数或百分比。这有助于在更新过程中保持冗余度，以应对可能的故障。
• maxUnavailable：表示在滚动更新过程中，允许的最大不可用Pod数或百分比。这有助于控制更新过程中服务的可用性。

配置示例：

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: myapp-deploy  
spec:  
  replicas: 3  
  strategy:  
    type: RollingUpdate  
    rollingUpdate:  
      maxSurge: 25%  # 或者设置为一个整数，如 maxSurge: 1  
      maxUnavailable: 25%  # 或者设置为一个整数，如 maxUnavailable: 1  
  selector:  
    matchLabels:  
      app: myapp  
  template:  
    metadata:  
      labels:  
        app: myapp  
    spec:  
      containers:  
      - name: myapp  

        image: myapp:v2

适用场景：

滚动更新特别适用于需要确保服务持续可用的场景，如生产环境中的应用程序升级。

2. 重建（Recreate）

重建策略会在创建新Pod之前删除所有现有的Pod。这种策略会导致应用程序的短暂中断，因为在删除旧Pod和创建新Pod之间存在时间差。

配置示例：

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: myapp-deploy  
spec:  
  replicas: 3  
  strategy:  
    type: Recreate  
  selector:  
    matchLabels:  
      app: myapp  
  template:  
    metadata:  
      labels:  
        app: myapp  
    spec:  
      containers:  
      - name: myapp  

        image: myapp:v2

适用场景：

重建策略适用于无状态应用程序或可以容忍短暂中断的应用程序，如开发环境或测试环境中的应用程序升级。
总结

在选择Deployment的更新策略时，需要根据应用程序的特性和业务需求进行权衡。滚动更新提供了更好的服务可用性和平滑的升级体验，但可能会增加系统的复杂性和资源消耗。重建策略则更简单直接，但可能会导致服务中断。在实际应用中，可以根据具体情况选择合适的更新策略，并通过调整maxSurge和maxUnavailable等参数来优化升级过程。

金丝雀部署

• 定义：金丝雀发布是在新旧版本之间平滑过渡的一种发布方式，通过让一部分用户先使用新版本，另一部分用户继续使用旧版本，从而逐步验证新版本的稳定性和性能。
• 目的：降低新软件版本部署的风险，确保新版本在生产环境中能够稳定运行，同时避免对整个系统造成过大影响。

vi deployment-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
  app: deployment-demo
 name: deployment-demo
spec:
 replicas: 10
 selector:
  matchLabels:
   app: deployment-demo
 template:
  metadata:
   labels:
    app: deployment-demo
  spec:
   containers:
   - image: wangyanglinux/myapp:v1.0
     name: deployment-demo-container

[root@master 6]# kubectl apply -f deployment-demo.yaml 
deployment.apps/deployment-demo created
[root@master 6]# kubectl create svc clusterip deployment-demo --tcp=80:80
service/deployment-demo created
[root@master 6]# kubectl get deploy deployment-demo -o yaml
spec:
  progressDeadlineSeconds: 600
  replicas: 10
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: deployment-demo
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate

# 修改滚动更新pod滚动时的数量
# json模式更新 允许pod超过最大值1个,允许不可用pod为0
# '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":2}}}}'
[root@master 6]# kubectl patch deploy deployment-demo -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":2}}}}'
deployment.apps/deployment-demo patched

# 进行滚动更新
# '{"spec":{"template":{"spec":{"containers":[{"image":"wangyanglinux/myapp:v2.0","name":"deployment-demo-container"}]}}}}'

[root@master 6]# kubectl patch deploy deployment-demo --patch '{"spec":{"template":{"spec":{"containers":[{"image":"wangyanglinux/myapp:v2.0","name":"deployment-demo-container"}]}}}}' && kubectl rollout pause deploy deployment-demo
deployment.apps/deployment-demo patched
deployment.apps/deployment-demo paused
[root@master 6]# kubectl get pod | grep deployment |wc -l
11
[root@master 6]# kubectl describe pod deployment-demo-7dd46c6f55-l5mdl
Image:          wangyanglinux/myapp:v2.0
[root@master 6]# kubectl rollout resume deploy deployment-demo
deployment.apps/deployment-demo resumed
# 回滚
[root@master 6]# kubectl rollout undo deployment/deployment-demo
deployment.apps/deployment-demo rolled back


[root@master 6]# kubectl get rs
NAME                         DESIRED   CURRENT   READY   AGE
deployment-demo-6465d4c5c9   0         0         0       2m34s
deployment-demo-6995c75668   10        10        10      8m3s

2.2.1. 应用（Apply）

kubectl apply 命令用于根据提供的配置文件（通常是YAML或JSON格式）来创建或更新资源。如果资源不存在，apply 会创建它；如果已存在，apply 会更新资源以匹配配置文件中的定义。

kubectl apply -f deployment.yaml

这个命令会根据deployment.yaml文件中的定义来创建或更新一个Deployment。

2.1.2. 替换（Replace）

在Kubernetes中，并没有直接的replace命令来替换整个Deployment。但是，你可以使用kubectl replace命令来替换资源的定义，但这通常用于特定的场景，比如你需要替换整个资源对象而不是简单地更新它。

kubectl replace -f deployment.yaml --force

注意：–force选项在较新版本的kubectl中可能不是必需的，具体取决于你的Kubernetes集群版本和kubectl版本。使用replace时要小心，因为它会替换整个资源对象，而不仅仅是更新它。

对比

	kubectl apply	kubectl replace
功能	创建或更新资源，使其与配置文件匹配	替换资源的当前配置，使其与配置文件完全匹配
特点	增量更新，幂等性，易于使用	全面替换，可能导致资源状态丢失，需要谨慎使用
适用场景	大多数资源更新场景	需要替换整个资源对象或资源状态复杂难以通过apply更新的场景

测试

apiVersion: apps/v1
kind: Deployment # 类别为Deployment
metadata:
 labels:
  app: myapp-deploy # Deployment 标签
 name: myapp-deploy # Deployment 名字
spec:
 replicas: 1
 selector:
  matchLabels:
   app: myapp-deploy # 容器标签app=myapp-deploy
 template:
  metadata:
   labels:
    app: myapp-deploy # 容器名字
  spec:
   containers:
   - image: wangyanglinux/myapp:v1.0
     name: myapp

[root@master 5]# kubectl get pod
NAME                            READY   STATUS    RESTARTS   AGE
myapp-deploy-7977896984-gsd6m   1/1     Running   0          36s
[root@master 5]# kubectl get deploy -o wide
NAME           READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                     SELECTOR
myapp-deploy   1/1     1            1           59s   myapp        wangyanglinux/myapp:v1.0   app=myapp-deploy

[root@master 5]# kubectl get deploy -o yaml
availableReplicas: 1
[root@master 5]# kubectl scale deploy myapp-deploy --replicas=10
deployment.apps/myapp-deploy scaled
[root@master 5]# kubectl get deploy -o wide
NAME           READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES                     SELECTOR
myapp-deploy   10/10   10           10          3m26s   myapp        wangyanglinux/myapp:v1.0   app=myapp-deploy
[root@master 5]# kubectl get deploy -o yaml
availableReplicas: 10


[root@master 5]# kubectl get pod -o wide
NAME                            READY   STATUS    RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
myapp-deploy-7977896984-6gwzj   1/1     Running   0          101s    10.244.166.167   node1   <none>           <none>
myapp-deploy-7977896984-9mmn4   1/1     Running   0          101s    10.244.104.35    node2   <none>           <none>
myapp-deploy-7977896984-b47vm   1/1     Running   0          101s    10.244.166.170   node1   <none>           <none>
myapp-deploy-7977896984-b6t5j   1/1     Running   0          101s    10.244.166.168   node1   <none>           <none>
myapp-deploy-7977896984-gsd6m   1/1     Running   0          4m42s   10.244.104.34    node2   <none>           <none>
myapp-deploy-7977896984-jbg62   1/1     Running   0          101s    10.244.166.171   node1   <none>           <none>
myapp-deploy-7977896984-m2kh6   1/1     Running   0          101s    10.244.104.36    node2   <none>           <none>
myapp-deploy-7977896984-r8shx   1/1     Running   0          101s    10.244.104.38    node2   <none>           <none>
myapp-deploy-7977896984-rp6rz   1/1     Running   0          101s    10.244.104.37    node2   <none>           <none>
myapp-deploy-7977896984-th76j   1/1     Running   0          101s    10.244.166.169   node1   <none>           <none>

[root@master 5]# curl 10.244.166.167
www.xinxianghf.com | hello MyAPP | version v1.0

[root@master 5]# vim 01_deploy.yaml
- image: wangyanglinux/myapp:v2.0

[root@master 5]# kubectl apply -f 01_deploy.yaml 
deployment.apps/myapp-deploy configured

[root@master 5]# kubectl get deploy -o wide
NAME           READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES                     SELECTOR
myapp-deploy   1/1     1            1           6m38s   myapp        wangyanglinux/myapp:v2.0   app=myapp-deploy

[root@master 5]# kubectl get pod -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
myapp-deploy-58b4dc6f5-dggz9   1/1     Running   0          95s   10.244.104.39   node2   <none>           <none>

[root@master 5]# curl 10.244.104.39
www.xinxianghf.com | hello MyAPP | version v2.0

[root@master 5]# vim 01_deploy.yaml
replicas: 10
- image: wangyanglinux/myapp:v3.0

[root@master 5]# kubectl replace -f 01_deploy.yaml 
deployment.apps/myapp-deploy replaced

[root@master 5]# kubectl get deploy -o wide 
NAME           READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES                     SELECTOR
myapp-deploy   10/10   10           10          17m   myapp        wangyanglinux/myapp:v3.0   app=myapp-deploy

[root@master 5]# kubectl get pod -o wide 
NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
myapp-deploy-6fd574ffd6-287zl   1/1     Running   0          97s   10.244.104.44    node2   <none>           <none>
myapp-deploy-6fd574ffd6-2rqpt   1/1     Running   0          60s   10.244.166.180   node1   <none>           <none>
myapp-deploy-6fd574ffd6-987n5   1/1     Running   0          97s   10.244.104.41    node2   <none>           <none>
myapp-deploy-6fd574ffd6-cmw6z   1/1     Running   0          61s   10.244.104.47    node2   <none>           <none>
myapp-deploy-6fd574ffd6-g2pkf   1/1     Running   0          97s   10.244.104.42    node2   <none>           <none>
myapp-deploy-6fd574ffd6-g9prr   1/1     Running   0          79s   10.244.166.178   node1   <none>           <none>
myapp-deploy-6fd574ffd6-jqjbz   1/1     Running   0          72s   10.244.166.179   node1   <none>           <none>
myapp-deploy-6fd574ffd6-vnzg4   1/1     Running   0          97s   10.244.166.174   node1   <none>           <none>
myapp-deploy-6fd574ffd6-zlfnz   1/1     Running   0          97s   10.244.166.175   node1   <none>           <none>
myapp-deploy-6fd574ffd6-zscjl   1/1     Running   0          63s   10.244.104.46    node2   <none>           <none>

[root@master 5]# kubectl diff -f 01_deploy.yaml 
diff -u -N /tmp/LIVE-1713354067/apps.v1.Deployment.default.myapp-deploy /tmp/MERGED-2968072580/apps.v1.Deployment.default.myapp-deploy
--- /tmp/LIVE-1713354067/apps.v1.Deployment.default.myapp-deploy	2024-08-22 23:48:21.313569984 +0800
+++ /tmp/MERGED-2968072580/apps.v1.Deployment.default.myapp-deploy	2024-08-22 23:48:21.314569996 +0800
@@ -4,7 +4,7 @@
   annotations:
     deployment.kubernetes.io/revision: "3"
   creationTimestamp: "2024-08-22T15:29:32Z"
-  generation: 4
+  generation: 5
   labels:
     app: myapp-deploy
   name: myapp-deploy
@@ -13,7 +13,7 @@
   uid: 383e54ba-ce53-4320-85d9-d72fd6abb35b
 spec:
   progressDeadlineSeconds: 600
-  replicas: 10
+  replicas: 1
   revisionHistoryLimit: 10
   selector:
     matchLabels:
@@ -30,7 +30,7 @@
         app: myapp-deploy
     spec:
       containers:
-      - image: wangyanglinux/myapp:v3.0
+      - image: wangyanglinux/myapp:v2.0
         imagePullPolicy: IfNotPresent
         name: myapp
         resources: {}


# deployment与rs关联升级 滚动更新
[root@master 5]# kubectl get rs -o wide
NAME                      DESIRED   CURRENT   READY   AGE   CONTAINERS   IMAGES                     SELECTOR
myapp-deploy-58b4dc6f5    0         0         0       20m   myapp        wangyanglinux/myapp:v2.0   app=myapp-deploy,pod-template-hash=58b4dc6f5
myapp-deploy-6fd574ffd6   10        10        10      10m   myapp        wangyanglinux/myapp:v3.0   app=myapp-deploy,pod-template-hash=6fd574ffd6
myapp-deploy-7977896984   0         0         0       26m   myapp        wangyanglinux/myapp:v1.0   app=myapp-deploy,pod-template-hash=7977896984

2.1.3. 删除（Delete）

kubectl delete 命令用于删除一个或多个资源。要删除一个Deployment，你可以使用以下命令：

kubectl delete deployment <deployment-name>

将替换为你的Deployment的名称。

2.1.4. 注意事项

在使用apply或replace时，请确保你的配置文件是最新的，以避免不必要的配置错误或资源状态不一致。
在删除Deployment之前，请确保你了解这将会删除该Deployment管理的所有Pods，并且你有适当的备份或恢划。
kubectl apply是更新资源的推荐方式，因为它可以处理资源配置的增量更新，而replace则更适合于替换整个对象。
对于复杂的应用场景，可能需要结合使用kubectl的多个命令，以及编写适当的Kubernetes配置文件，来精确你的应用部署和更新过程。

2.3 StatefulSet

• 作用：用于管理有状态的应用。它为Pod提供了稳定的网络标识、顺序部署、及扩展和滚动更新的能力。
• 特点：Pod的名称是有序的，且每个Pod都有独立的存储卷。它通常与HeadleService（无头服务）和PVC（持久化卷声明）一起使用，以实现稳定的持久和网络标识。

主要特点

• 1. 稳定的唯一网络标识符：
  • 每个StatefulSet的Pod都有一个稳定的网络标识符（如DNS名称），这个标识符由控制器自动生成，并与Pod的生命周期保持关联。这使得有状态应用更容易被其他应用或服务访问和发现。
• 2. 有序部署和扩展：
  • StatefulSet能够按照定义的顺序逐个创建和更新Pod实例，确保它们按照固定的命名规则有序启动。在扩展时，新的Pod也会按照相同的顺序创建，从而保证有状态应用的数据一致性和可用性。
• 3. 稳定的存储：
  • 每个StatefulSet的Pod都可以使用持久卷（PersistentVolume）来存储数据，这些存储卷在Pod重新启动或迁移时保持不变，从而确保数据的持久性和可靠性。
• 4. 域名解析：
  • 每个StatefulSet的Pod都有一个稳定的域名，格式通常为...svc.cluster.local。这使得有状态应用可以通过域名进行服务发现和通信。
• 5. 有序删除：
     在删除StatefulSet时，控制器会按照指定的顺序逐个删除Pod，确保有状态应用在删除过程中不会丢失数据。

应用场景

StatefulSet适用于需要持久化存储和唯一标识的有状态应用场景，包括但不限于：

• 数据库（如MySQL、PostgreSQL、MongoDB）
• 消息队列（如RabbitMQ、Kafka）
• 分布式存储（如Elasticsearch、Cassandra）

在这些场景中，StatefulSet提供的稳定网络标识、有序部署和扩展、持久化存储等特性对于保证应用的数据一致性和高可用性至关重要。
组成部分

StatefulSet主要由以下几个部分组成：

• Headless Service：用于定义Pod的网络标识（DNS域名），没有Cluster IP，解析其名称时将返回该Headless Service对应的全部Pod的Endpoint列表。
• volumeClaimTemplates：存储卷申请模板，用于为StatefulSet中的每个Pod生成独立的持久卷声明（PersistentVolumeClaim），从而实现数据的持久化存储。
• StatefulSet定义：定义具体应用，包括Pod副本数、Pod模板（容器配置、存储卷挂载等）、关联的Headless Service等。

示例

以下是一个简单的StatefulSet示例，用于部署一个具有3个副本的MySQL数据库服务：

apiVersion: apps/v1  
kind: StatefulSet  
metadata:  
  name: mysql-statefulset  
spec:  
  serviceName: mysql  
  replicas: 3  
  selector:  
    matchLabels:  
      app: mysql  
  template:  
    metadata:  
      labels:  
        app: mysql  
    spec:  
      containers: 
      - name: mysql-container  
        image: mysql:latest  
        ports:  
        - containerPort: 3306  
        env:  
        - name: MYSQL_ROOT_PASSWORD  
          value: "password"  
        volumeMounts:  
        - name: mysql-storage  
          mountPath: /var/lib/mysql  
  volumeClaimTemplates:  
  - metadata:  
      name: mysql-storage  
    spec:  
      accessModes: ["ReadWriteOnce"]  
      storageClassName: "standard"  
      resources:  
        requests:  
          storage: 1Gi

在这个示例中，StatefulSet mysql-statefulset 定义了3个MySQL Pod副本，每个Pod都挂载了一个名为mysql-storage的持久卷，用于存储数据库数据。这个持久卷通过volumeClaimTemplates自动生成，并请求了1GiB的存储空间。同时，StatefulSet还关联了一个名为mysql的Headless Service，用于提供Pod的网络标识和域名解析。

2.4 DaemonSet

作用：确保在集群中的每个Node上都运行一个Pod的副本。它通常用于运行集群存储、日志收集等守护进程类任务。
特点：无论Node何时加入集群，DaemonSet都会确保在该Node上运行一个Pod副本（除非Node被标记为不可调度）。

一、概述

DaemonSet 控制器能够确保 Kubernetes 集群中的每个节点（或选定的节点）都运行一个 Pod 的副本。当集群中增加新的节点时，DaemonSet 会自动在该节点上创建一个 Pod 副本；当节点从集群中移除时，DaemonSet 也会自动删除该节点上的 Pod。

二、工作原理

• 定义对象：用户定义一个 DaemonSet 对象，指定 Pod 模板和其他配置选项。Pod 模板定义了 Pod 的规格，包括容器、存储和网络配置。
• 调度 Pod：当 DaemonSet 控制器接收到创建请求时，它会在每个匹配的节点上创建一个 Pod 实例。
• 监控 Pod：DaemonSet 控制器监视 Pod 的状态，并确保每个节点上都有 Pod 实例。如果节点失败或重启，DaemonSet 控制器会自动在该节点上重新创建 Pod 实例。
• 更新 Pod：如果用户更新了 Pod 模板，DaemonSet 控制器将负责在所有节点上滚动更新 Pod 实例，以应用新的配置。
• 节点选择：DaemonSet 允许用户通过节点标签选择器来指定应在哪些节点上运行 Pod。如果没有指定选择器，Pod 将在所有节点上运行。

三、相关特性

• 节点覆盖：DaemonSet 确保在集群中的所有节点或选定节点上运行一个 Pod 实例，或者在满足特定条件的节点上运行。
• 自动恢复：如果节点失败或重启，DaemonSet 会自动在该节点上重新创建 Pod，确保服务的连续性。
• 滚动更新：当 Pod 模板更新时，DaemonSet 支持滚动更新，逐步替换旧的 Pod 实例。但通常建议避免在 DaemonSet 中使用 RollingUpdate 更新策略，因为这可能不适用于需要高度稳定性的守护进程应用程序。
• 灵活性：用户可以指定节点标签选择器来控制 Pod 在哪些节点上运行，提供灵活性。
• 资源和调度：DaemonSet 支持资源请求和限制，允许用户为 Pod 指定所需的 CPU 和内存资源。
• 集成：DaemonSet 与 Kubernetes 的其他资源和功能（如服务发现、存储卷和网络策略）紧密集成。

四、应用场景

• 日志收集：在每个节点上运行日志收集器，如 Fluentd、Logstash 或 Filebeat，以收集并转发节点上的日志数据。
• 监控代理：在每个节点上运行监控代理，如 Prometheus Node Exporter、collectd 等，以收集节点的性能指标并发送到监控中心。
• 存储守护进程：在每个节点上运行存储守护进程，如 Glusterd 或 Ceph，以提供分布式存储服务。

五、示例

以下是一个简单的 DaemonSet YAML 配置文件示例，用于在 Kubernetes 集群的每个节点上部署一个 Nginx Pod：

apiVersion: apps/v1  
kind: DaemonSet  
metadata:  
  name: nginx-daemonset  
  namespace: default  
spec:  
  selector:  
    matchLabels:  
      app: nginx-daemonset  
  template:  
    metadata:  
      labels:  
        app: nginx-daemonset  
    spec:  
      containers:  
      - name: nginx  
        image: nginx:latest  
        ports:  
        - containerPort: 80

在创建了这个 DaemonSet 后，Kubernetes 将在每个节点上部署一个 Nginx Pod 副本。如果集群中有新的节点加入，DaemonSet 将自动在该节点上创建一个新的 Nginx Pod 副本。

2.5 Job

作用：用于运行批处理任务，即执行一次性任务。当Pod完成其工作后，Job控制器会负责清理这些Pod。

K8s Job是Kubernetes中的一个核心概念，用于执行一次性任务或批处理作业。以下是关于K8s Job的详细解释：

一、基本概念

• 定义：Job是Kubernetes中的一种资源对象，专门用于处理那些需要运行至完成且不需要持续运行的任务。
• 用途：Job主要用于执行数据处理、备份恢复、日志打包压缩等一次性或批处理任务。

二、主要特性

• 任务执行：Job会创建一个或多个Pod来执行定义的任务，并确保这些Pod成功完成任务。
• 自动清理：当所有Pod都成功完成任务后，Job会停止这些Pod（默认情况下，已完成的Pod会被自动清理）。
• 失败重试：如果Pod执行失败，Job会根据定义的策略进行重试，直到任务成功或达到最大重试次数。
• 并行与串行：Job支持并行执行任务，也支持串行执行任务，具体取决于配置。

三、关键字段

• apiVersion：指定Job资源对象的API版本，通常为batch/v1。
• kind：指定资源对象的类型为Job。
• metadata：包含Job的元数据，如名称（name）、命名空间（namespace）等。
• spec：定义Job的规格，包括任务模板（template）、完成次数（completions）、并行度（parallelism）、重启策略（restartPolicy）等。
  • template：定义了Pod的模板，包括使用的镜像、命令、参数等。
  • completions：指定需要成功完成的任务数量。
  • parallelism：指定同时运行的Pod数量。
  • backoffLimit：指定任务失败后的重试次数。

四、使用场景

• 数据处理：如从数据库中导出数据到CSV文件。
• 日志打包压缩：如按时间段打包日志文件。
• 备份恢复：如备份数据库到云存储服务。
• 批处理任务：如根据输入参数计算机器学习模型的特征向量。

五、操作示例

以下是一个简单的Job配置文件示例：

apiVersion: batch/v1  
kind: Job  
metadata:  
  name: ubuntu-job  
spec:  
  template:  
    spec:  
      containers:  
      - name: ubuntu-container  
        image: ubuntu  
        command: ["echo", "Hello, Kubernetes!"]  
      restartPolicy: Never

[root@master ~]# kubectl logs  ubuntu-job-wlg8x
Hello, Kubernetes!

该配置文件定义了一个名为example-job的Job，它将启动一个Pod，该Pod包含一个运行echo "Hello, Kubernetes!"命令的容器。由于restartPolicy设置为Never，所以Pod在成功完成任务后不会重启。

六、注意事项

• Job适用于一次性任务或批处理作业，不适用于长时间运行的服务。
• 需要确保Job配置文件中定义的容器可以正常运行，并有足够的资源和权限执行指定操作。

2.6 CronJob

作用：用于周期性地创建Job对象，执行定时任务。它类似于Unix中的crontab，用于安排周期性作业。

在Kubernetes（K8s）中，CronJob是一种非常有用的资源对象，它基于Cron表达式，允许用户在指定的时间间隔内自动运行容器化的任务。以下是关于K8s CronJob的详细解释：

一、基本概念

• 定义：CronJob是Kubernetes中用于周期性执行任务的资源对象，它相当于在Job之上增加了基于时间的调度配置。
• 用途：CronJob通常用于部署定时备份、定时检查、定时同步、定时报告等周期性任务。

二、关键属性

• schedule：指定任务执行的时间表，使用标准的Cron表达式语法。例如，“0 * * * *”表示每小时执行一次任务。
• jobTemplate：定义要执行的任务的模板，通常是一个Pod模板。这个模板包含了任务所需的容器镜像、命令、环境变量等配置。
• concurrencyPolicy：指定任务并发策略，默认为Allow。Allow表示允许并发执行任务，Forbid表示禁止并发执行任务（新任务将会被跳过），Replace表示如果任务正在执行，则会终止当前任务并启动新任务。
• successfulJobsHistoryLimit和failedJobsHistoryLimit：分别指定保留成功和失败任务历史记录的数量。默认情况下，成功任务的历史记录保留数量为3，失败任务的历史记录保留数量为1。

三、工作原理

• 定义对象：用户创建一个CronJob对象，指定Pod模板和其他配置选项。
• 监控Job：Kubernetes的调度器会监控CronJob对象的状态。
• 生成Job：根据CronJob定义的时间表，调度器在预定的时间创建Job对象。
• 执行任务：Kubernetes根据Job模板创建Pod，并开始执行任务。
• 监控Pod：Kubernetes监控Pod的状态，确保任务成功完成。
• 记录历史：由CronJob创建的Job都会被记录，包括成功和失败的Job。
• 清理资源：完成的Job及对应的Pod会根据CronJob的配置进行清理。

四、Cron表达式

Cron表达式由五个或六个字段组成，分别代表分钟、小时、日、月、星期几（以及可选的年份）。每个字段的取值范围不同，可以使用通配符、逗号、连字符等方式进行配置。以下是一些常见的Cron表达式示例：

• 每分钟执行一次任务：* * * * *
• 每小时执行一次任务：0 * * * *
• 每天凌晨1点执行任务：0 1 * * *
• 每周一凌晨1点执行任务：0 1 * * 1
• 每月1号凌晨1点执行任务：0 1 1 * *

五、使用场景

• 定时备份：定期备份数据库或文件系统。
• 日志清理：定时清理过期的日志或缓存数据。
• 数据同步：定时拉取或更新数据，如镜像、代码库等。
• 发送通知：定时发送通知或警报。

六、操作示例

以下是一个简单的CronJob配置文件示例：

apiVersion: batch/v1  
kind: CronJob  
metadata:  
  name: hello-cronjob  
spec:  
  schedule: "*/1 * * * *"  # 每一分钟执行一次任务  
  jobTemplate:  
    spec:  
      template:  
        spec:  
          containers:  
          - name: hello  
            image: ubuntu  
            command: ["/bin/sh", "-c", "date; echo Hello from the Kubernetes cluster"]  
          restartPolicy: OnFailure

该配置文件定义了一个名为hello-cronjob的CronJob，它将每分钟执行一次任务，任务内容为打印当前日期和时间，并输出“Hello from the Kubernetes cluster”。

七、注意事项

• CronJob的时间精度为分钟级别，不支持秒级别的定时任务。
• 在设计CronJob时，应充分考虑任务执行的时间、频率和并发策略，以避免资源冲突或过度消耗。
• 对于重要的定时任务，建议设置失败重试和历史记录保留策略，以便在任务失败时能够及时发现并处理。

三、Pod与控制器之间的关系

控制器是Kubernetes中用于管理一组Pod的高级对象，而Pod是Kubernetes中运行容器的最小单元。
控制器通过定义一组标签选择器来跟踪和控制具有这些标签的Pod。当Pod因故障而终止时，控制器会根据定义的规则自动创建新的Pod来替换它，从而确保应用的持续运行和所需的副本数量。

四、Pod控制器的实现机制

Pod控制器是由Master节点的kube-controller-manager组件提供的。它通过内部和解（reconciliation loop）机制不断地监控Kubernetes集群内资源对象的状态，以保证集群中的资源对象的状限接近于用户所期望的状态。
当资源对象状态发生变动时，API Server将状态写入etcd中，并通过水平触发机制将事件主动通知给相关的客户端程序（包括kube-controller-manager）。然后，控制器通过API Server的watch实时监控目标资源对象的变动，并在必要时执行和解操作。

综上所述，Pod控制器是Kubernetes中用于管理Pod资源的重要机制，它通过确保Pod副本数量、自动恢复、扩缩容、更新和回滚等功能，为应用的持续运行和运维自动化提供了有力支持。