官方参考:https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/
https://www.kubernetes.org.cn/deployment
Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括:
你只需要在Deployment中描述你想要的目标状态是什么,Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment,也可以创建一个新的替换旧的Deployment。
一个典型的用例如下
下面是 Deployment 示例。创建一个 ReplicaSet 展开三个 nginx
Pods:
该示例为官方示例下载地址是
https://raw.githubusercontent.com/kubernetes/website/master/content/zh/examples/controllers/nginx-deployment.yaml
# cat nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:1.15.4 name: nginx ports: - containerPort: 80
也可以通过以下命令生成该yaml文档然后修改
# kubectl create deployment nginx-deployment --image=nginx:1.15.4 --dry-run -o yaml apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: nginx-deployment name: nginx-deployment spec: replicas: 1 selector: matchLabels: app: nginx-deployment strategy: {} template: metadata: creationTimestamp: null labels: app: nginx-deployment spec: containers: - image: nginx:1.15.4 name: nginx resources: {} status: {}
在该例中
注意:`matchLabels` 字段是 {key,value} 的映射。单个 {key,value}在 `matchLabels` 映射中的值等效于 `matchExpressions` 的元素,其键字段是“key”,运算符为“In”,值数组仅包含“value”。所有要求,从 `matchLabels` 和 `matchExpressions`,必须满足才能匹配。
通过运行以下命令创建Deployment
kubectl apply -f nginx-deployment.yaml
注意:将kubectl的 —record 的flag设置为 true可以在annotation中记录当前命令创建或者升级了该资源。这在未来会很有用,例如,查看在每个Deployment revision中执行了哪些命令。
--record示例如下
运行kubectl get deployments
以检查 Deployment 是否已创建。如果仍在创建 Deployment ,则输出以下内容:
# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 48s
显示以下字段
`READY` 3/3左边3是真正运行的副本数右边3是期望的副本数即replicas定义的副本数。 `UP-TO-DATE`显示已更新以实现期望状态的副本数。 `AVAILABLE`显示应用程序可供用户使用的副本数。 `AGE` 显示应用程序运行的时间量。
要查看Deployment创建的ReplicaSet(rs),运行kubectl get rs输出
# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-67656986d9 3 3 3 108s
请注意, ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子
要查看每个Pod自动生成的标签,运行kubectl get pods --show-labels输出
# kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-67656986d9-996kk 1/1 Running 0 3m35s app=nginx,pod-template-hash=67656986d9 nginx-deployment-67656986d9-fgdwz 1/1 Running 0 3m35s app=nginx,pod-template-hash=67656986d9 nginx-deployment-67656986d9-j8jt8 1/1 Running 0 3m35s app=nginx,pod-template-hash=67656986d9
刚创建的Replica Set将保证总是有3个nginx的pod存在。并且创建的Pod名为[DEPLOYMENT-NAME]-[pod-template-hash]-[RANDOM-STRING]
注意: 你必须在Deployment中的selector指定正确pod template label(在该示例中是 app = nginx),不要跟其他的controller搞混了(包括Deployment、Replica Set、Replication Controller等)。Kubernetes本身不会阻止你这么做,如果你真的这么做了,这些controller之间会相互打架,并可能导致不正确的行为。
注意:不要更改此标签
Deployment 控制器将 pod-template-hash
标签添加到 Deployment 创建或使用的每个 ReplicaSet 。
此标签可确保 Deployment 的子 ReplicaSets 不重叠。它通过对 ReplicaSet 的 PodTemplate
进行哈希处理,并使用生成的哈希值添加到 ReplicaSet 选择器、Pod 模板标签,并在 ReplicaSet 可能具有的任何现有 Pod 中。
注意: Deployment的rollout当且仅当Deployment的pod template(例如.spec.template)中的label更新或者镜像更改时被触发。其他更新,例如扩容Deployment不会触发rollout。
安装以下步骤更新Deployment
首先修改yaml把nginx版本修改成1.7.9
应用一下各项nginx Pods,使用nginx:1.9.1镜像,而不是nginx:1.7.9
# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 deployment.apps/nginx-deployment image updated
说明:设置更新Deployment名为nginx-deployment镜像的镜像为nginx:1.9.1
也可以使用edit
命令来编辑Deployment,修改 .spec.template.spec.containers[0].image
,将nginx:1.7.9
改写成nginx:1.9.1
。
kubectl edit deployment/nginx-deployment
修改完输出
deployment.apps/nginx-deployment edited
查看rollout的状态,只要执行:
# kubectl rollout status deployment/nginx-deployment deployment "nginx-deployment" successfully rolled out
rollout成功后查看deployment
# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 9m37s
UP-TO-DATE的replica的数目已经达到了配置中要求的数目。
CURRENT的replica数表示Deployment管理的replica数量,AVAILABLE的replica数是当前可用的replica数量。
我们通过执行kubectl get rs
可以看到Deployment更新了Pod,通过创建一个新的Replica Set并扩容了3个replica,同时将原来的Replica Set缩容到了0个replica。
# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-54f57cf6bf 0 0 0 12m nginx-deployment-56f8998dbc 3 3 3 9m6s
执行 get pods
只会看到当前的新的pod:
# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-56f8998dbc-8j49x 1/1 Running 0 5m25s nginx-deployment-56f8998dbc-fpzwt 1/1 Running 0 5m26s nginx-deployment-56f8998dbc-r2wvp 1/1 Running 0 5m28s
下次更新这些Pod的时候,只需要更新Deployment中pod的template即可
Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下,它确保至少 75%所需 Pods 运行(25%最大不可用)。
Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下,它可确保最多增加 25% 期望 Pods 数(25%最大增量)。
例如,如果仔细查看上述 Deployment ,将看到它首先创建了一个新的 Pod,然后删除了一些旧的 Pods,并创建了新的 Pods。它不会杀死老 Pods,直到有足够的数量新的 Pods 已经出现,并没有创造新的 Pods,直到足够数量的旧 Pods 被杀死。它确保至少 2 个 Pods 可用,并且总共最多 4 个 Pods 可用。
获取Deployment更多信息
# kubectl describe deployments nginx-deployment Name: nginx-deployment Namespace: default CreationTimestamp: Fri, 20 Mar 2020 16:01:54 +0800 Labels: app=nginx Annotations: deployment.kubernetes.io/revision: 2 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"d... 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 Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: nginx-deployment-56f8998dbc (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 53s deployment-controller Scaled up replica set nginx-deployment-54f57cf6bf to 3 Normal ScalingReplicaSet 8s deployment-controller Scaled up replica set nginx-deployment-56f8998dbc to 1 Normal ScalingReplicaSet 6s deployment-controller Scaled down replica set nginx-deployment-54f57cf6bf to 2 Normal ScalingReplicaSet 6s deployment-controller Scaled up replica set nginx-deployment-56f8998dbc to 2 Normal ScalingReplicaSet 5s deployment-controller Scaled down replica set nginx-deployment-54f57cf6bf to 1 Normal ScalingReplicaSet 5s deployment-controller Scaled up replica set nginx-deployment-56f8998dbc to 3 Normal ScalingReplicaSet 3s deployment-controller Scaled down replica set nginx-deployment-54f57cf6bf to 0
可以看到,当第一次创建 Deployment 时,它创建了一个 ReplicaSet (nginx-deployment-54f57cf6bf)并将其直接扩展至 3 个副本。更新 Deployment 时,它创建了一个新的 ReplicaSet (nginx-deployment-56f8998dbc),并将其扩展为 1,然后将旧 ReplicaSet 缩小到 2,以便至少有 2 个 Pod 可用,并且最多创建 4 个 Pod。然后,它继续向上和向下扩展新的和旧的 ReplicaSet ,具有相同的滚动更新策略。最后,将有 3 个可用的副本在新的 ReplicaSet 中,旧 ReplicaSet 将缩小到 0。
原文:https://www.cnblogs.com/minseo/p/12532336.html