金丝雀发布

    2. 确认你已经启用了 插件，我们的金丝雀发布依赖于 rollouts from OpenKruise，可通过如下命令启用插件。

    3. 请确保在你的集群中有一种 。 如果没有安装Ingress，你也可以通过如下命令启用 ingress-nginx 或 插件：

      请参考 插件文档 获取网关的访问地址。

    4. 一些命令比如 rollback 依赖 vela-cli 版本 >=1.5.0-alpha.1，请更新cli到最新版本。不需要更新controller。

    限制

    一个 helm chart 包含几乎所有功能，金丝雀发布在以下多种用例中都适用：

    1. 实例部署支持 Kubernetes Deployment, StatefulSet 和 OpenKruise Cloneset。这意味着在 helm chart 中的实例必须是以上三种中的一种。

    默认情况下每一个 helm chart 都使用 helm create 命令。

    当你开始使用金丝雀发布时，你需要在第一次部署应用时添加 kruise-rollout 特性，这个配置会在下一次发布时生效。特性在应用中的配置如下所示：

    1. cat <<EOF | vela up -f -
    2. apiVersion: core.oam.dev/v1beta1
    3. kind: Application
    4. metadata:
    5.   name: canary-demo
    6.   annotations:
    7.     app.oam.dev/publishVersion: v1
    8. spec:
    9.   components:
    10.   - name: canary-demo
    11.     type: helm
    12.     properties:
    13.       repoType: "helm"
    14.       url: "https://wangyikewxgm.github.io/my-charts/"
    15.       chart: "canary-demo"
    16.     traits:
    17.     - type: kruise-rollout
    18.       properties:
    19.         canary:
    20.           # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
    21.           steps:
    22.           - weight: 20
    23.           # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
    24.           - weight: 90
    25.           trafficRoutings:
    26.           - type: nginx
    27. EOF

    下面解释了在使用了 kruise-rollout 运维特征之后，下次升级应用时，是如何进行金丝雀发布的，整个发布过程会分成3步：

    1. 升级到第一个批次时，会创建 20% 的实例数量。在我们的示例中， 我们一共设置了5个实例，它会保留所有的老的版本并创建 5 * 20% = 1 个金丝雀版本，并且导入了 20% 的流量到新版本中。在所有都准备好后，它会等待手工批准。
      • 实例数量和导入流量的百分比默认是一致的，你可以根据 文档 配置比例。
    2. 在手工批准后，会进入到第二个阶段，它会创建 5 * 90% = 4.5 实际上是 5 个实例的新版本，并且导入 90% 的流量到新版本中。这样一来，目前系统一共有 10 个实例，它需要等待下一步的手工批准。
    3. 在批准后，它就会利用滚动更新的机制来更新实例，在实例完成升级后，所有的流量都指向新的实例，金丝雀发布也会被销毁。

    我们的首次部署和一般的部署并没有太大区别，你可以通过如下命令来检查应用的状态来确保可以进行下一步操作。

    1. vela status canary-demo

    访问网关，你会看到结果都是 Demo: V1

    Day-2 金丝雀发布

    将 helm chart 版本从 1.0.0 更新到 2.0.0：

    1. cat <<EOF | vela up -f -
    2. apiVersion: core.oam.dev/v1beta1
    3. kind: Application
    4. metadata:
    5.   name: canary-demo
    6.   annotations:
    7.     app.oam.dev/publishVersion: v2
    8. spec:
    9.   components:
    10.   - name: canary-demo
    11.     type: helm
    12.       repoType: "helm"
    13.       url: "https://wangyikewxgm.github.io/my-charts/"
    14.       chart: "canary-demo"
    15.       # Upgade to version 2.0.0
    16.       version: "2.0.0"
    17.     traits:
    18.     - type: kruise-rollout
    19.       properties:
    20.         canary:
    22.           steps:
    23.           - weight: 20
    24.           # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
    25.           - weight: 90
    26.           trafficRoutings:
    27.           - type: nginx
    28. EOF

    两个版本唯一的区别就是镜像标签。2.0.0 版本使用 barnett/canarydemo:v2。

    再次访问网关，你会发现访问结果中有 20% 的机率是 Demo: v2。

    1. $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
    2. Demo: V2

    其他 继续发布/回滚 等操作和上面的 webservice 的类型组件完全一致。

    1. vela workflow resume canary-demo

    在多次重新访问网关后，你会发现机率大幅提升，有 90% 的结果是 Demo: v2。

    金丝雀验证通过，全量发布

    最后，你可以再次执行工作流来完成全量发布。

    1. vela workflow resume canary-demo

    多次访问网关，你会发布结果一直是 Demo: v2。

    1. $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
    2. Demo: V2

    如果经过验证发现新版本有问题，你想中断发布，将应用回滚至上一个版本。可以如下操作：

    你需要在回滚前中止工作流：

    1. $ vela workflow suspend canary-demo
    2. Rollout default/canary-demo in cluster  suspended.
    3. Successfully suspend workflow: canary-demo

    回滚：

    在回滚完成后，再次访问网关，你会看到返回的结果一直是 Demo: V1。

    1. $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
    2. Demo: V1