K8s helm基本概念是什么

本篇内容介绍了“K8s helm基本概念是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

Helm简介

一、什么是 Helm(官网：https://helm.sh/)

在没使用 helm 之前，向 kubernetes 部署应用，我们要依次部署 deployment、svc 等，步骤较繁琐。况且随着很多项目微服务化，复杂的应用在容器中部署以及管理显得较为复杂，helm 通过打包的方式，支持发布的版本管理和控制，很大程度上简化了 Kubernetes 应用的部署和管理，就像 Java 使用 maven；node 使用 npm；python 使用 pip；Linux 使用 yum **

Helm 本质就是让 K8s 的应用管理（Deployment,Service 等 ) 可配置，能动态生成。通过动态生成 K8s 资源清单文件（deployment.yaml，service.yaml）。然后调用 Kubectl 自动执行 K8s 资源部署**。

helm的主要功能：

#查找要安装和使用的预打包软件
#轻松创建和托管自己的软件包
#将软件包安装到任何 K8S 集群中
#查询集群以查看已安装和正在运行的程序包
#更新、删除、回滚或查看已安装软件包的历史记录

二、Helm中的基本概念Chart

Helm 使用的包格式称为 chart，它是一个描述 Kubernetes 相关资源对象的文件集合。它的技术特点类似 jinja模版，以渲染模版的方式，生成运行一个服务实例所需的一系列资源对象文件，并以此进行服务的发布。通过这种方式，我们也可以十分简单的制作自定义的 chart。

Chart 有自已特定的目录布局，我们以官方提供的 wordpress为例说明，chart 的文件目录结构如下：

wordpress/
  Chart.yaml                # 包含了chart信息的YAML文件
  LICENSE                   # 可选: 包含chart许可证的纯文本文件
  README.md                 # 可选: 可读的README文件
  values.yaml               # chart 默认的配置值
  values.schema.json        # 可选: 一个使用JSON结构的values.yaml文件
  charts/                   # 包含chart依赖的其他chart
  crds/                     # 自定义资源的定义
  templates/                # 模板目录， 当和values 结合时，可生成有效的Kubernetes manifest文件
  templates/NOTES.txt       # 可选: 包含简要使用说明的纯文本文件

  #Helm Chart 基本元素为 charts/、Chart.yaml、templates/、values.yaml，并保留 crds/ ，要正确的使用 chart 进行发布，该元素是必不可少的。

Repo

Helm chart 可以被存储在专用的 HTTP 服务器上，称为 chart 仓库（repositories)，和 yum repository类似，chart 仓库提供了一个 index.yaml 来描述一批 chart，并且提供了每个 chart 的下载地址信息。

Helm 客户端可以指向多个 chart 仓库，默认情况下是没有配置仓库的，需要使用 helm repo add 来进行添加。helm3 中对于一些常用服务的下载安装，用 bitnami 仓库 取代了原来的stable 仓库，但是仍保留了 stable 仓库的使用

Release

当 chart 被发布后，Helm 库会创建一个 release 来跟踪这个发布的对象，它的实质是在 Kubernetes 中运行的各种资源，service、deployment、configmap、secret 等，在 K8S 集群中的直接的表现就是一个或多个 pod.

Helm 的 release 是允许启动多个不同服务的，且每个服务之间遵循依赖关系，这点就比较类似 docker compose.

三、从Helm2到Helm3的变化

1.Helm3新增的功能

Helm3新增了许多新功能，以下几个功能需要特别指出：

• release 的信息以新的形式存储

• 移除了 Tiller 组件

• Helm3 包含了对新版本 Helm charts （Charts v2）的支持

• Helm3 支持 library charts —— 一种作为其他 charts 元素的 charts

• 将 Chart 推送保存到 OCI 注册中心（类似 DockerRegistry ），以进行复用

• 升级Kubernetes资源时将应用向战略合并补丁

• 支持使用 JSON Schema 对 charts 的 values 进行校验

• 为了使Helm更安全，可用和健壮，已进行了许多小的改进。

2.重要变化概述

1）移除Tiller

Tiller 在 Helm2 中是一个重要的组成部分。Helm2 使用它和 GRPC 来处理 Helm chart 的安装和管理，呈现 chart 并将其推送到 Kubernetes API Server。Tiller 允许团队共享一个 Kubernetes 集群，多个 operator 可以使用同一组发行版，团队成员通过它就可以在一个共享的 Kubernetes 集群中管理复杂的应用发布。

但是从 Kubernetes 1.6 开始，考虑到安全性，集群默认会开启角色访问控制（RBAC），这使得管理和配置Tiller会变得非常复杂，因为可能的安全策略数量太多了。为了简化安全模型实现方式，并使管理员/SRE不需要去深入研究 Kubernetes 的安全组件，helm 提供了一个不需要太过关注安全规则的默认配置，但是这又会使得授权变得宽松，这反而会导致安全隐患。

因此在 Helm3 中干脆移除了 Tiller，而是选择从 Kubernetes API Server 中获取信息来渲染 Charts 客户端，并在 Kubernetes 中存在安装记录，这些过程既没有 Tiller 也可以实现。

Helm3 可以支持所有的 Kubernetes 认证及鉴权等全部安全特性。Helm和本地的 kubeconfig flie 中的配置使用一致的权限。管理员可以按照自己认为合适的粒度来管理用户权限，下图可详细看出helm2到helm3的改变

2）Chart仓库升级

在 Helm3 中，helm search 除了支持本地 repository 搜索外，还支持 helm search hub 搜索 Artifact Hub 中所有公开的 charts。

3）改进升级策略：使用三路策略合并补丁

在 Helm2 中，使用了双路策略合并补丁，简单来说就是在使用 helm upgrade 更新过程中，会比对本次发布的 chart manifest 和 最近一次发布的 chart manifest 的差异，以此来决定哪些更改被应用到 Kubernetes 的资源中去。并且，Helm 只会将最后一次应用的 chart manifest 作为 release 的当前状态，如果 chart 状态没有更改，资源的活动状态就不会更改，也就是说使用诸如 kubectl edit 、kubectl scale 这种外部方式进行的修改不会被 Helm 识别的，这种情况下如果发生回滚操作，Helm 会由于 chart 并没有发生变化而导致回滚失败。

而在 Helm3 中，这种策略被升级成了三路策略合并，Helm 在生成一个补丁时，也会考虑之前老的 manifest 的活动状态。也就是说，在使用老的 chart manifest 生成新的补丁时，Helm 还会考虑当前的活动状态，并将其与之前老的 manifest 进行比对，并再比对新的 manifest 是否有改动，并进行自动补全，以此来生成最终的更新补丁。

示例说明

用Chart渲染生成的manifest如下

containers:
- name: server
    image: my_app:2.0.0

通过非Helm的方式将应用的活动状态修改如下：

containers:
- name: server
    image: my_app:2.0.0
- name: sidecar
  	image: dump_handler:1.0.0

而现在我们想要将应用的镜像升级到2.1.0，通过chart进行升级操作

在 Helm2 中，由于不会考虑 chart 之外的修改，而是检测 chart 生成的 manifest 之间的区别，因此修改后的状态如下：

containers:
- name: server
    image: my_app:2.1.0

而在 Helm3 中，通过三路合并策略，会检查到除了 chart 的修改外，还多了一个 sidecar 容器，因此会进行补全，最终修改状态如下：

containers:
- name: server
    image: my_app:2.1.0
- name: sidecar
  	image: dump_handler:1.0.0

4）release名称存储位置改变

在 Helm2 中，release 的相关信息都被保存在 Tiller 的 namespace下，所以 release 的名称必须是唯一的；而随着 Tiller 组件的移除， Helm3 中release 相关的信息都被保存在了应用自己相对应的 namespace 下，因此根据 namespace 的隔离性质，在不同的 ns 下，release 的名称可以重复。

Helm3 中，在执行 helm list 时需要添加 --all-namespaces 参数才能获取到 Helm2 中同样的结果

5）requirements.yaml合并入 Chart.yaml

动态依赖关系的chart 依赖从 requirements.yaml 和 requirements.lock 移至 Chart.yaml 和 Chart.lock。 推荐在 Helm3 的新 chart 中使用 Chart API v2 的新格式，但是 Helm3 中依然可以识别 v1 版本，并且会自动加载已有的 requirements.yaml 文件。

在 Helm2 中，requirements.yaml 的表达式类似如下形式：

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://charts.helm.sh/stable
  condition: mariadb.enabled
  tags:
    - database

而在 Helm3 中，表达式的形式并没有变化，但是现在需要写在 Chart.yaml 中。Chart 依然会下载和放置在 charts/ 目录，所以 charts/ 目录中的子 chart 不需要做任何修改，可以沿用 Helm2 的。

6）CLI命令重命名

#删除release
	helm delete ---> helm uninstall
#在 Helm2 中，如果要清楚 release 的各种资源，必须要使用 --purge 参数，Helm3 中默认就会启用次功
#如果要保留历史行为数据，需执行 
	helm uninstall ---> keep-history
	helm inspect ---> helm show
    helm feach ---> helm pull
#这些命令还保留了它们较旧的命令作为别名，因此您可以继续以任何一种形式使用它们。

7）简化模板对象 .Capabilities

Capabilities 是 Helm 模版可以访问的内置对象之一，其提供了关于 Kubernetes 集群支持的功能的信息，包含以下内容：

四、Helm版本支持策略

1、版本形式

Helm 的版本用 x.y.z 的形式描述，x 是主版本，y 是次版本，z 是补丁版本。当一个 Helm 的新版本发布时，都是针对 Kubernetes 的一个特定版本编译的，比如 3.0.0 基于 Kubernetes 的 1.16.2 的客户端API版本构建，则可以兼容 Kubernetes 1.16。

2、可支持的版本偏差

相较于 Helm2 对于 Kubernetes 次版本变更支持的严格（n-1），Helm3 可以向下兼容 n-3 的次版本，比如你使用一个针对 Kubernetes 1.18 客户端 API 版本编译的 Helm3 版本，那么它可以支持的 Kubernetes 版本为 1.18、1.17、1.16、1.15 ；

如果你使用一个针对 Kubernetes 1.15 客户端 API 版本编译的 Helm2 版本，那么它可以支持的 Kubernetes 版本为 1.15、1.14。

Helm 没有向上兼容机制，故按照官方推荐安装即可：

“K8s helm基本概念是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！