应用包管理-Helm

傲~柏

已于 2024-08-24 17:59:12 修改

阅读量516

点赞数 17

文章标签： k8s 云原生运维

于 2024-08-16 17:26:00 首次发布

本文链接：https://blog.csdn.net/qq_45417574/article/details/141254219

版权

文章目录

引言

引言

对于K8s来说，应用资源配置可以定义为K8s API对象，包括Deployment，Namespace，Service， PV（Persistent Volumes）和PVC（PersistentVolumeClaims）等等。通常一个应用的部署会涉及很多资源的共同协作，用户会定义这些API对象到一系列Yaml文件中，然后通过kubectl来逐一进行部署。

如果说需要部署的是单一、少数服务的应用，那么完全可以使用yaml文件的方式，这样会很简单。但是在实际的项目当中，微服务的数量基本不可能是一个，可能是几十个，如果说再用yaml文件的部署方式，那就意味着需要编写几十个yaml文件，这就会导致数量多、维护难等诸多问题。，特别是微服务的项目，如果每个服务部署都需要使用kubectl apply依次执行，这将是一件很痛苦的事情，这个时候，使用Helm是一个很不错的选择。

Helm是Kubernetes的包管理器。包管理器类似于我们在Ubuntu中使用的apt、Centos中使用的yum或者Python中的pip一样，能快速查找、下载和安装软件包。helm通过打包的方式，支持发布的版本管理和控制，很大程度上简化了Kubernetes应用的部署和管理。

Helm具备以下功能：
简化部署：Helm允许使用单个命令轻松部署和管理应用程序，从而简化了整个部署过程；
高度可配置：Helm Charts提供了高度可配置的选项，可以轻松自定义和修改应用程序的部署配置；
版本控制：Helm允许管理应用程序的多个版本，从而轻松实现版本控制和回滚；
模板化：Helm Charts使用YAML模板来定义Kubernetes对象的配置，从而简化了配置过程，并提高了可重复性和可扩展性；
应用程序库：Helm具有应用程序库的概念，可以轻松地共享和重用Helm Charts，从而简化了多个应用程序的部署和管理；
插件系统：Helm拥有一个强大的插件系统，允许您扩展和定制Helm的功能，以满足特定的需求和要求。

一、helm的工作流程

以下是helm的工作流程（注意：这里使用的是helm的v3版本，该版本没有tiller，并使用了更加简单和灵活的架构，直接通过kubeconfig链接apiserver，简化安全模块，降低了用户的使用壁垒）：

如上图所示，Helm的工作流程如下：
1.开发者首先创建并编辑chart的配置；
2.接着打包并发布至helm的仓库repository；
3.当管理员会用helm命令安装时，相关的依赖会从仓库下载；
4.接着helm会根据下载的配置部署资源至kubernetes；

helm 组件及相关术语

在使用helm的过程中，需要理解如下的三个核心的概念：

概念	描述
chart	Helm的软件包，采用tar格式，其中包含了运行一个应用所需要的镜像、依赖和资源定义等，还可能包含Kubernetes集群中的服务定义，类似Homebrew中的formula、APT的dpkg或者Yum的rpm文件
repository	用于存储和管理chart。repository可以包含多个chart，用户可以从这个从这些存储库中选取需要的chart进行部署。helm支持多种类型的repository，包括官方的helm hub以及用户自定义的私有仓库等
release	release是chart在k8s急群中的部署实例。每个chart可以部署一个或多个release。release是chart在急群中的具体的运行实例，他代表了chart在集群中的状态和配置

helm的使用

安装helm

首先需要在本地机器或Kubernetes集群上安装Helm。可以从Helm官方网站下载适合自己平台的二进制文件，或使用包管理器安装Helm，安装教程参考官网 https://helm.sh

创建chart

使用helm create命令创建一个新的chart，chart目录包含描述应用程序的文件和目录，包括chart.yaml、templates目录等；
在生成的目录中有以下几个部分：

文件	含义
charts	一个普通的空文件，一般也不会写入内容
Chart.yaml	当前chart属性的配置信息
templates	自己定义的yaml文件存于此
values.yaml	定义yaml文件的全局配置

例如：在本地机器上使用helm create命令创建一个名为wordpress的chart：

$ helm create wordpress
Creating wordpress

创建/编辑chart配置

使用编辑器编辑chart配置文件，包括chart.yaml和values.yaml

chart.yaml

chart.yaml的模板及注释如下：

apiVersion: chart API 版本 （必需）  #必须有
name: chart名称 （必需）     # 必须有 
version: 语义化2 版本（必需） # 必须有

kubeVersion: 兼容Kubernetes版本的语义化版本（可选）
description: 一句话对这个项目的描述（可选）
type: chart类型 （可选）
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: 维护者URL （每个维护者可选）

icon: 用做icon的SVG或PNG图片URL （可选）
appVersion: 包含的应用版本（可选）。不需要是语义化，建议使用引号
deprecated: 不被推荐的chart （可选，布尔值）
annotations:
  example: 按名称输入的批注列表 （可选）.

举例：

name: nginx-helm
apiVersion: v1
version: 1.0.0

values.yaml

values.yaml包含应用程序的默认配置值，例如：

image:
  repository: nginx
  tag: '1.19.8'

templates

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-helm-{{ .Values.image.repository }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-helm
  template:
    metadata:
      labels:
        app: nginx-helm
    spec:
      containers:
      - name: nginx-helm
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        ports:
        - containerPort: 80
          protocol: TCP

将chart配置编辑完成后，我们就可以通过helm命令将其进行打包、发布、安装、管理（更新、回滚）等一系列操作，感兴趣的可以自行实验，这里就不一一列举了

helm的常用操作命令汇总

距离一些常用操作命令，直接使用在这里插入代码片helm --help`即可查看

#查看仓库
helm repo list

#更新仓库
helm repo update

#删除仓库
helm repo remove 仓库名称

#搜索应用
helm search repo 名称

#安装应用
helm install 自定义应用名称 搜索出的结果名

#查看安装后的应用
helm list
helm status 应用名称	

#创建chart
helm create chart名称

heml的执行安装顺序

最后值得一提的是，helm的安装顺序侧面反映出资源的依赖关系需要被正确的处理，一下是helm的执行安装顺序：

Namespace #首先会创建Namespace，因为它为集群内的资源提供了一个逻辑上的隔离区域

NetworkPolicy #接下来会安装NetworkPolicy，用于定义如何允许或拒绝Pod之间的网络通信

ResourceQuota #设置资源使用量的硬性限制

LimitRange #为Pod或Container设置默认的请求/限制值

PodSecurityPolicy #helm3中可能会通过其他方式管理，因为psp在k8s中已被弃用

PodDisruptionBudget #用于指定在资源中断（如节点维护）期间可以安全的中断的Pod的数量

ServiceAccount #创建sa，用于Pod的身份认证

Secret #用于存储敏感信息，如密码、OAuth令牌和ssh密钥

SecretList  #它是secret的列表表示，但通常不是直接安装的对象，而是通过列表操作查看Secret

ConfigMap #ConfigMap用于存储配置数据，这些数据可以被Pod中的容器使用

StorageClass #定义了存储“类”

PersistentVolume #是急群中存储资源的抽象

PersistentVolumeClaim #是用户对pv的请求

CustomResourceDefinition #自定义资源定义，允许用户扩展kubernetes API存储和管理新的资源对象

ClusterRole、ClusterRoleList、ClusterRoleBinding、ClusterRoleBindingList #这些资源用于定义集群级别的角色、角色列表、
角色绑定、角色绑定列表（想了解BAC的相关知识可以看我关于RBAC的文章）

Role、RoleList、RoleBinding、RoleBindingList #与ClusterRole系列资源类似，但这些资源定义的是命名空间级别的角色和角色绑定

Service #定义pod之间的通信规则，允许一个pod访问领一个pod的端口

DaemonSet、Pod、ReplicationController、ReplicaSet、Deployment、HorizontalPodAutoscaler、StatefulSet、Job、CronJob：
#这些workload资源定义了pod的部署、扩展、自动缩放和计划任务等

Ingress：ingress提供了一种将集群外部流量路由到集群内部服务的方式

本章内容已完结，感谢浏览 (完结撒花~）