深度解读Helm 3: 犹抱琵琶半遮面

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 自去年年初开始放风Helm v3将要开始开发,到去年年底KubeConn 上海被一堆人追问到底啥时候发版本。今年五月份,Helm v3 终于发布了第一个alpha版本,让我们来一窥新版本的Helm 到底带来了什么。

自去年年初开始放风Helm v3将要开始开发,到去年年底KubeConn 上海被一堆人追问到底啥时候发版本。今年五月份,Helm v3 终于发布了第一个alpha版本,让我们来一窥新版本的Helm 到底带来了什么。

Removal of Tiller

Helm 3最大的期待莫过于移除掉Tiller。很难想象一个开源项目,移除其中的一个核心组件会受到如此巨大的欢迎,其实毫不吝啬的说,Helm v3 alpha 1最大的功能就是去除了tiller。

由于历史原因,tiller 在集群应用版本管理和查询上扮演了重要的角色。但是随着RBAC等权限控制体系的组件完善,多租户和安全的需求日益兴起,tiller变得越来越不安全,社区在权限控制领域遇到了极大的阻碍。

移除tiller的好处主要有一下几点:

  • 更加简单和灵活的架构
  • 可以直接使用Kubernetes API交互
  • 客户端渲染Chart, 在Kubernetes集群中存储release信息
  • 客户使用壁垒更加的降低

CLI changes

  • helm delete ---> helm uninstall: 曾经完全删除一个release需要helm delete xxx --purge, 现在只需要uninstall就可以,purge会作为一个默认的行为
  • helm inspect ---> helm show: 这里可以查看Chart的具体信息
  • helm fetch ---> helm pull: 与docker pull看齐,为下一步兼容registry 做铺垫,像拉取镜像一样拉取Chart部署

Breaking Changes (Warning)

  • Namespaces changes

    Helm v2 只使用tiller 的namespace 作为release信息的存储,这样全集群的release名字都不能重复。Helm v3只会在release安装的所在namespace记录对应的信息,这样不同的namepsace就可以出现相同名字的release。

    同样的原因,如果已经使用Helm v2创建了release,那么就无法使用helm v3来进行升级操作,因为无法将原来的单一namespace信息迁移到所属namespace 下。这一块的迁移功能,社区正在紧锣密鼓的开发中

  • Chart dependency management

    • 老版本通过requirements.yaml和requirements.lock 来管理Chart的依赖,一个requirements.yaml 一般长相如下
    dependencies:
    - name: mariadb
      version: 5.x.x
      repository: https://kubernetes-charts.storage.googleapis.com/
      condition: mariadb.enabled
      tags:
    - database
    • 新版本直接使用Chart.yaml 来记录依赖信息,新的Chart.yaml格式和requirements.yaml 基本相同
      dependencies:
      - name: mariadb
        version: 5.x.x
        repository: https://kubernetes-charts.storage.googleapis.com/
        condition: mariadb.enabled
        tags:
          - database
  • Generate Name

    老版本Helm 可以直接安装chart 并不需要指定名称,Helm v3需要指定名称

Try

我们来试用一下Helm v3, 下载地址在这里https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1。 为了防止与已经安装的Helm v2冲突,我们需要设置一下
$HELM_HOME set an alternative location for Helm files. By default, these are stored in ~/.helm,比如放到/tmp目录下。安装完毕后,helmv3 init初始化一下就可以使用。

我们使用wordpress为例子

[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 install stabel/wordpress

[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 ls
NAME       NAMESPACE    REVISION    UPDATED                                    STATUS      CHART
test-v3    default      1           2019-05-27 16:50:46.100265945 +0800 CST    deployed    wordpress-0.6.13

可以看到,目前已经存在的Chart可以完全无缝迁移到helmv3 ,完全兼容。只是不需要tiller 来协助安装。以前Helm v2存储的release 都在tiller 所在的namespace。

[root@iZ8vbbnhdit552y4lytxpiZ ~]# kubectl get cm -n kube-system -l OWNER=TILLER
NAME                   DATA   AGE
wordpress-default.v1   1      26h
wordpress-default.v2   1      26h
wordpress-default.v3   1      26h

这就是Helm v2存储release 信息的地方,可以看到都在kube-system命名空间下。

[root@iZ8vbbnhdit552y4lytxpiZ ~]# kubectl get secret | grep word
test-v3-wordpress                                 Opaque                                2      26h
wordpress-default-mariadb                         Opaque                                2      26h
wordpress-default-wordpress                       Opaque                                2      26h

在看Helm v3,所有的信息都存储在release对应的namespace 下,而且以secret存储。这是v2和v3很不相同的地方。

Migrate from v2 to v3

  • 针对目前已经存在的chart, helm v3可以无缝安装,无需迁移
  • v2与v3可以共存,tiller 可以继续存在
  • 已经使用v2安装的release,不能通过v3来升级,查看

Pushing Charts to OCI Registries

在如何远程托管Chart这件事上,经历了很多次的发展。最初是保存在本地,然后是打成压缩包,上传到oss 等远程存储,然后社区出现了Chartmuseum 这样的开源工具,提供公共的Chart托管。但是关于权限认证等方便并没有很好的解决方案。同时在后端存储方面,也没有能像Docker Registry 那样很好的节省空间避免重复存储的功能。

因此所有的目光都转向了Docker Registry,毕竟目前各大厂商都已经提供了镜像托管功能,能否复用这个能力来托管Chart是一个很好的方向。由此微软推出了 OCI Registry As Storage。根据镜像 OCI 标准规范,复用Registry 来存储Chart。这个目前已经集成到Helm v3试验版本里面。

我们来试用一下这个功能.
首先本地启动一个registry
docker run -dp 5000:5000 --restart=always --name registry registry:2

然后下载一个chart包helm fetch stable/wordpress

[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart save wordpress localhost:5000/wordpress:latest
Name: wordpress
Version: 0.6.13
Meta: sha256:83c48dd3c01a2952066ead67023ea14963a88db4287650baad5ea1ddd8ff9590
Content: sha256:248c8c68f4f614003c8b1a9d78787e5f07e979e9b996981df993cf380f498c97
latest: saved


[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart list
REF                                NAME         VERSION    DIGEST     SIZE        CREATED
localhost:5000/wordpress:latest    wordpress    0.6.13     248c8c6    12.0 KiB    11 seconds


[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart push localhost:5000/wordpress:latest
The push refers to repository [localhost:5000/wordpress]
Name: wordpress
Version: 0.6.13
Meta: sha256:83c48dd3c01a2952066ead67023ea14963a88db4287650baad5ea1ddd8ff9590
Content: sha256:248c8c68f4f614003c8b1a9d78787e5f07e979e9b996981df993cf380f498c97
latest: pushed to remote (2 layers, 12.6 KiB total)

这样就完成了将Chart 推送到Registry的功能。这个功能目前处于实验性质,社区还是希望未来大家能够都转到这种存储方式上来。

What's Next

  • alpha1: 移除Tiller, 提供Library charts, 存储格式改成secret, 开始OCI集成工作
  • alpha2: 更好的 OCI 集成,Lua 模板支持
  • alpha3: 重构更新策略(可能是客户端侧进行,也可能是服务端侧进行)

容器服务 Kubernetes 版(ACK)

阿里云容器服务是 Kubernetes 认证服务提供商(KCSP),国内唯一进入 Gartner 竞争格局的公有云容器平台。容器服务 Kubernetes 版(ACK)是安全稳定的企业级容器平台,支持高性能网络和存储,提供面向应用的异构资源统一管理,为企业上云提供最佳云原生支持。点击了解产品详情 https://www.aliyun.com/product/kubernetes ;Kuberentes爱好者这请加入钉钉技术群:
image

相关实践学习
Docker镜像管理快速入门
本教程将介绍如何使用Docker构建镜像,并通过阿里云镜像服务分发到ECS服务器,运行该镜像。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
4月前
|
人工智能 PyTorch 算法框架/工具
AI 容器镜像部署 Stable Diffusion
本文将基于阿里云 AMD 服务器和龙蜥 AI 容器服务,快速搭建出个人版文生图服务
|
1月前
|
Kubernetes Linux Docker
深度解析:Kubernetes 1.28.2集群安装过程中的关键步骤
本文旨在为读者提供一份详尽的Kubernetes 1.28.2集群安装指南,帮助您从零开始构建稳定、高效的Kubernetes集群。我们将从环境准备、软件安装、集群初始化到节点添加等各个环节进行逐步讲解,确保您能够顺利完成集群的搭建。
|
3月前
|
Kubernetes 容器
ChaosBlade的Helm安装双架构主要包括以下步骤
【1月更文挑战第22天】【1月更文挑战第109篇】ChaosBlade的Helm安装双架构主要包括以下步骤
114 1
|
3月前
|
Kubernetes 容器
ChaosBlade的Helm安装双架构主要包括以下步骤:
【1月更文挑战第8天】【1月更文挑战第39篇】ChaosBlade的Helm安装双架构主要包括以下步骤:
71 1
|
9月前
|
Kubernetes 负载均衡 并行计算
基于Truss+Docker+Kubernetes把开源模型Falcon-7B送上云端(译)(下)
基于Truss+Docker+Kubernetes把开源模型Falcon-7B送上云端(译)(下)
126 0
|
9月前
|
并行计算 Kubernetes 安全
基于Truss+Docker+Kubernetes把开源模型Falcon-7B送上云端(译)(上)
基于Truss+Docker+Kubernetes把开源模型Falcon-7B送上云端(译)(上)
149 0
基于Truss+Docker+Kubernetes把开源模型Falcon-7B送上云端(译)(上)
|
11月前
|
人工智能 安全 Serverless
【换模型更简单】如何用 Serverless 一键部署 Stable Diffusion?
本篇则是以更大众的方式实现本地电脑的平替,使得人人皆可拥有一套实用的 Stable Diffusion 服务,不管你是普通用户,或者是技术同学,皆可适用。
|
11月前
|
Kubernetes Cloud Native 关系型数据库
【云原生】我将ChatGPT变成Kubernetes 和Helm 终端
【云原生】我将ChatGPT变成Kubernetes 和Helm 终端
83 0
|
存储 Kubernetes Cloud Native
【云原生-Helm】k8s-helm-简介及基础配置
【云原生-Helm】k8s-helm-简介及基础配置
307 0
【云原生-Helm】k8s-helm-简介及基础配置
|
机器学习/深度学习 存储 Kubernetes
Kubeflow 和 Argo 的综合比较
MLOps 通过自动化可重复的任务来帮助简化 ML 生命周期。它还提供了帮助数据科学团队与其他团队有效协作、沟通和协调的最佳实践。 机器学习管道是 MLOps 中的一个关键概念。理想情况下,一旦机器学习模型投入生产,就会构建一个可以根据需要重新训练模型的系统,并且可以进一步开发该系统,而不是依赖临时工作流。 许多公司的一个重要问题是找到最合适的平台来管理他们的自动化工作流程。一些人正在寻找为 ML/MLOps 构建的特定工具,例如:Kubeflow,而另一些人则在寻找更通用的编排器,例如:Argo 或 Airflow,它们可以适用于机器学习工作流。