Helm が kubeconfig でクラスターを見つける仕組み

Helmは独自のクラスター接続情報を作りません。kubectlがすでに使っているまったく同じ kubeconfig を再利用するため、kubectlが動作すればHelmも動作します。

デフォルトでは、設定ファイルは ~/.kube/config にあります。そこにはクラスターのエンドポイント、ユーザーの認証情報、それらを組み合わせるコンテキストが含まれています。

kubeconfigでは、clusters（サーバーURL）、ユーザー（認証情報）、そしてクラスター、ユーザー、名前空間を組み合わせるコンテキストを定義します。

Helmは current-context、つまりファイル内でアクティブとして指定されているコンテキストに対して動作します。コマンドを実行する前に、接続先のクラスターを確認してください。

kubectl config use-context でクラスターを切り替えます。Helmもすぐにそれに従うため、開発環境、ステージング環境、本番環境の間で作業を移すときに使います。

別のクラスターで1つのコマンドだけ実行したい場合は、--kube-context フラグを使って、アクティブなコンテキストを変更せずに対象を指定できます。

KUBECONFIG 環境変数を使うと、Helmが別の設定ファイルを参照するようにしたり、コロン区切りのリストで複数のファイルを統合したりできます。

Helmではリリースを namespace 単位で管理します。-nを指定しない場合はコンテキストのデフォルトが使われるため、誤った名前空間で操作しないよう、名前空間を明示してください。

クラウドクラスターはkubeconfigを自動的に作成します。aws eks update-kubeconfig のようなコマンドを実行すると、適切な認証情報を持つコンテキストが追加され、Helmが接続できるようになります。

接続可能なすべてのクラスターを確認するには、kubectl config get-contexts を実行します。アスタリスクが付いた行が、現在Helmの操作対象となるコンテキストです。

kubectl get nodes を実行すれば、設定を使って稼働中のクラスターに接続できることを簡単に確認できます。kubectlでノードが表示されれば、Helmも同じクラスターに接続できます。

Helmはkubectlの kubeconfig を利用します。現在のコンテキストを把握し、use-contextで切り替え、デプロイ前には必ず名前空間を確認してください。✅