云边协同下的统一应用管理: 基于 OpenYurt 和 KubeVela 的解决方案-六虎

作者：乔中沛（伊灵）

布景

随着万物互联场景的逐渐遍及，边际设备的算力也不断增强，怎么借助云核算的优势满意杂乱多样化的边际运用场景，让云原生技能延伸到端和边际成为了新的技能挑战，“云边协同”正在逐渐成为新的技能焦点。本文将围绕 CNCF 的两大开源项目 KubeVela 和 OpenYurt，以一个实践的 Helm 运用交给的场景，为咱们介绍云边协同的处理方案。

OpenYurt 专心于以无侵入的方法将 Kubernetes 扩展到边际核算领域。OpenYurt 依托原生 Kubernetes 的容器编列、调度才能，将边际算力归入到 Kubernetes 基础设施中一致办理，供给了诸如边际自治、高效运维通道、边际单元化办理、边际流量拓扑、安全容器、边际 Serverless/FaaS、异构资源支撑等才能。简而言之，OpenYurt 以 Kubernetes 原生的方法为云边协同构建了一致的基础设施。

KubeVela 孵化于 OAM 模型，专心于协助企业构建一致的运用交给和办理才能，为业务开发者屏蔽底层基础设施杂乱度，供给灵敏的扩展才能，并供给开箱即用的微服务容器办理、云资源办理、版别化和灰度发布、扩缩容、可观测性、资源依靠编列和数据传递、多集群、CI 对接、GitOps 等特性。最大化的提升开发者自助式运用办理的研制效能，提升也满意平台长时间演进的扩展性诉求。

OpenYurt 与KubeVela 结合能处理什么问题？

如上所述，OpenYurt 满意了边际节点的接入，让用户能够经过操作原生 Kubernetes 的方法办理边际节点。边际节点一般用来表示间隔用户更近的核算资源，比方某个就近机房中的虚拟机或物理服务器等，经过 OpenYurt 参加后，这些边际节点会转化为 Kubernetes 中能够运用的节点（Node）。OpenYurt 用节点池（NodePool）来描绘同一地域的一组边际节点。在满意了基本的资源办理后，针对运用怎么编列布置到一个集群中的不同节点池，咱们一般会有如下中心需求：

1. 一致装备： 假如对每一份要下发的资源做手动修正，需求许多人工介入，非常简单出错和遗漏。咱们需求一致的方法来做参数装备，不只能够方便地做批量办理操作，还能够对接安全和审计，满意企业风险控制与合规需求。

2. 差异布置： 布置到不同节点池的作业负载有大部分特点相同，然而总有个性化的装备差异。关键在于怎么设置和节点挑选相关的参数，例如NodeSelector能够指示 Kubernetes 调度器将作业负载调度到不同的节点池。

3. 可扩展性： 云原生生态昌盛，不管是作业负载品种仍是不同的运维功用都在不断增加，为了更灵敏地满意业务需求，咱们需求全体的运用架构是可扩展的，能够充沛享用云原生生态的红利。

而 KubeVela 在运用层与 OpenYurt 能够很好的互补，满意上述三个中心需求。接下来，咱们结合实践的操作流程来展现这些功用点。

将运用布置到边际

咱们将以Ingress控制器为例，展现怎么运用KubeVela 将运用程序布置到边际。在这种状况下，咱们期望将 Nginx Ingress 控制器布置到多个节点池中，以完成经过边际 Ingress 拜访指定节点池供给的服务，某个 Ingress 仅能由所在节点池的 Ingress 控制器处理。

示意图的集群中有两个节点池：北京和上海，他们之间的网络不互通。咱们期望再其间每个节点池都布置一个 Nginx Ingress Controller，并作为各自节点池的网络流量入口。一个接近北京的客户端，能够经过拜访北京节点池的 Ingress Controller，拜访北京节点池内供给的服务，且不会拜访到上海节点池供给的服务。

云边协同下的统一应用管理: 基于 OpenYurt 和 KubeVela 的解决方案

Demo 的基础环境

咱们将运用 Kubernetes 集群模拟边际场景。群集有 3 个节点，它们的角色分别是：

节点 1：master 节点，云端节点
节点 2：worker 节点，边际节点，在节点池beijing中
节点 3：worker 节点，边际节点，在节点池 shanghai中

准备作业

1. 装置 YurtAppManager

YurtAppManager 是 OpenYurt 的中心组件。它供给节点池 CRD 和控制器。OpenYurt 中还有其他组件，但在本教程中咱们只需求 YurtAppManager.

git clone https://github.com/openyurtio/yurt-app-managercd yurt-app-manager && helm install yurt-app-manager -n kube-system ./charts/yurt-app-manager/

2.装置KubeVela，启用 FluxCD 插件。

装置 Vela 命令行工具，并在集群中装置 KubeVela。

curl -fsSl https://kubevela.net/script/install.sh | bash
vela install

在本案例中，为了复用社区供给的成熟的 Helm Chart，咱们用 Helm 类型的组件来装置 Nginx Ingress Controller。在微内核设计的 KubeVela 中，Helm 类型的组件是由 FluxCD 插件供给的，下面启用FluxCD 插件 [ 1] 。

vela addon enable fluxcd

3. 准备节点池

创立两个节点池：北京节点池和上海节点池。在实践的边际场景中，以地域划分节点池是常见的形式。不同分组的节点间往往存在网络不互通、资源不共享、资源异构、运用独立等显着的隔离特点。这也是节点池概念的由来。在 OpenYurt 中，经过节点池、服务拓扑等功用协助用户处理上述问题。今天的例子中咱们将运用节点池来描绘和办理节点。

kubectl apply -f - <<EOF
apiVersion: apps.openyurt.io/v1beta1
kind: NodePool
metadata:
  name: beijing
spec:
  type: Edge
  annotations:
    apps.openyurt.io/example: test-beijing
  taints:
    - key: apps.openyurt.io/example
      value: beijing
      effect: NoSchedule
---
apiVersion: apps.openyurt.io/v1beta1
kind: NodePool
metadata:
  name: shanghai
spec:
  type: Edge
  annotations:
    apps.openyurt.io/example: test-shanghai
  taints:
    - key: apps.openyurt.io/example
      value: shanghai
      effect: NoSchedule
EOF

将边际节点参加到各自的节点池，边际节点的参加方法能够参考 OpenYurt 节点参加的方法。

kubectl label node <node1> apps.openyurt.io/desired-nodepool=beijing
kubectl label node <node2> apps.openyurt.io/desired-nodepool=shanghai

kubectl get nodepool

预期输出

NAME       TYPE   READYNODES   NOTREADYNODES   AGE
beijing    Edge   1            0               6m2s
shanghai   Edge   1            0               6m1s

批量布置边际运用

在咱们深化细节之前，让咱们看看 KubeVela 是怎么描绘布置到边际的运用的。经过下面这个运用，咱们能够将 Nginx Ingress Controller 布置多份到各自的边际节点池。运用同一个运用来一致装备 Nginx Ingress 能够消除重复，下降办理负担，也方便后续对集群内的组件一致进行发布运维等常见操作。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: edge-ingress
spec:
  components:
    - name: ingress-nginx
      type: helm
      properties:
        chart: ingress-nginx
        url: https://kubernetes.github.io/ingress-nginx
        repoType: helm
        version: 4.3.0
        values:
          controller:
            service:
              type: NodePort
            admissionWebhooks:
              enabled: false
      traits:
        - type: edge-nginx
  policies:
    - name: replication
      type: replication
      properties:
        selector: [ "ingress-nginx" ]
        keys: [ "beijing","shanghai" ]
  workflow:
    steps:
      - name: deploy
        type: deploy
        properties:
          policies: ["replication"]

一个 KubeVela Application 有 3 个部分：

一个helm类型组件。它描绘了咱们想要装置到集群的 Helm 包版别。此外，咱们给这个组件附加了一个运维特征（trait）edge-nginx。咱们稍后将展现这个运维特征的具体状况，现在你能够将其视为一个包含不同节点池的特点的补丁。
一个replication（组件分裂）战略。它描绘了怎么将组件仿制到不同的节点池。该selector字段用于挑选需求仿制的组件。它的keys字段将把一个组件转换为具有不同 key 的两个组件。（“beijing”和“shanghai”）

3.deploy作业流过程。它描绘了怎么布置运用程序。它指定replication 战略执行仿制作业的战略。

留意：

假如你期望此运用程序正常作业，请先在集群下发在下文介绍的edge-ingress特性。

deploy是一个 KubeVela 内置的作业流程过程。它还能够在多集群场景 [2 ] 中与override、topology战略一同运用。

现在，咱们能够将运用下发到集群。

vela up -f app.yaml

检查运用状况和 KubeVela 创立的资源。

vela status edge-ingress --tree --detail

预期输出

CLUSTER       NAMESPACE     RESOURCE                           STATUS    APPLY_TIME          DETAIL
local  ─── default─┬─ HelmRelease/ingress-nginx-beijing  updated   2022-11-02 12:00:24 Ready: True  Status: Release reconciliation succeeded  Age: 153m
                   ├─ HelmRelease/ingress-nginx-shanghai updated   2022-11-02 12:00:24 Ready: True  Status: Release reconciliation succeeded  Age: 153m
                   └─ HelmRepository/ingress-nginx       updated   2022-11-02 12:00:24 URL: https://kubernetes.github.io/ingress-nginx  Age: 153m
                                                                                         Ready: True
                                                                                         Status: stored artifact for revision '7bce426c58aee962d479ca84e5c
                                                                                         fc6931c19c8995e31638668cb958d4a3486c2'

Vela CLI 不只能够站在较高层次一致汇集展现运用健康状况，当需求的时分，Vela CLI 也能够协助你穿透运用，直达底层作业负载，并供给丰厚的观测和 Debug 才能，例如，你能够经过vela logs把打印运用的日志；能够经过vela port-forward把布置运用的端口转发到本地；能够经过vela exec命令，深化到边际的容器中执行 Shell 命令排查问题。

假如你想更直观地了解运用去状况，KubeVela 官方还供给了 Web 控制台插件 VelaUX。启用 VelaUX 插件 [3 ] ，你能够检查更具体的资源拓扑。

vela addon enable velaux

拜访 VelaUX 的资源拓扑页面。

正如你所看到的，KubeVela 创立了两个HelmRelease资源，把 Nginx Ingress Controller 的 Helm Chart 交给到两个节点池。HelmRelease资源被上述 FluxCD 插件处理并在集群两个节点池中分别装置了 Nginx Ingress。经过以下命令，检查是否在北京节点池中创立了 Ingress Controller 的 Pod，上海节点池同理。

$ kubectl get node -l  apps.openyurt.io/nodepool=beijing
NAME                      STATUS   ROLES    AGE   VERSION
iz0xi0r2pe51he3z8pz1ekz   Ready    <none>   23h   v1.24.7+k3s1

$ kubectl get pod ingress-nginx-beijing-controller-c4c7cbf64-xthlp -oyaml|grep iz0xi0r2pe51he3z8pz1ekz
  nodeName: iz0xi0r2pe51he3z8pz1ekz

差异化布置

KubeVela 运用交给过程中怎么完成了同一个组件的差异化布置？让咱们继续深化了解支撑运用的 Trait（运维特征）和 Policy（运用战略）。上文说到咱们在作业流中运用了 KubeVela 内置的组件分裂（replication） Policy，给 ingress-nginx 组件附加了一个自界说的 edge-nginxTrait。

组件分裂 Policy 将组件拆为两个组件，带有不同的 context.replicaKey。
edge-nginxTrait 运用不同的 context.replicaKey，将带有不同装备值的 Helm Chart 交给到集群中。让两个 Nginx Ingress Controller 运行在不同的节点池，监听具有不同 ingressClass 的 Ingress 资源。具体的方法是 Patch 了 Helm Chart 的 Values 装备，修正了和节点挑选、亲和性以及 ingressClass 相关的字段。
在 Patch 不同字段时，运用了不同的Patch 战略 [4 ] （PatchStrategy），例如运用retainKeys战略能够掩盖原本的值，运用jsonMergePatch战略则会和原本的值合并。

"edge-nginx": {
  type: "trait"
  annotations: {}
  attributes: {
    podDisruptive: true
    appliesToWorkloads: ["helm"]
  }
}
template: {
  patch: {
    // +patchStrategy=retainKeys
    metadata: {
      name: "(context.name)-(context.replicaKey)"
    }
    // +patchStrategy=jsonMergePatch
    spec: values: {
      ingressClassByName: true
      controller: {
        ingressClassResource: {
          name:            "nginx-" + context.replicaKey
          controllerValue: "openyurt.io/" + context.replicaKey
        }
        _selector
      }
      defaultBackend: {
        _selector
      }
    }
  }
  _selector: {
    tolerations: [
      {
        key:      "apps.openyurt.io/example"
        operator: "Equal"
        value:    context.replicaKey
      },
    ]
    nodeSelector: {
      "apps.openyurt.io/nodepool": context.replicaKey
    }
  }
  parameter: null
}

让更多类型的运用走向边际

能够看到，为了将 Nginx Ingress 布置到不同节点池，咱们仅自界说了一个四十余行的 Trait 并充沛利用了 KubeVela 内置的才能。在云原生生态愈加昌盛和云边协同的趋势下，更多的运用都或许走向边际布置。当新场景中需求一个新的运用布置在边际节点池时，也无需烦恼，由于在 KubeVela 的协助下，模仿该形式扩展出一个新的边际运用布置 Trait 也很简单，无需编写代码。

例如，咱们期望将 K8s 社区近期的演进热点Gateway API [5 ] 的完成也布置到边际，经过 Gateway API 增强边际节点池暴露服务的表达才能、扩展性，在边际节点运用根据角色的网络 API 等。关于这种场景，咱们也能够根据上述扩展方法轻松完成布置使命，只需求界说如下的一个新 Trait。

"gateway-nginx": {
  type: "trait"
  annotations: {}
  attributes: {
    podDisruptive: true
    appliesToWorkloads: ["helm"]
  }
}
template: {
  patch: {
    // +patchStrategy=retainKeys
    metadata: {
      name: "(context.name)-(context.replicaKey)"
    }
    // +patchStrategy=jsonMergePatch
    spec: values: {
      _selector
      fullnameOverride: "nginx-gateway-nginx-" + context.replicaKey
      gatewayClass: {
        name:           "nginx" + context.replicaKey
        controllerName: "k8s-gateway-nginx.nginx.org/nginx-gateway-nginx-controller-" + context.replicaKey
      }
    }
  }
  _selector: {
    tolerations: [
      {
        key:      "apps.openyurt.io/example"
        operator: "Equal"
        value:    context.replicaKey
      },
    ]
    nodeSelector: {
      "apps.openyurt.io/nodepool": context.replicaKey
    }
  }
  parameter: null
}

这个 Trait 和前文说到的布置 Nginx Ingress 运用的 Trait 非常类似，其间，咱们也同样对 Nginx Gateway Chart 的 Values 做了一些类似的 Patch，包含节点挑选、亲和性、资源称号。和前文 Trait 的区别是该 Trait 指定了 gatewayClass 而非 IngressClass。该案例的 Trait 和运用文件详见GitHub 库房 [6 ] 。经过自界说这样一个 Trait，咱们就给集群扩展了布置一种新运用到边际的才能。

假如咱们无法预知未来边际核算的发展带来的更多运用布置需求，至少咱们能够经过这种更简单扩展的方法不断适应新的场景。

KubeVela 怎么处理了边际布置难题

回忆 KubeVela 是怎么处理文章开端提出的关键问题的。

1. 一致装备： 咱们运用一个组件来描绘要布置的 ingress-nginx Helm Chart 的通用的特点例如 Helm 库房、Chart 称号、版别等一致装备。

2. 特点差异： KubeVela 运用了一个用户自界说的运维特征界说，它描绘下发到不同的节点池的 Helm 装备差异。该运维特征能够重复用于布置相同的 Helm Chart。

3. 可扩展性： KubeVela 能够为常见的作业负载（如 Deployment/StatefulSet）或其他打包方法（如 Helm/Kustomize/…）以可编程的方法进行扩展，只需若干行的代码，即可将一种新运用推向边际场景。

这些得益于 KubeVela 在运用交给和办理领域供给的强大功用，KubeVela 除了能在单个集群内部处理运用的界说、交给、运维和可观测问题，还原生支撑了多集群形式的运用发布和办理。目前适合边际核算场景的 Kubernetes 布置形式并无定式，不管单集群+边际节点池的架构，仍是多边际集群架构，KubeVela 都能胜任其间的运用办理使命。

在 OpenYurt 和 KubeVela 的合作下，云边运用以一致方法布置，共享相同的笼统、运维、可观测才能，避免了在不同场景中分裂的体会。而且云端运用和边端运用都得以运用 KubeVela 以插件形式不断集成的云原生生态的优异实践。未来 KubeVela 社区还将不断丰厚开箱即用的体系插件，持续交给更好用、更易用的运用交给和办理才能。

假如想了解更多运用布置、办理的才能，能够阅读KubeVela 官方文档 [7 ] ，想要了解 KubeVela 社区的最新动态，欢迎来到KubeVela 社区 [8 ] （钉钉群 23310022）参加评论！若你对 OpenYurt 感兴趣，也欢迎来到 OpenYurt 社区（钉钉群 31993519）参加评论。

您也能够经过如下资料了解更多关于 KubeVela 以及 OAM 项目的细节：

项目代码库：github.com/kubevela/ku… 欢迎 Star/Watch/Fork！
项目官方主页与文档：kubevela.io ，从 1.1 版别开端，已供给中文、英文文档，更多言语文档欢迎开发者进行翻译。
项目钉钉群：23310022；Slack：CNCF #kubevela Channel
参加微信群：请先增加以下 maintainer 微信号，表明进入 KubeVela 用户群：

戳此处 ：检查 KubeVela 项目官网！！

相关链接

[1] FluxCD 插件

kubevela.net/zh/docs/ref…

[2] 多集群场景

kubevela.net/docs/case-s…

[3] 启用 VelaUX 插件

kubevela.net/zh/docs/ref…

[4] Patch 战略

kubevela.net/zh/docs/pla…

[5]Gateway API

gateway-api.sigs.k8s.io/

[6] GitHub 库房

github.com/chivalryq/y…

[7] KubeVela 官方文档

kubevela.net/

[8] KubeVela 社区

github.com/kubevela/co…

云边协同下的统一应用管理: 基于 OpenYurt 和 KubeVela 的解决方案

布景

OpenYurt 与KubeVela 结合能处理什么问题？

将运用布置到边际

Demo 的基础环境

准备作业

批量布置边际运用

差异化布置

让更多类型的运用走向边际

KubeVela 怎么处理了边际布置难题

相关文章

如何使用Python操作Redis的所有类型？

云原生爱好者周刊：Dapr 成为 CNCF 孵化项目

LayoutInspectorV2-Pro 插件让 LayoutInspector 更好用

Nodejs、GraphQL、MongoDB、Hapi 和 Swagger 构建 API（一）

作者信息