動画出典：Station B「k8s（Kubernetes）クラスターオーケストレーションツールhelm3実践チュートリアル」
学習中に先生の授業内容やテストノートを整理してみんなで共有してください。違反しているものは削除されます。よろしくお願いします。
概要の投稿を添付します: k8s クラスター オーケストレーション ツール helm3 実践チュートリアル | 概要
1 ヘルムおよび関連コンポーネントとは
- 環境整備
k8s クラスターを準備する必要がありますが、Helm は主に k8s クラスターのパッケージ マネージャーであり、主に Helm 内の各種チャート パッケージを管理するために使用されます。
- 従来のサービスを k8s クラスターにデプロイするプロセス
コードをプル --> パッケージ化してコンパイル --> イメージをビルド --> 関連するデプロイメント yaml ファイル (デプロイメント、サービス、イングレスなど) を多数準備 --> kubectl apply で k8s クラスターにデプロイ
- 従来の導入によって生じる問題
1) 参照の増加に伴い、多数の yaml ファイルを維持する必要がある
2) 一連の yaml ファイルに基づいて複数の環境を作成することはできないため、手動で変更する必要があります。
例: 一般的な環境は、開発環境、実稼働前環境、および実稼働環境に分かれています。開発環境をデプロイした後、後で実稼働前環境と実稼働環境をデプロイした後、2 つのセットをコピーして手動で変更する必要があります。
- ヘルムとは何ですか
Helm は、Kubernetes アプリケーションを簡単に検出、共有、構築できる Kubernetes 用のパッケージ管理ツールです。
helm は k8s のパッケージ マネージャーであり、centos システムの yum ツールに相当します。サービスに関連するすべてのリソース情報をチャート パッケージに統合でき、リソースのセットを使用して複数の環境に公開できます。アプリケーションは、 のすべてのリソースとデプロイメント情報にすることができます。
Linux の rpm パッケージ マネージャー (yum/apt など) と同様に、以前にパッケージ化した yaml ファイルを kubernetes に簡単にデプロイできます。
- ヘルムのコンポーネント
1) Chart: Helm の統合チャート パッケージであり、yum の rpm パッケージや apt の dpkg ファイルと同様に、すべてのアプリケーションの kubernetes 宣言テンプレートが含まれています。
理解：
helm は、パッケージ化されたアプリケーションを k8s にデプロイし、それを Charts に構築します。これらのチャートには、すべての事前構成されたアプリケーション リソースとすべてのバージョンが、管理しやすい 1 つのパッケージに含まれています。
Helm は kubernetes リソース (デプロイ、サービス、イングレスなど) をチャートにパッケージ化し、チャートはチャート ウェアハウスに保存されます。チャートウェアハウスを通じてチャートを保存および共有するために使用できます
2) Helm クライアント: Helm のクライアント コンポーネント。k8s apiserver との通信を担当します。
3) リポジトリ: yum ウェアハウスや Docker ウェアハウスに似た、チャート パッケージを公開および保存するためのウェアハウス
4) リリース: チャート パッケージとともにデプロイされたインスタンス。チャートを通じて k8s にデプロイされたアプリケーションは、固有のリリースを生成します。同じチャートが複数回デプロイされる場合、複数のリリースが生成されます。
理解：
これらの yaml をデプロイした後、デプロイメント時のバージョンも記録し、リリース バージョンのステータスを維持します。Release のインスタンスを通じて、ポッドやデプロイメントなどのリソースの作成に役立ちます。
- Helm3 と Helm2 の違い
1) Helm3 は Tiler コンポーネントを削除します。helm2 では、helm クライアントと k8s は Tiller コンポーネントと k8s を介して通信します。Helm3 は Tiller コンポーネントを削除し、kubeconfig ファイルを直接使用して k8s の apiserver と通信します。
2) リリースコマンドの変更を削除します。
#helm delete リリース名 --purge ------------>> helm uninstall リリース名
3) チャート情報の表示コマンドの変更
#helm Inspection リリース名 ------------>> Helm show リリース名
4) プルチャートパッケージコマンドの変更
#helm fetch チャート名 ------------>> helm pull チャート名
5) helm3 でリリース名を指定する必要があります。ランダムな名前を生成する必要がある場合は、オプション --generate-name を追加する必要があります。helm2 でリリース名が指定されていない場合は、ランダムな名前を自動的に生成できます
#helm install ./mychart --generate-name
2 Helm3 のインストールとチャートのディレクトリ構造
- Helm3 をバイナリ モードでインストールする
#kubectl get node
NAME STATUS ROLES AGE VERSION
m1 Ready control-plane,master 257d v1.20.4
m2 Ready control-plane,master 257d v1.20.4
m3 Ready control-plane,master 257d v1.20.4
n1 Ready <none> 257d v1.20.4
# wget https://get.helm.sh/helm-v3.5.2-linux-amd64.tar.gz
# ls helm-v3.5.2-linux-amd64.tar.gz
helm-v3.5.2-inux-amd64.ta.gd
# tar -zxf helm-v3.5.2-linux-amd64.tar.gz
# ls
helm-v3.5.2-linux-amd64.tar.gz linux-amd64
# ls linux-amd64/
helm LICENSE README.md
# mv linux-amd64/helm /usr/local/bin/
# helm version
version.BuildInfo{Version:"v3.5.2", GitCommit:"167aac70832d3a384f65f9745335e9fb40169dc2", GitTreeState:"dirty", GoVersion:"go1.15.7"}- チャートのディレクトリ構造
#helm create my chart #创建一个chart， 指定chart名：mychart
#tree mychart/
mychart/ #chart包的名称
├── charts #存放子chart的目录， 目录里存放这个chart依赖的所有子chart Chart.yaml
├── Chart.yaml #保存chart的基本信息， 包括名字、描述信息及版本等， 这个变量文件都可以被templates目录下文件所引用
├── templates #模板文件目录， 目录里面存放所有yaml模板文件， 包含了所有部署应用的yaml文件
│ ├── deployment.yaml #创建deployment对象的模板文件
│ ├── _helpers.tpl #放置模板助手的文件， 可以在整个chart中重复使用， 是放一些templates目录下这些yaml都有可能会用的一些模板
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── NOTES.txt #存放提示信息的文件， 介绍chart帮助信息， helm install部署后展示给用户.如何使用chart等， 是部署chart后给用户的提示信息
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests #用于测试的文件， 测试完部署完chart后， 如web， 做一个链接， 看看你是否部署正常
│ └── test-connection.yaml
└── values.yaml #用于渲染模板的文件(变量文件，定义变量的值)定义templates目录下的yaml文件可能引用到的变量
#values.yaml用于存储templates目录中模板文件中用到变量的值， 这些变量定义都是为了让templates目录下yaml引用- Chart.yaml ファイルのフィールドの説明
# cat Chart.yaml
apiVersion: v2
name: mychart
description: A Helm chart for Kubernetes
# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application
# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0
# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.16.0"