コンテンツにスキップ

コマンド＠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"
}