侧边栏壁纸
博主头像
孔子说JAVA博主等级

成功只是一只沦落在鸡窝里的鹰,成功永远属于自信且有毅力的人!

  • 累计撰写 297 篇文章
  • 累计创建 134 个标签
  • 累计收到 4 条评论

目 录CONTENT

文章目录

Helm3入门教程-1:Helm 3 简介

孔子说JAVA
2022-04-12 / 0 评论 / 0 点赞 / 579 阅读 / 3,698 字 / 正在检测是否收录...

Helm3入门教程全系列,26小时轻松掌握Helm

1、Helm概述

1.1 Helm简介

Helm是Kubernetest(k8s)的包管理工具,类似Linux系统常用的 apt、yum等包管理工具。使用helm可以简化k8s应用部署,它能够把创建一个应用所需的所有 Kubernetes API 对象声明文件组合并打包在一起。并提供了仓库的机制便于分发共享,还支持模版变量替换,同时还有版本的概念,能够对应用的版本进行统一化管理。

背景: k8s是一个分布式的容器集群管理系统,它将集群中的所有资源都抽象成 API 对象,并且使用声明的方式来创建、修改、删除这些对象。在微服务盛行的今天,如果使用这种方式将导致大量API声明文件的编写维护,使运维工作量爆发式增长,并且对每个微服务应用都需要编写对应的yaml配置文件,极容易出错,维护困难。helm就是为解决这些问题而诞生的。

  • 在云 (Kubernetes)上,部署一个应用往往不是那么简单。如果想要部署一个应用程序到云上,首先要准备好它所需要的环境,打包成 Docker 镜像,进而把镜像放在部署文件 (Deployment) 中、配置服务 (Service)、应用所需的账户 (ServiceAccount) 及权限 (Role)、命名空间 (Namespace)、密钥信息 (Secret)、可持久化存储 (PersistentVolumes) 等资源。也就是编写一系列互相相关的 YAML 配置文件,将它们部署在 Kubernetes 集群上。
  • 即便应用的开发者可以把这些 Docker 镜像存放在公共仓库中,并且将所需的 YAML 资源文件提供给用户,用户仍然需要自己去寻找这些资源文件,并把它们一一部署。倘若用户希望修改开发者提供的默认资源,比如使用更多的副本 (Replicas) 或是修改服务端口 (Port),他还需要自己去查需要在这些资源文件的哪些地方修改,更不用提版本变更与维护会给开发者和用户造成多少麻烦了。

1.2 Helm主要功能

Helm主要功能如下:

  1. 查找要安装和使用的预打包软件(Chart);
  2. 轻松创建和托管自己的软件包;
  3. 将软件包安装到任何K8s集群中;
  4. 查询集群已安装和正在运行的程序包;
  5. 更新、删除、回滚或查看已安装软件包的历史记录;

从使用方角度看:

  • 应用发布者:可以通过Helm打包应用,管理应用依赖关系,管理应用版本并发布应用到软件仓库。Helm还提供了kubernetes上的软件部署,删除,升级,回滚应用的强大功能。
  • 使用者:使用Helm后不用需要了解Kubernetes的Yaml语法并编写应用部署文件,可以通过Helm下载并在kubernetes上安装需要的应用。

2、基本概念

  • Helm:Helm 是一个命令行下的客户端工具。主要用于 Kubernetes 应用程序 Chart 的创建、打包、发布以及创建和管理本地和远程的 Chart 仓库。
  • Tiller:Tiller 是 Helm 的服务端,部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求,并根据 Chart 生成 Kubernetes 的部署文件( Helm 称为 Release ),然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。
  • Chart:一个 Helm 包,采用 TAR 格式,其中包含了运行一个应用所需要的镜像、依赖和资源定义等,还可能包含 Kubernetes 集群中的服务定义,类似 Homebrew 中的 formula、APT 的 dpkg 或者 Yum 的 rpm 文件。
  • Release:在 Kubernetes 集群上运行的 Chart 的一个实例。在同一个集群上,一个 Chart 可以安装很多次。每次安装都会创建一个新的 release。例如一个 MySQL Chart,如果想在服务器上运行两个数据库,就可以把这个 Chart 安装两次。每次安装都会生成自己的 Release,会有自己的 Release 名称。
  • Repository:Helm 的软件仓库,用于发布和存储 Chart 的存储库。Repository 本质上是一个 Web 服务器,该服务器保存了一系列的 Chart 软件包以供用户下载,并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。

3、Helm 3与Helm 2的不同

Helm 3以Helm 2的核心功能为基础,对Chart repo、发行版管理、安全性和library Charts进行了改进。

相比Helm 2,Helm 3最明显的变化是Tiller的删除,它新增丰富功能,某些功能已被弃用或重构,与Helm 2不再兼容。此外,Helm 3还引入了一些新的实验功能,包括OCI支持等。以下只列出重要改动,完整内容请参考helm官网:https://v3.helm.sh/zh/docs/faq/

3.1 移除Tiller

在Helm 2开发周期中,Helm团队引入了Tiller(Helm2是C/S架构,主要分为客户端helm和服务端 Tiller)。它使多个不同的操作员可以与同一组发行版进行交互,对于在共享集群中工作的团队非常有用。但Kubernetes v1.6默认启用基于角色的访问控制(RBAC),这之后在生产环境中用Tiller会变得难以管理。同时出于安全策略考虑,Helm 3移除了Tiller,helm 直接和 Kubernetes API 进行通信,安全模型从根本上得以简化。这样做带来的好处有如下几点:

  • Helm 的架构变的更为简单和灵活
  • 不再需要创建 ServiceAccount,直接使用当前环境中的 kubeconfig 配置
  • 可以直接和 Kubernetes API 交互,更为安全
  • 不再需要使用 helm init 来进行初始化(以前的版本需要使用该命令来向 K8S 集群中安装 Tiller)

3.2 三方战略合并补丁

  • Helm 2使用双向战略合并补丁,在升级过程中,它会比较最新Chart清单与建议Chart清单的差异,以确定需要对Kubernetes中的资源进行哪些更改。
  • 在Helm 3中,它现在使用三向战略合并补丁。生成补丁时,Helm会考虑旧清单、当前状态和新清单,充分保障资源能回滚到以前的状态。

3.3 Secrets作为默认存储驱动程序

  • 在helm 2中,默认情况下使用ConfigMaps存储发行信息。
  • 在helm 3中,将Secrets用作默认存储驱动程序。

3.4 Release版本信息

  • 在helm 2中,release 的信息全部存储在 Tiller 所在的命名空间中,所以 release 的名称不能重复。
  • 在helm 3中,随着Tiller的删除,release 的信息只会存储在 release 安装的命名空间中,这样不同的 namepsace 就可以出现相同名字的 release。

3.5 安装时必须指定release名称

  • 在helm 2中,如果在 helm install 时没有指定release名称,会自动生成一个随机名称。
  • 在helm 3中,则必须要指定 release 名称,或者使用 --generate-name 选项。

3.6 删除release命令变更

  • 在helm 2中,删除命令:helm delete release-name --purge
  • 在helm 3中,删除只需要使用 uninstall 命令即可,–purge 会作为一个默认的行为:helm uninstall release-name

3.7 查看charts信息命令变更

  • 在helm 2中,查看具体的 charts 信息命令:helm inspect
  • 在helm 3中,查看具体的 charts 信息命令:helm show

3.8 拉取charts包命令变更

  • 在helm 2中,拉取charts包命令:helm fetch
  • 在helm 3中,拉取charts包命令:helm pull

您如果需要将 helm 2 升级至 helm 3,需要使用官方提供的 2To3 插件来完成,具体的操作流程可以参考官网:https://helm.sh/zh/docs/topics/v2_v3_migration

4、Helm架构

image-1649729181002

Chart Install 过程:

  1. Helm从指定的目录或者tgz文件中解析出Chart结构信息。
  2. Helm将指定的Chart结构和Values信息通过gRPC传递给Tiller。
  3. Tiller根据Chart和Values生成一个Release。
  4. Tiller将Release发送给Kubernetes运行。

Chart Update过程:

  1. Helm从指定的目录或者tgz文件中解析出Chart结构信息。
  2. Helm将要更新的Release的名称和Chart结构,Values信息传递给Tiller。
  3. Tiller生成Release并更新指定名称的Release的History。
  4. Tiller将Release发送给Kubernetes运行。

Chart Rollback过程:

  1. Helm将要回滚的Release的名称传递给Tiller。
  2. Tiller根据Release的名称查找History。
  3. Tiller从History中获取上一个Release。
  4. Tiller将上一个Release发送给Kubernetes用于替换当前Release并运行。
0

评论区