Kubernetes包管理神器Kustomize与Helm对比

云计算 云原生
Helm 将所有 K8s 对象封装到一个包中,减少了与各个yaml 文件的交互。除此之外,大多数第三方供应商还提供预构建的 Helm 图表,以简化将其产品部署到 K8s 中的过程。因此,Helm 通常是安装现成解决方案(例如监控、数据库和消息中间件等)的首选。

K8s 是一个开源容器编排平台,可自动执行容器化应用程序的部署、扩展和管理。近年来,K8s 已成为采用云原生架构和容器化技术的组织的标准。

但是由于K8s的复杂性,因此诞生很多工具来简化使用的门槛。大多数公司使用的两个工具是Kustomize (K8s 的配置管理器)和Helm (K8s 的包管理器)

在本文中,我们将讨论 Helm 和 Kustomize、它们可以做什么、如何使用它们以及这些工具之间有什么区别。


Kustomize

Helm

操作方法

overlays

templating

使用成本

简单

复杂

是否支持封装



原生 kubectl 集成



声明式/ 命令式

声明式

命令式

什么是Kustomize?

Kustomize 是 k8s集群的配置定制工具。它允许管理员使用非模板文件进行声明性更改,而不影响原始清单文件。

所有自定义规范都包含在 kustomization.yaml 文件中,该文件将规范叠加在现有清单之上以生成资源的自定义版本。

比如我们有一个应用,需要在生产环境和测试环境部署,并且它的 yaml 配置大部分是相同的,只有少数的字段不同,那么这时候就可以用kustomize 来解决

Kustomize结构

Kustomize 使用共享基础资源和覆盖来提供可重用性和配置生成。Kustomize 项目的典型目录结构如下所示:

图片图片

Kustomize 项目结构通常包含基本目录和覆盖目录。在上面结构中,基本目录包含一个名为kustomization.yaml的文件和共享资源的清单文件。

base/kustomization.yaml文件声明文件,将包含在所有环境中

Overlays目录也包含kustomization.yaml,此文件会引用base文件夹的yaml 文件并进行自定义修改来构建个性化资源。同时Overlays 目录还包括单独的yaml文件,Kustomize 使用这些文件来创建特定环境资源

自定义部署示例

下面通用示例演示如何使用 Kustomize 进行最小 K8s 部署,将资源部署到开发和生产环境。

前置依赖

  • k8s 集群(1.14+)
  • Kubectl 客户端

使用以下命令克隆示例 Git 存储库并将所需的清单下载到您的工作环境中:

git clone https://github.com/dongweizhao/kustomize-demo.git

图片图片

结构如下

图片图片

此示例模拟在不同环境部署httpd 的dp和svc,其中dev会在名称前增加dev-,prod 会在名称前增加prod-,而 base会使用默认名称 httpd

  1. base
resources:
- deployment.yaml
- service.yaml
  1. prod
bases:
- ../../base
namePrefix: prod-
  1. dev
bases:
- ../../base
namePrefix: dev-

部署

cd base && kubectl apply -k .

执行完成以后会输出以下结果

图片图片

注意: kubectl 使用 -k 或 --kustomize 标志来识别 Kustomize

和前面一样,到“/overlays/dev”文件夹执行部署,如下所示:

cd overlays/dev && kubectl apply -k .

输出结果

图片图片

prod 部署

cd overlays/prod && kubectl apply -k .

输出结果

图片图片

结果验证

kubectl get pods|grep http

图片图片

kubectl get svc|grep http

图片图片

根据以上结果,可以看到配置已经生效

什么是Helm?

Helm 是一个能够在 K8s 上打包、部署和管理应用程序的工具,即使是最复杂的 K8s 应用程序它都可以帮助定义,安装和升级,同时Helm 也是 CNCF 的毕业项目。

图片图片

以下Helm中的概念

Helm Charts:预先配置yaml的模板,在这里叫Chart,用于描述 K8s 应用程序的yaml和配置

Helm Client:用于与 Helm 交互并管理这些Chart版本的命令行界面

Chart 仓库:管理Chart的仓库,跟Maven的Nexus一个意思,比如在公司环境构建上传,在客户的机房连接到这Chart 仓库下载Chart,并部署到k8s中。

Helm 示例

前置依赖

  • k8s 集群
  • Kubectl 客户端
  • helm客户端

Helm Charts 是预先配置的 K8s 资源包。Helm Chart 包含部署特定应用程序或服务所需的所有信息,包括 K8s 清单、环境变量和其他配置

目录名称是Chart的名称,如Helm 文档所示,我们通过helm create helm-demo命令创建一个Chart,执行完以后,默认会生成一个 nginx 的Chart,如下图

图片图片

Chart.yaml

定义了当前 chart版本,以及描述当前chart用途,其中 name 参数表示 chart 名称,后期上传下载都会用此名称

apiVersion: v2
name: helm-demo
description: A Helm chart for K8s

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.16.0"

values.yaml

可变参数,都是在此文件中定义,在yaml模板中引用,比如:image.repository,而引用则通过.Values+变量的名进行引用,如下图

图片图片

_helpers.tpl

定义通用代码块,然后yaml 文件会通过 include 引用

定义

{{- define "helm-demo.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}

引用

{{ include "helm-demo.fullname" . }}

templates

此目录主要存放的是要部署的 yaml文件模板,同时也包含_helpers.tpl文件,模板会引用values.yaml、Chart.yaml定义的参数,以及_helpers.tpl定义的通用代码块

图片图片

部署

helm package helm-demo

图片图片

以下命令,通过 set指定部署 2 个副本pod,此参数在 values.yaml 中有定义

helm install helm-demo helm-demo-0.1.0.tgz --set replicaCount=2

图片图片

结果验证

可以看到部署了 2 个副本

kubectl get pods|grep helm

图片图片

主要差异

操作方法

Kustomize 依赖特定于目录的kustomization.yaml文件来构建各个资源并对其进行更改。这些文件将补丁和覆盖应用到共享基文件夹中声明的资源,以提供自动化的多环境配置。

Helm 通过引用value.yaml文件作为变量源,使用模板生成有效的 K8s 配置。模板目录托管 Helm Chart在部署期间用于创建资源的文件。

便捷性

从K8s 版本 1.14 开始,Kustomize 与 kubectl CLI 捆绑在一起,因此不需要掌握任何其他工具。Kustomize 支持声明式部署,并对每个文件使用纯 YAML,从而更容易使用。

Helm 为K8s包管理任务添加了额外的抽象层,从而加快了希望简化集群配置和发布自动化的团队的学习曲线。Helm Chart 相对Kustomize复杂,不过功能更加强大。

打包

Kustomize 缺乏的打包功能,并且每个资源都必须在基本文件夹中声明,并在覆盖kustomization.yaml文件中单独声明变体。

而Helm将所有必需的K8s资源都打包到一个文件夹中,该文件夹可以根据需要重复使用。Helm 还允许设置应用程序默认值,并且使用values.yaml文件修改参数,从而注入引用的 yaml 文件中。

原生 kubectl 集成

从 K8s 1.14 版开始,Kustomize 就预装了 kubectl,Helm 并未与 K8s 预先集成,因此必须手动安装 Helm。

Kustomize 与 Helm - 何时使用

何时使用 Kustomize

Kustomize允许在不改变原始文件的情况下进行精确更改。因此可以有以下场景

  • 应用配置的变体管理:当你需要管理多个环境(例如开发、测试、生产)中应用的变体时,Kustomize 是一个很好的选择。它允许你为不同的环境创建不同的配置,并使用一套基础配置来定义通用部分。
  • 持续集成和持续部署(CI/CD)流水线:Kustomize 可以与 CI/CD 工具集成,帮助你实现自动化部署。通过在流水线中使用 Kustomize,你可以根据需要生成特定环境的配置,并将其应用到集群中。

何时使用 Helm

Helm 将所有 K8s 对象封装到一个包中,减少了与各个yaml 文件的交互。除此之外,大多数第三方供应商还提供预构建的 Helm 图表,以简化将其产品部署到 K8s 中的过程。因此,Helm 通常是安装现成解决方案(例如监控、数据库和消息中间件等)的首选

责任编辑:武晓燕 来源: 架构成长指南
相关推荐

2020-11-05 11:00:21

KubernetesKustomize开源

2023-03-10 22:14:49

KustomizeKubernetes

2021-04-14 18:54:20

Kubernetes开发工具开发

2022-02-28 10:22:08

前端管理工具

2013-10-21 10:01:04

编码工具扩展

2022-02-21 09:58:31

包管理器npmyarn

2021-06-24 08:25:38

flux2GitOps 云原生

2019-03-29 09:00:31

Kubernetes开发者工具

2020-08-16 08:34:15

Helm图表Kubernetes Kubernetes

2021-10-15 08:27:14

Kubernetes 工具Mizu

2019-09-02 13:57:07

Helm Chart工具Kubernetes

2021-11-11 09:01:01

Helm Chart Kubernetes

2019-01-15 08:58:40

Kubernetes生态圈Docker

2021-02-05 07:48:06

Linux操作系统软件

2022-05-07 11:08:50

Linuxapt 命令

2022-05-04 11:10:58

Linuxdnf 命令

2020-09-09 07:00:00

Kubernetes集群容器

2022-09-05 08:33:32

HartKubernetes

2019-12-25 09:53:01

虚拟机技术固态硬盘

2020-12-03 12:06:54

HarmonyOS
点赞
收藏

51CTO技术栈公众号