Kubernetes调度基础（一）

Kubernetes调度基础（一）

1 Replication Controller 和 ReplicaSet

Replication Controller（复制控制器，RC）和 ReplicaSet（复制集，RS）是两种简单部署 Pod 的方式。因为在生产环境中，主要使用更高级的 Deployment 等方式进行 Pod 的管理和部署，所 以只需要简单了解即可。

1.1 Replication Controller

Replication Controller（简称 RC）可确保 Pod 副本数达到期望值，也就是 RC 定义的数量。 换句话说，Replication Controller 可确保一个 Pod 或一组同类 Pod 总是可用。

如果存在的 Pod 大于设定的值，则 Replication Controller 将终止额外的 Pod。如果太小， Replication Controller 将启动更多的 Pod 用于保证达到期望值。与手动创建 Pod 不同的是，用 Replication Controller 维护的 Pod 在失败、删除或终止时会自动替换。因此即使应用程序只需要 一个 Pod，也应该使用 Replication Controller 或其他方式管理。Replication Controller 类似于进程 管理程序，但是 Replication Controller 不是监视单个节点上的各个进程，而是监视多个节点上的 多个 Pod。

定义一个 Replication Controller 的示例如下。

apiVersion: v1kind: ReplicationControllermetadata: name: nginxspec: replicas: 3 selector: app: nginx template: metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80

1.2 ReplicaSet

ReplicaSet 是支持基于集合的标签选择器的下一代 Replication Controller，它主要用作 Deployment 协调创建、删除和更新 Pod，和 Replication Controller 唯一的区别是，ReplicaSet 支持 标签选择器。在实际应用中，虽然 ReplicaSet 可以单独使用，但是一般建议使用 Deployment 来 自动管理 ReplicaSet，除非自定义的 Pod 不需要更新或有其他编排等。

定义一个 ReplicaSet 的示例如下：

apiVersion: apps/v1kind: ReplicaSetmetadata: name: frontend labels: app: guestbook tier: frontendspec: # modify replicas according to your case replicas: 3 selector: matchLabels: tier: frontend matchExpressions: - {key: tier, operator: In, values: [frontend]} template: metadata: labels: app: guestbook tier: frontend spec: containers: - name: php-redis image: gcr.io/google_samples/gb-frontend:v3 resources: requests: cpu: 100m memory: 100Mi env: - name: GET_HOSTS_FROM value: dns # If your cluster config does not include a dns service, then to # instead access environment variables to find service host # info, comment out the 'value: dns' line above, and uncomment the # line below. # value: env ports: - containerPort: 80

Replication Controller 和 ReplicaSet 的创建删除和 Pod 并无太大区别，Replication Controller 目前几乎已经不在生产环境中使用，ReplicaSet 也很少单独被使用，都是使用更高级的资源 Deployment、DaemonSet、StatefulSet 进行管理 Pod。

2 无状态应用管理 Deployment

2.1 创建 Deployment

apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.15.12 ports: - containerPort: 80

示例解析：

1. nginx-deployment：Deployment的名称；

2. replicas： 创建Pod的副本数；

3. selector：定义Deployment如何找到要管理的Pod，与template的label（标签）对应，apiVersion 为apps/v1必须指定该字段；

4. template字段包含以下字段：

app: nginx使用label（标签）标记Pod；

spec：表示Pod运行一个名字为nginx的容器；

image：运行此Pod使用的镜像；

Port：容器用于发送和接收流量的端口。

使用 kubectl create 创建此 Deployment：

# kubectl create -f dp-nginx.yaml deployment.apps/nginx-deployment created

使用 kubectl get 或者 kubectl describe 查看此 Deployment 的状态：

# kubectl get deployNAME READY UP-TO-DATE AVAILABLE AGEnginx-deployment 0/3 3 0 8s

NAME：集群中Deployment的名称；READY：Pod就绪个数和总副本数； UP-TO-DATE：显示已达到期望状态的被更新的副本数；AVAILABLE：显示用户可以使用的应用程序副本数，当前为0，说明目前还没有达到期望的Pod；AGE：显示应用程序运行的时间。

可以使用 rollout 命令查看整个 Deployment 创建的状态：

# kubectl rollout status deployment/nginx-deploymentdeployment "nginx-deployment" successfully rolled out

当 rollout 结束时，再次查看此 Deployment，可以看到 AVAILABLE 的数量和 yaml 文件中 定义的 replicas 相同：

# kubectl get deployNAME READY UP-TO-DATE AVAILABLE AGEnginx-deployment 3/3 3 3 10m

查看此 Deployment 当前对应的 ReplicaSet：

# kubectl get rs -l app=nginxNAME DESIRED CURRENT READY AGEnginx-deployment-5c689d88bb 3 3 3

DESIRED：应用程序副本数； CURRENT：当前正在运行的副本数；

当 Deployment 有过更新，对应的 RS 可能不止一个，可以通过-o yaml 获取当前对应的 RS是哪个，其余的 RS 为保留的历史版本，用于回滚等操作。

查看此 Deployment 创建的 Pod，可以看到 Pod 的 hash 值 5c689d88bb 和上述 Deployment 对应的 ReplicaSet 的 hash 值一致：

# kubectl get pods --show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx-deployment-5c689d88bb-6b95k 1/1 Running 0 13m app=nginx,pod-template-hash=5c689d88bbnginx-deployment-5c689d88bb-9z5z2 1/1 Running 0 13m app=nginx,pod-template-hash=5c689d88bbnginx-deployment-5c689d88bb-jc8hr 1/1 Running 0 13m app=nginx,pod-template-hash=5c689d88bb

2.2 更新 Deployment

假如更新 Nginx Pod 的 image 使用 nginx:latest，并使用--record 记录当前更改的参数，后期 回滚时可以查看到对应的信息：

# kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --recorddeployment.extensions/nginx-deployment image updated

当然也可以使用 edit 命令直接编辑 Deployment，效果相同：

# kubectl edit deployment.v1.apps/nginx-deploymentdeployment.apps/nginx-deployment edited

同样可以使用 kubectl rollout status 查看更新过程：

# kubectl rollout status deployment.v1.apps/nginx-deploymentWaiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...deployment "nginx-deployment" successfully rolled out

可以看出更新过程为新旧交替更新，首先新建一个 Pod，当 Pod 状态为 Running 时，删除一 个旧的 Pod，同时再创建一个新的 Pod。当触发一个更新后，会有新的 ReplicaSet 产生，旧的 ReplicaSet 会被保存，查看此时 ReplicaSet，可以从 AGE 或 READY 看出来新旧 ReplicaSet：

# kubectl get rs NAME DESIRED CURRENT READY AGEnginx-deployment-5c689d88bb 0 0 0 34mnginx-deployment-6987cdb55b 3 3 3 5m14s

通过 describe 查看 Deployment 的详细信息：

# kubectl describe deploy nginx-deploymentName: nginx-deploymentNamespace: default...OldReplicaSets: NewReplicaSet: nginx-deployment-6987cdb55b (3/3 replicas created)Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 36m deployment-controller Scaled up replica set nginx-deployment-5c689d88bb to 3 Normal ScalingReplicaSet 7m16s deployment-controller Scaled up replica set nginx-deployment-6987cdb55b to 1 Normal ScalingReplicaSet 5m18s deployment-controller Scaled down replica set nginx-deployment-5c689d88bb to 2 Normal ScalingReplicaSet 5m18s deployment-controller Scaled up replica set nginx-deployment-6987cdb55b to 2 Normal ScalingReplicaSet 4m35s deployment-controller Scaled down replica set nginx-deployment-5c689d88bb to 1 Normal ScalingReplicaSet 4m34s deployment-controller Scaled up replica set nginx-deployment-6987cdb55b to 3 Normal ScalingReplicaSet 3m30s deployment-controller Scaled down replica set nginx-deployment-5c689d88bb to 0

在 describe 中可以看出，第一次创建时，它创建了一个名为 nginx-deployment-5c689d88bb 的 ReplicaSet，并直接将其扩展为 3 个副本。更新部署时，它创建了一个新的 ReplicaSet，命名为 nginx-deployment-6987cdb55b，并将其副本数扩展为 1，然后将旧的 ReplicaSet 缩小为 2，这样至 少可以有 2 个 Pod 可用，最多创建了 4 个 Pod。以此类推，使用相同的滚动更新策略向上和向下 扩展新旧 ReplicaSet，最终新的 ReplicaSet 可以拥有 3 个副本，并将旧的 ReplicaSet 缩小为 0。

2.3 回滚 Deployment

当更新了版本不稳定或配置不合理时，可以对其进行回滚操作，假设我们又进行了几次更新 （此处以更新镜像版本触发更新，更改配置效果类似）：

# kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record# kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record

使用 kubectl rollout history 查看更新历史：

# kubectl rollout history deployment/nginx-deploymentREVISION CHANGE-CAUSE1 2 kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true3 kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true4 kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true

查看 Deployment 某次更新的详细信息，使用--revision 指定某次更新版本号：

# kubectl rollout history deployment/nginx-deployment --revision=3deployment.apps/nginx-deployment with revision #3Pod Template: Labels: app=nginxpod-template-hash=645959bf6b Annotations: kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true Containers: nginx: Image: dotbalo/canary:v1 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes:

如果只需要回滚到上一个稳定版本，使用 kubectl rollout undo 即可：

# kubectl rollout undo deployment/nginx-deploymentdeployment.apps/nginx-deployment

再次查看更新历史，发现 REVISION5 回到了 canary:v1：

# kubectl rollout history deployment/nginx-deploymentREVISION CHANGE-CAUSE1 2 kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 --record=true4 kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true5 kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true

如果要回滚到指定版本，使用--to-revision 参数：

# kubectl rollout undo deployment/nginx-deployment --to-revision=2deployment.extensions/nginx-deployment

2.4 扩容 Deployment

当公司访问量变大，或者有预期内的活动时，三个 Pod 可能已无法支撑业务时，可以提前 对其进行扩展。

使用 kubectl scale 动态调整 Pod 的副本数，比如增加 Pod 为 5 个：

# kubectl scale deployment.v1.apps/nginx-deployment --replicas=5deployment.apps/nginx-deployment scaled

查看 Pod，此时 Pod 已经变成了 5 个：

# kubectl get poNAME READY STATUS RESTARTS AGEnginx-deployment-5f89547d9c-5r56b 1/1 Running 0 90snginx-deployment-5f89547d9c-htmn7 1/1 Running 0 25snginx-deployment-5f89547d9c-nwxs2 1/1 Running 0 99snginx-deployment-5f89547d9c-rpwlg 1/1 Running 0 25snginx-deployment-5f89547d9c-vlr5p 1/1 Running 0 95s

2.5 暂停和恢复 Deployment 更新

上述演示的均为更改某一处的配置，更改后立即触发更新，大多数情况下可能需要针对一个 资源文件更改多处地方，而并不需要多次触发更新，此时可以使用 Deployment 暂停功能，临时 禁用更新操作，对 Deployment 进行多次修改后在进行更新。

使用 kubectl rollout pause 命令即可暂停 Deployment 更新：

# kubectl rollout pause deployment/nginx-deploymentdeployment.extensions/nginx-deployment paused

然后对 Deployment 进行相关更新操作，比如先更新镜像，然后对其资源进行限制（如果使 用的是 kubectl edit 命令，可以直接进行多次修改，无需暂停更新，kubectlset 命令一般会集成在 CICD 流水线中）：

# kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1deployment.apps/nginx-deployment image updated# kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mideployment.apps/nginx-deployment resource requirements updated

通过 rollout history 可以看到没有新的更新：

# kubectl rollout history deployment.v1.apps/nginx-deploymentdeployment.apps/nginx-deployment REVISION CHANGE-CAUSE1 5 kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v1 --record=true7 kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true8 kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=true

进行完最后一处配置更改后，使用 kubectl rollout resume 恢复 Deployment 更新：

# kubectl rollout resume deployment.v1.apps/nginx-deploymentdeployment.apps/nginx-deployment resumed

可以查看到恢复更新的 Deployment 创建了一个新的 RS（ReplicaSet 缩写）：

# kubectl get rsNAME DESIRED CURRENT READY AGEnginx-deployment-57895845b8 5 5 4 11s

可以查看 Deployment 的 image（镜像）已经变为 nginx:1.9.1

# kubectl describe deploy nginx-deploymentName: nginx-deploymentNamespace: default...Annotations: deployment.kubernetes.io/revision: 9 kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx=dotbalo/canary:v2 --record=trueSelector: app=nginxReplicas: 5 desired | 5 updated | 5 total | 5 available | 0 unavailableStrategyType: RollingUpdateMinReadySeconds: 0RollingUpdateStrategy: 25% max unavailable, 25% max surgePod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP

2.6 更新 Deployment 的注意事项

历史版本清理策略：

在默认情况下，revision 保留 10 个旧的 ReplicaSet，其余的将在后台进行垃圾回收，可以 在.spec.revisionHistoryLimit 设置保留 ReplicaSet 的个数。当设置为 0 时，不保留历史记录。

更新策略：

5. .spec.strategy.type==Recreate，表示重建，先删掉旧的Pod再创建新的Pod；

6. .spec.strategy.type==RollingUpdate，表示滚动更新，可以指定maxUnavailable和maxSurge

来控制滚动更新过程；

.spec.strategy.rollingUpdate.maxUnavailable，指定在回滚更新时最大不可用的Pod数量， 可选字段，默认为25%，可以设置为数字或百分比，如果maxSurge为0，则该值不能 为0；

.spec.strategy.rollingUpdate.maxSurge可以超过期望值的最大Pod数，可选字段，默认为 25%，可以设置成数字或百分比，如果maxUnavailable为0，则该值不能为0。Ready 策略：

.spec.minReadySeconds 是可选参数，指定新创建的 Pod 应该在没有任何容器崩溃的情况下 视为 Ready（就绪）状态的最小秒数，默认为 0，即一旦被创建就视为可用，通常和容器探针连 用。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。