管理应用程序生命周期

使用 Kubernetes本机工具和第三方工具来执行应用程序的滚动更新和回滚，而无需为用户提供停机时间。

更新策略

要更新应用程序，可以从各种策略中进行选择，例如以下策略。在执行更复杂的金丝雀部署之前，您可能要首先执行滚动部署或即时切换。

滚动部署: 可以使用 Kubernetes 本机功能来创建 v2 部署，并逐渐替换先前的 v1 部署。这种方法要求应用程序向后兼容，这样，使用 v2 应用程序版本的用户就不会体验到任何破坏性更改。有关更多信息，请参阅管理滚动部署来更新应用程序。
即时切换: 即时切换也称为蓝绿部署，这种方法需要将计算资源加倍，以同时运行两个版本的应用程序。通过此方法，可以近乎实时地将用户切换到更高版本。确保使用服务标签选择器（如 version: green 和 version: blue），以确保请求被发送到正确的应用程序版本。可以创建新的 version: green 部署，等待它准备就绪，然后删除 version: blue 部署。或者也可以执行滚动更新，但将 maxUnavailable 参数设置为 0%，maxSurge 参数设置为 100%。
金丝雀或 A/B 部署: 金丝雀部署是更复杂的更新策略，使用此方法时，要求您选取用户百分比（例如，5%），然后将这一比例的用户发送到新的应用程序版本。可以在日志记录和监视工具中收集有关新应用程序版本执行情况的度量值，执行 A/B 测试，然后将更新应用到更多用户。与所有部署一样，标注应用程序（例如，version: stable 和 version: canary）至关重要。要管理金丝雀部署，可以安装受管 Istio 附加服务网格，为集群设置Monitoring，然后按照本博文所述使用 Istio 服务网格进行 A/B 测试。

缩放应用程序

使用Kubernetes，您可以启用水平 pod 自动扩展，根据 CPU 自动增加或减少应用程序的实例数量。

要缩放工作程序节点而不是 pod？请查看集群自动缩放器。

准备工作

登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。
确保为您分配了授予适当KubernetesRBAC 角色的服务访问角色，以便您能在命名空间中使用Kubernetes资源。

扩展您的应用程序：

通过 CLI 将应用程序部署到集群。对于更复杂的部署，您可能需要创建配置文件。
```
kubectl create deployment <app_name> --image=<image>
```
设置在部署中运行的容器 (例如 100m) 的 CPU 资源限制 (以毫秒计)。您还可以设置内存限制，但水平 pod 自动缩放器仅考虑用于缩放目的的 CPU 资源限制。有关更多信息，请参阅 kubectl set resources 文档。
```
kubectl set resources deployment <app_name> --limits=cpu=100m
```

创建 Horizontal Pod Autoscaler，然后定义策略。有关更多信息，请参阅 kubectl autoscale 文档。

kubectl autoscale deployment <deployment_name> --cpu-percent=<percentage> --min=<min_value> --max=<max_value>

了解命令选项
选项	描述
`--cpu-percent`	Horizontal Pod Autoscaler 保持的平均 CPU 使用率，以百分比为单位指定。
`--min`	用于保持指定 CPU 使用率百分比的最小部署 Pod 数。
`--max`	用于保持指定 CPU 使用率百分比的最大部署 Pod 数。

管理滚动部署以更新应用程序

您可以使用 pod 模板（例如，部署），以自动化和受控方式来为工作负载管理应用程序更改的应用。如果应用未按计划开展，那么可以将部署回滚到先前的修订版。

要避免在滚动更新期间发生中断吗？请确保在部署中指定就绪性探测器，以便在最近更新的 pod 就绪后，继续对下一个应用程序 pod 执行应用。

准备工作

登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。
创建部署。
确保您拥有授予适当KubernetesRBAC 角色的服务访问角色，这样您才能在命名空间中使用Kubernetes资源。

要管理应用程序的滚动更新，请执行以下操作：

要确保仅在容器正在运行并准备好处理请求时将部署标记为准备就绪，请向部署添加活性和就绪性探测器。
更新部署以包含滚动更新策略，用于指定更新期间的最大激增 pod 数和不可用 pod 数或指定 pod 的百分比。
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 10
  selector:
    matchLabels:
      service: http-server
  minReadySeconds: 5
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
      maxSurge: 2
...
```
spec.minReadySeconds

缺省情况下，部署会一直等到 pod 标记为 ready 才会继续执行应用。如果您注意到尽管最新 pod 中的应用程序尚未准备就绪，部署仍继续创建 pod，请使用此字段来降低部署应用的速度。例如，如果指定 5，那么在 pod 处于 ready 状态后，部署会等待 5 秒，然后再创建下一个 pod。

spec.progressDeadlineSeconds

设置超时（以秒为单位），在此时间后会将部署视为失败。例如，如果没有超时，如果新的应用程序版本出现错误并立即挂起，则无法继续推出，因为 pod 永远无法达到 ready 状态。如果将此超时设置为 600 秒，那么应用中的任何阶段在 10 分钟内未能有所进展时，会将部署标记为失败，并且应用会停止。

spec.strategy.type

指定 RollingUpdate 策略类型。

spec.strategy.rollingUpdate.maxUnavailable

将更新期间可以不可用的最大 pod 数设置为数字 (2) 或百分比 (50%)。通常，请使用百分比，这样如果日后更改了副本数，不必记得要更新此处的数字，除非您希望将应用限制为一次只允许一个 pod 停止运行。如果永远不想低于 100% 容量，请将此值设为 0%，并指定 spec.strategy.type.rollingUpdate.maxSurge 参数。

spec.strategy.rollingUpdate.maxSurge

将应用期间部署可以使用的额外资源数设置为数字 (2) 或百分比 (50%)。例如，如果部署指定了 10 个副本，并且您将 maxSurge 设置为 2，那么在应用期间会创建 2 个新副本。现在，您有 12 个副本（10 个现有副本，2 个新副本）。在 2 个新副本准备就绪后，部署会将旧副本缩减为 8 个，以满足指定的 10 个副本的设置。此过程会一直持续到应用完成，此时所有 10 个副本都将运行新版本。

如果要执行蓝绿即时交换机样式更新，请将 maxSurge 设置为 100%。部署将创建所有新的必需副本，然后将旧版本副本向下扩展至 0。
转出更改。例如，您可能希望更改初始部署中使用的映像。
1. 获取部署名称。
```
kubectl get deployments
```
2. 获取 pod 名称。
```
kubectl get pods
```
3. 获取在 pod 中运行的容器的名称。
```
kubectl describe pod <pod_name>
```
4. 设置新映像以供部署使用。
```
kubectl set image deployment/<deployment_name><container_name>=<image_name>
```
运行命令时，更改会立即应用并会记录在应用历史记录中。

检查部署的状态。

kubectl rollout status deployments/<deployment_name>

如果您注意到状态中有些内容需要一些时间来跟进，那么可以使用以下命令来暂停和恢复应用。

kubectl rollout pause deployment <deployment_name>

kubectl rollout resume deployment <deployment_name>

回滚更改。
1. 查看部署的应用历史记录，并确定上次部署的修订版号。
```
kubectl rollout history deployment/<deployment_name>
```
  提示：要查看特定修订版的详细信息，请包含相应的修订版号。
```
kubectl rollout history deployment/<deployment_name> --revision=<number>
```
2. 回滚到先前的版本或指定修订版。要回滚到先前的版本，请使用以下命令。
```
kubectl rollout undo deployment/<depoyment_name> --to-revision=<number>
```

设置持续集成和交付

通过 IBM Cloud 和其他开放式源代码工具，您可以设置持续集成和交付 (CI/CD)，版本控制，工具链等，以帮助自动化应用程序开发和部署。

要查看受支持的集成的列表以及用于设置持续交付管道的步骤，请参阅设置持续集成和交付。

将部署复制到其他集群

在集群中使用版本控制系统（如Git）、配置管理项目（如 kustomize）或持续交付工具（如 Razee）时，您可以在集群之间快速部署应用程序配置文件。有时，您仅有少量在集群中测试过的部署，并且希望复制这些部署，然后在另一个集群中重新部署。

在开始之前，您需要两个群集和两个群集中所有命名空间的 Manager 服务访问角色，以便从一个群集复制所有资源并部署到另一个群集。

登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。

列出集群中的所有配置文件，并验证是否要复制这些配置。

kubectl get all

示例输出

NAME                                   READY   STATUS             RESTARTS   AGE
pod/java-web-6955bdbcdf-l756b          1/1     Running            0          59d

NAME                                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/java-web                       NodePort    172.21.xxx.xxx   <none>        8080:30889/TCP   59d

NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/java-web               1/1     1            1           59d

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/java-web-6955bdbcdf    1         1         1       59d

将集群中的配置文件复制到本地目录。选项 --export 会从配置文件中删除特定于群集的信息。
```
kubectl get all -o yaml --export > myconfigs.yaml
```
登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。
可选项：如果您的群集使用多个命名空间，请在标准群集和将图像提取秘密复制到每个命名空间中创建相同的命名空间。

将复制的配置文件部署到集群。如果配置文件中有无法应用的特定信息，可能需要更新配置文件并重新应用。

kubectl apply -f myconfigs.yaml

示例输出

pod/java-web-6955bdbcdf-l756b created
service/java-web created
deployment.apps/java-web created
replicaset.apps/java-web-6955bdbcdf created

验证配置文件是否已应用。
```
kubectl get all
```