Kubernetes / Linux Note / 运维笔记

Kubevela 多集群应用交付

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

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

一. Kubevela 能解决什么问题

版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!
  • 给开发者

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

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

  • 应用生命周期的管理

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

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

组件提供的是负载率的定义,CloneSet。Trait 提供特征的定义,例如 Ingress、Istio。通过这种部署、抽象,Kubevela 允许平台的开发者能够组装、定制适合自己业务的平台。

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

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

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

  • 统一的视角

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

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

  • 应用的定义
版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!

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

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

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

因此,OAM 的出现,有一个统一的应用周期管理(AL)。虽然以前有 Kubernetes 应用程序死在了晚上,但 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个副本数量。

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-w版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!ork-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-tekton-resource-cross-clu版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!ster.html
  • https://www.cnblogs.com/tencent-cloud-native/p/15136879.html
0 条回应