多集群应用交付

    如今，在越来越多的场景下，开发者和系统运维人员开始将应用部署在多个集群中：

    • 由于 Kubernetes 集群存在着部署规模的局限性（单一集群最多容纳 5k 节点），需要应用多集群技术来部署、管理海量的应用。
    • 考虑到稳定性及高可用性，同一个应用可以部署在多个集群中，以实现容灾、异地多活等需求。
    • 应用可能需要部署在不同的区域来满足不同政府对于数据安全性的政策需求。

    下文将会介绍如何在 KubeVela 中进行使用管理多集群应用。

    在使用多集群应用部署之前，你需要将子集群通过 KubeConfig 加入到 KubeVela 的管控中来。Vela CLI 可以帮你实现这一点。

    该命令会自动使用 KubeConfig 中的 字段作为集群名称，你也可以使用 --name 参数来指定，如

    1. $ vela cluster join beijing.kubeconfig --name beijing
    2. $ vela cluster join hangzhou-1.kubeconfig --name hangzhou-1
    3. $ vela cluster join hangzhou-2.kubeconfig --name hangzhou-2

    在子集群加入 KubeVela 中后，你同样可以使用 CLI 命令来查看当前正在被 KubeVela 管控的所有集群。

    1. $ vela cluster list
    2. CLUSTER                 TYPE            ENDPOINT                ACCEPTED        LABELS
    3. local                   Internal        -                       true                  
    4. cluster-beijing         X509Certificate <ENDPOINT_BEIJING>      true                  
    5. cluster-hangzhou-1      X509Certificate <ENDPOINT_HANGZHOU_1>   true                  
    6. cluster-hangzhou-2      X509Certificate <ENDPOINT_HANGZHOU_2>   true

    如果你不需要某个子集群了，还可以将子集群从 KubeVela 管控中移除。

    1. $ vela cluster detach beijing

    移除一个正在使用的集群是危险行为。不过如果你想要对集群的认证信息做修改，比如轮转证书，你可以强行删除它。

    你也可以给你的集群打标签，帮助你选择要部署的集群。

    1. $ vela cluster labels add cluster-hangzhou-1 region=hangzhou
    2. $ vela cluster labels add cluster-hangzhou-2 region=hangzhou
    3. $ vela cluster list
    4. CLUSTER                 TYPE            ENDPOINT                ACCEPTED        LABELS
    5. local                   Internal        -                       true                  
    6. cluster-beijing         X509Certificate <ENDPOINT_BEIJING>      true                  
    7. cluster-hangzhou-1      X509Certificate <ENDPOINT_HANGZHOU_1>   true            region=hangzhou
    8. cluster-hangzhou-2      X509Certificate <ENDPOINT_HANGZHOU_2>   true            region=hangzhou

    你只需要使用 topology 策略来声明要部署的集群，就可以部署多集群应用了。例如，你可以使用下面这个样例将 nginx webservice 部署在两个杭州集群中，

    1. $ cat <<EOF | vela up -f -
    2. apiVersion: core.oam.dev/v1beta1
    3. kind: Application
    4. metadata:
    5.   name: basic-topology
    6.   namespace: examples
    7. spec:
    8.   components:
    9.     - name: nginx-basic
    10.       type: webservice
    11.       properties:
    12.         image: nginx
    13.       traits:
    14.         - type: expose
    15.           properties:
    16.             port: [80]
    17.   policies:
    18.     - name: topology-hangzhou-clusters
    19.       type: topology
    20.       properties:
    21.         clusters: ["cluster-hangzhou-1", "cluster-hangzhou-2"]
    22. EOF

    你可以运行以下 CLI 命令调试上述的多集群应用。通过这些 CLI 命令，你可以在管控集群上直接操纵子集群中的资源，而不需要切换 KubeConfig 等集群配置。如果你的应用使用了多个集群，CLI 向你询问你希望操纵的集群。

    • vela status 如上文所示，为你展示多集群应用的整体部署情况。
    • vela logs 查询子集群中的 Pod 日志。
    1. $ vela logs basic-topology -n examples 
    2. ? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
    3. + nginx-basic-dfb6dcf8d-km5vk › nginx-basic
    4. nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540430392Z /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
    5. nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540742240Z /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
    • vela port-forward 将子集群中的 Pod 或者 Service 通过端口映射到本地使其可以在本地被访问。
    1. $ vela exec basic-topology -n examples -it -- ls 
    2. ? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
    3. bin   docker-entrypoint.d   home   media  proc  sbin  tmp
    4. boot  docker-entrypoint.sh  lib    mnt    root  srv   usr
    5. dev   etc                   lib64  opt    run   sys   var
    • vela exec 帮助你在子集群的 Pod 里执行命令。
    1. $ vela port-forward basic-topology -n examples 8080:80
    2. ? You have 4 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
    3. Forwarding from 127.0.0.1:8080 -> 80
    4. Forwarding from [::1]:8080 -> 80
    6. Forward successfully! Opening browser ...
    7. Handling connection for 8080

    理解多集群应用

    下图为多集群应用的整体结构图。如图所示，所有的配置信息（包括应用、策略和工作流）都处于管控集群中。只有资源（如 deployment 或者 service）会被下发到子集群之中。

    策略主要负责描述资源的位置以及它们应该如何被差异化配置。资源下发真正的执行者是工作流。在工作流中，deploy 步骤会根据引用的策略对资源进行差异化配置，然后再将它们分发到对应的集群中。

    选择部署目标的最直接的方法就是在 topology 策略中声明你想要部署的集群名称。有的时候，使用标签来筛选要部署的集群会更方便，比如下面这个例子通过标签筛选出所有的杭州集群：

    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3. metadata:
    4.   name: label-selector-topology
    5.   namespace: examples
    6. spec:
    7.   components:
    8.     - name: nginx-label-selector
    9.       type: webservice
    10.       properties:
    11.         image: nginx
    12.   policies:
    13.     - name: topology-hangzhou-clusters
    14.       type: topology
    15.       properties:
    16.         clusterLabelSelector:
    17.           region: hangzhou

    如果你想要在管控集群中部署应用，你也可以使用 local 集群。除此之外，你还可以选择希望部署的命名空间，取代应用原有的命名空间。

    1. apiVersion: core.oam.dev/v1beta1
    2. metadata:
    3.   name: local-ns-topology
    4.   namespace: examples
    5. spec:
    6.   components:
    7.     - name: nginx-local-ns
    8.       type: webservice
    9.       properties:
    10.         image: nginx
    12.     - name: topology-local
    13.       type: topology
    14.       properties:
    15.         clusters: ["local"]
    16.         namespace: examples-alternative

    控制部署工作流

    默认情况下，如果你在应用中声明了多个 topology 策略，应用组件将会依次分发到这些目标位置上。

    如果你想要控制整个部署流程，比如更改默认的部署顺序，或者是添加人工审核步骤，你可以显式使用 deploy 工作流步骤来实现。

    如果你希望并行地部署所有集群，你可以在一个 deploy 工作流步骤中使用所有的 topology 策略。

    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3. metadata:
    4.   name: deploy-concurrently
    5.   namespace: examples
    6. spec:
    7.   components:
    8.     - name: nginx-deploy-concurrently
    9.       type: webservice
    10.       properties:
    11.         image: nginx
    12.   policies:
    13.     - name: topology-hangzhou-clusters
    14.       type: topology
    15.       properties:
    16.         clusterLabelSelector:
    17.           region: hangzhou
    18.     - name: topology-local
    19.       type: topology
    20.       properties:
    21.         clusters: ["local"]
    22.         namespace: examples-alternative
    23.   workflow:
    24.     steps:
    25.       - type: deploy
    26.         name: deploy-all
    27.         properties:
    28.           policies: ["topology-local", "topology-hangzhou-clusters"]

    override 策略可以帮助你实现差异化配置。你可以在 deploy 工作流步骤中，配合 topology 策略来使用它。

    在下面的样例中，应用会在 local 集群中部署一个默认的 nginx webservcie，然后在杭州集群中部署含有 3 副本的高可用 nginx webservice，并且使用 nginx:1.20 镜像。

    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3. metadata:
    4.   name: deploy-with-override
    5.   namespace: examples
    6. spec:
    7.   components:
    8.     - name: nginx-with-override
    9.       type: webservice
    10.       properties:
    11.         image: nginx
    12.   policies:
    13.     - name: topology-hangzhou-clusters
    14.       type: topology
    15.       properties:
    16.         clusterLabelSelector:
    17.           region: hangzhou
    18.     - name: topology-local
    19.       type: topology
    20.       properties:
    21.         clusters: ["local"]
    22.         namespace: examples-alternative
    23.     - name: override-nginx-legacy-image
    24.       type: override
    25.       properties:
    26.         components:
    27.           - name: nginx-with-override
    28.             properties:
    29.               image: nginx:1.20
    30.     - name: override-high-availability
    31.       type: override
    32.       properties:
    33.         components:
    34.           - type: webservice
    35.             traits:
    36.               - type: scaler
    37.                 properties:
    38.                   replicas: 3
    39.   workflow:
    40.     steps:
    41.       - type: deploy
    42.         name: deploy-local
    43.         properties:
    44.           policies: ["topology-local"]
    45.       - type: deploy
    46.         name: deploy-hangzhou
    47.         properties:
    48.           policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]

    注意：override 策略是用来修改基础配置的策略，因此它被设计成必须需要和 topology 策略一同使用。如果你不想要使用 topology 策略，你可以直接将配置写在组件声明中，而不是使用 override 策略。如果你错误的在 deploy 工作流步骤中使用了 override 策略，而没有使用 topology 策略，应用不会发生错误，但是也不会下发任何资源。

    差异化配置有一些高级配置能力，比如添加额外的组件，或者选择部分组件。下面的样例中，应用会首先在 local 集群中部署一个镜像为 nginx:1.20 的 webservice，然后再将 nginx 和 nginx:stable 两个 webservice 部署到杭州集群中

    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3.   name: advance-override
    4.   namespace: examples
    5. spec:
    6.   components:
    7.     - name: nginx-advance-override-legacy
    8.       type: webservice
    9.       properties:
    10.         image: nginx:1.20
    11.     - name: nginx-advance-override-latest
    12.       type: webservice
    13.       properties:
    14.         image: nginx
    15.   policies:
    16.     - name: topology-hangzhou-clusters
    17.       type: topology
    18.       properties:
    19.         clusterLabelSelector:
    20.           region: hangzhou
    21.     - name: topology-local
    22.       type: topology
    23.       properties:
    24.         clusters: ["local"]
    25.         namespace: examples-alternative
    26.     - name: override-nginx-legacy
    27.       type: override
    28.       properties:
    29.         selector: ["nginx-advance-override-legacy"]
    30.     - name: override-nginx-latest
    31.       type: override
    32.       properties:
    33.         selector: ["nginx-advance-override-latest", "nginx-advance-override-stable"]
    34.         components:
    35.           - name: nginx-advance-override-stable
    36.             type: webservice
    37.             properties:
    38.               image: nginx:stable
    39.   workflow:
    40.     steps:
    41.       - type: deploy
    42.         name: deploy-local
    43.         properties:
    44.           policies: ["topology-local", "override-nginx-legacy"]
    45.       - type: deploy
    46.         name: deploy-hangzhou
    47.         properties:
    48.           policies: ["topology-hangzhou-clusters", "override-nginx-latest"]

    使用外置策略和工作流

    有时，你可能希望在不同的应用之间使用相同的策略，或者在部署资源的时候复用之前的工作流配置。 为了减少重复的配置，你可以使用外置的策略和工作流，并在应用中引用它们。

    1. apiVersion: core.oam.dev/v1alpha1
    2. kind: Policy
    3. metadata:
    4.   name: topology-hangzhou-clusters
    5.   namespace: examples
    6. type: topology
    7. properties:
    8.   clusterLabelSelector:
    9.     region: hangzhou
    10. ---
    11. apiVersion: core.oam.dev/v1alpha1
    12. kind: Policy
    13. metadata:
    14.   name: override-high-availability-webservice
    15.   namespace: examples
    16. type: override
    17. properties:
    18.   components:
    19.     - type: webservice
    20.       traits:
    21.         - type: scaler
    22.           properties:
    23.             replicas: 3
    24. ---
    25. apiVersion: core.oam.dev/v1alpha1
    26. kind: Workflow
    27. metadata:
    28.   name: make-release-in-hangzhou
    29.   namespace: examples
    30. steps:
    31.   - type: deploy
    32.     name: deploy-hangzhou
    33.     properties:
    34.       auto: false
    35.       policies: ["override-high-availability-webservice", "topology-hangzhou-clusters"]
    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3. metadata:
    4.   name: external-policies-and-workflow
    5.   namespace: examples
    6. spec:
    7.   components:
    8.     - name: nginx-external-policies-and-workflow
    9.       type: webservice
    10.       properties:
    11.         image: nginx
    12.   workflow:

    注意：内置的策略会被优先使用。只有当工作流使用的策略不存在于内置策略中时才会使用外置策略。在下面的样例中，你可以复用 topology-hangzhou-clusters 策略以及 make-release-in-hangzhou 工作流，但是通过在应用中声明 override-high-availability-webservice 策略来覆盖同名的外置策略。

    KubeVela 的 v1.3 应用相较于之前的版本使用了不同的策略和工作流步骤来分发、管理多集群应用。

    旧版本中的 策略以及 deploy2env 工作流步骤在目前版本中仍保留并兼容，但可能会在未来的版本中逐步废弃。

    新的策略和工作流步骤可以完全覆盖旧版本中多集群应用的所有使用场景，而且提供了更强的能力。自动化升级工具将会在废弃旧版本之前提供给用户。