kubectl configを使用した複数Kubernetesクラスター管理ガイド

開発環境、ステージング環境、本番環境、または複数のクラウドにクラスターがある場合、複数のKubernetesクラスターを管理することは一般的です。リスクは単純です。コンテキストが明確でない場合、1つのコマンドが誤ったクラスターに影響を与える可能性があります。

このガイドでは、kubectl configを使用してコンテキストを確認し、クラスターを切り替え、名前空間を設定し、複数のkubeconfigファイルを整理する方法を説明します。

Kubeconfigファイルの理解

kubectl configコマンドに進む前に、kubeconfigファイルを理解することが重要です。このファイルには、クラスター、ユーザー、およびそれらを結び付けるコンテキストに関する情報が保存されています。kubectlはこのファイルを使用して認証し、操作するクラスターを指定します。デフォルトでは、kubectlは$HOME/.kube/configにあるkubeconfigファイルを探します。

このファイル内には、主に3つのセクションがあります。

clusters: Kubernetesクラスターを定義し、APIサーバーのエンドポイントと認証局を含みます。
users: クライアント証明書やトークンなどの認証情報を保存します。
contexts: クラスター、ユーザー、およびオプションで名前空間を関連付けます。コンテキストはこれらの設定をグループ化する便利な方法を提供し、kubectlが異なるクラスター/ユーザーの組み合わせを簡単に切り替えられるようにします。

`kubectl config`を使用したコンテキストの管理

コンテキストは、kubectlが異なるKubernetesクラスターへの接続を管理する主要な方法です。これらはショートカットとして機能し、1つのコマンドで切り替えることができます。

利用可能なコンテキストの表示

現在のkubeconfigファイル内のすべてのコンテキストを表示するには、次のコマンドを使用します。

kubectl config get-contexts

このコマンドは、各コンテキストに関連付けられたクラスター、ユーザー、名前空間とともにリストを出力します。現在アクティブなコンテキストはアスタリスク(*)でマークされます。

出力例:

CURRENT   NAME                 CLUSTER              AUTHINFO       NAMESPACE
*         my-dev-context       my-dev-cluster       dev-user       default
          my-prod-context      my-prod-cluster      prod-user      production
          staging-context      staging-cluster      staging-user   staging

現在のコンテキストの取得

現在使用しているコンテキストをすばやく確認するには、次のコマンドを実行します。

kubectl config current-context

これにより、アクティブなコンテキストの名前が出力されます。

コンテキストの切り替え

別のコンテキストに切り替えるのは簡単です。use-contextサブコマンドの後に、アクティブにしたいコンテキストの名前を指定します。

kubectl config use-context <context-name>

たとえば、上記の例からmy-prod-contextに切り替えるには、次のようにします。

kubectl config use-context my-prod-context

このコマンドを実行すると、後続のkubectlコマンドはmy-prod-contextで指定されたクラスターに送信されます。

コンテキストの設定

クラスターとユーザーに対して特定のコンテキストを設定することもできますが、必ずしも将来のデフォルトにする必要はありません。これは一時的な操作に便利です。

kubectl config set-context <context-name> --cluster=<cluster-name> --user=<user-name> --namespace=<namespace-name>

--namespaceを省略すると、クラスターのデフォルトの名前空間が使用されます。

クラスターとユーザーの管理

コンテキストは切り替えに使用されますが、コンテキストが参照するクラスターとユーザーの設定を直接管理することもできます。

クラスター情報の表示

設定されているすべてのクラスターを一覧表示するには、次のようにします。

kubectl config get-clusters

特定のクラスターの詳細を表示するには、次のようにします。

kubectl config view --minify -o jsonpath='{.clusters[?(@.name=="<cluster-name>")].cluster}'

<cluster-name>を実際のクラスター名に置き換えます。

ユーザー情報の表示

設定されているすべてのユーザーを一覧表示するには、次のようにします。

kubectl config get-users

設定の追加と変更

新しいクラスター、ユーザー、コンテキストを追加したり、既存のものを変更したりできます。

新しいクラスターの追加:

kubectl config set-cluster <cluster-name> --server=<api-server-url> --certificate-authority=<path-to-ca-file> --embed-certs=true

新しいユーザーの追加:

kubectl config set-credentials <user-name> --client-certificate=<path-to-cert-file> --client-key=<path-to-key-file> --embed-certs=true

新しいコンテキストの追加:

kubectl config set-context <context-name> --cluster=<cluster-name> --user=<user-name> --namespace=<namespace-name>

複数のKubeconfigファイルの管理

特に多くのクラスターや機密性の高い認証情報を扱う場合、セキュリティと整理のためにkubeconfigファイルを分離しておくことは良い習慣です。kubectlは、KUBECONFIG環境変数または--kubeconfigフラグを使用して複数のkubeconfigファイルを管理できます。

`KUBECONFIG`環境変数の使用

ロードするkubeconfigファイルのリストを指定できます。kubectlはこれらのファイルをマージします。同じ名前のクラスター、ユーザー、またはコンテキストが複数のファイルに存在する場合、マージの優先順位はKUBECONFIG内のファイルの順序に依存するため、予期しない事態を避けるために一意の名前を使用してください。

現在のシェルセッションでこの変数を設定するには、次のようにします。

export KUBECONFIG=~/.kube/config:~/.kube/config-dev:~/.kube/config-prod

これを永続的にするには、シェルのプロファイルファイル（例：~/.bashrc、~/.zshrc）にexport行を追加します。

`--kubeconfig`フラグの使用

または、単一のkubectlコマンドに対して特定のkubeconfigファイルを指定できます。

kubectl --kubeconfig=~/.kube/config-dev get pods

これは、1回限りのコマンドや、どのファイルが使用されているかを絶対に確認したい場合に便利です。

マルチクラスター管理のベストプラクティス

別々のファイルを使用する: 異なる環境（dev、staging、prod）やクラウドプロバイダーの設定を別々のkubeconfigファイル（例：config-dev、config-staging、config-prod）に保存します。
KUBECONFIGを活用する: シェルプロファイルでKUBECONFIG環境変数を設定し、手動でマージすることなく複数のファイルを簡単にマージおよび管理します。
わかりやすいコンテキスト名: 混乱を避けるために、コンテキストには明確でわかりやすい名前（例：aws-prod-us-east-1、gke-dev-eu-west-2）を使用します。
名前空間を意識する: 操作している名前空間に常に注意を払います。--namespaceフラグを使用するか、コンテキストに設定して正しい名前空間をターゲットにします。
定期的に監査する: コンテキストとクラスター設定を定期的に確認し、最新で安全であることを確認します。
Kubeconfigを保護する: kubeconfigファイルを機密性の高い認証情報として扱います。ファイルのアクセス許可を制限し、バージョン管理にコミットしないようにします。

最終的なポイント

コンテキストチェックをワークフローの一部にしましょう。リスクのあるコマンドの前にkubectl config current-contextを実行し、わかりやすいコンテキスト名を使用し、意図的に名前空間を設定し、必要のないときは本番環境の認証情報をカジュアルなシェルセッションから遠ざけてください。