Helm Chart 多环境、多集群交付实践,透视资源拓扑和差异

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 在本文中,我们将介绍如何通过 KubeVela解决多集群环境下 Helm Chart 的部署问题。如果你手里没有多集群也不要紧,我们将介绍一种仅依赖于 Docker 或者 Linux 系统的轻量级部署方式,可以让你轻松的体验多集群功能。当然,KubeVela 也完全具备单集群的 Helm Chart 交付能力。

Helm Charts[1] 如今已是一种非常流行的软件打包方式,在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中,业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下,单纯依赖 Helm 工具可能无法做到灵活的部署和交付。


在本文中,我们将介绍如何通过 KubeVela[2]解决多集群环境下 Helm Chart 的部署问题。如果你手里没有多集群也不要紧,我们将介绍一种仅依赖于 Docker 或者 Linux 系统的轻量级部署方式,可以让你轻松的体验多集群功能。当然,KubeVela 也完全具备单集群的 Helm Chart 交付[3]能力。


前提条件


  • 安装 Docker v20.10.5+ (runc >= v1.0.0-rc93) 或者你的操作系统是 Linux。
  • VelaD[4],一个轻量级的部署 KubeVela 和 Kubernetes 的工具。 


准备集群


本节是做 KubeVela 以及多集群环境的准备,我们将基于 Docker 或者 Linux 环境从头开始。如果你已经具备了 KubeVela 的环境并且完成了集群管理[5],则可以跳过本节。

安装 KubeVela 控制平面


velad install


将新创建的集群导入到环境变量


export KUBECONFIG=$(velad kubeconfig --name default --host)


到这里,恭喜你!我们已经完成了 KubeVela 控制平面的安装。你可以通过下面这个方式加入你的 Kubernetes 集群:


vela cluster join <path-to-kubeconfig-of-cluster> --name foo


如果你没有现成的 Kubernetes 集群,VelaD 也可以很方便的为你创建一个:


用 velad 创建一个名为 foo 的集群,并加入到控制平面


velad install --name foo --cluster-only
vela cluster join $(velad kubeconfig --name foo --internal) --name foo


作为一个充分可扩展的控制平面,KubeVela 的大多数能力都是作为插件提供的。接下来的几步我们介绍安装 Helm 多集群部署的必要插件。


启用 velaux 插件,获得 UI 控制台


vela addon enable velaux


启用 fluxcd 插件获得 helm chart 交付能力


vela addon enable fluxcd


如果你在加入新集群之前已启用过 fluxcd 插件,则应该通过以下方式来为新加入的集群启用(部署)插件:


vela addon enable fluxcd --clusters foo


至此,我们完成了所有的准备工作,可以查看加入的集群了:


$ vela cluster ls
CLUSTER ALIAS   TYPE            ENDPOINT                ACCEPTED    LABELS
local           Internal        -                       true
foo             X509Certificate https://172.20.0.6:6443 true


local 是 KubeVela 控制平面的集群,foo 则是我们刚刚添加的集群。


多集群部署


我们可以使用 topology 策略来指定 Helm Chart 交付的环境,指令如下:


cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: helm-hello
spec:
  components:
    - name: hello
      type: helm
      properties:
        repoType: "helm"
        url: "https://jhidalgo3.github.io/helm-charts/"
        chart: "hello-kubernetes-chart"
        version: "3.0.0"
  policies:
    - name: foo-cluster-only
      type: topology
      properties:
        clusters: ["foo"]
EOF


clusters 字段的 topology 策略是一个切片(slice),此处可以指定多个集群的名称。你还可以使用标签选择器或指定命名空间,详情见参考文档[6]


部署后,你可以通过以下方式检查已部署的应用程序:


vela status helm-hello


部署成功的预期输出应该如下:


About:
  Name:         helm-hello
  Namespace:    default
  Created at:   2022-06-09 19:14:57 +0800 CST
  Status:       running
Workflow:
  mode: DAG
  finished: true
  Suspend: false
  Terminated: false
  Steps
  - id:vtahj5zrz4
    name:deploy-foo-cluster-only
    type:deploy
    phase:succeeded
    message:
Services:
  - Name: hello
    Cluster: foo  Namespace: default
    Type: helm
    Healthy Fetch repository successfully, Create helm release successfully
    No trait applied


你可以通过以下方式检查已部署的资源:


$ vela status helm-hello --tree
CLUSTER       NAMESPACE     RESOURCE             STATUS
foo       ─── default   ─┬─ HelmRelease/hello    updated
                         └─ HelmRepository/hello updated


你也可以通过 VelaUX 检查已部署的资源。


使用 UI 控制台查看部署状态


通过使用 velaux UI 控制台,则可以很方便的查看多集群信息,并获得统一的体验。你可以参考文档[7]了解 VelaUX 的访问和使用细节。


通过 UI 界面,我们可以:


  • 检查来自不同集群的实例状态和事件:


1.jpeg


  • 检查来自不同集群的实例日志:


2.jpeg


  • 检查资源拓扑关系和状态:


3.jpeg


使用 Override 配置进行部署


在某些情况下,我们会为不同集群的 Helm Chart 设置不同的 Value ,这样我们可以使用 Override 策略[8]


下面是一个复杂的示例,我们将把一个 Helm Chart 部署到两个集群中,并为每个集群指定不同的 Value 。让我们部署它:


cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: helm-hello
spec:
  components:
    - name: hello
      type: helm
      properties:
        repoType: "helm"
        url: "https://jhidalgo3.github.io/helm-charts/"
        chart: "hello-kubernetes-chart"
        version: "3.0.0"
  policies:
    - name: topology-local
      type: topology
      properties:
        clusters: ["local"]
    - name: topology-foo
      type: topology
      properties:
        clusters: ["foo"]
    - name: override-local
      type: override
      properties:
        components:
          - name: hello
            properties:
              values:
                configs:
                  MESSAGE: Welcome to Control Plane Cluster!
    - name: override-foo
      type: override
      properties:
        components:
          - name: hello
            properties:
              values:
                configs:
                  MESSAGE: Welcome to Your New Foo Cluster!
  workflow:
    steps:
      - name: deploy2local
        type: deploy
        properties:
          policies: ["topology-local", "override-local"]
      - name: manual-approval
        type: suspend
      - name: deploy2foo
        type: deploy
        properties:
          policies: ["topology-foo", "override-foo"]
EOF


注意:如果你觉得策略和工作流程有点复杂,你可以将它们作为一个外部对象并仅引用该对象,用法和器交付[9]是一样的。


部署过程分为三个步骤:

(1)部署到本地集群;

(2)等待人工审批;

(3)部署到 foo 集群。


你会发现它在第一步之后就被暂停了,就像下面这样:


$ vela status helm-hello
About:
  Name:         helm-hello
  Namespace:    default
  Created at:   2022-06-09 19:38:13 +0800 CST
  Status:       workflowSuspending
Workflow:
  mode: StepByStep
  finished: false
  Suspend: true
  Terminated: false
  Steps
  - id:ww4cydlvee
    name:deploy2local
    type:deploy
    phase:succeeded
    message:
  - id:xj6hu97e1e
    name:manual-approval
    type:suspend
    phase:succeeded
    message:
Services:
  - Name: hello
    Cluster: local  Namespace: default
    Type: helm
    Healthy Fetch repository successfully, Create helm release successfully
    No trait applied


你可以查看并使用 Value 为 “Welcome to Control Plane Cluster!” 的部署在控制平面的 Helm Chart 。


vela port-forward helm-hello


浏览器会自动提示如下页面:


4.jpeg

image.gif

发现部署成功,让我们继续。


vela workflow resume helm-hello


然后它会部署到 foo 集群,你可以查看这些资源的详细信息。


$ vela status helm-hello --tree --detail
CLUSTER       NAMESPACE     RESOURCE             STATUS    APPLY_TIME          DETAIL
foo       ─── default   ─┬─ HelmRelease/hello    updated   2022-06-09 19:38:13 Ready: True  Status: Release reconciliation succeeded  Age: 64s
                         └─ HelmRepository/hello updated   2022-06-09 19:38:13 URL: https://jhidalgo3.github.io/helm-charts/  Age: 64s  Ready: True
                                                                               Status: stored artifact for revision 'ab876069f02d779cb4b63587af1266464818ba3790c0ccd50337e3cdead44803'
local     ─── default   ─┬─ HelmRelease/hello    updated   2022-06-09 19:38:13 Ready: True  Status: Release reconciliation succeeded  Age: 7m34s
                         └─ HelmRepository/hello updated   2022-06-09 19:38:13 URL: https://jhidalgo3.github.io/helm-charts/  Age: 7m34s  Ready: True

                                                                             Status: stored 再次使用端口转发:


vela port-forward helm-hello


然后它会弹出一些选项:


? You have 2 deployed resources in your app. Please choose one:  [Use arrows to move, type to filter]
> Cluster: foo | Namespace: default | Kind: HelmRelease | Name: hello
  Cluster: local | Namespace: default | Kind: HelmRelease | Name: hello


选择带有 foo 集群的选项,然后你会看到结果已经被新消息覆盖。


$ curl http://127.0.0.1:8080/
...snip...
      <div id="message">
  Welcome to Your New Foo Cluster!
</div>
...snip...

为不同环境指定不同的 Value 文件


你可以为不同环境选择 Helm Chart 中现有的不同 Value 文件。比如:


请确保你的本地集群有两个命名空间 “test” 和 “prod”,它们代表我们示例中的两个环境。


我们以 Chart hello-kubernetes-chart 为例。这个 Chart 有两个 Value 文件。你可以拉取此 Chart 并查看其中包含的所有文件:


$ tree ./hello-kubernetes-chart
./hello-kubernetes-chart
├── Chart.yaml
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── config-map.yaml
│ ├── deployment.yaml
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── tests
│ └── test-connection.yaml
├── values-production.yaml
└── values.yaml


我们可以看到此 Chart 中有 values.yaml values-production.yaml 这两个 Value 文件。


cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: hello-kubernetes
spec:
  components:
    - name: hello-kubernetes
      type: helm
      properties:
        repoType: "helm"
        url: "https://wangyikewxgm.github.io/my-charts/"
        chart: "hello-kubernetes-chart"
        version: "0.1.0"
  policies:
    - name: topology-test
      type: topology
      properties:
        clusters: ["local"]
        namespace: "test"
    - name: topology-prod
      type: topology
      properties:
        clusters: ["local"]
        namespace: "prod"
    - name: override-prod
      type: override
      properties:
        components:
          - name: hello-kubernetes
            properties:
              valuesFiles:
                - "values-production.yaml"
  workflow:
    steps:
      - name: deploy2test
        type: deploy
        properties:
          policies: ["topology-test"]
      - name: deploy2prod
        type: deploy
        properties:
          policies: ["topology-prod", "override-prod"]  
EOF


访问 Application 的 endpoint :


vela port-forward hello-kubernetes


如果你选择 Cluster: local | Namespace: test | Kind: HelmRelease | Name: hello-kubernetes 你会看到:


5.jpeg


选择 Cluster: local | Namespace: prod | Kind: HelmRelease | Name: hello-kubernetes 则会看到:image.gif

6.jpeg


清理


如果你使用 velad 进行此演示,则可以通过以下方式便捷地进行清理:


  • 清理 foo 集群


velad uninstall -n foo

 

  • 清理默认集群


velad uninstall

不仅如此


KubeVela 提供的能力远不止如此,通过安装其他插件,你还可以获得包括金丝雀发布[10]在内的更多能力,为你的 Helm Chart 交付保驾护航。


快使用 KubeVela 交付 Helm Chart ,让现代化的应用交付和管理更简单、轻松、可靠!


相关链接


[1] Helm Charts:

https://artifacthub.io/packages/search?kind=0


[2] KubeVela:

https://kubevela.io/


[3] 单集群的 Helm Charts 交付

https://kubevela.net/zh/docs/tutorials/helm


[4] velad:

https://github.com/kubevela/velad


[5] 集群管理:

https://kubevela.net/zh/docs/platform-engineers/system-operation/managing-clusters


[6] 参考文档:

https://kubevela.net/zh/docs/end-user/policies/references#topology


[7] 文档

https://kubevela.io/docs/install#2-install-velaux


[8] Override 策略

https://kubevela.io/docs/end-user/policies/references#override


[9] 容器交付

https://kubevela.io/docs/case-studies/multi-cluster#use-policies-and-workflow-outside-the-application


[10] 金丝雀发布:

https://kubevela.io/docs/tutorials/helm-rollout




您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节:


  • 项目代码库:github.com/oam-dev/kubevela 欢迎 Star/Watch/Fork!
  • 项目官方主页与文档:kubevela.io ,从 1.1 版本开始,已提供中文、英文文档,更多语言文档欢迎开发者进行翻译。
  • 项目钉钉群:23310022;Slack:CNCF #kubevela Channel
  • 加入微信群:请先添加以下 maintainer 微信号,表明进入 KubeVela 用户群:


7.png


此处:查看 KubeVela 项目官网!

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
7月前
|
Kubernetes 安全 Linux
开源Chart包安全分析发布,阿里云视角容器安全基线的重要性
云原生环境下,容器成为了软件开发过程中打包与分发的标准。
203 0
开源Chart包安全分析发布,阿里云视角容器安全基线的重要性
|
18天前
|
Prometheus Kubernetes 数据可视化
Helm3部署kubeview资源可视化工具
Helm3部署kubeview资源可视化工具
12 0
|
5月前
|
Kubernetes Cloud Native 应用服务中间件
解密Kubernetes(K8s)集群的创建过程和关键步骤
创建Kubernetes集群是在云原生环境中托管和管理容器化应用程序的关键步骤之一。Kubernetes(通常缩写为K8s)是一个强大的容器编排工具,它可以帮助您管理容器的部署、伸缩和维护。在本文中,我们将深入探讨如何创建一个基本的Kubernetes集群,以及在创建过程中涉及的关键代码和步骤。
118 0
|
5月前
|
负载均衡 安全 Cloud Native
[大厂实践] 零配置服务网格与按需集群发现
[大厂实践] 零配置服务网格与按需集群发现
48 0
|
6月前
|
监控 安全 Cloud Native
构建无缝的服务网格体验:分享在生产环境中构建和管理服务网格的最佳实践
构建无缝的服务网格体验:分享在生产环境中构建和管理服务网格的最佳实践
27 0
|
6月前
|
Kubernetes jenkins 测试技术
【Kubernetes的DevOps自动化,Jenkins上的Pipeline实现自动化构建、测试、部署、发布以及Bookinginfo实例的部署灰度发布故障注入流量】
【Kubernetes的DevOps自动化,Jenkins上的Pipeline实现自动化构建、测试、部署、发布以及Bookinginfo实例的部署灰度发布故障注入流量】
125 1
|
9月前
|
Java 测试技术
【2022】快速部署一个可用的EFK-7.17架构
【2022】快速部署一个可用的EFK-7.17架构
110 0
|
运维 Cloud Native 数据可视化
KubeVela 1.7 版本解读: 接管你的已有工作负载
KubeVela 1.7 版本已经正式发布一段时间,在此期间 KubeVela 正式晋级成为了 CNCF 的孵化项目,开启了一个新的里程碑。而 KubeVela 1.7 本身也是一个转折点,由于 KubeVela 从一开始就专注于可扩展体系的设计,对于控制器核心功能的需求也开始逐步收敛,我们开始腾出手来更加专注于用户体验、易用性、以及性能。在本文中,我们将重点挑选 1.7 版本中的工作负载接管、性
KubeVela 1.7 版本解读: 接管你的已有工作负载
|
运维 Kubernetes Cloud Native
KubeVela 1.7 版本解读:接管你的已有工作负载
KubeVela 1.7 版本解读:接管你的已有工作负载
KubeVela 1.7 版本解读:接管你的已有工作负载
|
域名解析 Prometheus Kubernetes
kubernetes 部署Prometheus监控集群传统部署方案)(2)
kubernetes 部署Prometheus监控集群传统部署方案)(2)
kubernetes 部署Prometheus监控集群传统部署方案)(2)