Kubernetes基礎 #4 - Namespaces & Helm

DevOps

Last Edited: 3/30/2025

このブログ記事では、KubernetesにおけるnamespacesとHelmについて紹介します。

DevOps

これまでの記事では、Kubernetesクラスターをセットアップするための多くの基本的なコンポーネントとリソースについて説明してきました。 これらのクラスターの多数のリソースを管理することは、一見簡単に見えるかもしれませんが、 特に異なる環境向けの同じアプリケーションの複数バージョンを扱う場合や、複数の開発者が同じクラスターで作業している場合には面倒になることがあります。 そこでこの記事では、クラスターのリソースを明確かつ効率的に整理・管理する方法をいくつか紹介します。

Namespaces

KubernetesのNamespaces(名前空間)は、クラスター内の仮想クラスターのようなもので、様々なリソースを整理するために使用されます。 デフォルトで4つの名前空間が設定されており、kubectl get namespaceを実行すると表示されます：kube-system（マスターやkubectlなどのシステムプロセス用）、 kube-public（コンフィグマップなどクラスターに関する公開情報を含む）、kube-node-lease（ノードに関する情報を含む）、 そしてdefault（ユーザーが作成したリソースのデフォルト名前空間）。リソースを作成する際はデフォルトでdefault名前空間に作成されます。

frontend-config.yaml
## frontend-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: frontend-config
  namespace: my-new-namespace
data:
  backend-url: backend-service

新しい名前空間を作成するには、kubectl create namespace <namespace-name>コマンドを使用するか、 YAMLコンフィグファイルのmetadataセクションにnamespaceフィールドを指定します。 特定の名前空間内のリソースを表示するには、kubectl getコマンドに-n <namespace-name>を追加します。 名前空間を使用すると、リソースタイプ（ロギング、モニタリング、データベースなど）を分離したり、異なるチーム用にリソースを分離したり、 開発環境と本番環境のクラスター間でリソースを共有したりすることができます。明示的に設定しない限り、 リソースは名前空間間で共有できませんが、サービスは例外で、<service-name>.<namespace-name>を介してアクセスできます。

Helm

開発者チームとクラスターで作業する場合、すべてのチームメンバーがビルド設定を簡単に複製し、一貫して適用できるようにすることが重要です。 GitHubでYAMLファイルを共有することは良い出発点ですが、すべてのチームメンバーが同じ方法でリソースを適用することを確保するのは、 特に多くのリソースや異なるバージョン・ステージがある場合には面倒になります。そこでパッケージマネージャーであるHelmで、 複数のYAMLファイルをHelmチャートにバンドルし、簡単な配布、デプロイ、削除を可能にできます。チャートには、 環境に基づいてデプロイメントをカスタマイズするためのテンプレート機能も含まれています。

Helmを始めるには、homebrewを使用してインストールする（brew install helm）か、公式ドキュメント（記事の最後に引用）のインストールスクリプトに従ってインストールできます。 Artifact Hub（公式ハブ）でチャートを検索するには、そのウェブサイトを利用するか、helm search hub <name>を使用します。 helm repo add <name> <url>を使用して、ローカルクライアントにリポジトリを追加できます。 Helmチャートをインストールするには、helm install <release-name> <chart-name>を使用できます。 デプロイメントを削除するには、単にhelm uninstall <release-name>を実行します。 既存のリリースを確認するには、--allフラグを付けてhelm listを使用できます。

chart-name/
├── Chart.yaml
├── values.yaml
├── charts/
├── templates/
│   ├── resource.yaml
└── └── ... other resources

自分自身のHelmチャートを作成することもでき、典型的なファイル構造は上記のようになります。Chart.yamlファイルにはチャートの説明とメタデータが含まれ、 values.yamlにはテンプレートで使用されるデフォルト値が含まれ、chartsディレクトリにはチャートの依存関係が含まれ、 templatesディレクトリにはすべてのリソーステンプレートが含まれ、NOTES.txtはhelm install中に表示されるテキストが含まれます。 Chart.yamlとvalues.yamlの値は、{{ .Chart.Version }}や{{ .Values.<key> }}のような構文を使用してテンプレート内からアクセスできます。 {{ .Release.Name }}などのリリース情報にもアクセスできます。

# In Chart.yaml
apiVersion: v2
name: chart-name
version: 0.0.1
# ...bunch of other optional fields
 
# In values.yaml
config:
  mypokemon: "Pikachu"
# ...other values
 
# In templates/config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  mypokemon: {{ .Values.config.mypokemon }}

パッケージ化の準備として、helm lintコマンドでチャートが適切に形成されているかを確認できます。 チャートのパッケージ化の準備ができたら、helm package <chart-name>を実行すると、<chart-name>-<chart-version>.tgzが作成されます。 このファイルは、helm push <chart-name> <remote>を使用するか、GitHubを使用してウェブサイト経由でチャートリポジトリにプッシュできます。 values.yamlで定義されたものとは異なる値のセットを使用するには、my-values.yamlなどの希望する値を含む別のYAMLファイルを作成し、 チャートをインストールする際に--values=my-values.yamlフラグを使用できます。 helm upgradeとhelm rollbackを使用してリリースをアップグレードおよびロールバックすることも可能です。

Helmチャートは、テンプレート機能を備えたリソースのバンドル、公開または非公開メンバーへのビルドの配布、 既存のチャートを活用してクラスターに有用なサードパーティソフトウェアを迅速にデプロイする（将来取り上げる予定のモニタリング用Prometheusの実行など）のに役立ちます。 この記事では、柔軟なビルドのためのテンプレート関数、その他のHelmコマンドとフラグ、組み込みオブジェクトなど、多くの詳細が省略されています。 詳細については、記事の最後に引用されている公式ドキュメントで詳しく学ぶことができます。

結論

この記事では、KubernetesのNamespacesとHelmの基本について説明しました。 これらはリソースとクラスターを整理し、クラスターでの共同作業を容易にするのに役立つツールです。 名前空間とHelmチャートを同時に使用して、明確な整理と管理を行うこともできます。 例えば、新しくインストールしたHelmチャートをテストするための環境を分離するために名前空間を使用したり、 チャート内でリソースを名前空間で整理したりすることが考えられます。

リソース

TOPに戻る↑