Kubernetes / Linux Note / 运维笔记

Kubevela 多集群应用交付

Einic Yeo · 9月15日 · 2021年 · · ·

Kubevela最近发布了1.1版本。通常情况下，我们认为是比较稳定的学习版本。的文档。

版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！

一. Kubevela 能解决什么问题

  • 给开发者

需要几个角色：开发、运维、运维。 开发是需求，维提供业务稳定，运维开发提供运维能力。开发和运维之间的业务壁垒，既要快速满足业务上线。又要保障稳定。

Kubevela 开发维拉并没有因为对水平的期待，而让Kubevela 显露出来，开发耳目一新。

  • 应用生命周期的管理

Kubevela 提供了整个应用周期的解决方案定义的应用程序，部署应用程序部署，管理应用程序修订，回滚应用程序，应用程序覆盖范围、应用程序。利用这些 CRD 对象，能够有很大的业务需求。

  • 应用负载率和特性的组件化

组件提供的是负载率的定义，CloneSet。Trait 提供特征的定义，例如 Ingress、Istio。通过这种部署、抽象，Kubevela 允许平台的开发者能够组装、定制适合自己版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！业务的平台。

而 Workflow 的能力，可以为集成到各种编排的云烤组件提供更多的可能，甚至可以延展到 CICD 的领域。

二.多群体下应用面临的挑战

  • 统一的视角

在给应用的平台上，球队是一个非常的用户修改服务体验。

我们应该以应用为中心，服务组不能只是将应用的一个属性应用到同一组，而希望提供给用户。统一的视角就是能够包含一个应用描述、运行时、实时的应用描述。 。

  • 应用的定义

世界上，没有两个平台团队对应用程序的定义是一样的。

一个应用程序应该包含哪些属性，哪些特征，对现场进行哪些限制，很多细节需要敲击和考虑。当然你也可以选择承担债务技术，将解决，快速交付几个问题版本。阻且长，越来越难。

团队在定义应用时，会列出一些业务属性。

因此，OAM 的出现，有一个统一的应用周期管理（AL）。虽然以前有 Kubernete版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！s 应用程序死在了晚上，但 Kubevela 就像黑夜星光机会，但有一个特殊的希望。

  • 分批发布

分发布有两个维度，每个集群中的多个副本应用，多个集群中的同一个应用。

单个组织上的副本，不断更新，不断更新。这个过程需要不断地反复发布，是一个放放量的过程。

多个集中或者多个区域的服务，在更新的时候，也需要观察，而不能同时展示手。

三. AppDeployment 下的多群应用

这里主要是作为主要对象进行应用部署，将应用在多个集群上发布。

  • 在主队上添加多个子群

需要在 kubeconfig 配置配置的集群的上下文中，然后按照一个官方文档操作。

kubectl get clusters.core.oam.dev

NAME             AGE
prod-cluster-1   57d
prod-cluster-2   57d
  • 定义的应用程序

需要提前定义组件和特征，下面是应用的定义：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: cluster-test-app-cloneset
  namespace: default
  annotations:
    app.oam.dev/revision-only: "true"
spec:
  components:
    - name: helloworld-cloneset
      type: cloneset
      properties:
        image: oamdev/helloworld-python:v1
        env:
          - name: "TARGET"
            value: "KubeVela-v1"
        port: 8080
      traits:
        - type: expose-nodeport
          properties:
            ports:
              - protocol: "TCP"
                port: 80

app.oam.dev/revision-only: "true"有的注释，因此相关的资源并不会创建。我们在此只是定义应用，并不需要创建相应的负载率。

  • 修改应用的版本，产生不同的应用版本

为了近逼近的生产环境，我们修改了应用程序的参数，比如：环境变量、版本等，产生不同的应用版本。

kubectl get applicationrevisions.core.oam.dev

NAME                  AGE
cluster-test-app-v1   57d
cluster-test-app-v2   57d
cluster-test-app-v3   57d

最终，这些更新到后来产生了类似上的应用版本，随后，大致相同而有差异。

  • AppDeployment 多组织分发应用

AppDeployment 了一个更贴近应用程序的视角。应用程序包含对理解应用程序的定义，还有对运行时的选择。这里将 cluster-test-app-v1 部署到 prod-cluster-1 集群，设置3个副本数量；而将cluster-test-app-v2部署到prod-cluster-2集群，设置4个副本数量。

版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！ 
apiVersion: core.oam.dev/v1beta1
kind: AppDeployment
metadata:
  name: cross-cluster-app
  namespace: default
spec:
  appRevisions:
    - revisionName: cluster-test-app-v1
      placement:
        - clusterSelector:
            labels:
              env: stage
            name: prod-cluster-1
          distribution:
            replicas: 3

    - revisionName: cluster-test-app-v2
      placement:
        - clusterSelector:
            labels:
              env: production
            name: prod-cluster-2
          distribution:
            replicas: 4

四. Workflow 下的多群应用

Workflow 是 Kubevela 近期版本需要新增的一个特性的主要对象。

4.1 配置开放集群管理（OCM）

  • 使用 vela 命令安装 打开集群管理
vela addon enable ocm-cluster-manager
  • 在主队上添加多个子群

需要在同一个 kubeconfig 配置多个集群的上下文中。在 dev1 集群上，添加 dev2 集群的 kubeconfig。

kubectl config get-contexts

CURRENT   NAME           CLUSTER              AUTHINFO                NAMESPACE
*         dev1-context   dev1.cluster.local   dev1-kubernetes-admin
          dev2-context   dev2.cluster.local   dev2-kubernetes-admin
  • 配置环境变量

使用dev1(主集群)管理dev2(子集群)。在主集群上，执行命令：

export HUB_CLUSTER_NAME=dev1
export MANAGED_CLUSTER_NAME=dev2
export CTX_HUB_CLUSTER=dev1-context
export CTX_MANAGED_CLUSTER=dev2-context
  • 寻找添加子群的代币

在主集群上，执行命令：

clusteradm get token

xxxxxxxxxxxxxx

获取其中的 token 值，Base64 的反解码，可以得到一个的 hub-token 值。

  • 添加子集群

这里的 hub-apiserver 就是主集群的 kube-apiserver 的访问地址。在主集群上，执行命令：

clusteradm join --context ${CTX_MANAGED_CLUSTER} --hub-token xxxxxxxxxxxxxx --hub-apiserver https://1.1.1.1:6443 --cluster-name ${MANAGED_CLUSTER_NAME}
  • 接受新的群体添加请求

在主集群上，执行命令：

clusteradm accept --clusters dev2
  • 查看被管理的团体

在主集群上，执行命令：

kubectl get managedcluster

NAME   HUB ACCEPTED   MANAGED CLUSTER URLS                JOINED   AVAILABLE   AGE
dev2   true           https://dev1.chenshaowen.com:6443   True     True        3m38s
  • 在被管理的集群上安装 Kubevela 推出

在子集上，执行命令：

helm repo add kubevela https://charts.kubevela.net/core
helm install vela-rollout  --create-namespace -n vela-system kubevela/vela-rollout

4.2 新建 WorkflowStepDefinition 描述全集群资源

在主集群使用 Workflow 将整个集群的资源定义在 Workflow StepDefinition 中。是需要下面的托管资源之一：

apiVersion: core.oam.dev/v1beta1
kind: WorkflowStepDefinition
metadata:
  name: dispatch-traits
  namespace: vela-system
spec:
  schematic:
    cue:
      template: |
        import ("vela/op")

        comp: op.#Load & {
           component: parameter.component
        }

        apply: op.#Apply & {
            value: {
                apiVersion: "work.open-cluster-management.io/v1"
                kind: "ManifestWork"
                metadata: {
                   namespace: parameter.cluster
                   name: parameter.component + "-traits"
                }
                spec: {
                   workload: manifests : comp.value.auxiliaries
                }
            }
        }


        parameter: {
          component: string
          cluster: string
        }

其中，如果定义了分发信息到这里最有特色的工作，只需要定义和配置，我们还需要定义dispatch-comp-rev。

资源的过程中，将待分发的资源打包成主群上的清单对象，通过OCM可以分发到子集的应用清单对象，然后由子组织抽取资源进行创建。

4.3 创建应用进行分发

这里使用应用程序主集群 dev1 上定义一个应用程序，分发到子集群 dev2 上。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: workflow-rollout-demo
  namespace: default
spec:
  components:
    - name: nginx-server
      externalRevision: nginx-server-v1
      type: webservice
      properties:
        image: nginx:1.20.0
        port: 80
      traits:
        - type: rollout
          properties:
            targetRevision: nginx-server-v1
            targetSize: 2
            rolloutBatches:
              - replicas: 1
              - replicas: 1

  workflow:
    steps:
      - name: dispatch-comp-rev-v1
        type: dispatch-comp-rev
        properties:
           compRev: nginx-server-v1
           cluster: dev2

      - name: dispatchRollout
        type: dispatch-traits
        properties:
          component: nginx-server
          cluster: dev2

在 OCM 多个应用程序运行正常运行的场景下，需要部署 Kubevel 一个部署组件，因此，Kubevela 部署一个精确的中控子集群部署。整个过程的比例和数量等。

4.4 可能会触发的问题

  • OCM 在创建资源时出错
E0905 14:36:23.461052       1 base_controller.go:270] "ManifestWorkAgent" controller failed to sync "nginx-server-traits", err: rollouts.standard.oam.dev "nginx-server" is forbidden: User "system:serviceaccount:open-cluster-management-agent:klusterlet-work-sa" cannot get resource "rollouts" in API group "standard.oam.dev" in the namespace "default"

提示是权限，在子群上，直接给klusterlet-work-sa绑定了一个管理员权限。

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin-ocm
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: klusterlet-work-sa
    namespace: open-cluster-management-agent

五. 总结

本篇主要是 Kubevela 在多讨论会下的应用，主要内容如下：

  • 多集群下的应用场所，图像设计单一组织，不能实现简单切换数据源，其支持，有更高的要求。应用为中心，将集体当做属性，分清主次。
  • AppDeployment 是一个很好的抽象，也可以为一些平台，看到一些 Kube 的画面。AppDeployment 是用户视角的多焦点应用，但当前针对工作量的处理尺寸，给了整个是应用，也是全量删除、更新、创建工作量。如果用于生产，还需要配合推出进行更新。
  • OCM 的工作流程，使用 Kubevela 多集群应用，实现扩展性，我们也可以集成其他集群组件。发布、滚动更新。

自动集群下的应用，需要考虑的多个任务，是对应用的描述分发更重要的更新、资源的统一分配、应用的调度、扩容、扩容的应用Kubevela 针对目前还看得见的应用状态，但支持启动整个应用平台需要更多的动力组件。

六. 参考文献

  • https://kubevela.io/zh/docs/case-studies/multi-cluster
  • https://open-cluster-management.io/getting-started/quick-start/#install-clusteradm-cli-tool
  • https://www.chenshaowen.com/blog/using-kubefed-to-distribute-版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！tekton-resource-cross-cluster.html
  • https://www.cnblogs.com/tencent-cloud-native/p/15136879.html
相关文章

Google SRE 二十年的经验教训

11月20日 · 2023年

虚机网格(istio)管理实战篇

11月17日 · 2023年

云原生混沌工程平台 – ChaosMeta

11月9日 · 2023年

云原生落地实践指南

11月2日 · 2023年
0 条回应
© 2017~ Infvie Envoy. All Rights Reserved.
IPV6 | GITHUB