【K8S系列】第十一讲：包管理神器-Helm

序言

当发现自己的才华撑不起野心时，就请安静下来学习吧

三言两语，不如细心探索

今天学习整理了一下Helm相关内容，希望此文，能帮助读者对Helm 包管理有一个初步的了解

文章标记颜色说明：

黄色：重要标题

红色：用来标记结论

绿色：用来标记一级论点

蓝色：用来标记二级论点

1.背景介绍

1.1 k8s 简单介绍

Kubernetes 是一个提供了基于容器的应用集群管理解决方案，

Kubernetes 为容器化应用提供了：

部署运行

资源调度

服务发现

动态伸缩

等完整功能。

Kubernetes 的核心设计理念:

规则定义：用户定义要部署的应用程序的规则

运行部署：K8s 负责按照定义的规则，部署并运行应用程序

修正：如果应用程序出现问题，导致偏离了定义的规格，K8s 负责对其进行自动修正

例如：定义的应用规则要求部署两个实例（Pod），其中一个实例异常终止了，Kubernetes 会检查到并重新启动一个新的实例。

用户通过使用 Kubernetes API 对象来描述应用程序规则，包括 Pod、Service、Volume、Namespace、ReplicaSet、Deployment、Job等等。

一般这些资源对象的定义需要写入一系列的 YAML 文件中，然后通过 Kubernetes 命令行工具 Kubectl 调 Kubernetes API 进行部署。

1.2 k8s部署挑战

以一个典型的三层应用 Wordpress 为例，该应用程序就涉及到多个 Kubernetes API 对象，而要描述这些 Kubernetes API 对象就可能要同时维护多个 YAML 文件。在进行 Kubernetes 软件部署时，就会面临下述几个问题：

如何管理、编辑和更新这些这些分散的 Kubernetes 应用配置文件

如何把一套相关的配置文件作为一个应用进行管理

如何分发和重用 Kubernetes 的应用配置

可以看到，在使用kubernetes 的过程中，用的最多的是 kubectl，但是，使用 kubectl 工具需要提前编写好各种部署文件，随着应用越来越多，会越来越不方便。

于是。 Helm 这个 kubernetes 包管理工具就应运而生了。

2.Helm

2.1 Helm介绍

Helm 是 Deis 开发的一个用于 Kubernetes 应用的包管理工具，主要用来管理 Charts。

类似于：

Ubuntu 中的 APT

CentOS 中的 YUM

主要功能：

创建：创建新的charts

打包：将charts打包成tgz文件

交互：与chart仓库交互

安装：安装和卸载K8s的应用

管理：管理使用Helm安装的charts的生命周期

2.1 使用优势：

1.应用发布方面：可以通过 Helm

打包应用

管理应用依赖关系

管理应用版本并发布应用到软件仓库

2.使用方面：
    使用 Helm 后不用需要编写复杂的应用部署文件，可以用简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

3.Helm模块

以Helm 3 为例，其主要模块有：

Helm

Chart

Repoistory

Config

Release

3.1 Helm

Helm 是一个命令行下的客户端工具。主要用于 Kubernetes 应用程序中：

Chart 的创建

Chart 的打包

Chart 的发布

Chart 的创建

管理本地/远程的 Chart 仓库

3.1.1 安装Helm

helm3 是一个二进制文件，安装相对简单，

二进制下载地址页面: https://github.com/helm/helm/releaseswget

其命令如下：
https://get.helm.sh/helm-v3.4.1-linux-amd64.tar.gztar zxf helm-v3.4.1-linux-amd64.tar.gzcp linux-amd64/helm /usr/local/bin/helm

**1.安装 **

#从github下载helm
wget https://get.helm.sh/helm-v3.4.1-linux-amd64.tar.gz
 #解包，只需要包中的一个命令
tar zxf helm-v3.4.1-linux-amd64.tar.gz    
 mv linux-amd64/helm /usr/local/bin/
chmod +x /usr/local/bin/helm

2.自动补全命令设置：

#设置命令自动补全
echo 'source <(helm completion bash)' >> /etc/profile
. /etc/profile    #重载环境变量

3.配置helm仓库

#查看其仓库信息
helm repo list
NAME      URL                                             
stable    https://kubernetes-charts.storage.googleapis.com
#如上，默认是Google，在国外，速度特别慢
local     http://127.0.0.1:8879/charts

** 4.更新仓库**

#执行下面命令，更改为国内阿里云的仓库
helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

5.查看结果

#再次查看，可以发现更改生效了
helm repo list

6. 结果

NAME      URL                                                   
stable    https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
local     http://127.0.0.1:8879/charts

7. 更新helm仓库

helm repo update

** 8.查看信息**

helm version

9.结果

查看helm版本信息，必须保证可以查看出来client和server，helm才可正常使用


Client: &version.Version{SemVer:"v3.4.1", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v3.4.1", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

10.测试

helm search mysql      #搜索MySQL
#查看到的是charts包文件，查出来的版本是helm的Charts包的版本

#查看其详细信息
helm inspect stable/mysql 

#下载搜索到的包到本地   
helm fetch stable/mysql  
  
#在线安装这个MySQL    
helm install stable/mysql

3.2 Chart

3.2.1 Chart 基本介绍

Chart 是 Helm 的应用打包格式。是创建Kubernetes应用实例的信息集合

Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。由一系列文件组成，这些文件描述了 Kubernetes 部署应用时所需要的资源

比如:

Service

Deployment

PersistentVolumeClaim

Secret

ConfigMap

我们可以在部署应用的时候自定义应用程序的一些 Metadata，以便于应用程序的分发。

Chart可以很简单：例如，只用于部署一个服务，比如 Memcached。

Chart 也可以很复杂：例如，部署整个应用，比如包含 HTTP Servers、 Database、消息中间件、cache 等。

Chart 将这些文件放置在预定义的目录结构中，通常整个 chart 被打成 tar 包，而且标注上版本信息，便于 Helm 部署。

3.2.2 Chart目录结构

Chart.yaml : chart 的描述文件, 包含版本信息, 名称等.

Chart.lock : chart 依赖的版本信息. ( apiVersion: v2 )

values.yaml : 存储 chart 所需要的默认配置，用于配置 templates/ 目录下的模板文件使用的变量.

values.schema.json : 一个使用JSON结构的 values.yaml 文件，用于校检 values.yaml 的完整性.

charts : chart 所依赖的其他 chart，依赖包的存储目录.

README : 说明文件.

LICENSE : 版权信息文件.

crd : 自定义资源的定义，存放 CRD 资源的文件的目录.

templates : 模板文件存放目录，chart 模板文件，引入变量值后可以生成用于 Kubernetes 的 manifest 文件- NOTES.txt : 模板须知/说明文件. helm install 成功后会显示此文件内容到屏幕.- deployment.yaml : kubernetes 资源文件. ( 所有类型的 kubernetes 资源文件都存放于 templates 目录下 )- _helpers.tpl : 以 _ 开头的文件, 可以被其他模板引用.

Chart.yaml文件结构与说明：

apiVersion:             # chart API 版本信息, 通常是 "v1" (必须)
name:                     # chart 的名称 (必须)
version:                 # chart 包的版本 (必须)
kubeVersion:             # 指定 Kubernetes 版本 (可选)
type:                     # chart类型 （可选）
description:             # 对项目的描述 (可选)
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:                 # 维护者的个人主页
engine: gotpl             # 模板引擎的名称（可选，默认为 gotpl）
icon:                     # （可选）指定 chart 图标的 SVG 或 PNG 图像的 URL
appVersion:             # 应用程序包含的版本
deprecated:             # （可选，使用布尔值）该 chart 是否被废弃
annotations:
  example:                 # 按名称输入的批注列表 （可选）.

在同一个集群中，一个Charts可以使用不同的config重复安装多次，每次安装都会创建一个新的Release。

其他Chart相关内容，后面会写专门文章介绍

3.3 Repoistory

chart Repoistory是一个可用来存储index.yaml与打包的chart文件的HTTP server。

可以理解为是存放chart的仓库，类似于docker的镜像仓库。

当要分享chart时，需要上传chart文件到chart仓库，任何一个能够提供yaml与tar文件的HTTP server都可以当作chart仓库，比如自己的web服务器。

官方的chart仓库由kubernetes Charts维护，helm允许创建私有的chart仓库。

3.4 Config

应用程序实例化安装时运行使用的配置信息；

3.5 Release

chart的实例化，将chart安装到k8s上，就叫做生成一个release。

如果把 chart 比作程序源码的话，那么 release 则可以看做是程序运行时的进程。

chart 是用户可直接感知的对象（其表现形式就是 .tgz 格式的压缩包）

release 比较抽象，它是专属于 helm 的一个逻辑概念，用来标识在 k8s 中运行的一组资源。有了 release，helm 在操作 k8s 时，就再也不用逐个管理资源，而可以将一组相关的资源当做一个整体来操作，比如删除或升级。

4.投票

标签： kubernetes 容器云原生

本文转载自: https://blog.csdn.net/weixin_36755535/article/details/128191589
版权归原作者 颜淡慕潇 所有，如有侵权，请联系我们删除。