管理应用程序生命周期

使用 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）至关重要。要管理 Canary 部署，您可以安装托管的 Istio 附加服务网格，为您的集群配置 Monitoring，然后按照本博客文章中的说明，使用 Istio 服务网格进行 A/B 测试。

缩放应用程序

借助 Kubernetes，您可以启用水平Pod自动缩放功能，系统将根据CPU使用情况自动增加或减少应用程序的实例数量。

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

开始之前：

登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。
请确保您已被分配了一个服务访问角色，该角色授予了相应的“Kubernetes”RBAC角色，以便您能够在此命名空间中管理 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 执行应用。

开始之前：

登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。
创建部署。
请确保您拥有一个服务访问角色，该角色授予了相应的“Kubernetes”RBAC角色，以便您能够在此命名空间中管理 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。

转出更改。例如，您可能希望更改初始部署中使用的映像。

获取部署名称。

    kubectl get deployments
    ```
2. 获取 pod 名称。

```sh {: pre}
    kubectl get pods
    ```
3. 获取在 pod 中运行的容器的名称。

```sh {: pre}
    kubectl describe pod <pod_name>
    ```
4. 设置新映像以供部署使用。

```sh {: pre}
    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>

回滚更改。

查看部署的应用历史记录，并确定上次部署的修订版号。

    kubectl rollout history deployment/<deployment_name>
    ```
    要查看特定修订版的详细信息，请包含相应的修订版号。
    {: tip}

    ```sh {: pre}
    kubectl rollout history deployment/<deployment_name> --revision=<number>
    ```
2. 回滚到先前的版本或指定修订版。 要回滚到先前的版本，请使用以下命令。

```sh {: pre}
    kubectl rollout undo deployment/<deployment_name> --to-revision=<number>
    ```

设置持续集成和交付

借助 IBM Cloud 及其他开源工具，您可以搭建持续集成与交付（CI/CD）系统、版本控制、工具链等，从而实现应用程序开发与部署的自动化。

要查看支持的集成列表和设置持续交付管道的步骤，请查看 IBM Cloud 控制台中的可用集成和相关群集文档。

将部署复制到其他集群

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

开始之前，您需要两个集群，并且需要对这两个集群中的所有命名空间都拥有“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

将集群中的配置文件复制到本地目录。然后，在将文件应用到另一个集群之前，请从导出的 YAML 文件中手动删除集群特定的字段，例如 resourceVersion、uid、creationTimestamp 和 status。
```
kubectl get all -o yaml > 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
```