Kubernetes包管理神器Kustomize与Helm对比

2024年 2月 3日 60.7k 0

转载至我的博客 www.infrastack.cn ,公众号:架构成长指南

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

  • base

    resources:
    - deployment.yaml
    - service.yaml
    
  • prod

    bases:
    - ../../base
    namePrefix: prod-
    
  • 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 通常是安装现成解决方案(例如监控、数据库和消息中间件等)的首选

    又到过年了,龙年红包封面是必备的,大家不要花钱购买了,我制作一款封面红包,数量4千个,效果如下

    图片

    领取方法,关注公众号架构成长指南,回复「封面」领取

    相关文章

    KubeSphere 部署向量数据库 Milvus 实战指南
    探索 Kubernetes 持久化存储之 Longhorn 初窥门径
    征服 Docker 镜像访问限制!KubeSphere v3.4.1 成功部署全攻略
    那些年在 Terraform 上吃到的糖和踩过的坑
    无需 Kubernetes 测试 Kubernetes 网络实现
    Kubernetes v1.31 中的移除和主要变更

    发布评论