Kubernetes初学の書Part3
はじめに
Kubernetesをはじめて学習する人へ向けて、基本概念の説明からアプリケーションを作成していく過程について記載する。
前回のおさらい
Part2
kubectlのインストールとKubernetesクラスタの作成について記載した。
Part3での説明内容
- CLIツールkubectlについて
- 認証情報
- リソースの作成/削除/更新
CLIツールkubectlについて
kubectlとは、Kubernetes MasterのAPIを介してクラスタの操作を行うためのCLIツールである。
認証情報
kubectlがKubernetes Masterと通信する際には、接続先サーバの情報や認証情報などが必要となっている。kubectlは、kubeconfig（デフォルトでは「~/.kube/config」）に書かれている情報を使用して接続を行なっている。ここでは、接続先の確認と切り替え方法について記載する。
- 接続先の一覧を表示する。
kubectl config get-contexts
実行結果
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
kind-kindcluster kind-kindcluster kind-kindcluster
* kind-kindcluster2 kind-kindcluster2 kind-kindcluster2
- 接続先の切り替えを行う。
kubectl config use-context kind-kindcluster
実行結果
Switched to context "kind-kindcluster".
- 現在の接続先を表示する。
kubectl config current-context
実行結果
kind-kindcluster
マニフェストとリソース操作
kubectlを利用して、マニフェストを元にコンテナを起動する。今回は、1つのコンテナからなるPodを操作する。
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
spec:
containers:
- name: nginx-container
image: nginx
リソースの作成
- Podを作成する。
kubectl create -f nginx-container.yml
実行結果
リソースが存在しない場合
pod/sample-pod created
リソースが存在する場合
Error from server (AlreadyExists): error when creating "nginx-container.yml": pods "sample-pod" already exists
- Podの一覧を取得する。
kubectl get pods
実行結果
NAME READY STATUS RESTARTS AGE
sample-pod 1/1 Running 0 4m15s
リソースの削除
- Podを削除する。
kubectl delete -f nginx-container.yml
実行結果
リソースが存在する場合
pod "sample-pod" deleted
リソースが存在しない場合
Error from server (NotFound): error when deleting "nginx-container.yml": pods "sample-pod" not found
- 特定リソースのみ削除する場合
kubectl delete pod sample-pod
- 特定のリソース種別を全て削除する場合
kubectl delete pod --all
- "--wait"オプション
kubectl delete -f nginx-container.yml --wait
kubectlコマンドでは、リソースの処理は非同期で行われる。"--wait"オプションを使用することで、リソースの削除完了を持ってからコマンドを終了されることができる。
リソースの更新
- Podの設定を更新する。
kubectl apply -f nginx-container.yml
実行結果
更新がある場合
pod/sample-pod configured
更新がない場合
pod/sample-pod unchanged
リソースの作成にもkubectl applyを使うべき理由
リソース作成にも「kubectl create」ではなく「kubectl apply」を使うべき理由は大きく2つある。
1つ目は、作成時には「kubectl create」を使い、更新時には「kubectl apply」を使うといった使い分けが不要になるため。また、スクリプトやCICDなどの組み込みを考えると、条件分岐を増やさないといったメリットが挙げられる。
2つ目は、「kubectl create」で作成し「kubectl apply」で更新する場合、前回の更新情報が保持されておらず、差分を検出できないことがあるため。「kubectl apply」で適用される差分は、「前回適用したマニフェスト」「現在クラスタに登録されているリソースの状態」「適用するマニフェスト」の3種類から算出される。「kubectl create」で作成した場合、「前回適用したマニフェスト」が保持されないので、差分を検出することができない。
Discussion