• Home
  • home > tools > Cluster > kubernetes >

    Kubernetes包管理器Helm小记

    Author：zhoulujun Date：

    Helm 是 Kubernetes 的软件包管理工具。Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。

    Helm 是 Kubernetes 的软件包管理工具。官网：https://helm.sh/zh/docs/

    包管理器类似于我们在 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样，能快速查找、下载和安装软件包。


    Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。

    利用Helm简化Kubernetes应用部署？

    Helm 的诞生及发展

    Helm 1

    最早期的 Helm 是一个内部黑客马拉松项目，旨在帮助独立开发人员创建 Kubernetes 资源包并将其部署至集群当中。它是于 2015 年在 Deis 创建，后被微软收购 。在同年的11月9日由 CNCF 主办的 KubeCon 上，正式推出（现在称之为 Helm Classic），这是 Helm 的第一个公开版本。

    Helm 2

    2016 年 1 月，Helm Classic 与名为 Kubernetes Deployment Manager 的 GCS 工具合并成 Helm，并移至 Kubernetes下。之后，Helm 加入了 CNCF，成为顶级项目，并已成功毕业。

    Helm 3

    Tiller 的目标是可以通过 Kubernetes API 来获取信息，在客户端进行 charts 渲染并且将记录存储于 Kubernetes 。 Helm 3 做的第一个决定就是移除 Tiller。随着 Tiller 消失，Helm 的安全模型得到了简化。可以借助 kubeconfig 文件来为 Helm 进行授权。在 Helm 3 中，默认使用 Secrets 存储发布信息（Release）。并且也将其 Go 模块路径从 k8s.io/helm 切换到了 helm.sh/helm/v3 。

    CNCF（云原生计算基金会） 的 Artifact Hub 于 2020 年 10 月取代了 Helm Hub 。Artifact Hub 是一个基于 Web 的应用程序，可用于查找、安装和发布 CNCF 项目的包和配置。比如，我们想快速找到 Helm 的 Chart 和插件就可以借助于 Artifact Hub。

    Helm 解决了什么痛点？

    在 Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。

    比如你安装一个 WordPress 博客，用到了一些 Kubernetes (下面全部简称k8s)的一些资源对象，包括 Deployment 用于部署应用、Service 提供服务发现、Secret 配置 WordPress 的用户名和密码，可能还需要 pv 和 pvc 来提供持久化服务。并且 WordPress 数据是存储在mariadb里面的，所以需要 mariadb 启动就绪后才能启动 WordPress。这些 k8s 资源过于分散，不方便进行管理，直接通过 kubectl 来管理一个应用，你会发现这十分蛋疼。 

    所以总结以上，我们在 k8s 中部署一个应用，通常面临以下几个问题：

    1. 如何统一管理、配置和更新这些分散的 k8s 的应用资源文件

    2. 如何分发和复用一套应用模板

    3. 如何将应用的一系列资源当做一个软件包管理

    Helm 包含两个组件，分别是 helm 客户端 和 Tiller 服务器：

    • helm 是一个命令行工具，用于本地开发及管理chart，chart仓库管理等

    • Tiller 是 Helm 的服务端。Tiller 负责接收 Helm 的请求，与 k8s 的 apiserver 交互，根据chart 来生成一个 release 并管理 release

      • chart Helm的打包格式叫做chart，所谓chart就是一系列文件, 它描述了一组相关的 k8s 集群资源

      • release 使用 helm install 命令在 Kubernetes 集群中部署的 Chart 称为 Release

      • Repoistory Helm chart 的仓库，Helm 客户端通过 HTTP 协议来访问存储库中 chart 的索引文件和压缩包

    v2-2fddd23fa8f679ccdf95c538aff7612a_720w.webp

    Helm 原理

    下面两张图描述了 Helm 的几个关键组件 Helm（客户端）、Tiller（服务器）、Repository（Chart 软件仓库）、Chart（软件包）之间的关系以及它们之间如何通信

    v2-d00f6117bc08847067103d7f1a8a3834_720w.webp

    Helm 原理Helm3 Workflow


    Helm概念

    在使用Helm的过程中，需要理解如下的几个核心的概念：

    概念

    描述

    Chart

    一个Helm包，其中包含了运行一个应用所需要的镜像、依赖和资源定义等，还可能包含Kubernetes集群中的服务定义，类似Homebrew中的formula、APT的dpkg或者Yum的rpm文件

    Repository

    存储Helm Charts的地方

    Release

    Chart在k8s上运行的Chart的一个实例，例如，如果一个MySQL Chart想在服务器上运行两个数据库，可以将这个Chart安装两次，并在每次安装中生成自己的Release以及Release名称。

    Value

    Helm Chart的参数，用于配置Kubernetes对象

    Template

    使用Go模板语言生成Kubernetes对象的定义文件

    Namespace

    Kubernetes中用于隔离资源的逻辑分区


    Helm工作流程

    注意：这里使用的是Helm的v3版本，该版本没有了tiller并并使用更加简单和灵活的架构，直接通过kubeconfig连接apiserver，简化安全模块，降低了用户的使用壁垒

    13000210_645e6302de5e828912.webp

    如上图所示，Helm的工作流程总结如下：

    1. 开发者首先创建并编辑chart的配置；

    2. 接着打包并发布至Helm的仓库（Repository）；

    3. 当管理员使用helm命令安装时，相关的依赖会从仓库下载；

    4. 接着helm会根据下载的配置部署资源至k8s；


    Chart配置

    Helm的打包格式叫做chart，所谓chart就是一系列文件, 它描述了一组相关的 k8s 集群资源。Chart中的文件安装特定的目录结构组织, 最简单的chart 目录如下所示：

    wordpress
├── charts
├── Chart.yaml
├── README.md
├── requirements.lock
├── requirements.yaml
├── templates
│   ├── deployment.yaml
│   ├── externaldb-secrets.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── pvc.yaml
│   ├── secrets.yaml
│   ├── svc.yaml
│   └── tls-secrets.yaml
└── values.yaml

    • charts 目录存放依赖的chart

    • Chart.yaml 包含Chart的基本信息，包括chart版本，名称等

    • templates 目录下存放应用一系列 k8s 资源的 yaml 模板

      • _helpers.tpl 此文件中定义一些可重用的模板片断，此文件中的定义在任何资源定义模板中可用

      • NOTES.txt 介绍chart 部署后的帮助信息，如何使用chart等

    • values.yaml 包含了必要的值定义（默认值）, 用于存储 templates 目录中模板文件中用到变量的值

    Chart.yaml解析

    Chart.yaml包含Chart的元数据和依赖项

    Chart.yaml的模板及注释如下：

    apiVersion: chart API 版本 （必需）  #必须有
name: chart名称 （必需）     # 必须有 
version: 语义化2 版本（必需） # 必须有

kubeVersion: 兼容Kubernetes版本的语义化版本（可选）
description: 一句话对这个项目的描述（可选）
type: chart类型 （可选）
keywords: 关于项目的一组关键字（可选）
home: 项目home页面的URL （可选）
sources: 项目源码的URL列表（可选）
dependencies: # chart 必要条件列表 （可选）
  - name: chart名称 (nginx)
    version: chart版本 ("1.2.3")
    repository: （可选）仓库URL ("https://example.com/charts") 或别名 ("@repo-name")
    condition: （可选） 解析为布尔值的yaml路径，用于启用/禁用chart (e.g. subchart1.enabled )
    tags: # （可选） 用于一次启用/禁用 一组chart的tag
    import-values: # （可选）
      - ImportValue 保存源值到导入父键的映射。每项可以是字符串或者一对子/父列表项
    alias: （可选） chart中使用的别名。当你要多次添加相同的chart时会很有用

maintainers: # （可选） # 可能用到
  - name: 维护者名字 （每个维护者都需要）
    email: 维护者邮箱 （每个维护者可选）
    url: 维护者URL （每个维护者可选）

icon: 用做icon的SVG或PNG图片URL （可选）
appVersion: 包含的应用版本（可选）。不需要是语义化，建议使用引号
deprecated: 不被推荐的chart （可选，布尔值）
annotations:
  example: 按名称输入的批注列表 （可选）.



    参考文章：

    Helm入门（一篇就够了） https://zhuanlan.zhihu.com/p/668270298

     张晋涛的回答 - 知乎 https://www.zhihu.com/question/63526885/answer/2406691314




    转载本站文章《Kubernetes包管理器Helm小记》,
    请注明出处：https://www.zhoulujun.cn/html/tools/Cluster/kubernetes/9296.html

    收藏
    上一篇：云原生：谷歌、Kubernetes、云原生计算基金会（CNCF）之纠葛
    下一篇：最后一页