20230602 深入剖析Kubernetes学习指南

笔者近期有接触快速拉起k8s应用的需求，因此特开一篇博客记录一下helm学习的相关指南。

Helm安装

参考：https://helm.sh/zh/docs/intro/install/

Helm一键安装

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Helm使用

理解Helm包的概念

在 Helm 中，Chart 是一个预先定义的、可配置的 Kubernetes 资源包。它是一组文件和模板，用于描述一组相关的 Kubernetes 资源，例如部署、服务和配置。Chart 的目的是简化 Kubernetes 应用程序的部署和管理，使其更加可重用和可共享。

以下是关于 Chart 包的一些关键概念：

模板化：Chart 中的文件（通常是 YAML 文件）使用 Go 模板语言编写，这使得 Chart 可以根据用户提供的值生成特定于环境的 Kubernetes 资源清单。这意味着，您可以使用相同的 Chart 在不同的环境中部署相同的应用程序，只需更改配置值即可。
可配置：Chart 包含一个名为 values.yaml 的文件，其中包含用户可以自定义的默认配置值。用户可以在部署过程中覆盖这些值，以适应特定环境的需求。这使得 Chart 可以在不修改其源代码的情况下进行定制。
版本控制：Chart 可以具有版本号，这有助于跟踪和管理应用程序的不同版本。当您更新 Chart 时，可以使用新的版本号来标识更改。这使得回滚到以前的版本变得容易。
依赖管理：Chart 可以依赖于其他 Chart，这有助于组织和管理复杂的应用程序。例如，一个应用程序可能需要数据库和缓存服务。您可以将这些服务作为依赖项添加到应用程序的 Chart 中，Helm 将负责部署和管理它们。
存储库：Chart 可以托管在 Helm 存储库中，以方便共享和分发。Helm 存储库是一个 HTTP 服务器，用于存储和提供 Chart 包。用户可以从存储库中搜索、安装和更新 Chart。

总之，Helm Chart 是一个用于简化 Kubernetes 应用程序部署和管理的工具。它们提供了一种模板化、可配置、可版本控制的方法来描述一组相关的 Kubernetes 资源。通过使用 Chart，您可以更轻松地在不同环境中部署和共享应用程序。

创建Helm应用

helm create nginx

nginx/
├── .helmignore             # 文件，包含在打包 Chart 时要忽略的文件和目录模式
├── Chart.yaml              # 文件，包含 Chart 的元数据，如名称、描述、版本等
├── values.yaml             # 文件，包含 Chart 的默认配置值
├── templates/              # 目录，包含 Kubernetes 资源模板
│   ├── deployment.yaml     # 文件，包含 Deployment 资源模板
│   ├── service.yaml        # 文件，包含 Service 资源模板
│   ├── ingress.yaml        # 文件，包含 Ingress 资源模板 (可选)
│   ├── _helpers.tpl        # 文件，包含模板辅助函数
│   └── ...                 # 更多模板文件，如 ConfigMap、Secret 等
└── charts/                 # 目录，包含 Chart 的依赖 Chart（子 Chart）(可选)

其中 templates/ 目录下deployment.yaml 为应用模版，它们会根据 values.yaml 文件中的配置值生成对应的 Kubernetes 资源清单。您可以通过修改 values.yaml 文件来自定义 Chart 的配置，或者在部署时提供自定义的值。

#安装命令
helm install -n nginx  findmynginx -f values.yaml ./
#渲染命令 
helm template --dry-run -n nginx  findmynginx -f values.yaml ./
#升级命令
helm upgrade --install -n nginx  findmynginx -f values.yaml ./

污点和零容忍

由于业务特殊性且需要支持高可用，修改nodeSelector配置方案为k8s通过NodeLabel去选择合适的母机进行部署，因此需要设置污点和反亲和性，参照k8s官方文档污点和容忍度

        ...
      nodeSelector:
        kubernetes.io/hostname: {{ .Values.ClusterIp }} #当前指定节点方式为ClusterIp指定
      ...

节点亲和性是 Pod 的一种属性，它使 Pod 被吸引到一类特定的节点（这可能出于一种偏好，也可能是硬性要求）。污点（Taint）则相反——它使节点能够排斥一类特定的 Pod。

容忍度（Toleration）是应用于 Pod 上的。容忍度允许调度器调度带有对应污点的 Pod。容忍度允许调度但并不保证调度：作为其功能的一部分，调度器也会评估其他参数。

污点和容忍度（Toleration）相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。

    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodelabel
                operator: In
                values:
                - {{ .Values.NodeLabel }}
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: k8s-app
                  operator: In
                  values:
                  - {{ .Values.App }}-{{ .Values.City }}-{{ .Values.Type }}-{{ .Values.Redun }}
              topologyKey: kubernetes.io/hostname

nodeAffinity表示Pod 的调度需要满足 requiredDuringSchedulingIgnoredDuringExecution 规则。这意味着在调度时必须满足这些规则，但在执行期间，即使这些规则不再满足，Pod 也不会被驱逐。

labelSelector 的 matchExpressions 配置要求节点具有名为 nodelabel 的标签，其值必须在 values 列表中（即等于 {{ .Values.NodeLabel }}）

podAntiAffinity 配置表示在调度时，尽量避免将具有相同 k8s-app 标签的 Pod 调度到同一节点上。具体来说：

labelSelector 的 matchExpressions 配置要求 Pod 具有名为 k8s-app 的标签，其值必须在 values 列表中（即等于 netq-{{ .Values.City }}-{{ .Values.Type }}-{{ .Values.Redun }}）。

topologyKey 设置为 kubernetes.io/hostname，表示不同的 Pod 应尽量分布在具有不同主机名的节点上。

weight 设置为 100，表示这个规则的优先级较高。

目录CONTENT