Kubernetes:Helm の概念・用語や周辺知識を整理する

Kubernetes:Helm の概念・用語や周辺知識を整理する

Helm について #

名称の由来 #

  • Kubernetes(クバネティス):ギリシャ語で「航海長」「水先案内人」の意味。
  • Helm(ヘルム):船の「舵(かじ)」の意味。
  • Chart(チャート):船の「航海図」の意味。

Helm ってなに? #

Helm は Kubernetes のパッケージマネージャ。Debian(Linux)の apt や Node.js の npm のようなもの。

Helm ではパッケージのことを Chart と呼ぶ。

helm install my-grafana oci://ghcr.io/grafana-community/helm-charts/grafana

このコマンドを実行すると、Helm は ghcr.io/grafana-community/helm-charts リポジトリにある grafana という Chart を Kubernetes クラスタにリリースする。作成するリリース名は my-grafana で、リリース名は Helm が管理する Kubernetes リソースの名前空間になる。

このようにインストールしたリソースのステータスを確認するには、次のコマンドを実行する。

helm status my-grafana

Helm リポジトリとは #

Chart を配布するためのリポジトリ。

たとえば Docker のエコシステムでは、Docker Hub(https://hub.docker.com/)が公式の Docker イメージリポジトリとして機能している。

Helm では公式となるような中心リポジトリは存在しない。ただし、どのようなリポジトリがありそこにどのような Chart があるのかが Artifact Hub で検索できる(https://artifacthub.io/packages/search)。

Helm Chart(チャート)とは #

Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.

https://helm.sh/docs/topics/charts/

Chart は Kubernetes のリソース定義の集合。

ここで Kubernetes リソースとは、Deployment、Service、ConfigMap、Secret、Pod などの総称のこと。Kubernetes では、Deployment、Pod などの定義をリソースタイプと呼び、そこから作成される実体をリソースまたはオブジェクトと呼ぶ。

チャートは、Kubernetes リソースを作成するための定義を、再配布・再利用可能な形でまとめたものである。その中心はマニフェストのテンプレートである。

チャートの利用者は、チャートのテンプレートに値を注入して最終的な Kubernetes マニフェストを生成し、Kubernetes クラスタに適用することで、リソースを作成する。

例えばチャートで以下のように定義されている場合、

spec:
  replicas: { { .Values.replicaCount } }

チャートを利用してリソースを作成する際に値を設定すると、

helm install my-app ./my-chart --set replicaCount=3

最終的に次の Kubernetes マニフェストとしてリソースが作成される

spec:
  replicas: 3

Helm Release(リリース)とは #

Helm でのリリースとは、Kubernetes クラスタに作成された、チャートの特定のインスタンスのこと。

  • 各リリースは一意の名前を持つ。
  • リリースの状態(インストール済み、アップグレード済み、削除済みなど)が記録されている。ロールバックも可能。
  • 同じチャートから作成された異なるリリースは異なる設定を持つことができる。

Helm で作成されたリリースの情報は Kubernetes クラスタに Secret として保存される仕組み。

Helm install 時の処理の流れ #

helm install my-grafana oci://ghcr.io/grafana-community/helm-charts/grafana を実行した場合の処理の流れは次のようになる。

Chart のリポジトリ
│ Chart を取得
v
helm install を実行したマシン
│ テンプレートから Kubernetes マニフェストを生成
│ kube-apiserver に対してリソース作成を指示
v
Kubernetes クラスタの kube-apiserver
v
Scheduler
v
Pod などのリソースが起動

補足:Helm バージョン2までは「Tiller」という Helm 専用の Pod を Kubernetes クラスタ内に作成しておき、Helm install コマンドを実行したマシンから Tiller にリクエストを送信して、Tiller が Kubernetes クラスタにリソース作成を指示する仕組みだった。バージョン3以降 Tilter は廃止され、Helm install コマンドを実行したマシンから直接 kube-apiserver にリソース作成を指示する仕組みに変更された。

Helm の周辺知識 #

Custom Resource(カスタムリソース)とは #

Kubernetes リソースとは、Deployment、Service、ConfigMap、Secret、Pod などの総称のこと。Kubernetes ではこれらの定義をリソースタイプと呼び、そこから作成される実体をリソースまたはオブジェクトと呼ぶ。

「CRD(Custom Resource Definition)」とは、Kubernetes に独自のリソースタイプを追加するための仕組み。CRD によって作成されたリソースを「CR(Custom Resource)」と呼ぶ。

カスタムリソースそれ自身は、単純に構造化データを格納、取り出す機能を提供している。カスタムリソースはカスタムコントローラ(Custom Controller)と組み合わせることで動作を提供する。コントローラは、カスタムリソースの構造化データをユーザーが指定したあるべき状態と解釈し、その状態を維持するよう管理し続ける。

On their own, custom resources let you store and retrieve structured data. When you combine a custom resource with a custom controller, custom resources provide a true declarative API.

The Kubernetes controller keeps the current state of Kubernetes objects in sync with your declared desired state.

https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

なお、カスタムリソースを定義する方法は2つある。1つが CRD で、もう1つが API Aggregation(AA、API アグリゲーション) である。CRD はシンプルで、プログラミングなしに作成可能なことがメリット。AA は定義が複雑だが、より詳細な制御が可能である。

Helm での CRD の扱いの注意点 #

参照:https://helm.sh/docs/chart_best_practices/custom_resource_definitions/

Helm で CRD を配布するメソッドは2つある。

  • 1.Chart に CRD を内包させるメソッド
    • Chart に crds/ ディレクトリを作成し、そこに CRD を含める。
    • こうすると、helm install を実行したとき、Helm は最初に crds/ 内の CRD を登録し、その後 CRD のカスタムリソースを作成する動きとなる。
    • この方法は1回のコマンドで CRD とアプリケーションを導入できるため導入が簡単。
  • 2.CRD を専用の別の Chart に分けるメソッド
    • CRD とそれを利用する本体を別々の Chart として管理する。
    • CRD を先に helm install し、その後本体を helm install する。つまり2回コマンドを実行する。
    • CRD 内包メソッドと比べると導入は手間だが、

Helm で CRD をアップデートするときの注意点

どちらの方法で導入しても、helm upgrade では CRD は自動ではアップグレードされない。この挙動を知っておくことが重要。

CRD は Kubernetes に新しいリソースの種類を追加するもの。CRD のスキーマを変更することで、すでに作成されているカスタムリソースが読み込めなくなる可能性がある。そのため Helm は CRD のアップグレードは自動では行わないように設計されている。

CRD の更新を伴う Chart のアップグレードを行う場合は、以下のような流れになる。

  1. kubectl コマンドなどで CRD を先にアップグレードする。
  2. その後、helm upgrade で本体のアップグレードを行う。

あるいは、それが可能であれば一度 CRD および CR を削除してから、CRD および CR を新しいバージョンで再作成する方法がシンプル。