はじめに
kubectl は、CKAD スタイルの Kubernetes 作業全体で使用するコマンドラインツールです。Pod、Deployment、Service、または設定オブジェクトを作成する前に、kubectl がどのクラスターと通信しているか、またデフォルトでどのネームスペースを対象にコマンドが実行されるかを把握しておく必要があります。
このラボでは、アクティブな Kubernetes コンテキストの確認、ネームスペースの一覧表示、練習用ネームスペースの現在のネームスペースへの設定、そして小さな ConfigMap を作成してネームスペース化されたオブジェクトがどのように分離されるかを確認します。チェックは、作成した Kubernetes の主要な状態に焦点を当てており、コマンド出力の正確なフォーマットには依存しません。
kubectl アクセスの確認
このステップでは、kubectl が準備された Kubernetes クラスターに到達できることを確認し、コマンドが使用しているコンテキストを特定します。
まずは /home/labex/project から始めます。mkdir -p コマンドは、ディレクトリが存在しない場合に作成し、存在する場合は何もしません。このコースでは、後のラボでマニフェストやヘルパーファイルを一貫した場所に作成できるよう、学習者の作業をこのディレクトリ内に保持します。
mkdir -p /home/labex/project
cd /home/labex/project
Kubernetes コンテキストは、kubeconfig 内に保存された接続設定です。これは kubectl に対して、どのクラスター、ユーザー認証情報、デフォルトのネームスペースを使用するかを指示します。オブジェクトを変更するコマンドを実行する前に、アクティブなコンテキストを確認してください。
kubectl config current-context
準備された LabEx の Kubernetes プロファイル名が表示されるはずです：
labex-v135
予測可能な開始点とするために、現在のコンテキストのネームスペースを default に設定します。ここではオブジェクトを作成しているわけではなく、後のネームスペース関連コマンドで --namespace を省略した際に、kubectl がどのネームスペースを使用すべきかを指示しているだけです。
kubectl config set-context --current --namespace=default
現在のコンテキストが更新されたことが出力で確認できます：
Context "labex-v135" modified.
VM が表示された直後は、Kubernetes プロファイルの起動が完了するまで少し時間がかかる場合があります。まずクラスターのノードを一覧表示します。このコマンドで API サーバーがまだ準備できていないと報告された場合は、数秒待ってから、ノードが Ready になるまで同じコマンドを再実行してください。
kubectl get nodes --request-timeout=5s
期待される出力には、準備完了状態のノードと Kubernetes のバージョンが含まれます：
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
次に、API サーバーに基本的なクラスター情報を問い合わせます。これにより、ターミナルが単に kubectl バイナリを見つけているだけでなく、実際に実行中のクラスターに対して認証されていることが証明されます。
kubectl cluster-info
出力には、Kubernetes コントロールプレーンのエンドポイントが記載されているはずです：
Kubernetes control plane is running at ...
...
ネームスペースの読み取り
このステップでは、Kubernetes のネームスペースを調査し、現在のコンテキストがデフォルトでどのネームスペースを使用しているかを確認します。
ネームスペースは、同じクラスター内でネームスペース化された Kubernetes オブジェクトを別々のスコープに分割する方法です。Pod、Deployment、Service、Secret、ConfigMap などの多くのアプリケーションリソースは、正確に 1 つのネームスペース内に存在します。
クラスター内に既に存在するネームスペースを一覧表示します：
kubectl get namespaces
kube-system のようなシステムネームスペースや、一般的なアプリケーション用ネームスペースである default が表示されるはずです：
NAME STATUS AGE
default Active ...
kube-system Active ...
...
コンテキストにはデフォルトのネームスペースを保存することもできます。--namespace を指定せずにネームスペース関連のコマンドを実行すると、kubectl はそのデフォルトのネームスペースを使用します。--minify オプションはアクティブなコンテキストのみを表示し、jsonpath 式はネームスペースフィールドのみを出力します。
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
前のステップでコンテキストのネームスペースを設定したため、default と表示されます：
default
単一のコマンドに対して現在のネームスペースを上書きしたい場合は、いつでも --namespace を使用できます。例えば、コンテキストを変更せずに Kubernetes システムネームスペース内の Pod を調査するには次のようにします：
kubectl get pods --namespace kube-system
正確な Pod 名は異なる場合がありますが、コマンドは CoreDNS、ネットワーキング、ストレージコンポーネントなどのシステム Pod を返すはずです：
NAME READY STATUS RESTARTS AGE
... ... ... ... ...
練習用ネームスペースの選択
このステップでは、このラボ用のネームスペースを作成し、後のコマンドのデフォルトネームスペースとして設定します。
ckad-prep-contexts という名前のネームスペースを作成します。ネームスペース名はオブジェクトの識別情報の一部です。あるネームスペース内の app-settings という名前の ConfigMap は、別のネームスペース内の同じ名前の ConfigMap とは別物として扱われます。
kubectl create namespace ckad-prep-contexts
作成コマンドで新しいネームスペースが確認できるはずです：
namespace/ckad-prep-contexts created
次に、--namespace を指定しないコマンドが ckad-prep-contexts を対象とするように、現在のコンテキストのみを更新します。--current オプションは、コンテキストを手動で指定する代わりに「現在使用しているコンテキストを変更する」ことを意味します。
kubectl config set-context --current --namespace=ckad-prep-contexts
コンテキストが変更されたことが出力で確認できます：
Context "labex-v135" modified.
アクティブなコンテキストに保存されているネームスペースを再度確認します：
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
今度は以下のように表示されるはずです：
ckad-prep-contexts
--namespace を指定せずに単純な Pod 一覧表示を実行します。現在のネームスペースが ckad-prep-contexts になっているため、このコマンドは練習用ネームスペースの中身を確認します。ネームスペースが空であることは正常です。
kubectl get pods
期待される出力：
No resources found in ckad-prep-contexts namespace.
ネームスペースのスコープの観察
このステップでは、小さな ConfigMap を作成し、それを使用して現在のネームスペースがオブジェクトの検索にどのように影響するかを観察します。
ConfigMap は、アプリケーションの非機密設定データを保存します。軽量で作成が容易であり、ネームスペース化されているため、実際のアプリケーションをデプロイする前にネームスペースの動作を練習するのに適しています。
--namespace を指定せずに app-settings という名前の ConfigMap を作成します。前のステップで ckad-prep-contexts を選択したため、Kubernetes はそのネームスペース内に作成します。
kubectl create configmap app-settings --from-literal=mode=prep
コマンドは以下のように報告するはずです：
configmap/app-settings created
ネームスペースフラグを指定せずに ConfigMap を一覧表示します。これは現在のコンテキストのネームスペースを使用します。
kubectl get configmap app-settings
期待される出力：
NAME DATA AGE
app-settings 1 ...
次に、明示的にネームスペースを指定して同じオブジェクトを要求します。ckad-prep-contexts で作成したため、同じ ConfigMap が返されるはずです。
kubectl get configmap app-settings --namespace ckad-prep-contexts
最後に、default ネームスペースを確認します。--ignore-not-found オプションを使用すると、オブジェクトが存在しない場合に kubectl が正常終了し、何も出力しなくなります。これは、結果として「存在しないこと」が期待されるガイド付きラボにおいて便利です。
kubectl get configmap app-settings --namespace default --ignore-not-found
出力がないことは、ConfigMap が default に作成されなかったことを意味します。これで、現在のコンテキストでネームスペースを設定することの実用的な効果を確認できました。
まとめ
kubectl が準備された Kubernetes クラスターに到達できることを確認し、アクティブなコンテキストを特定し、既存のネームスペースを調査し、現在のコンテキストのネームスペースを変更し、ConfigMap を作成してネームスペースのスコープを観察しました。これらの基本は、後の CKAD 準備ラボの基礎となります。そこではアプリケーションオブジェクトを作成し、各オブジェクトが正確にどこで作成され、調査されているかを把握する必要があります。
