📝

Kubernetes初学の書Part3

2022/12/04に公開約3,300字

はじめに

Kubernetesをはじめて学習する人へ向けて、基本概念の説明からアプリケーションを作成していく過程について記載する。

前回のおさらい

Part2

kubectlのインストールとKubernetesクラスタの作成について記載した。
https://zenn.dev/higashi10/articles/e6ffcb2b998858

Part3での説明内容

  • CLIツールkubectlについて
    • 認証情報
    • リソースの作成/削除/更新

CLIツールkubectlについて

kubectlとは、Kubernetes MasterのAPIを介してクラスタの操作を行うためのCLIツールである。

認証情報

kubectlがKubernetes Masterと通信する際には、接続先サーバの情報や認証情報などが必要となっている。kubectlは、kubeconfig(デフォルトでは「~/.kube/config」)に書かれている情報を使用して接続を行なっている。ここでは、接続先の確認と切り替え方法について記載する。

  1. 接続先の一覧を表示する。
kubectl config get-contexts
実行結果
CURRENT   NAME                CLUSTER             AUTHINFO            NAMESPACE
          kind-kindcluster    kind-kindcluster    kind-kindcluster
*         kind-kindcluster2   kind-kindcluster2   kind-kindcluster2
  1. 接続先の切り替えを行う。
kubectl config use-context kind-kindcluster
実行結果
Switched to context "kind-kindcluster".
  1. 現在の接続先を表示する。
kubectl config current-context
実行結果
kind-kindcluster

マニフェストとリソース操作

kubectlを利用して、マニフェストを元にコンテナを起動する。今回は、1つのコンテナからなるPodを操作する。

nginx-container.yml
apiVersion: v1
kind: Pod
metadata:
    name: sample-pod
spec:
    containers:
    - name: nginx-container
      image: nginx

リソースの作成

  1. 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
  1. Podの一覧を取得する。
kubectl get pods
実行結果
NAME         READY   STATUS    RESTARTS   AGE
sample-pod   1/1     Running   0          4m15s

リソースの削除

  1. 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"オプションを使用することで、リソースの削除完了を持ってからコマンドを終了されることができる。

リソースの更新

  1. 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

ログインするとコメントできます