コンテンツにスキップ

コマンド＠Kubernetes

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。


01. kubectl コマンド

セットアップ

▼ kubeconfig ファイル

~/.kube/config 配下にあり、Cluster の資格情報が定義されている。

kubectl コマンドは、kubeconfig ファイル上の Cluster の資格情報を基に、kube-apiserver にリクエストを送信する。

▼ config シンボリックリンク、--kubeconfig

ユーザーが、config ファイルを任意のディレクトリで管理する場合、シンボリックリンクを作成する。

または、コマンドの実行時に config ファイルを明示的に指定する。

$ cd ~/.kube

# 現在のディレクトリに、configシンボリックリンクを作成する。
$ ln -s /etc/kubernetes/kubeconfig config

$ kubectl get pod --kubeconfig=/etc/kubernetes/kubeconfig


annotate

▼ annotate とは

指定した Kubernetes リソースのアノテーションを操作する。

▼ --overwrite

指定したアノテーションを書き換える。

$ kubectl annotate --overwrite pod foo-pod <キー名>=<値> -n foo-namespace

kubectl apply コマンドではアノテーションを変更できず、また kubectl diff コマンドでも差分として認識されない仕様になっている。

そのため、kubectl annotate コマンドが必要になる。

キー名の後に - (ハイフン) をつけるのアノテーションを削除できる。

$ kubectl annotate --overwrite pod foo-pod <キー名>- -n foo-namespace


apply

▼ apply とは

同じ識別子 (名前) のリソースが存在しない場合は、リソースを作成し、存在する場合はマニフェストの差分を更新する。

すべての項目を更新できるわけでない。

▼ -f -R

kube-apiserver に送信するマニフェストを指定する。-R オプションでディレクトリ内のファイルを再帰的に指定もできる。

＊例＊

マニフェストを指定し、kubectl apply コマンドを実行する。

# リソースを作成する。
$ kubectl apply -f <マニフェストへのパス>

pod/foo-pod created

# 設定値を変更する。
$ kubectl apply -f <マニフェストへのパス>

pod/foo-pod configured

# ディレクトリ内のファイルを再起的に指定する。
$ kubectl apply -f <マニフェストのあるディレクトリ> -R

pod/foo-pod configured

▼ --server-side

ServerSideApply を実行する。

$ kubectl apply --server-side -f manifests.yaml

ServerSideApply ではない通常の Apply は、ClientSideApply という。

ServerSideApply と ClientSideApply の間で、マニフェストの最終的な状態を決める主体が異なる。

ClientSideApply では、クライアント側（例：kubectl、ArgoCD の application-controller など）が kube-apiserver からマニフェストの実体を取得し、クライアントを変更してから kube-apiserver に送信する。

ServerSideApply ClientSideApply
主体 kube-apiserver kubectl、ArgoCD の application-controller など

特に、ServerSideApply では kube-apiserver がよしなにマニフェストの最終状態を決めることもある。そのため、マニフェストファイルと実体が異なる場合もある。

一方で ServerSideApply では、kube-apiserver 側でマニフェストを変更する。

ClientSideApply では、クライアント側の制約により metadata.annotations キーのサイズ制限でエラーになる。

そういった場合は、ServerSideApply で解決できる。


cluster-info

▼ cluster-info とは

コントロールプレーン Node の情報を取得する。

$ kubectl cluster-info

Kubernetes control plane is running at https://*.*.*.*:443
CoreDNS is running at https://*.*.*.*:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Metrics-server is running at https://*.*.*.*:443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy


config

▼ config とは

kubeconfig ファイルのパラメーターを操作する。

▼ current-context

kubectl コマンドの宛先になっている kube-apiserver を取得する。

$ kubectl config current-context

minikube

▼ get-contexts

適用できるコンテキストの一覧と現在のコンテキストを取得する。

$ kubectl config get-contexts

CURRENT   NAME             CLUSTER          AUTHINFO         NAMESPACE
*         minikube         minikube         minikube         default
          docker-desktop   docker-desktop   docker-desktop
...

▼ use-context

kubectl コマンドの向き先を、指定した Kubernetes の実行環境の kube-apiserver に変更する。

＊例＊

宛先を Minikube の kube-apiserver に変更する。

$ kubectl config use-context minikube

宛先を Docker for Desktop の kube-apiserver に変更する。

$ kubectl config use-context docker-desktop

宛先を Amazon EKS Cluster の kube-apiserver に変更する。

$ kubectl config use-context <ClusterのARN>

▼ view

パラメーターのデフォルト値が設定された kubeconfig ファイルを取得する。

＊例＊

$ kubectl config view

apiVersion: v1
clusters:
# ---------------------------------------------
# Docker for Desktopの資格情報
# ---------------------------------------------
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubernetes.docker.internal:6443 # kube-apiserverのIPアドレス
  name: docker-desktop
contexts:
- context:
    cluster: docker-desktop
    user: docker-desktop
  name: docker-desktop
# ---------------------------------------------
# Minikubeの資格情報
# ---------------------------------------------
- cluster:
    certificate-authority: /Users/h.hasegawa/.minikube/ca.crt
    extensions:
    - extension:
        last-update: Mon, 21 Mar 2022 20:47:56 JST
        provider: minikube.sigs.k8s.io
        version: v1.25.2
      name: cluster_info
    server: https://*.*.*.*:8443 # kube-apiserverのIPアドレス
  name: minikube
- context:
    cluster: minikube
    extensions:
    - extension:
        last-update: Mon, 21 Mar 2022 20:47:56 JST
        provider: minikube.sigs.k8s.io
        version: v1.25.2
      name: context_info
    namespace: default
    user: minikube
  name: minikube
# ---------------------------------------------
# 現在のコンテキスト
# ---------------------------------------------
current-context: docker-desktop
kind: Config
preferences: {}
users:
- name: docker-desktop
  user:
    client-certificate-data: REDACTED # クライアント証明書
    client-key-data: REDACTED # 秘密鍵
- name: minikube
  user:
    client-certificate: /Users/h.hasegawa/.minikube/profiles/minikube/client.crt
    client-key: /Users/h.hasegawa/.minikube/profiles/minikube/client.key


cordon

▼ cordon とは

指定した Node にこれ以上 Pod をスケジューリングできないようにする (SchedulingDisabled 状態) 。

kubectl drain コマンドとは異なり、Pod を退避させることはない。

$ kubectl cordon <Node名>


cp

▼ cp とは

ホスト PC のファイルまたはディレクトリを指定した Pod 内のコンテナにコピーする。

▼ オプション無し

$ kubectl cp <ホストPCのパス> <Namespace名>/<PodID>:<コンテナのパス>

$ kubectl cp <ホストPCのパス> <Namespace名>/<PodID>:<コンテナのディレクトリパス>/


create

▼ create とは

さまざまなリソースを作成する。

kubectl expose コマンドと kubectl run コマンドで作成できるリソースを含むさまざまなものを作成できるが、オプションが少ない。

そのため、-f オプションで、マニフェストを指定したほうがよい。

同じ識別子 (リソース名) の Kubernetes リソースが存在する場合は重複エラーになってしまう。

＊例＊

マニフェストを指定し、kubectl create コマンドを実行する。

$ kubectl create -f ./kubernetes/foo-pod.yaml

pod/foo-pod created

$ kubectl create -f ./kubernetes/foo-service.yaml

service/foo-service created

▼ deployment

Pod 数を維持管理する ReplicaSet を作成する。

Pod を終了するためには、Deployment 自体を削除しなければならない。

＊例＊

$ kubectl create deployment -f ./kubernetes/foo-deployment.yaml

▼ secret docker-registry

イメージレジストリの資格情報を持つ Secret を作成する。

Pod と同じ Namespace に所属する必要があるため、作成時に Namespace の指定を忘れないようにする。

# DockerHubの場合
$ kubectl create secret docker-registry foo-secret \
    --docker-server=http://bar.example.com \
    --docker-username=bar \
    --docker-password=baz \
    --docker-email=http://baz.example.com \
    -n foo-namespace

▼ secret generic

Secret を作成する。

＊例＊

指定した .env ファイルから Secret を作成する。

$ kubectl create secret generic foo-secret --from-env-file=./foo/.env

secret/foo-secret created

指定した .env ファイル以外から Secret を作成する。

$ kubectl create secret generic foo-secret --from-file=./foo/values.txt

secret/foo-secret created

キー名と値から Secret を作成する。

$ kubectl create secret generic foo-secret --from-literal=username="bar" --from-literal=password="baz"

secret/foo-secret created

▼ secret tls

サーバー証明書を持つ Secret を作成する。

$ kubectl create secret tls tls-secret --cert=/etc/ssl/certs/foo.crt --key=./foo.key


delete

▼ delete とは

Kubernetes リソースを削除する。

$ kubectl delete <Kubernetesリソース> <Kubernetesリソース名>

＊例＊

Pod を終了する。

Pod の場合、オプションのない kubectl delete コマンドが Graceful Shutdown となる。

$ kubectl delete pod foo-pod

＊例＊

指定した名前の Pod をすべて削除する。

$ kubectl delete pod -n foo \
    $(kubectl get pod --no-headers -o custom-columns=":metadata.name" -n foo | grep '<指定した名前>'  | tr -s '\n' ' ')

▼ --force

Pod を強制的に削除する。

特に、Terminating フェーズのまま削除されない Pod に対して有効である。

合わせて --grace-period オプションを有効化することで、即時に削除できる。

$ kubectl delete pod <TerminatingステータスのままのPod名> --force --grace-period=0


describe

▼ describe とは

リソースの詳細な情報を参照する。

簡易的な情報を参照するときは、kubectl get コマンドを使用する。

＊例＊

$ kubectl describe node

grep コマンドを使用して、Pod をスケジューリングさせている Node を取得する。

$ kubectl describe pod <Pod名> | grep Node:

＊例＊

$ kubectl describe clusterrole foo-cluster-role

Name:         anthos-baremetal-operator
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources               Non-Resource URLs  Resource Names  Verbs
  ---------               -----------------  --------------  -----
  pods                    []                 []              [get list watch]
  deployments.apps        []                 []              [create delete get list patch update watch]
...

▼ -A

＊例＊

すべての Node の詳細な情報を取得する。

grep コマンドを使用し、必要な情報のみを確認する。

$ kubectl describe node -A | grep -e Name -e cpu

Name:               foo-node
  cpu:                8
  cpu:                7510m
  cpu                1050m (13%)  4850m (64%) # <--- Node全体の使用率
Name:               bar-node
  cpu:                4
  cpu:                3520m
  cpu                2183m (62%)  4950m (140%) # <--- Node全体の使用率
Name:               baz-node
  cpu:                8
  cpu:                7510m
  cpu                1937m (25%)  10245m (136%) # <--- Node全体の使用率


diff

▼ diff とは

既存のマニフェストと、指定したマニフェストの差分を表示する。

▼ -f

ファイルを指定して、差分を表示する。

CRD を Helm の管理外で作成する場合に役立つ。

$ curl "https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.15/manifests/crds/application-crd.yaml" \
    | kubectl diff -f -


drain

▼ drain とは

Node にこれ以上 Pod をスケジューリングできないようにし (SchedulingDisabled 状態) 、また既存の Pod を退避させる。

Node が他に存在すれば、その Node 上で Pod をスケジューリングさせる。

$ kubectl drain <Node名>

kubernetes_drain_node


edit

▼ edit とは

マニフェストの設定値を直接的に変更する。

ただし、Pod の設定値は直接的に変更できず、代わりに Deployment や StatefulSet 上での設定値を変更する必要がある。

$ kubectl edit <リソースの種類> <Pod以外のKubernetesリソース名>

$ kubectl edit deployment foo-deployment

$ kubectl edit statefulset foo-statefulset


exec

▼ exec とは

指定した Pod 内のコンテナのシェルを実行し、コンテナにログインする。

注意点として、シェルのないコンテナ (distroless 型など) はそもそもシェルを実行できないため、ログインもできない。

▼ -it

＊例＊

コンテナを指定して、デタッチモードで kubectl exec コマンドを実行する。

$ kubectl exec -it <Pod名> -c <コンテナ名> -- bash

[root@<Pod名>] $ ls -la

コンテナを指定しない場合は、デフォルトのコンテナが選択される。

Pod の .metadata.labels キーではなく、Pod 名であることに注意する。

$ kubectl exec -it <Pod名> -- bash

Defaulted container "foo-container" out of: foo-container, bar-container


expose

▼ expose とは

Service を作成する。

▼ --type、--port、--target-port

＊例＊

ClusterIP Service を作成する。

$ kubectl expose <Service名> \
    --type=ClusterIP \
    --port=<受信ポート番号> \
    --target-port=<フォワーディング先ポート番号>

NodePort Service を作成する。

$ kubectl expose <Service名> \
    --type=NodePort \
    --port=<受信ポート番号> \
    --target-port=<フォワーディング先ポート番号>

LoadBalancer Service を作成する。

$ kubectl expose <Service名> \
    --type=LoadBalancer \
    --port=<受信ポート番号> \
    --target-port=<フォワーディング先ポート番号>


get <リソース>

▼ get とは

リソースの簡易的な情報を参照する。

詳細な情報を参照するときは、kubectl describe コマンドを使用する。

＊例＊

特定の Namespace のすべての Kubernetes リソースを取得する。

$ kubectl get "$(kubectl api-resources --namespaced=true --verbs=list -o name | tr "\n" "," | sed -e 's/,$//')" -n foo-namespace

＊例＊

すべての Node の情報を取得する。

$ kubectl get node

NAME      STATUS   ROLES                  AGE   VERSION
foo-node  Ready    worker                 12h   v1.22.0 # ワーカーNode
bar-node  Ready    worker                 12h   v1.22.0 # 同上
baz-node  Ready    worker                 12h   v1.22.0 # 同上
# qux-node  Ready    control-plane,master   12h   v1.22.0 # セルフマネージドなコントロールプレーンNodeを使用する場合はこれも表示される

＊例＊

指定した Pod の情報を取得する。

$ kubectl get pod

NAME       READY   STATUS             RESTARTS   AGE
foo-pod    0/2     ImagePullBackOff   0          7m52s
bar-pod    2/2     Running            0          5m01s

＊例＊

指定した Service の情報を取得する。

$ kubectl get service

NAME           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
foo-service    ClusterIP   *.*.*.*        <none>        80/TCP    10s
kubernetes     ClusterIP   *.*.*.*        <none>        443/TCP   12h

＊例＊

grep コマンドを使用して、Running フェーズの Pod のみを取得する。

$ kubectl get pod | grep -e NAME -e Running

NAME       READY   STATUS             RESTARTS   AGE
bar-pod    2/2     Running            0          5m01s

＊例＊

wc コマンドで出力内容の行数を数える。

これにより、Pod の個数を確認できる。

$ kubectl get pod --no-headers | wc -l

20

＊例＊

各 Node で作成できる Pod の上限数を確認する。

$ kubectl get node \
    -o=custom-columns=NODE:.metadata.name,MAX_PODS:.status.allocatable.pods,CAPACITY_PODS:.status.capacity.pods,INSTANCE_TYPE:.metadata.labels."node\.kubernetes\.io/instance-type"

さらに、各 Node で稼働中の Pod 数を確認する。

$ for node in $(kubectl get node | awk '{if (NR!=1) {print $1}}'); \
    do echo""; echo "Checking ${node}..."; \
    kubectl describe node ${node} | grep "Non-terminated" ; done

＊例＊

ArgoCD の Application から、argocd app diff コマンドで反復的に差分を確認する。

#!/bin/bash

application=$(kubectl get application -A | grep foo )

# 一列目の実を取得する。
application_names=$(echo "$application" | awk '{if(NR>1) print $1}')

# 差分を取得する。
for application_name in "${application_names[@]}"; do
  argocd app diff "$application_name"
done

＊例＊

特定の値を持つマニフェストのみを取得する。

$ kubectl get applications -o yaml -n foo \
    | yq eval '.items[] | select(.spec.destination.namespace == "foo")'

▼ -A

指定した Kubernetes リソースを Namespace に関係なく取得する。

$ kubectl get pod -A

grep コマンドを使用して、特定の Node のみを取得する。

$ kubectl get pod -A -o wide | grep -e NAMESPACE -e <Node名>

すべての Pod のイメージをアルファベット順で取得する。

$ kubectl get pod -A -o jsonpath="{.items[*].spec.containers[*].image}" \
    | tr -s '[[:space:]]' '\n' \
    | sort \
    | uniq -c

▼ -o custom-columns

指定した Kubernetes リソースの情報でユーザー定義のカラムで取得する。

カスタムリソースの情報をいい感じに取得する際、役立つ。

＊例＊

Service の指定した情報をユーザー定義のカラムで取得する。

$ kubectl get service \
    -n kube-system \
    -o custom-columns='NAME:.metadata.name,IP:.spec.clusterIP,PORT:.spec.ports[*].targetPort'

NAME                   IP           PORT
kube-dns               10.0.0.10    53,53
kubernetes-dashboard   10.0.0.250   9090

なお、さらに json 形式で出力できる。

$ kubectl get service \
    -n kube-system \
    -o custom-columns='NAME:.metadata.name,IP:.spec.clusterIP,PORT:.spec.ports[*].targetPort' \
    -o json

＊例＊

Application の指定した情報をユーザー定義のカラムを取得する。

$ kubectl get application \
    -n foo \
    -o custom-columns="NAME:metadata.name,PROJECT:spec.project,STATUS:status.sync.status"

NAME               PROJECT        STATUS
foo-application    foo-project    Synced
bar-application    bar-project    OutOfSync
baz-application    baz-project    Unknown

＊例＊

kubectl コマンドの結果をマークダウンの表にして出力する。

$ kubectl get application \
    -n foo \
    -o custom-columns='NAME:metadata.name,PROJECT:spec.project,STATUS:status.sync.status' \
    | awk '
      BEGIN {
        FS="  *"
        OFS=" | "
      }
      {
        if (NR==1) {
          for(i=1; i<=NF; i++) {
            gsub(/ */, "", $i)
            printf "| %s ", $i
          }
          print "|"
          for(i=1; i<=NF; i++) {
            gsub(/./, "-", $i)
            printf "|-%s-", $i
          }
          print "|"
        } else {
          for(i=1; i<=NF; i++) {
            printf "| %s ", $i
          }
          print "|"
        }
      }'

複数の結果をマージして、マークダウンの表にして出力する。

#!/bin/bash

# 各Applicationを全て抽出する。
kubectl get application \
  -n foo \
  -o custom-columns='NAME:metadata.name,PROJECT:spec.project' >| foo.txt

kubectl get application \
  -n bar \
  -o custom-columns='NAME:metadata.name,PROJECT:spec.project' >| bar.txt

kubectl get application \
  -n baz \
  -o custom-columns='NAME:metadata.name,PROJECT:spec.project' >| baz.txt

# ヘッダーを削除する。
# https://akiniwa.hatenablog.jp/entry/2014/05/01/123126
tail -n +2 foo.txt >| foo-without-header.txt
tail -n +2 bar.txt >| bar-without-header.txt
tail -n +2 baz.txt >| baz-without-header.txt

# 並び替える。
# 後述のuniqコマンドでは、隣り合う重複しか削除できないため、ここでソートしておく。
cat foo-without-header.txt bar-without-header.txt baz-without-header.txt \
  | sort >| sorted.txt

# 行の重複を削除する。
cat sorted.txt \
  | uniq >| uniq.txt

# ヘッダーをつけ直す。
echo 'Application Project' >| merged.txt

# ヘッダーとそれ移行を接続する
cat uniq.txt >> merged.txt

# マークダウン表として出力する。
cat merged.txt | awk '
      BEGIN {
        FS="  *"
        OFS=" | "
      }
      {
        if (NR==1) {
          for(i=1; i<=NF; i++) {
            gsub(/ */, "", $i)
            printf "| %s ", $i
          }
          print "|"
          for(i=1; i<=NF; i++) {
            gsub(/./, "-", $i)
            printf "|-%s-", $i
          }
          print "|"
        } else {
          for(i=1; i<=NF; i++) {
            printf "| %s ", $i
          }
          print "|"
        }
      }' >| merged.md


# 場合によっては、他のフォーマットに変換する
# 例えばWiki記法の表に変換する
md2confl merged.md >| merged.wiki

＊例＊

kubectl コマンドの結果でアノテーションの一覧を出力する。

kubectl get pod -n foo -o custom-columns=NAME:.metadata.name,ANNOTATIONS:.metadata.annotations

▼ -o custom-columns-file

事前に定義したユーザー定義のカラムに基づいて、Kubernetes リソースを取得する。

＊例＊

Application の指定した情報をユーザー定義のカラムを取得する。

$ cat columns-file
NAME:metadata.name,PROJECT:spec.project,STATUS:status.sync.status


$ kubectl get application \
    -n foo \
    -o custom-columns-file=columns-file

NAME               PROJECT        STATUS
foo-application    foo-project    Synced
bar-application    bar-project    OutOfSync
baz-application    baz-project    Unknown

▼ -o jsonpath

指定した Kubernetes リソースの特定の設定を出力する。

＊例＊

L4 ロードバランサーの IP アドレスを取得する。

$ kubectl get service istio-ingressgateway \
    -n istio-system \
    -o jsonpath="{.status.loadBalancer.ingress[0].ip}"

＊例＊

Pod 内のコンテナを取得する。

# 特定のPodを対象とする。
$ kubectl get pod foo-pod \
    -n foo-namespace \
    -o jsonpath="{.spec.containers[*].name}" | sed 's/ /\n/g' && echo

# 全てのPodを対象とする。
$ kubectl get pod \
    -n foo-namespace \
    -o jsonpath="{.items[*].spec.containers[*].name}" | sed 's/ /\n/g' && echo

＊例＊

Pod の現在の IP アドレスを取得する。

$ kubectl get pod foo-pod \
    -n foo-namespace \
    -o jsonpath="{.status.podIP}"

＊例＊

IstioOperator に定義した Istio のバージョンを取得する。

$ kubectl get istiooperator \
    -n istio-system \
    -o jsonpath="{.metadata.labels.operator\.istio\.io\/version}"

▼ -o wide

指定したリソースの詳細な情報を取得する。

Node が複数ある場合、Node に渡って Kubernetes リソースの情報を確認できるところがよい。

＊例＊

Pod の詳細な情報を取得する。

$ kubectl get pod -o wide

NAMESPACE   NAME        READY   STATUS        RESTARTS   AGE   IP          NODE       NOMINATED NODE   READINESS GATES
foo         foo-pod     2/2     Running       0          16d   *.*.*.*     foo-node   <none>           <none>
bar         bar-pod     2/2     Running       0          16d   *.*.*.*     bar-node   <none>           <none>
baz         baz-pod     2/2     Running       0          16d   *.*.*.*     bar-node   <none>           <none>

＊例＊

grep コマンドを使用して、特定の Pod のみを取得する。

$ kubectl get pod -o wide | grep -e NAMESPACE -e foo

NAMESPACE   NAME        READY   STATUS        RESTARTS   AGE   IP          NODE       NOMINATED NODE   READINESS GATES
foo         foo-pod     2/2     Running       0          16d   *.*.*.*     foo-node   <none>           <none>

grep コマンドを使用して、特定の Service のみを取得する。

$ kubectl get service -o wide | grep -e NAMESPACE -e foo

NAMESPACE   NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)       AGE   SELECTOR
foo         foo-service  NodePort    *.*.*.*      <none>        443:443/TCP   2d    app.kubernetes.io/instance=prd-foo-app

＊例＊

Node の詳細な情報を取得する。

$ kubectl get node -o wide

NAME       STATUS   ROLES                  AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION       CONTAINER-RUNTIME
foo-node   Ready    worker                 17h   v1.22.0   *.*.*.*         <none>        Amazon Linux 2   1.0.0.amzn2.x86_64   containerd://1.0.0
bar-node   Ready    worker                 17h   v1.22.0   *.*.*.*         <none>        Amazon Linux 2   1.0.0.amzn2.x86_64   containerd://1.0.0
baz-node   Ready    worker                 17h   v1.22.0   *.*.*.*         <none>        Amazon Linux 2   1.0.0.amzn2.x86_64   containerd://1.0.0
# qux-node   Ready    control-plane,master   17h   v1.22.0   *.*.*.*         <none>        Amazon Linux 2   1.0.0.amzn2.x86_64   containerd://1.0.0 # セルフマネージドなコントロールプレーンNodeを使用する場合

▼ -o yaml

指定した Kubernetes リソースの設定を取得し、yaml 形式で出力する。

＊例＊

指定した Secret を yaml 形式で取得する。

正規表現と同様に、一部の文字列ではエスケープする必要がある。

$ kubectl get secret <Secret名> -o yaml
---
apiVersion: v1
kind: Secret
metadata:
  creationTimestamp: "2021-12-00T00:00:00Z"
  name: swp-secret
  namespace: default
  resourceVersion: "18329"
type: Opaque
data:
  FOO: ***** # base64 方式のエンコード値
  BAR: *****
  BAZ: *****

▼ -l

特定の .metadata.labels キーと値を持つ Kubernetes リソースを取得する。

大文字の -L オプションとは異なり、特定のラベルの値を持つ Kubernetes リソースを絞り込める。

＊例＊

$ kubectl get pod -l <キー>=<値>

複数の .metadata.labels キーを AND 条件で指定できる。

$ kubectl get pod -l <キー>=<値>,<キー>=<値>

.metadata.labels キーの値を OR 条件で指定できる。

$ kubectl get pod -l <キー>=<値>,<キー>=<値>

$ kubectl get pod -l '<キー> in (<値>,<値>)'

＊例＊

.metadata.labels.topology.kubernetes.io/zone キーの値が ap-northeast-1a である Node を取得する。

$ kubectl get node -l topology.kubernetes.io/zone=ap-northeast-1a

▼ -L

特定の .metadata.labels キーを持つ Kubernetes リソースを取得し、kubectl get コマンドの結果に新しい列として追加する。

小文字の -l オプションとは異なり、特定のラベルを持つ Kubernetes リソースを一覧で表示する。

該当のキーがない場合は、空欄で表示される。

$ kubectl get <Kubernetesリソースの種類> -L <metadata.labelsキー>

＊例＊

Amazon EKS にて、Node グループの種類を確認するため、eks.amazonaws.com/nodegroup キーを取得する。

$ kubectl get node -L eks.amazonaws.com/nodegroup

NAME        STATUS   ROLES    AGE    VERSION       NODEGROUP
foo-node    Ready    <none>   31d    v1.22.0-eks   service
bar-node    Ready    <none>   41d    v1.22.0-eks   ingress
baz-node    Ready    <none>   6d8h   v1.22.0-eks   collector
qux-node    Ready    <none>   6d8h   v1.22.0-eks   mesh
...

＊例＊

Node が作成された AWS リージョンを確認するため、topology.kubernetes.io/zone キーを取得する。

$ kubectl get node -L topology.kubernetes.io/zone

NAME       STATUS   ROLES    AGE     VERSION   ZONE
foo-node   Ready    <none>   18h     v1.22.0   ap-northeast-1a
bar-node   Ready    <none>   18h     v1.22.0   ap-northeast-1c
baz-node   Ready    <none>   18h     v1.22.0   ap-northeast-1d

＊例＊

istio のコンテナインジェクションが有効されている Namespace を確認するため、.metadata.labels.istio.io/rev キーを取得する。

$ kubectl get namespace -L istio.io/rev

NAME                   STATUS   AGE     REV
foo-namespace          Active   145d    1-0-0
bar-namespace          Active   145d           # キーが設定されていないNamespace
baz-namespace          Active   145d           # 同上

＊例＊

特定の Kubernetes リソースがどのように管理されているかを取得する。

公式の Helm チャートでは、Deployment、Daemonset、StatefulSet がタグを持つことが多い。

# argocd.argoproj.io/instance：ArgoCDのApplication名
# app.kubernetes.io/managed-by：テンプレート管理のツール名
# helm.sh/chart：テンプレート管理ツールがHelmの場合に、チャート名
# release：Helmチャートのリリース名
$ kubectl get -A <Kubernetesリソース> \
    -L argocd.argoproj.io/instance \
    -L app.kubernetes.io/managed-by \
    -L helm.sh/chart \
    -L release

▼ --selector

指定した .spec.selector キーを持つ Deployment を取得する。

＊例＊

$ kubectl get deployment --selector<キー>=<値>

▼ --show-labels

指定した Kubernetes リソースの .metadata.labels キーの値を表示する。

＊例＊

すべての Kubernetes リソースの .metadata.labels キーの値を表示する。

$ kubectl get all -A --show-labels

＊例＊

すべての Kubernetes リソースのなかから、ArgoCD で管理していないものの .metadata.labels キーの値を表示する。

$ kubectl get all -A --show-labels | grep -v "argocd.argoproj.io/instance"

▼ --watch (-w)

指定した Pod の情報 (フェーズ、ステータスなど) を継続的に取得し、情報に変更があれば出力を追記していく。

別ツールで時間のかかる Kubernetes リソースを作成しながら、--watch オプションを使用すると、作成状況を確認できる。

＊例＊

$ kubectl get pod -w


label

▼ label とは

指定したリソースの .metadata.labels キーを操作する。

▼ オプション無し (キーの追加)

指定したリソースに .metadata.labels キーを作成する。

＊例＊

$ kubectl label <リソースの種類> <リソース名> foo=bar

$ kubectl label ns default istio.io/rev=stable

▼ オプション無し (キーの削除)

指定したリソースの .metadata.labels キーを削除する。

$ kubectl label <リソースの種類> <リソース名> foo-

＊例＊

$ kubectl label ns default istio.io/rev-

▼ --overwrite

指定したリソースに .metadata.labels キーを上書きする。

$ kubectl label --overwrite <リソースの種類> <リソース名> foo=bar

＊例＊

.metadata.labels.istio-injection キーを .metadata.labels.istio.io/rev キー (値は 1-0-0) に上書きする。

$ kubectl label --overwrite namespace foo istio.io/rev=1-0-0 istio-injection-


logs

▼ logs とは

指定したリソースのログを取得する。

▼ -c

Pod 名とコンテナ名を指定し、コンテナのログを取得する。

＊例＊

$ kubectl logs -n <Namespace名> <Pod名> -c <コンテナ名> | grep -i error

[ERROR] *****

＊例＊

Namespace 名、Pod 名、コンテナ名を指定し、kube-proxy のログを確認する。

$ kubectl logs -n kube-system <Pod名> -c kube-proxy | grep -i error

▼ -f

ログを継続的に取得する。

$ kubectl logs -f <Pod名> | grep -i error

▼ --previous

前回停止したコンテナのログを取得する。

$ kubectl logs -f <Pod名> --previous

▼ --timestamps

タイムスタンプを取得する。

コンテナがタイムスアンプを出力していない場合に役立つ。

$ kubectl logs -n <Namespace名> --timestamps <Pod名> -c <コンテナ名> | grep -i error

2021/11/27 08:34:01 [ERROR] *****


replace

▼ replace とは

Kubernetes リソースを安全に削除し、別のマニフェストで再作成する。

$ kubectl replace -f foo.yaml

▼ --force

Kubernetes リソースを強制的に削除し、別のマニフェストで再作成する。

$ kubectl replace --force -f foo.yaml


rollout

▼ rollout とは

Deployment、DaemonSet、StatefulSet、でコピーされた Pod を操作する。

▼ restart

配下の Pod を再作成する。

Pod の Volume (例：ConfigMap、Secret、PersistentVolume、persistentVolumeClaim) の設定を変更した後、Pod へ再び読み込ませるために役立つ。

＊例＊

# Deployment配下のPodを再作成する。
$ kubectl rollout restart deployment foo-deployment -n foo-namespace

# DaemonSet配下のPodを再作成する。
$ kubectl rollout restart daemonset foo-daemonset -n foo-namespace

# StatefulSet配下のPodを再作成する。
$ kubectl rollout restart statefulset foo-statefulset -n foo-namespace


patch

▼ patch とは

JSON/yaml 形式を入力値として、リソースの設定値を変更する。

ただし、マニフェストは変更されない。

▼ cronjob

CronJob のバッチを一時無効にする。

kubectl patch cronjobs foo-batch -p '{"spec" : {"suspend" : true }}'

▼ pv

PersistentVolume の設定値を変更する。

＊例＊

削除されないボリュームを削除する。

$ kubectl get pv \
    |  tail -n+2 \
    |  awk '{print $1}' \
    |  xargs -I{} kubectl patch pv {} -p '{"metadata":{"finalizers": null}}'


port-forward

▼ port-forward とは

ポートフォワーディングを実行し、ホストのポートから Pod にリクエストを送信できるようにする。

Pod を直接的に指定する場合と、他の Kubernetes リソース (例：Service、Deployment) の情報を使用して、Pod を指定する方法がある。

このとき、通信自体は他の Kubernetes リソースを経由しているわけではないことに注意する (例えば、Kiali を確認すると、Ingress Controller を経由していないことがわかる) 。

開発環境にて、Service を介さずに直接的に Pod へリクエストを送信したい場合や、SQL クライアントを使用して Pod 内の DB コンテナへ TCP/IP 接続したい場合に使用する。

# Podを直接的に指定する場合
$ kubectl port-forward pod/<Pod名> <ホストポート番号>:<Podのポート番号>

# Serviceの情報を使用して、Podを指定する場合
$ kubectl port-forward svc/<Service名> <ホストポート番号>:<Serviceのポート番号>

# ホストポートを介してPodのポートにリクエストを送信する。
$ curl http://127.0.0.1:<ホストポート番号>

▼ 複数のポートをフォワーディングする

同じ Pod や Service で複数のポートが公開されている場合、同時にポートフォワーディングできる。

$ kubectl port-forward svc/<Service名> 8080:8080 8443:8443 9090:9090

Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Forwarding from 127.0.0.1:8443 -> 8443
Forwarding from [::1]:8443 -> 8443
Forwarding from 127.0.0.1:8443 -> 9090
Forwarding from [::1]:8443 -> 9090

異なる Pod や Service の場合、& (1 つだけ) でつなぐと、同時にポートフォワーディングできる。

$ kubectl port-forward svc/<Service名> 8080:8080 & \
    kubectl port-forward svc/<Service名> 8443:8443 & \
    kubectl port-forward svc/<Service名> 9090:9090

Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Forwarding from 127.0.0.1:8443 -> 8443
Forwarding from [::1]:8443 -> 8443
Forwarding from 127.0.0.1:8443 -> 9090
Forwarding from [::1]:8443 -> 9090


proxy

▼ proxy とは

kube-apiserver の送信元にフォワード/リバースプロキシサーバーとして動作するリソースを作成する。

kube-proxy とは異なるリソースであることに注意する。

▼ --address、--accept-hosts

＊例＊

$ kubectl proxy --address=0.0.0.0 --accept-hosts='.*'

Starting to serve on [::]:8001


run

▼ run とは

Deployment、Pod、Job を作成する。

▼ --restart、--image、--port

＊例＊

もし --restart オプションが Always なら、Deployment を作成する。

$ kubectl run <Deployment名> --restart=Always --image=<コンテナイメージ名>:<バージョンタグ> --port=<ポート番号>

もし --restart オプションが Never なら、Pod を作成する。

$ kubectl run <Pod名> --restart=Never --image=<コンテナイメージ名>:<バージョンタグ> --port=<ポート番号>

もし --restart オプションが OnFailure なら、Job を作成する。

$ kubectl run <Job名> --restart=OnFailure --image=<コンテナイメージ名>:<バージョンタグ> --port=<ポート番号>

taint

▼ taint とは

Node に Taint を付与する。

エフェクトごとに、Toleration が付与された Pod のスケジューリング方法が異なる。

エフェクト 説明
NoExecute Toleration が付与された Pod しか、その Node にスケジューリングさせられない。付与した Pod がすでに稼働している場合、その Pod も再スケジューリングさせる。
NoSchedule Toleration が付与された Pod しか、その Node にスケジューリングさせられない。付与した Pod がすでに稼働している場合、その Pod は再スケジューリングさせない。
PreferNoSchedule Toleration が付与された Pod をその Node にスケジューリングさせる。ただし、いずれの Pod にも Toleration が付与されていなければ、付与されていない Pod もその Node にスケジューリングさせる。Toleration が付与された Pod がすでにスケジューリングをさせている場合、その Pod は再スケジューリングさせない。

＊例＊

Node に Taint (app=batch:NoSchedule) を付与する。

$ kubectl taint node foo-node app=batch:NoSchedule

これにより、以下の .spec.tolerations キーが付与された Pod しかスケジューリングさせられない。

apiVersion: v1
kind: Pod
metadata:
  name: foo-pod
spec:
  containers:
    - name: app
      image: app:1.0.0
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 8080
  tolerations:
    - key: app
      value: batch
      operator: Equal
      effect: NoSchedule

＊例＊

コントロールプレーン Node として扱う Taint を付与する。

キー名のみ指定し、値は指定していない。

$ kubectl taint node foo-node node-role.kubernetes.io/master:NoSchedule

これにより、以下の .spec.tolerations キーが付与された Pod しかスケジューリングさせられない。

apiVersion: v1
kind: Pod
metadata:
  name: foo-pod
spec:
  containers:
    - name: app
      image: app:1.0.0
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 8080
  tolerations:
    - key: node-role.kubernetes.io/master
      operator: Exists
      effect: NoSchedule

▼ - (ラベル値のハイフン)

指定した Node から Taint を削除する。

＊例＊

$ kubectl taint node foo-node app=batch:NoSchedule-


version

kubectl と Kubernetes のバージョンをそれぞれ取得する。

両方のバージョンに差があっても、1 つ以内のマイナーバージョンであれば許容範囲である。

$ kubectl version

# kubectlコマンドのバージョン
Client Version: version.Info{
  Major:"1",
  Minor:"22",
  GitVersion:"v1.22.4",
  GitCommit:"*****",
  GitTreeState:"clean",
  BuildDate:"2021-11-17T15:41:42Z",
  GoVersion:"go1.16.10",
  Compiler:"gc",
  Platform:"darwin/amd64"
}

# kube-apiserverのバージョン
Server Version: version.Info{
  Major:"1",
  Minor:"22",
  GitVersion:"v1.22.3",
  GitCommit:"*****",
  GitTreeState:"clean",
  BuildDate:"2021-10-27T18:35:25Z",
  GoVersion:"go1.16.9",
  Compiler:"gc",
  Platform:"linux/amd64"
}