有关Kubernetes部署的自学笔记（第一部分）
以下是有关Kubernetes部署的学习笔记，关于YAML文件的头部常见的 kind: Deployment。
apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
部署是指
部署提供了对Pod和Replica Set（下一代复制控制器）进行声明性更新的功能。通过描述部署对象的目标状态，部署控制器可以以受控速度将实际状态修改为目标状态。可以通过定义部署并创建新资源或将现有资源替换为新资源。
以下是典型的使用案例：
-
- デプロイメントを作成し、レプリカセットとポッドが起動します。
-
- デプロイメントの状態をチェックして、成功か否かを確認できます。
-
- 実行中のデプロイメントを更新して、ポッドを再作成できます。（たとえば、新しいイメージを使用するなど）
-
- 更新後のデプロイメントが安定しないケースには、以前のレビジョンにロールバックできます。
- デプロイメントの一時停止と再開
创建部署
部署控制器会通过读取以下的YAML文件来创建3个nginx pod和副本集。
1: apiVersion: apps/v1beta2 # for versions before 1.8.0 use apps/v1beta1
2: kind: Deployment
3: metadata:
4: name: nginx-deployment
5: labels:
6: app: nginx
7: spec:
8: replicas: 3 <--- レプリカ・セット 3個を指定
9: selector:
10: matchLabels:
11: app: nginx
12: template:
13: metadata:
14: labels:
15: app: nginx
16: spec:
17: containers:
18: - name: nginx
19: image: nginx:1.7.9 <--- コンテナのイメージを指定
20: ports:
21: - containerPort: 80
主要项目说明
-
- 一行目にAPIのバージョン指定 (注１)
-
- コントローラの種別指定は、2行目 kind: Deployment
このデプロイメントの名前は、3行目のmetadata:の下 name:の nginx-deployment
デプロイメントのポッド数は、8行目replicas:で示される3つのレプリカのポッドを作成
管理対象のポッドは、9行目からのapp: nginxに一致するポッド
ポッド・テンプレートであるメタ情報と仕様が、12行目から記述、メタ情報(metadata)には管理対象として識別するラベル、仕様(spec)には、レジストリに登録されたコンテナ・イメージの名前とタグ、外部とのポート番号の指定
请注意，即使在IBM Cloud k8s中使用版本1.8.2.1501，也是通过apps/v1beta1提供的。根据apiVersion的次要字符串的处理方式并不是统一的。
部署创建的示例执行
还可以指定在GitHub上保存的上述YAML文件，如下所示。
$ kubectl create -f https://raw.githubusercontent.com/takara9/k8s_study/master/nginx_deploy.yaml
要确认并执行操作，请使用 “get deployment” 的选项。
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 12s
-
- NAME クラスター内のデプロイメントの名前をリストします。
-
- DESIRED アプリケーションのレプリカの必要な数を表示します。これは、デプロイメントの作成時に定義します。 これが望ましい状態です。
-
- CURRENT 現在実行中のレプリカの数を表示します。
-
- UP-TO-DATE 希望の状態になるように更新されたレプリカの数を表示します。
-
- AVAILABLE アプリケーションに使用可能なレプリカの数を表示します。
- AGE アプリケーションが実行されている時間が表示されます。
要确认部署（发布）执行的情况，请执行 kubectl rollout status。
$ kubectl rollout status deployment nginx-deployment
deployment "nginx-deployment" successfully rolled out
部署的层次结构 de
用kubectl命令确认部署配置的要素。请注意NAME字段并追踪查看。你会发现部署的名称后面连接着副本集的ID，然后是容器组的ID。你可以看到最底层是运行着的Docker容器。
部署
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 6m
复制品套装
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-569477d6d8 3 3 3 6m
咱只需要一个选项，请原生中文重述以下内容：
瞧这个对话框
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-569477d6d8-4fcgg 1/1 Running 0 6m
nginx-deployment-569477d6d8-vk69d 1/1 Running 0 6m
nginx-deployment-569477d6d8-vnz8b 1/1 Running 0 6m
容器（内部）
通过查看容器，我们可以知道正在使用docker容器。
$ kubectl describe pod
Name: nginx-deployment-569477d6d8-4fcgg
Namespace: default
Node: 10.132.253.17/10.132.253.17
Start Time: Thu, 14 Dec 2017 04:52:57 +0000
Labels: app=nginx
pod-template-hash=1250338284
Status: Running
IP: 172.30.170.222
Controllers: ReplicaSet/nginx-deployment-569477d6d8
Containers:
nginx:
Container ID: docker://2709b784b9fd160b658c1c7f5ec5ff79d3fb6aa739cd1922f658b77662aa2d0b
Image: nginx:1.7.9
Image ID: docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451
Port: 80/TCP
State: Running
Started: Thu, 14 Dec 2017 04:52:59 +0000
Ready: True
Restart Count: 0
Pod模板的标签
通过在kubectl get pods命令中添加–show-labels选项，可以查看已经分配的标签。
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-569477d6d8-4fcgg 1/1 Running 0 32m app=nginx,pod-template-hash=1250338284
nginx-deployment-569477d6d8-vk69d 1/1 Running 0 32m app=nginx,pod-template-hash=1250338284
nginx-deployment-569477d6d8-vnz8b 1/1 Running 0 32m app=nginx,pod-template-hash=1250338284
请提供参考资料。
请提供相关信息。
请提供相应的资讯。
请提供相关参考资料。
Kubernetes 应用程序接口
标签和选择器
Pod 模板
更新部署
为了理解“k8s如何更新应用程序”的操作，我们将容器中的nginx 1.7.9镜像更新到`nginx 1.9.2’并验证其运行情况。
初始状态
最初的状态是在一个Nginx 1.7.9的容器中，服务由复制集哈希569477d6d8提供。
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-569477d6d8-4fcgg 1/1 Running 0 32m app=nginx,pod-template-hash=1250338284
nginx-deployment-569477d6d8-vk69d 1/1 Running 0 32m app=nginx,pod-template-hash=1250338284
nginx-deployment-569477d6d8-vnz8b 1/1 Running 0 32m app=nginx,pod-template-hash=1250338284
将nginx从1.7.9更新至1.9.2。
有三种方法可以更新容器映像。
在更新了YAML文件之后进行应用
通过编辑部署时的YAML文件并执行”kubectl apply -f nginx-deployment.yml”来进行第一种方法。
在vim中编辑文件，将1.7.9修改为1.9.1。
16: spec:
17: containers:
18: - name: nginx
19: image: nginx:1.7.9 -> 1.9.1 へ変更
使用kubectl命令应用更新过的YAML文件。
$ kubectl apply -f nginx-deployment.yml
2. 编辑正在运行的部署的YAML文件
第二种方法是使用 “kubectl edit” 命令，可以在运行中的部署中使用编辑器进行修改。完成编辑并保存后，将立即开始进行滚动更新。
$ kubectl edit deployment nginx-deployment
deployment "nginx-deployment" edited
以下是正在使用默认编辑器vim编辑的屏幕示例。
31 template:
32 metadata:
33 creationTimestamp: null
34 labels:
35 app: nginx
36 spec:
37 containers:
38 - image: nginx:1.9.1
39 imagePullPolicy: IfNotPresent
40 name: nginx
41 ports:
42 - containerPort: 80
43 protocol: TCP
3. 在命令行中指定所需的容器。
改变版本的第三种方法是通过命令行来进行。
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated
确认执行结果
您可以通过以下任何一种方法，使用下面的命令来确认整体操作。
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out
在完成发布后，可以在Pod级别进行验证，发现所有副本集和Pod的哈希值都发生了改变，说明部署的内容全部被替换了。
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-6bd4859cdb-2kpnl 1/1 Running 0 27s app=nginx,pod-template-hash=2680415786
nginx-deployment-6bd4859cdb-mdx4q 1/1 Running 0 32s app=nginx,pod-template-hash=2680415786
nginx-deployment-6bd4859cdb-mg5f5 1/1 Running 0 45s app=nginx,pod-template-hash=2680415786
正在推出的行动中。
我們將確認在釋出現有服務的新版本時，k8s的運作方式。
具體來說，我們將從映像的web:v1升級到web:v2版本。
14 spec:
15 containers:
16 - name: nginx
17 image: registry.ng.bluemix.net/takara/web:v1
14 spec:
15 containers:
16 - name: nginx
17 image: registry.ng.bluemix.net/takara/web:v2
最初的状态
有三个部署的Web:v1正在运行中，每个部署中有三个Pod。现在要将这个状态切换至Web:v2。
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-web-deployment 3 3 3 3 10m
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-765656d945-7fkk7 1/1 Running 0 10m
nginx-web-deployment-765656d945-fjt7w 1/1 Running 0 10m
nginx-web-deployment-765656d945-g6zbd 1/1 Running 0 10m
网络：开始更新到v2版本
应用描述了web:v2的图像的nginx-web2.yml，并开始执行故障转移。
$ kubectl apply -f nginx-web2.yml
deployment "nginx-web-deployment" configured
网页正在从v1切换到v2。
网站v1的复制品套装是765656d945，有两个正在运行。
网站v2的复制品套装是b6fd9b64b。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-765656d945-7fkk7 1/1 Terminating 0 11m
nginx-web-deployment-765656d945-fjt7w 1/1 Running 0 11m
nginx-web-deployment-765656d945-g6zbd 1/1 Running 0 11m
nginx-web-deployment-b6fd9b64b-kf2hp 0/1 ContainerCreating 0 3s
nginx-web-deployment-b6fd9b64b-x7ckc 0/1 ContainerCreating 0 3s
当web:v2的两个副本设置开始运行时，应用程序的升级已完成。然后，web:v1将全部终止。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-765656d945-7fkk7 0/1 Terminating 0 11m
nginx-web-deployment-765656d945-fjt7w 0/1 Terminating 0 11m
nginx-web-deployment-765656d945-g6zbd 0/1 Terminating 0 11m
nginx-web-deployment-b6fd9b64b-kf2hp 1/1 Running 0 5s
nginx-web-deployment-b6fd9b64b-wp995 0/1 ContainerCreating 0 2s
nginx-web-deployment-b6fd9b64b-x7ckc 1/1 Running 0 5s
网站v2的第三个已经启动。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-765656d945-7fkk7 0/1 Terminating 0 11m
nginx-web-deployment-765656d945-fjt7w 0/1 Terminating 0 11m
nginx-web-deployment-765656d945-g6zbd 0/1 Terminating 0 11m
nginx-web-deployment-b6fd9b64b-kf2hp 1/1 Running 0 9s
nginx-web-deployment-b6fd9b64b-wp995 1/1 Running 0 6s
nginx-web-deployment-b6fd9b64b-x7ckc 1/1 Running 0 9s
网页：正在进行v1的清理工作
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-765656d945-fjt7w 0/1 Terminating 0 11m
nginx-web-deployment-b6fd9b64b-kf2hp 1/1 Running 0 15s
nginx-web-deployment-b6fd9b64b-wp995 1/1 Running 0 12s
nginx-web-deployment-b6fd9b64b-x7ckc 1/1 Running 0 15s
切换过程已经完成。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-b6fd9b64b-kf2hp 1/1 Running 0 18s
nginx-web-deployment-b6fd9b64b-wp995 1/1 Running 0 15s
nginx-web-deployment-b6fd9b64b-x7ckc 1/1 Running 0 18s
参考资料：使用复制控制器执行滚动更新
策略
在上述过渡期状态下，根据RollingUpdateStrategy所设定的值，web:v1的Pod数量减少，而web:v2的Pod数量增加。
$ kubectl describe deploy
Name: nginx-web-deployment
Namespace: default
CreationTimestamp: Thu, 14 Dec 2017 11:00:49 +0000
Labels: app=nginx
Selector: app=nginx
Replicas: 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-web-deployment-b6fd9b64b (3/3 replicas created)
<以下省略>
对移行中的 Pod 数进行控制，使用 RollingUpdateStrategy 指定，通过 1 max unavailable，将处于停止状态的 Pod 限制在一个。同时，也指定了最大 1 个 surge（1 max surge），尽管在上述例子中没有体现，但是超过 Pod 同时运行数的数量将被限制在最大 1 个。
详细查看以上部署的情况，我们可以看到，在创建新的Pod之后，删除了一些旧的Pod并创建了新的Pod。直到有足够数量的新Pod出现之前，不会停止旧的Pod。直到有足够数量的旧Pod被停止之前，新Pod不会被创建。确保可用的Pod数量大于等于2，并且Pod的总数最多为4。
下面是对kubectl describe deploy命令中的Events部分进行了编辑，只保留了理解所需的部分。在该事件记录中，首先启动了一个新的Pod。在这里可以看出，有3个正在运行的Web:v1 Pod和最初启动的Web:v2 Pod，总共运行了4个Pod，并且符合最大1个Pod的扩容限制。
Events:
From Reason Message
----- ------ -------
{deployment-controller } ScalingReplicaSet Scaled up replica set nginx-web-deployment-b6fd9b64b to 1
{deployment-controller } ScalingReplicaSet Scaled down replica set nginx-web-deployment-765656d945 to 2
{deployment-controller } ScalingReplicaSet Scaled up replica set nginx-web-deployment-b6fd9b64b to 2
{deployment-controller } ScalingReplicaSet Scaled down replica set nginx-web-deployment-765656d945 to 1
{deployment-controller } ScalingReplicaSet Scaled up replica set nginx-web-deployment-b6fd9b64b to 3
{deployment-controller } ScalingReplicaSet Scaled down replica set nginx-web-deployment-765656d945 to 0
kubectl的滚动更新和部署之间的比较。
kubectl滚动更新在Pod和ReplicationControllers上执行类似的更新。但是，Deployment在服务器端是声明性的，并且具有出色的功能，例如在滚动更新完成后还可以回滚到先前的修订版本等，所以我认为使用Deployment是很好的选择。
滚动处理
在推进升级的过程中，”ロールオーバー”指的是在服务提供中将版本切换到下一个版本的过程中，进一步覆盖并要求进行下一个版本的多个更新的情况。在智能手机应用程序中，由于同时连接的客户端数量很多，可能存在大约100台应用程序服务器的情况。因此，在进行新版本发布时，需要保持运行中的会话并进行迁移，这需要相当长的时间。在推进新版本发布的过程中，如果需要发布问题修复版本并进行执行，Kubernetes将发挥出色的作用。我们将通过实际实验结果来观察这种运行方式。
在实验中，有Web:v1、Web:v2和Web:v3的版本。在Web:v1正在正式提供的时候，我们正在将Web:v2推向生产环境，同时进行Web:v3的滚动升级。
在内部操作中，要求对Web:v3的复制集进行增加操作，增加Web:v2复制集的Pod，并减少Web:v1复制集的Pod。在进行此操作时，部署控制器将不等待Web:v2的迁移，而是立即终止Web:v1并开始迁移至Web:v3。已经启动的Web:v2的Pod将被逐步终止。现在我们来确认一下实际操作。
最初的网络状态为Web:v1。
在初始状态下，部署的副本集中的所有Pod都处于Web:v1的状态。这里，我们可以将Web:v1的副本集标识为哈希值765656d945。
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-765656d945-9g8ks 1/1 Running 0 14s
nginx-web-deployment-765656d945-b44mt 1/1 Running 0 14s
nginx-web-deployment-765656d945-j9bft 1/1 Running 0 14s
nginx-web-deployment-765656d945-jvccm 1/1 Running 0 14s
nginx-web-deployment-765656d945-p69qx 1/1 Running 0 14s
nginx-web-deployment-765656d945-p6v6d 1/1 Running 0 14s
nginx-web-deployment-765656d945-p8l7l 1/1 Running 0 14s
nginx-web-deployment-765656d945-qm4s7 1/1 Running 0 14s
nginx-web-deployment-765656d945-s2ljf 1/1 Running 0 14s
nginx-web-deployment-765656d945-t742l 1/1 Running 0 14s
正在推出中 网络版本：v1 -> 网络版本：v2
下面是请求Web:v2的升级之后的状态。可以看到，Web:v2的哈希值为b6fd9b64b的Pod在增加，而Web:v1的哈希值为765656d945的Pod在减少。如果一切正常，所有的Pod都应该切换到Web:v2。
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-765656d945-9g8ks 1/1 Terminating 0 19s
nginx-web-deployment-765656d945-b44mt 1/1 Running 0 19s
nginx-web-deployment-765656d945-j9bft 0/1 Terminating 0 19s
nginx-web-deployment-765656d945-jvccm 1/1 Running 0 19s
nginx-web-deployment-765656d945-p69qx 1/1 Terminating 0 19s
nginx-web-deployment-765656d945-p6v6d 1/1 Running 0 19s
nginx-web-deployment-765656d945-p8l7l 1/1 Terminating 0 19s
nginx-web-deployment-765656d945-qm4s7 0/1 Terminating 0 19s
nginx-web-deployment-765656d945-s2ljf 1/1 Running 0 19s
nginx-web-deployment-765656d945-t742l 1/1 Running 0 19s
nginx-web-deployment-b6fd9b64b-7qqg7 0/1 Pending 0 0s
nginx-web-deployment-b6fd9b64b-pgj4s 0/1 Pending 0 0s
nginx-web-deployment-b6fd9b64b-rccl5 1/1 Running 0 3s
nginx-web-deployment-b6fd9b64b-rmfwk 1/1 Running 0 3s
nginx-web-deployment-b6fd9b64b-tz2tv 1/1 Running 0 5s
nginx-web-deployment-b6fd9b64b-wht4l 1/1 Running 0 5s
请投入Web:v3的升级版本 (Web: v3的升级版即将上线)。
在这里发现了v2的问题，対策容器v3立即建立并且要求进行Web:v3的扩展部署。在这种几乎难以想象的情况下，Web:v3的复制集(758c4bbc7f)在开始进行换代后的情况如下：
同时存在Web:v1、Web:v2和Web:v3三个版本。当前有9个正在运行的Pod，1个已停止的Pod，总共有11个Pod正在运行或创建容器，而且有1个突发性Pod数，实现了滚动更新策略的要求，并且换代正在进行中。Web:v2 b6fd9b64b也已经开始停止过程。
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-758c4bbc7f-m9vqs 0/1 ContainerCreating 0 0s
nginx-web-deployment-758c4bbc7f-zg6qh 0/1 ContainerCreating 0 0s
nginx-web-deployment-765656d945-9g8ks 1/1 Terminating 0 23s
nginx-web-deployment-765656d945-b44mt 1/1 Running 0 23s
nginx-web-deployment-765656d945-j9bft 0/1 Terminating 0 23s
nginx-web-deployment-765656d945-jvccm 1/1 Running 0 23s
nginx-web-deployment-765656d945-p69qx 1/1 Terminating 0 23s
nginx-web-deployment-765656d945-p6v6d 1/1 Running 0 23s
nginx-web-deployment-765656d945-p8l7l 1/1 Terminating 0 23s
nginx-web-deployment-765656d945-qm4s7 0/1 Terminating 0 23s
nginx-web-deployment-765656d945-s2ljf 1/1 Running 0 23s
nginx-web-deployment-765656d945-t742l 1/1 Running 0 23s
nginx-web-deployment-b6fd9b64b-7qqg7 0/1 Terminating 0 4s
nginx-web-deployment-b6fd9b64b-pgj4s 0/1 Terminating 0 4s
nginx-web-deployment-b6fd9b64b-rccl5 1/1 Running 0 7s
nginx-web-deployment-b6fd9b64b-rmfwk 1/1 Running 0 7s
nginx-web-deployment-b6fd9b64b-tz2tv 1/1 Running 0 9s
nginx-web-deployment-b6fd9b64b-wht4l 1/1 Running 0 9s
在Web上进行滚动中，版本:v3。
Web:v2全部停用并进行清理工作。目前运行最多的版本是Web:v3。
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-758c4bbc7f-8zps4 1/1 Running 0 10s
nginx-web-deployment-758c4bbc7f-d4ln5 1/1 Running 0 21s
nginx-web-deployment-758c4bbc7f-m9vqs 1/1 Running 0 23s
nginx-web-deployment-758c4bbc7f-nspbm 1/1 Running 0 9s
nginx-web-deployment-758c4bbc7f-rc2v6 1/1 Running 0 8s
nginx-web-deployment-758c4bbc7f-rzwv5 1/1 Running 0 21s
nginx-web-deployment-758c4bbc7f-sff26 0/1 ContainerCreating 0 6s
nginx-web-deployment-758c4bbc7f-snb6w 1/1 Running 0 17s
nginx-web-deployment-758c4bbc7f-vw5nb 1/1 Running 0 11s
nginx-web-deployment-758c4bbc7f-zg6qh 1/1 Running 0 23s
nginx-web-deployment-765656d945-s2ljf 0/1 Terminating 0 46s
nginx-web-deployment-b6fd9b64b-rccl5 0/1 Terminating 0 30s
nginx-web-deployment-b6fd9b64b-tz2tv 0/1 Terminating 0 32s
nginx-web-deployment-b6fd9b64b-wht4l 1/1 Terminating 0 32s
ロールオーバー完了 Web:v3
网页: v3的部署已经完成。
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-758c4bbc7f-8zps4 1/1 Running 0 21s
nginx-web-deployment-758c4bbc7f-d4ln5 1/1 Running 0 32s
nginx-web-deployment-758c4bbc7f-m9vqs 1/1 Running 0 34s
nginx-web-deployment-758c4bbc7f-nspbm 1/1 Running 0 20s
nginx-web-deployment-758c4bbc7f-rc2v6 1/1 Running 0 19s
nginx-web-deployment-758c4bbc7f-rzwv5 1/1 Running 0 32s
nginx-web-deployment-758c4bbc7f-sff26 1/1 Running 0 17s
nginx-web-deployment-758c4bbc7f-snb6w 1/1 Running 0 28s
nginx-web-deployment-758c4bbc7f-vw5nb 1/1 Running 0 22s
nginx-web-deployment-758c4bbc7f-zg6qh 1/1 Running 0 34s
展示复制品套装时，可以全面了解并包括已清理的物品。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-758c4bbc7f 10 10 10 1h
nginx-web-deployment-765656d945 0 0 0 1h
nginx-web-deployment-b6fd9b64b 0 0 0 1h
この機能はk8sの有用性を最も顕著に示すものと思います。大規模なシステムでアプリのリリースで苦労した経験を持った者であれば、この機能の素晴らしさが理解できると思います。 しかし、ロードバランサーとの関係やコンテナ内のアプリ設計に注意を払う必要がありますので、後述したいと思います。
滚动更新的调整功能
滚动升级部署（RollingUpdate Deployments）支持同时运行多个应用程序版本。当您或自动缩放正在调整正在进行中（进行中或暂停）的滚动升级部署的规模时，部署控制器会采取额外的平衡措施来减少风险，即向现有的活动副本集（具有Pod的副本集）添加平衡。例如，假设使用replicas = 10、maxSurge = 3和maxUnavailable = 2来执行部署。
1 apiVersion: extensions/v1beta1
2 kind: Deployment
3 metadata:
4 name: nginx-web-deployment
5 spec:
6 replicas: 10
7 selector:
8 matchLabels:
9 app: nginx
10 strategy:
11 rollingUpdate: <--- ここからの条件に注意
12 maxSurge: 3
13 maxUnavailable: 2
14 type: RollingUpdate
15 template:
16 metadata:
17 labels:
18 app: nginx
19 spec:
20 containers:
21 - name: nginx
22 image: registry.ng.bluemix.net/takara/web:v1
23 ports:
24 - containerPort: 80
执行下面的命令 `kubectl create -f nginx-web6.yml`，应用程序正在运行状态。
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-6798cb747c 10 10 10 19s
在这里，将应用Web:v2。
$ kubectl create -f nginx-web7.yml
deployment "nginx-web-deployment" created
通过 maxUnavailable = 2 的条件，可以减少 6798cb747c 的副本集共2个。通过 maxSurge = 3 的条件，允许总共13个Pod存在，因此将67bcffb8b6 的期望副本数（DESIRED）设为5。
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-6798cb747c 8 8 8 22s
nginx-web-deployment-67bcffb8b6 5 5 0 0s
接下来，我们将增加67bcffb8b6的复制集数量，并在保持maxUnavailable = 2的条件下推进滚动更新。
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-6798cb747c 5 5 5 25s
nginx-web-deployment-67bcffb8b6 8 8 3 3s
当6798cb747c的DESIRED逐个减少，与之对应的67bcffb8b6的DESIRED增加，当最终READY达到10时，即可完成滚动更新。
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-6798cb747c 0 0 0 42s
nginx-web-deployment-67bcffb8b6 10 10 10 20s
回退
这是一种情况，出于某种原因，将部署的应用程序回滚到先前的版本。
回到上一个版本
在之前的基础上，以下是Web:v3已经完全上线的状态。现在，我们将尝试回滚到之前的Web:v2版本。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-758c4bbc7f 10 10 10 1h
nginx-web-deployment-765656d945 0 0 0 1h
nginx-web-deployment-b6fd9b64b 0 0 0 1h
将回滚命令 kubectl rollout undo deployment 应用于之前的版本 Web:v2。
$ kubectl rollout undo deployment nginx-web-deployment
deployment "nginx-web-deployment" rolled back
在执行回滚命令后的初始状态。可以观察到Web:v3(758c4bbc7f)的Pod数量减少，而Web:v2(b6fd9b64b)的Pod数量增加。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-758c4bbc7f 7 7 7 1h
nginx-web-deployment-765656d945 0 0 0 1h
nginx-web-deployment-b6fd9b64b 4 4 2 1h
一段时间过去后，所有的Pod都被回滚到了Web:v2(b6fd9b64b)版本。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-758c4bbc7f 0 0 0 1h
nginx-web-deployment-765656d945 0 0 0 1h
nginx-web-deployment-b6fd9b64b 10 10 10 1h
我被k8s的部署控制器所感动，它可以如此简便地回滚之前发布的应用程序。
发布失败的回滚
有一种情况需要紧急撤回发布。例如，容器不稳定，反复重启，容器镜像名称拼写错误或者注册表登记错误等问题导致无法成功完成部署。我们将对这类问题进行调查，以确定部署控制器的行为和处理方法。
使用以下命令将Web:v4版本发布：
然而，Web:v4镜像已被注册到其他名称的注册表中，导致无法拉取容器的状态。
$ kubectl apply -f nginx-web4.yml
deployment "nginx-web-deployment" configured
使用以下命令确认升级的状态。显示了2个失败和等待完成的信息。
$ kubectl rollout status deployment nginx-web-deployment
Waiting for rollout to finish: 2 out of 10 new replicas have been updated...
使用 `Ctrl + C` 命令停止，并使用下一个命令确认副本集的状态。这样一来，我们就可以知道 Web:v4(7598f5987b) 的副本集已经启动了 2 个，但还没有 READY 状态。另外，Web:v2(b6fd9b64b) 的副本数减少了 1 个。这个 Pod 数量受 RollingUpdateStrategy 的默认值控制。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-758c4bbc7f 0 0 0 9h
nginx-web-deployment-7598f5987b 2 2 0 3m
nginx-web-deployment-765656d945 0 0 0 9h
nginx-web-deployment-b6fd9b64b 9 9 9 9h
接下来我们要确认一下Pod的状态。我们发现Web:v4副本集7598f5987b的Pod未能启动，处于ImagePullBackOff状态，即从注册表中下载镜像失败，并进入了中断状态。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-7598f5987b-pk87t 0/1 ImagePullBackOff 0 4m
nginx-web-deployment-7598f5987b-z5t8h 0/1 ImagePullBackOff 0 4m
nginx-web-deployment-b6fd9b64b-4s2v9 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-ffmdk 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-h544r 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-hf44d 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-kp8x5 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-rzmst 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-s9swt 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-wxjf7 1/1 Running 0 7h
nginx-web-deployment-b6fd9b64b-x696f 1/1 Running 0 7h
在这里执行回滚操作。
$ kubectl rollout undo deployment nginx-web-deployment
deployment "nginx-web-deployment" rolled back
当我检查复制集时，可以看出它已经回滚到Web: v2 版本。
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-758c4bbc7f 0 0 0 9h
nginx-web-deployment-7598f5987b 0 0 0 5m
nginx-web-deployment-765656d945 0 0 0 9h
nginx-web-deployment-b6fd9b64b 10 10 10 9h
部署控制器具有防止无法启动的部署意外发布导致服务完全崩溃的功能，只需一个命令即可回滚。
坠入循环的案例
我曾经见过拉取（下载）容器镜像失败的情况，但以下是容器在启动后立即崩溃的情况。可以看出故障安全功能正在起作用。
$ kubectl apply -f nginx-web5.yml
deployment "nginx-web-deployment" configured
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-web-deployment-69c86977bf 2 2 0 5s
nginx-web-deployment-758c4bbc7f 0 0 0 11h
nginx-web-deployment-7598f5987b 0 0 0 1h
nginx-web-deployment-765656d945 0 0 0 11h
nginx-web-deployment-b6fd9b64b 9 9 9 11h
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-69c86977bf-fsklh 0/1 CrashLoopBackOff 1 15s
nginx-web-deployment-69c86977bf-xhjdr 0/1 CrashLoopBackOff 1 15s
nginx-web-deployment-b6fd9b64b-4s2v9 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-ffmdk 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-h544r 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-hf44d 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-kp8x5 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-rzmst 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-s9swt 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-wxjf7 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-x696f 1/1 Running 0 9h
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-web-deployment-69c86977bf-fsklh 0/1 CrashLoopBackOff 6 8m
nginx-web-deployment-69c86977bf-xhjdr 0/1 CrashLoopBackOff 6 8m
nginx-web-deployment-b6fd9b64b-4s2v9 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-ffmdk 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-h544r 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-hf44d 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-kp8x5 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-rzmst 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-s9swt 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-wxjf7 1/1 Running 0 9h
nginx-web-deployment-b6fd9b64b-x696f 1/1 Running 0 9h
从这种状态下，可以通过回滚来撤销失败的发布。
指定版本进行回溯
通过将–record标志作为命令的标志添加到kubectl apply -f nginx-web2.yml中，可以记录以前发布的修订版本的历史记录。 这样就可以指定该修订版本并进行回滚。
$ kubectl rollout history deployment nginx-web-deployment
deployments "nginx-web-deployment"
REVISION CHANGE-CAUSE
1 kubectl create -f nginx-web1.yml --record
2 kubectl apply -f nginx-web2.yml --record
4 kubectl apply -f nginx-web4.yml --record
5 kubectl apply -f nginx-web3.yml --record
举例来说，要返回到第二个修订版本，您需要添加”–to-revision=2″。
$ kubectl rollout undo deployment nginx-web-deployment --to-revision=2
继续到第二部分。
请参考一下相关资料。
-
- Kubernetes Reference Documentation Deployment https://kubernetes-v1-4.github.io/docs/user-guide/deployments/
Kubernetes Documentation CONCEPTS Deployment https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
Kubernetes: Deployment の仕組み https://qiita.com/tkusumi/items/01cd18c59b742eebdc6a
