其他分享
首页 > 其他分享> > 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中的基本概念

  1. 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 进行发布,该元素是必不可少的。
  1. Repo

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

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

  1. Release

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

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

三、从Helm2到Helm3的变化

  1. Helm3新增的功能

​ Helm3新增了许多新功能,以下几个功能需要特别指出:

  1. 重要变化概述

​ 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的改变

img

​ 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 editkubectl 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.yamlrequirements.lock 移至 Chart.yamlChart.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 集群支持的功能的信息,包含以下内容:

对象名称 描述
Capabilities.APIVersions 集群的版本信息
Capabilities.APIVersions.Has $version 说明集群中的版本 (例如, batch/v1) 或是资源 (例如, apps/v1/Deployment) 是否可用
Capabilities.KubeVersion 提供了查找 Kubernetes 版本的方法。可以获取到 MajorMinorGitVersionGitCommitGitTreeStateBuildDateGoVersionCompilerPlatform
Capabilities.TillerVersion 提供了查找Tiller版本的方法。可以获取到SemVer, GitCommit, and GitTreeState.

四、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 没有向上兼容机制,故按照官方推荐安装即可:

Helm 版本 支持的 Kubernetes 版本
3.8.x 1.23.x - 1.20.x
3.7.x 1.22.x - 1.19.x
3.6.x 1.21.x - 1.18.x
3.5.x 1.20.x - 1.17.x
3.4.x 1.19.x - 1.16.x
3.3.x 1.18.x - 1.15.x
3.2.x 1.18.x - 1.15.x
3.1.x 1.17.x - 1.14.x
3.0.x 1.16.x - 1.13.x
2.16.x 1.16.x - 1.15.x
2.15.x 1.15.x - 1.14.x
2.14.x 1.14.x - 1.13.x
2.13.x 1.13.x - 1.12.x
2.12.x 1.12.x - 1.11.x
2.11.x 1.11.x - 1.10.x
2.10.x 1.10.x - 1.9.x
2.9.x 1.10.x - 1.9.x
2.8.x 1.9.x - 1.8.x
2.7.x 1.8.x - 1.7.x
2.6.x 1.7.x - 1.6.x
2.5.x 1.6.x - 1.5.x
2.4.x 1.6.x - 1.5.x
2.3.x 1.5.x - 1.4.x
2.2.x 1.5.x - 1.4.x
2.1.x 1.5.x - 1.4.x
2.0.x 1.4.x - 1.3.x

标签:Helm3,Kubernetes,简介,chart,Helm,版本,helm,K8s
来源: https://www.cnblogs.com/xycloud/p/16493941.html