コマンド＠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という。
ClientSideApplyでは、クライアント側がkube-apiserverからマニフェストの実体を取得し、これを変更してから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
宛先をAWS 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¶
SSL証明書を持つ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名>
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
▼ -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リソースを取得する。
小文字の-lオプションとは異なり、特定のラベルを持つKubernetesリソースを一覧で表示する。
該当のキーがない場合は、空欄で表示される。
$ kubectl get <Kubernetesリソースの種類> -L <metadata.labelsキー>
＊例＊
AWS 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
▼ オプション無し (キーの削除)¶
指定したリソースの.metadata.labelsキーを削除する。
$ kubectl label <リソースの種類> <リソース名> foo-
＊例＊
$ kubectl label namespace 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
▼ --timestamps¶
タイムスタンプを取得する。
$ kubectl logs -n <Namespace名> --timestamps=true <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形式を入力値として、リソースの設定値を変更する。
ただし、マニフェストは変更されない。
▼ 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リソースを経由しているわけではないことに注意する。
開発環境にて、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:<ホストポート番号>
- https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/#forward-a-local-port-to-a-port-on-the-pod
- https://stackoverflow.com/questions/53898627/mysql-remote-connect-over-ssh-to-a-kubernetes-pod
- https://qiita.com/superbrothers/items/0dca5d2a10727fc14734#%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E5%A4%96%E3%81%8B%E3%82%89-clusterip-%E3%81%AB%E7%B4%90%E3%81%A5%E3%81%8F-pod-%E3%81%AB%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%99%E3%82%8B
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"
}