これは、このセクションの複数ページの印刷可能なビューです。 印刷するには、ここをクリックしてください.
kubectl CLI
- 1: kubectlの概要
- 2: JSONPathのサポート
- 3: kubectlの使用規則
- 4: kubectlチートシート
1 - kubectlの概要
kubectl
コマンドラインツールを使うと、Kubernetesクラスターを制御できます。環境設定のために、kubectl
は、$HOME/.kube
ディレクトリにあるconfig
という名前のファイルを探します。他のkubeconfigファイルは、KUBECONFIG
環境変数を設定するか、--kubeconfig
フラグを設定することで指定できます。
この概要では、kubectl
の構文を扱い、コマンド操作を説明し、一般的な例を示します。サポートされているすべてのフラグやサブコマンドを含め、各コマンドの詳細については、kubectlリファレンスドキュメントを参照してください。インストール方法については、kubectlのインストールおよびセットアップをご覧ください。
構文
ターミナルウィンドウからkubectl
コマンドを実行するには、以下の構文を使用します。
kubectl [command] [TYPE] [NAME] [flags]
ここで、command
、TYPE
、NAME
、flags
は、以下を表します。
-
command
: 1つ以上のリソースに対して実行したい操作を指定します。例えば、create
、get
、describe
、delete
です。 -
TYPE
: リソースタイプを指定します。リソースタイプは大文字と小文字を区別せず、単数形や複数形、省略形を指定できます。例えば、以下のコマンドは同じ出力を生成します。kubectl get pod pod1 kubectl get pods pod1 kubectl get po pod1
-
NAME
: リソースの名前を指定します。名前は大文字と小文字を区別します。kubectl get pods
のように名前が省略された場合は、すべてのリソースの詳細が表示されます。複数のリソースに対して操作を行う場合は、各リソースをタイプと名前で指定するか、1つまたは複数のファイルを指定することができます。
-
リソースをタイプと名前で指定する場合
-
タイプがすべて同じとき、リソースをグループ化するには
TYPE1 name1 name2 name<#>
とします。
例:kubectl get pod example-pod1 example-pod2
-
複数のリソースタイプを個別に指定するには、
TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>
とします。
例:kubectl get pod/example-pod1 replicationcontroller/example-rc1
-
-
リソースを1つ以上のファイルで指定する場合は、
-f file1 -f file2 -f file<#>
とします。- 特に設定ファイルについては、YAMLの方がより使いやすいため、JSONではなくYAMLを使用してください。
例:kubectl get pod -f ./pod.yaml
- 特に設定ファイルについては、YAMLの方がより使いやすいため、JSONではなくYAMLを使用してください。
-
-
flags
: オプションのフラグを指定します。例えば、-s
または--server
フラグを使って、Kubernetes APIサーバーのアドレスやポートを指定できます。
ヘルプが必要な場合は、ターミナルウィンドウからkubectl help
を実行してください。
操作
以下の表に、kubectl
のすべての操作の簡単な説明と一般的な構文を示します。
操作 | 構文 | 説明 |
---|---|---|
alpha |
kubectl alpha SUBCOMMAND [flags] |
アルファ機能に該当する利用可能なコマンドを一覧表示します。これらの機能は、デフォルトではKubernetesクラスターで有効になっていません。 |
annotate |
kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] |
1つ以上のリソースのアノテーションを、追加または更新します。 |
api-resources |
kubectl api-resources [flags] |
利用可能なAPIリソースを一覧表示します。 |
api-versions |
kubectl api-versions [flags] |
利用可能なAPIバージョンを一覧表示します。 |
apply |
kubectl apply -f FILENAME [flags] |
ファイルまたは標準出力から、リソースの設定変更を適用します。 |
attach |
kubectl attach POD -c CONTAINER [-i] [-t] [flags] |
実行中のコンテナにアタッチして、出力ストリームを表示するか、コンテナ(標準入力)と対話します。 |
auth |
kubectl auth [flags] [options] |
認可を検査します。 |
autoscale |
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] |
ReplicationControllerで管理されているPodのセットを、自動的にスケールします。 |
certificate |
kubectl certificate SUBCOMMAND [options] |
証明書のリソースを変更します。 |
cluster-info |
kubectl cluster-info [flags] |
クラスター内のマスターとサービスに関するエンドポイント情報を表示します。 |
completion |
kubectl completion SHELL [options] |
指定されたシェル(bashまたはzsh)のシェル補完コードを出力します。 |
config |
kubectl config SUBCOMMAND [flags] |
kubeconfigファイルを変更します。詳細は、個々のサブコマンドを参照してください。 |
convert |
kubectl convert -f FILENAME [options] |
異なるAPIバージョン間で設定ファイルを変換します。YAMLとJSONに対応しています。 |
cordon |
kubectl cordon NODE [options] |
Nodeをスケジュール不可に設定します。 |
cp |
kubectl cp <file-spec-src> <file-spec-dest> [options] |
コンテナとの間でファイルやディレクトリをコピーします。 |
create |
kubectl create -f FILENAME [flags] |
ファイルまたは標準出力から、1つ以上のリソースを作成します。 |
delete |
kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] |
ファイル、標準出力、またはラベルセレクター、リソースセレクター、リソースを指定して、リソースを削除します。 |
describe |
kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] |
1つ以上のリソースの詳細な状態を表示します。 |
diff |
kubectl diff -f FILENAME [flags] |
ファイルまたは標準出力と、現在の設定との差分を表示します。 |
drain |
kubectl drain NODE [options] |
メンテナンスの準備のためにNodeをdrainします。 |
edit |
kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] |
デファルトのエディタを使い、サーバー上の1つ以上のリソースリソースの定義を編集し、更新します。 |
exec |
kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]] |
Pod内のコンテナに対して、コマンドを実行します。 |
explain |
kubectl explain [--recursive=false] [flags] |
様々なリソースのドキュメントを取得します。例えば、Pod、Node、Serviceなどです。 |
expose |
kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] |
ReplicationController、Service、Podを、新しいKubernetesサービスとして公開します。 |
get |
kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] |
1つ以上のリソースを表示します。 |
kustomize |
kubectl kustomize <dir> [flags] [options] |
kustomization.yamlファイル内の指示から生成されたAPIリソースのセットを一覧表示します。引数はファイルを含むディレクトリのPath,またはリポジトリルートに対して同じ場所を示すパスサフィックス付きのgitリポジトリのURLを指定しなければなりません。 |
label |
kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] |
1つ以上のリソースのラベルを、追加または更新します。 |
logs |
kubectl logs POD [-c CONTAINER] [--follow] [flags] |
Pod内のコンテナのログを表示します。 |
options |
kubectl options |
すべてのコマンドに適用されるグローバルコマンドラインオプションを一覧表示します。 |
patch |
kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] |
Strategic Merge Patchの処理を使用して、リソースの1つ以上のフィールドを更新します。 |
plugin |
kubectl plugin [flags] [options] |
プラグインと対話するためのユーティリティを提供します。 |
port-forward |
kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags] |
1つ以上のローカルポートを、Podに転送します。 |
proxy |
kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags] |
Kubernetes APIサーバーへのプロキシーを実行します。 |
replace |
kubectl replace -f FILENAME |
ファイルや標準出力から、リソースを置き換えます。 |
rollout |
kubectl rollout SUBCOMMAND [options] |
リソースのロールアウトを管理します。有効なリソースには、Deployment、DaemonSetとStatefulSetが含まれます。 |
run |
kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client|none] [--overrides=inline-json] [flags] |
指定したイメージを、クラスタ上で実行します。 |
scale |
kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] |
指定したReplicationControllerのサイズを更新します。 |
set |
kubectl set SUBCOMMAND [options] |
アプリケーションリソースを設定します。 |
taint |
kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options] |
1つ以上のNodeのtaintを更新します。 |
top |
kubectl top [flags] [options] |
リソース(CPU/メモリー/ストレージ)の使用量を表示します。 |
uncordon |
kubectl uncordon NODE [options] |
Nodeをスケジュール可に設定します。 |
version |
kubectl version [--client] [flags] |
クライアントとサーバーで実行中のKubernetesのバージョンを表示します。 |
wait |
kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] |
実験中の機能: 1つ以上のリソースが特定の状態になるまで待ちます。 |
コマンド操作について詳しく知りたい場合は、kubectlリファレンスドキュメントを参照してください。
リソースタイプ
以下の表に、サポートされているすべてのリソースと、省略されたエイリアスの一覧を示します。
(この出力はkubectl api-resources
から取得でき、Kubernetes 1.13.3時点で正確でした。)
リソース名 | 短縮名 | APIグループ | 名前空間に属するか | リソースの種類 |
---|---|---|---|---|
bindings |
true | Binding | ||
componentstatuses |
cs |
false | ComponentStatus | |
configmaps |
cm |
true | ConfigMap | |
endpoints |
ep |
true | Endpoints | |
limitranges |
limits |
true | LimitRange | |
namespaces |
ns |
false | Namespace | |
nodes |
no |
false | Node | |
persistentvolumeclaims |
pvc |
true | PersistentVolumeClaim | |
persistentvolumes |
pv |
false | PersistentVolume | |
pods |
po |
true | Pod | |
podtemplates |
true | PodTemplate | ||
replicationcontrollers |
rc |
true | ReplicationController | |
resourcequotas |
quota |
true | ResourceQuota | |
secrets |
true | Secret | ||
serviceaccounts |
sa |
true | ServiceAccount | |
services |
svc |
true | Service | |
mutatingwebhookconfigurations |
admissionregistration.k8s.io | false | MutatingWebhookConfiguration | |
validatingwebhookconfigurations |
admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | |
customresourcedefinitions |
crd , crds |
apiextensions.k8s.io | false | CustomResourceDefinition |
apiservices |
apiregistration.k8s.io | false | APIService | |
controllerrevisions |
apps | true | ControllerRevision | |
daemonsets |
ds |
apps | true | DaemonSet |
deployments |
deploy |
apps | true | Deployment |
replicasets |
rs |
apps | true | ReplicaSet |
statefulsets |
sts |
apps | true | StatefulSet |
tokenreviews |
authentication.k8s.io | false | TokenReview | |
localsubjectaccessreviews |
authorization.k8s.io | true | LocalSubjectAccessReview | |
selfsubjectaccessreviews |
authorization.k8s.io | false | SelfSubjectAccessReview | |
selfsubjectrulesreviews |
authorization.k8s.io | false | SelfSubjectRulesReview | |
subjectaccessreviews |
authorization.k8s.io | false | SubjectAccessReview | |
horizontalpodautoscalers |
hpa |
autoscaling | true | HorizontalPodAutoscaler |
cronjobs |
cj |
batch | true | CronJob |
jobs |
batch | true | Job | |
certificatesigningrequests |
csr |
certificates.k8s.io | false | CertificateSigningRequest |
leases |
coordination.k8s.io | true | Lease | |
events |
ev |
events.k8s.io | true | Event |
ingresses |
ing |
extensions | true | Ingress |
networkpolicies |
netpol |
networking.k8s.io | true | NetworkPolicy |
poddisruptionbudgets |
pdb |
policy | true | PodDisruptionBudget |
podsecuritypolicies |
psp |
policy | false | PodSecurityPolicy |
clusterrolebindings |
rbac.authorization.k8s.io | false | ClusterRoleBinding | |
clusterroles |
rbac.authorization.k8s.io | false | ClusterRole | |
rolebindings |
rbac.authorization.k8s.io | true | RoleBinding | |
roles |
rbac.authorization.k8s.io | true | Role | |
priorityclasses |
pc |
scheduling.k8s.io | false | PriorityClass |
csidrivers |
storage.k8s.io | false | CSIDriver | |
csinodes |
storage.k8s.io | false | CSINode | |
storageclasses |
sc |
storage.k8s.io | false | StorageClass |
volumeattachments |
storage.k8s.io | false | VolumeAttachment |
出力オプション
ある特定のコマンドの出力に対してフォーマットやソートを行う方法については、以下の節を参照してください。どのコマンドが様々な出力オプションをサポートしているかについては、kubectlリファレンスドキュメントをご覧ください。
出力のフォーマット
すべてのkubectl
コマンドのデフォルトの出力フォーマットは、人間が読みやすいプレーンテキスト形式です。特定のフォーマットで、詳細をターミナルウィンドウに出力するには、サポートされているkubectl
コマンドに-o
または--output
フラグのいずれかを追加します。
構文
kubectl [command] [TYPE] [NAME] -o <output_format>
kubectl
の操作に応じて、以下の出力フォーマットがサポートされています。
出力フォーマット | 説明 |
---|---|
-o custom-columns=<spec> |
カスタムカラムのコンマ区切りのリストを使用して、テーブルを表示します。 |
-o custom-columns-file=<filename> |
<filename> ファイル内のカスタムカラムのテンプレートを使用して、テーブルを表示します。 |
-o json |
JSON形式のAPIオブジェクトを出力します。 |
-o jsonpath=<template> |
jsonpath式で定義されたフィールドを表示します。 |
-o jsonpath-file=<filename> |
<filename> ファイル内のjsonpath式で定義されたフィールドを表示します。 |
-o name |
リソース名のみを表示します。 |
-o wide |
追加情報を含めて、プレーンテキスト形式で出力します。Podの場合は、Node名が含まれます。 |
-o yaml |
YAML形式のAPIオブジェクトを出力します。 |
例
この例において、以下のコマンドは1つのPodの詳細を、YAML形式のオブジェクトとして出力します。
kubectl get pod web-pod-13je7 -o yaml
各コマンドでサポートされている出力フォーマットの詳細については、kubectlリファレンスドキュメントを参照してください。
カスタムカラム
カスタムカラムを定義して、必要な詳細のみをテーブルに出力するには、custom-columns
オプションを使います。カスタムカラムをインラインで定義するか、-o custom-columns=<spec>
または-o custom-columns-file=<filename>
のようにテンプレートファイルを使用するかを選択できます。
例
インラインで定義する例は、以下の通りです。
kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
テンプレートファイルを使用して定義する例は、以下の通りです。
kubectl get pods <pod-name> -o custom-columns-file=template.txt
ここで、template.txt
には以下の内容が含まれます。
NAME RSRC
metadata.name metadata.resourceVersion
どちらのコマンドを実行した場合でも、以下の結果を得ます。
NAME RSRC
submit-queue 610995
サーバーサイドカラム
kubectl
は、サーバーからオブジェクトに関する特定のカラム情報を受け取ることをサポートしています。
つまり、与えられた任意のリソースについて、サーバーはそのリソースに関連する列や行を返し、クライアントが表示できるようにします。
これにより、サーバーが表示の詳細をカプセル化することで、同一クラスターに対して使用されているクライアント間で、一貫した人間が読みやすい出力が可能です。
この機能は、デフォルトで有効になっています。無効にするには、kubectl get
コマンドに--server-print=false
フラグを追加します。
例
Podの状態に関する情報を表示するには、以下のようなコマンドを使用します。
kubectl get pods <pod-name> --server-print=false
以下のように出力されます。
NAME AGE
pod-name 1m
オブジェクトリストのソート
ターミナルウィンドウで、オブジェクトをソートされたリストに出力するには、サポートされているkubectl
コマンドに--sort-by
フラグを追加します。--sort-by
フラグで任意の数値フィールドや文字列フィールドを指定することで、オブジェクトをソートします。フィールドの指定には、jsonpath式を使用します。
構文
kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
例
名前でソートしたPodのリストを表示するには、以下のように実行します。
kubectl get pods --sort-by=.metadata.name
例: 一般的な操作
よく使われるkubectl
の操作に慣れるために、以下の例を使用してください。
kubectl apply
- ファイルや標準出力から、リソースの適用や更新を行います。
# example-service.yaml内の定義を使用して、Serviceを作成します。
kubectl apply -f example-service.yaml
# example-controller.yaml内の定義を使用して、ReplicationControllerを作成します。
kubectl apply -f example-controller.yaml
# <directory>ディレクトリ内の、任意の.yaml、.yml、.jsonファイルで定義されているオブジェクトを作成します。
kubectl apply -f <directory>
kubectl get
- 1つ以上のリソースの一覧を表示します。
# すべてのPodの一覧をプレーンテキスト形式で表示します。
kubectl get pods
# すべてのPodの一覧を、ノード名などの追加情報を含めて、プレーンテキスト形式で表示します。
kubectl get pods -o wide
# 指定した名前のReplicationControllerの一覧をプレーンテキスト形式で表示します。'replicationcontroller'リソースタイプを短縮して、エイリアス'rc'で置き換えることもできます。
kubectl get replicationcontroller <rc-name>
# すべてのReplicationControllerとServiceの一覧をまとめてプレーンテキスト形式で表示します。
kubectl get rc,services
# すべてのDaemonSetの一覧をプレーンテキスト形式で表示します。
kubectl get ds
# server01ノードで実行中のPodの一覧をプレーンテキスト形式で表示します。
kubectl get pods --field-selector=spec.nodeName=server01
kubectl describe
- 1つ以上のリソースの詳細な状態を、デフォルトでは初期化されないものも含めて表示します。
# Node <node-name>の詳細を表示します。
kubectl describe nodes <node-name>
# Pod <pod-name>の詳細を表示します。
kubectl describe pods/<pod-name>
# ReplicationController <rc-name>が管理しているすべてのPodの詳細を表示します。
# ReplicationControllerによって作成された任意のPodには、ReplicationControllerの名前がプレフィックスとして付与されます。
kubectl describe pods <rc-name>
# すべてのPodの詳細を表示します。
kubectl describe pods
kubectl get
コマンドは通常、同じリソースタイプの1つ以上のリソースを取得するために使用します。豊富なフラグが用意されており、例えば-o
や--output
フラグを使って、出力フォーマットをカスタマイズできます。-w
や--watch
フラグを指定することで、特定のオブジェクトの更新を監視できます。kubectl describe
コマンドは、指定されたリソースに関する多くの側面を説明することに重点を置いています。ユーザーに対してビューを構築するために、APIサーバーへ複数のAPIコールを呼び出すことができます。例えば、kubectl describe node
コマンドは、Nodeに関する情報だけでなく、その上で動いているPodやNodeで生成されたイベントなどをまとめて表示します。
kubectl delete
- ファイル、標準出力、または指定したラベルセレクター、名前、リソースセレクター、リソースを指定して、リソースを削除します。
# pod.yamlファイルで指定されたタイプと名前を用いて、Podを削除します。
kubectl delete -f pod.yaml
# '<label-key>=<label-value>'というラベルを持つPodとServiceをすべて削除します。
kubectl delete pods,services -l <label-key>=<label-value>
# 初期化されていないPodを含む、すべてのPodを削除します。
kubectl delete pods --all
kubectl exec
- Pod内のコンテナに対してコマンドを実行します。
# Pod <pod-name>から、'date'を実行している時の出力を取得します。デフォルトでは、最初のコンテナから出力されます。
kubectl exec <pod-name> -- date
# Pod <pod-name>のコンテナ <container-name>から、'date'を実行している時の出力を取得します。
kubectl exec <pod-name> -c <container-name> -- date
# インタラクティブな TTY を取得し、Pod <pod-name>から/bin/bashを実行します。デフォルトでは、最初のコンテナから出力されます。
kubectl exec -ti <pod-name> -- /bin/bash
kubectl logs
- Pod内のコンテナのログを表示します。
# Pod <pod-name>のログのスナップショットを返します。
kubectl logs <pod-name>
# Pod <pod-name>から、ログのストリーミングを開始します。Linuxの'tail -f'コマンドと似ています。
kubectl logs -f <pod-name>
kubectl diff
- 提案されたクラスタに対する更新の差分を表示します。
# pod.jsonに含まれるリソースの差分を表示します。
kubectl diff -f pod.json
# 標準出力から読み込んだファイルの差分を表示します。
cat service.yaml | kubectl diff -f -
例: プラグインの作成と使用
kubectl
プラグインの書き方や使い方に慣れるために、以下の例を使用してください。
# 任意の言語でシンプルなプラグインを作成し、生成される実行可能なファイルに
# プレフィックス"kubectl-"で始まる名前を付けます。
cat ./kubectl-hello
#!/bin/sh
# このプラグインは、"hello world"という単語を表示します。
echo "hello world"
プラグインを書いたら、実行可能にします。
chmod a+x ./kubectl-hello
# さらに、PATH内の場所に移動させます。
sudo mv ./kubectl-hello /usr/local/bin
sudo chown root:root /usr/local/bin
# これでkubectlプラグインを作成し、"インストール"できました。
# 通常のコマンドのようにkubectlから呼び出すことで、プラグインを使用できます。
kubectl hello
hello world
# 配置したPATHのフォルダから削除することで、プラグインを"アンインストール"できます。
sudo rm /usr/local/bin/kubectl-hello
kubectl
で利用可能なプラグインをすべて表示するには、kubectl plugin list
サブコマンドを使用してください。
kubectl plugin list
出力は以下のようになります。
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
kubectl plugin list
コマンドは、実行不可能なプラグインや、他のプラグインの影に隠れてしまっているプラグインなどについて、警告することもできます。例えば、以下のようになります。
sudo chmod -x /usr/local/bin/kubectl-foo # 実行権限を削除します。
kubectl plugin list
The following kubectl-compatible plugins are available:
/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
- warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar
error: one plugin warning was found
プラグインは、既存のkubectl
コマンドの上に、より複雑な機能を構築するための手段であると考えることができます。
cat ./kubectl-whoami
次の例では、下記の内容を含んだkubectl-whoami
が既に作成済であることを前提としています。
#!/bin/bash
# このプラグインは、`kubectl config`コマンドを使って
# 現在選択されているコンテキストに基づいて、現在のユーザーに関する情報を提供します。
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
上記のコマンドを実行すると、KUBECONFIGファイル内のカレントコンテキストのユーザーを含んだ出力を得られます。
# ファイルを実行可能にします。
sudo chmod +x ./kubectl-whoami
# さらに、ファイルをPATHに移動します。
sudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
次の項目
-
kubectlを使い始めてください。
-
プラグインについてより詳しく知りたい場合は, example cli pluginを御覧ください。
2 - JSONPathのサポート
kubectlはJSONPathのテンプレートをサポートしています。
JSONPathのテンプレートは、波括弧{}
によって囲まれたJSONPathの式によって構成されています。
kubectlでは、JSONPathの式を使うことで、JSONオブジェクトの特定のフィールドをフィルターしたり、出力のフォーマットを変更することができます。
本来のJSONPathのテンプレートの構文に加え、以下の機能と構文が使えます:
- JSONPathの式の内部でテキストをクォートするために、ダブルクォーテーションを使用します。
- リストを反復するために、
range
、end
オペレーターを使用します。 - リストを末尾側から参照するために、負の数のインデックスを使用します。負の数のインデックスはリストを「周回」せず、
-index + listLength >= 0
が満たされる限りにおいて有効になります。
-
式は常にルートのオブジェクトから始まるので、
$
オペレーターの入力は任意になります。 -
結果のオブジェクトはString()関数を適用した形で表示されます。
以下のようなJSONの入力が与えられたとします。
{
"kind": "List",
"items":[
{
"kind":"None",
"metadata":{"name":"127.0.0.1"},
"status":{
"capacity":{"cpu":"4"},
"addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
}
},
{
"kind":"None",
"metadata":{"name":"127.0.0.2"},
"status":{
"capacity":{"cpu":"8"},
"addresses":[
{"type": "LegacyHostIP", "address":"127.0.0.2"},
{"type": "another", "address":"127.0.0.3"}
]
}
}
],
"users":[
{
"name": "myself",
"user": {}
},
{
"name": "e2e",
"user": {"username": "admin", "password": "secret"}
}
]
}
機能 | 説明 | 例 | 結果 |
---|---|---|---|
text |
プレーンテキスト | kind is {.kind} |
kind is List |
@ |
現在のオブジェクト | {@} |
入力した値と同じ値 |
. or [] |
子要素 | {.kind} , {['kind']} or {['name\.type']} |
List |
.. |
子孫要素を再帰的に探す | {..name} |
127.0.0.1 127.0.0.2 myself e2e |
* |
ワイルドカード。すべてのオブジェクトを取得する | {.items[*].metadata.name} |
[127.0.0.1 127.0.0.2] |
[start:end:step] |
添字 | {.users[0].name} |
myself |
[,] |
和集合 | {.items[*]['metadata.name', 'status.capacity']} |
127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8] |
?() |
フィルター | {.users[?(@.name=="e2e")].user.password} |
secret |
range , end |
リストの反復 | {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} |
[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] |
'' |
解釈済みの文字列をクォートする | {range .items[*]}{.metadata.name}{'\t'}{end} |
127.0.0.1 127.0.0.2 |
kubectl
とJSONPathの式を使った例:
kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'
Windowsでは、空白が含まれるJSONPathのテンプレートをクォートする場合は(上記のようにシングルクォーテーションを使うのではなく)、ダブルクォーテーションを使わなければなりません。 また、テンプレート内のリテラルをクォートする際には、シングルクォーテーションか、エスケープされたダブルクォーテーションを使わなければなりません。例えば:
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
JSONPathの正規表現はサポートされていません。正規表現を利用した検索を行いたい場合は、jq
のようなツールを使ってください。
# kubectlはJSONpathの出力として正規表現をサポートしていないので、以下のコマンドは動作しない
kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}'
# 上のコマンドに期待される結果が欲しい場合、以下のコマンドを使うとよい
kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image'
3 - kubectlの使用規則
kubectl
の推奨される使用規則です。
再利用可能なスクリプトでのkubectl
の使用
スクリプトでの安定した出力のために:
-o name
,-o json
,-o yaml
,-o go-template
,-o jsonpath
などの機械指向の出力形式のいずれかを必要します。- バージョンを完全に指定します。例えば、
jobs.v1.batch/myjob
のようにします。これにより、kubectlが時間とともに変化する可能性のあるデフォルトのバージョンを使用しないようにします。 - コンテキストや設定、その他の暗黙的な状態に頼ってはいけません。
ベストプラクティス
kubectl run
kubectl run
がインフラのコード化を満たすために:
- イメージにバージョン固有のタグを付けて、そのタグを新しいバージョンに移さない。例えば、
:latest
ではなく、:v1234
、v1.2.3
、r03062016-1-4
を使用してください(詳細は、Best Practices for Configurationを参照してください)。 - パラメーターが多用されているイメージをスクリプトでチェックします。
kubectl run
フラグでは表現できない機能を、ソースコントロールでチェックした設定ファイルに切り替えます。
dry-run=client
フラグを使用すると、実際に送信することなく、クラスターに送信されるオブジェクトを確認することができます。
kubectl run
ジェネレーターは非推奨です。ジェネレーターのリストとその使用方法については、Kubernetes v1.17のドキュメントを参照してください。
Generators
kubectl create --dry-run=client -o yaml
というkubectlコマンドで以下のリソースを生成することができます。
clusterrole
: ClusterRoleを作成します。clusterrolebinding
: 特定のClusterRoleに対するClusterRoleBindingを作成します。configmap
: ローカルファイル、ディレクトリ、またはリテラル値からConfigMapを作成します。cronjob
: 指定された名前のCronJobを作成します。deployment
: 指定された名前でDeploymentを作成します。job
: 指定された名前でJobを作成します。namespace
: 指定された名前でNamespaceを作成します。poddisruptionbudget
: 指定された名前でPodDisruptionBudgetを作成します。priorityclass
: 指定された名前でPriorityClassを作成します。quota
: 指定された名前でQuotaを作成します。role
: 1つのルールでRoleを作成します。rolebinding
: 特定のロールやClusterRoleに対するRoleBindingを作成します。secret
: 指定されたサブコマンドを使用してSecretを作成します。service
: 指定されたサブコマンドを使用してServiceを作成します。ServiceAccount
: 指定された名前でServiceAccountを作成します。
kubectl apply
- リソースの作成や更新には
kubectl apply
を使用できます。kubectl applyを使ったリソースの更新については、Kubectl Bookを参照してください。
4 - kubectlチートシート
このページには、一般的によく使われるkubectl
コマンドとフラグのリストが含まれています。
Kubectlコマンドの補完
BASH
source <(kubectl completion bash) # 現在のbashシェルにコマンド補完を設定するには、最初にbash-completionパッケージをインストールする必要があります。
echo "source <(kubectl completion bash)" >> ~/.bashrc # bashシェルでのコマンド補完を永続化するために.bashrcに追記します。
また、エイリアスを使用している場合にもkubectl
コマンドを補完できます。
alias k=kubectl
complete -F __start_kubectl k
ZSH
source <(kubectl completion zsh) # 現在のzshシェルにコマンド補完を設定します
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # zshシェルでのコマンド補完を永続化するために.zshrcに追記します。
Kubectlコンテキストの設定
kubectl
がどのKubernetesクラスターと通信するかを設定します。
設定ファイル詳細についてはkubeconfigを使用した複数クラスターとの認証をご覧ください。
kubectl config view # マージされたkubeconfigの設定を表示します。
# 複数のkubeconfigファイルを同時に読み込む場合はこのように記述します。
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2
kubectl config view
# e2eユーザのパスワードを取得します。
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'
kubectl config view -o jsonpath='{.users[].name}' # 最初のユーザー名を表示します
kubectl config view -o jsonpath='{.users[*].name}' # ユーザー名のリストを表示します
kubectl config get-contexts # コンテキストのリストを表示します
kubectl config current-context # 現在のコンテキストを表示します
kubectl config use-context my-cluster-name # デフォルトのコンテキストをmy-cluster-nameに設定します
# basic認証をサポートする新たなユーザーをkubeconfigに追加します
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword
# 現在のコンテキストでkubectlのサブコマンドの名前空間を永続的に変更します
kubectl config set-context --current --namespace=ggckad-s2
# 特定のユーザー名と名前空間を使用してコンテキストを設定します
kubectl config set-context gce --user=cluster-admin --namespace=foo \
&& kubectl config use-context gce
kubectl config unset users.foo # ユーザーfooを削除します
Kubectl Apply
apply
はKubernetesリソースを定義するファイルを通じてアプリケーションを管理します。kubectl apply
を実行して、クラスター内のリソースを作成および更新します。これは、本番環境でKubernetesアプリケーションを管理する推奨方法です。
詳しくはKubectl Bookをご覧ください。
Objectの作成
Kubernetesのマニフェストファイルは、JSONまたはYAMLで定義できます。ファイル拡張子として、.yaml
や.yml
、.json
が使えます。
kubectl apply -f ./my-manifest.yaml # リソースを作成します
kubectl apply -f ./my1.yaml -f ./my2.yaml # 複数のファイルからリソースを作成します
kubectl apply -f ./dir # dirディレクトリ内のすべてのマニフェストファイルからリソースを作成します
kubectl apply -f https://git.io/vPieo # urlで公開されているファイルからリソースを作成します
kubectl create deployment nginx --image=nginx # 単一のnginx Deploymentを作成します
kubectl explain pods # Podマニフェストのドキュメントを取得します
# 標準入力から複数のYAMLオブジェクトを作成します
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000000"
---
apiVersion: v1
kind: Pod
metadata:
name: busybox-sleep-less
spec:
containers:
- name: busybox
image: busybox
args:
- sleep
- "1000"
EOF
# いくつかの鍵を含むSecretを作成します
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: $(echo -n "s33msi4" | base64 -w0)
username: $(echo -n "jane" | base64 -w0)
EOF
リソースの検索と閲覧
# Getコマンドで基本的な情報を確認します
kubectl get services # 現在の名前空間上にあるすべてのサービスのリストを表示します
kubectl get pods --all-namespaces # すべての名前空間上にあるすべてのPodのリストを表示します
kubectl get pods -o wide # 現在の名前空間上にあるすべてのPodについてより詳細なリストを表示します
kubectl get deployment my-dep # 特定のDeploymentを表示します
kubectl get pods # 現在の名前空間上にあるすべてのPodのリストを表示します
kubectl get pod my-pod -o yaml # PodのYAMLを表示します
# Describeコマンドで詳細な情報を確認します
kubectl describe nodes my-node
kubectl describe pods my-pod
# 名前順にソートしたServiceのリストを表示します
kubectl get services --sort-by=.metadata.name
# Restartカウント順にPodのリストを表示します
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
# capacity順にソートしたPersistentVolumeのリストを表示します
kubectl get pv --sort-by=.spec.capacity.storage
# app=cassandraラベルのついたすべてのPodのversionラベルを表示します
kubectl get pods --selector=app=cassandra -o \
jsonpath='{.items[*].metadata.labels.version}'
# 'ca.crt'のようなピリオドが含まれるキーの値を取得します
kubectl get configmap myconfig \
-o jsonpath='{.data.ca\.crt}'
# すべてのワーカーノードを取得します(セレクターを使用して、
# 「node-role.kubernetes.io/master」という名前のラベルを持つ結果を除外します)
kubectl get node --selector='!node-role.kubernetes.io/master'
# 現在の名前空間でrunning状態のPodのリストを表示します
kubectl get pods --field-selector=status.phase=Running
# すべてのノードのExternal IPのリストを表示します
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'
# 特定のRCに属するPodの名前のリストを表示します
# `jq`コマンドは複雑なjsonpathを変換する場合に便利であり、https://stedolan.github.io/jq/で見つけることが可能です
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})
# すべてのPod(またはラベル付けをサポートする他のKubernetesオブジェクト)のラベルのリストを表示します
kubectl get pods --show-labels
# どのノードがready状態か確認します
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"
# Podで現在使用中のSecretをすべて表示します
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq
# すべてのPodのInitContainerのコンテナIDのリストを表示します
# initContainerの削除を回避しながら、停止したコンテナを削除するときに役立つでしょう
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3
# タイムスタンプでソートされたEventのリストを表示します
kubectl get events --sort-by=.metadata.creationTimestamp
# クラスターの現在の状態を、マニフェストが適用された場合のクラスターの状態と比較します。
kubectl diff -f ./my-manifest.yaml
# Nodeから返されるすべてのキーをピリオド区切りの階層表記で生成します。
# 複雑にネストされたJSON構造をもつキーを指定したい時に便利です
kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
# Pod等から返されるすべてのキーをピリオド区切り階層表記で生成します。
kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")'
リソースのアップデート
kubectl set image deployment/frontend www=image:v2 # frontend Deploymentのwwwコンテナイメージをv2にローリングアップデートします
kubectl rollout history deployment/frontend # frontend Deploymentの改訂履歴を確認します
kubectl rollout undo deployment/frontend # 1つ前のDeploymentにロールバックします
kubectl rollout undo deployment/frontend --to-revision=2 # 特定のバージョンにロールバックします
kubectl rollout status -w deployment/frontend # frontend Deploymentのローリングアップデートを状態をwatchします
kubectl rollout restart deployment/frontend # frontend Deployment を再起動します
cat pod.json | kubectl replace -f - # 標準入力から渡されたJSONに基づいてPodを置き換えます
# リソースを強制的に削除してから再生成し、置き換えます。サービスの停止が発生します
kubectl replace --force -f ./pod.json
# ReplicaSetリソースで作られたnginxについてServiceを作成します。これは、ポート80で提供され、コンテナへはポート8000で接続します
kubectl expose rc nginx --port=80 --target-port=8000
# 単一コンテナのPodイメージのバージョン(タグ)をv4に更新します
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -
kubectl label pods my-pod new-label=awesome # ラベルを追加します
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # アノテーションを追加します
kubectl autoscale deployment foo --min=2 --max=10 # "foo" Deploymentのオートスケーリングを行います
リソースへのパッチ適用
# ノードを部分的に更新します
kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'
# コンテナのイメージを更新します。spec.containers[*].nameはマージキーであるため必須です
kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'
# ポテンシャル配列を含むJSONパッチを使用して、コンテナのイメージを更新します
kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'
# ポテンシャル配列のJSONパッチを使用してDeploymentのlivenessProbeを無効にします
kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'
# ポテンシャル配列に新たな要素を追加します
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'
リソースの編集
任意のエディターでAPIリソースを編集します。
kubectl edit svc/docker-registry # docker-registryという名前のサービスを編集します
KUBE_EDITOR="nano" kubectl edit svc/docker-registry # エディターを指定します
リソースのスケーリング
kubectl scale --replicas=3 rs/foo # 「foo」という名前のレプリカセットを3にスケーリングします
kubectl scale --replicas=3 -f foo.yaml # 「foo.yaml」で指定されたリソースを3にスケーリングします
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # mysqlと名付けられたdeploymentの現在のサイズが2であれば、mysqlを3にスケーリングします
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 複数のReplication controllerをスケーリングします
リソースの削除
kubectl delete -f ./pod.json # pod.jsonで指定されたタイプと名前を使用してPodを削除します
kubectl delete pod,service baz foo # 「baz」と「foo」の名前を持つPodとServiceを削除します
kubectl delete pods,services -l name=myLabel # name=myLabelラベルを持つのPodとServiceを削除します
kubectl -n my-ns delete pod,svc --all # 名前空間my-ns内のすべてのPodとServiceを削除します
# awkコマンドのpattern1またはpattern2に一致するすべてのPodを削除します。
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
実行中のポッドとの対話処理
kubectl logs my-pod # Podのログをダンプします(標準出力)
kubectl logs -l name=myLabel # name=myLabelラベルの持つPodのログをダンプします(標準出力)
kubectl logs my-pod --previous # 以前に存在したコンテナのPodログをダンプします(標準出力)
kubectl logs my-pod -c my-container # 複数コンテナがあるPodで、特定のコンテナのログをダンプします(標準出力)
kubectl logs -l name=myLabel -c my-container # name=mylabelラベルを持つPodのログをダンプします(標準出力)
kubectl logs my-pod -c my-container --previous # 複数コンテナがあるPodで、以前に作成した特定のコンテナのログをダンプします(標準出力)
kubectl logs -f my-pod # Podのログをストリームで確認します(標準出力)
kubectl logs -f my-pod -c my-container # 複数のコンテナがあるPodで、特定のコンテナのログをストリームで確認します(標準出力)
kubectl logs -f -l name=myLabel --all-containers # name-myLabelラベルを持つすべてのコンテナのログをストリームで確認します(標準出力)
kubectl run -i --tty busybox --image=busybox -- sh # Podをインタラクティブシェルとして実行します
kubectl run nginx --image=nginx -n
mynamespace # 特定の名前空間でnginx Podを実行します
kubectl run nginx --image=nginx # nginx Podを実行し、マニフェストファイルをpod.yamlという名前で書き込みます
--dry-run=client -o yaml > pod.yaml
kubectl attach my-pod -i # 実行中のコンテナに接続します
kubectl port-forward my-pod 5000:6000 # ローカルマシンのポート5000を、my-podのポート6000に転送します
kubectl exec my-pod -- ls / # 既存のPodでコマンドを実行(単一コンテナの場合)
kubectl exec my-pod -c my-container -- ls / # 既存のPodでコマンドを実行(複数コンテナがある場合)
kubectl top pod POD_NAME --containers # 特定のPodとそのコンテナのメトリクスを表示します
ノードおよびクラスターとの対話処理
kubectl cordon my-node # my-nodeをスケジューリング不能に設定します
kubectl drain my-node # メンテナンスの準備としてmy-nodeで動作中のPodを空にします
kubectl uncordon my-node # my-nodeをスケジューリング可能に設定します
kubectl top node my-node # 特定のノードのメトリクスを表示します
kubectl cluster-info # Kubernetesクラスターのマスターとサービスのアドレスを表示します
kubectl cluster-info dump # 現在のクラスター状態を標準出力にダンプします
kubectl cluster-info dump --output-directory=/path/to/cluster-state # 現在のクラスター状態を/path/to/cluster-stateにダンプします
# special-userキーとNoScheduleエフェクトを持つTaintがすでに存在する場合、その値は指定されたとおりに置き換えられます
kubectl taint nodes foo dedicated=special-user:NoSchedule
リソースタイプ
サポートされているすべてのリソースタイプを、それらがAPI groupかNamespaced、Kindに関わらずその短縮名をリストします。
kubectl api-resources
APIリソースを探索するためのその他の操作:
kubectl api-resources --namespaced=true # 名前空間付きのすべてのリソースを表示します
kubectl api-resources --namespaced=false # 名前空間のないすべてのリソースを表示します
kubectl api-resources -o name # すべてのリソースを単純な出力(リソース名のみ)で表示します
kubectl api-resources -o wide # すべてのリソースを拡張された形(別名 "wide")で表示します
kubectl api-resources --verbs=list,get # "list"および"get"操作をサポートするすべてのリソースを表示します
kubectl api-resources --api-group=extensions # "extensions" APIグループのすべてのリソースを表示します
出力のフォーマット
特定の形式で端末ウィンドウに詳細を出力するには、サポートされているkubectl
コマンドに-o
(または--output
)フラグを追加します。
出力フォーマット | 説明 |
---|---|
-o=custom-columns=<spec> |
コンマ区切りされたカスタムカラムのリストを指定してテーブルを表示します |
-o=custom-columns-file=<filename> |
<filename> ファイル内のカスタムカラムテンプレートを使用してテーブルを表示します |
-o=json |
JSON形式のAPIオブジェクトを出力します |
-o=jsonpath=<template> |
jsonpath式で定義されたフィールドを出力します |
-o=jsonpath-file=<filename> |
<filename> ファイル内のjsonpath式で定義されたフィールドを出力します |
-o=name |
リソース名のみを出力し、それ以外は何も出力しません。 |
-o=wide |
追加の情報を含むプレーンテキスト形式で出力します。Podの場合、Node名が含まれます。 |
-o=yaml |
YAML形式のAPIオブジェクトを出力します |
-o=custom-columns
を使用したサンプル:
# クラスター内で実行中のすべてのイメージ名を表示する
kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image'
# "k8s.gcr.io/coredns:1.6.2"を除いたすべてのイメージ名を表示する
kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image'
# 名前に関係なくmetadata以下のすべてのフィールドを表示する
kubectl get pods -A -o=custom-columns='DATA:metadata.*'
kubectlに関するより多くのサンプルはカスタムカラムのリファレンスを参照してください。
Kubectlのログレベルとデバッグ
kubectlのログレベルは、レベルを表す整数が後に続く-v
または--v
フラグで制御されます。一般的なKubernetesのログ記録規則と関連するログレベルについて、こちらで説明します。
ログレベル | 説明 |
---|---|
--v=0 |
これは、クラスターオペレーターにログレベルが0であることを"常に"見えるようにするために役立ちます |
--v=1 |
ログレベルが必要ない場合に、妥当なデフォルトのログレベルです |
--v=2 |
サービスに関する重要な定常状態情報と、システムの重要な変更に関連する可能性がある重要なログメッセージを表示します。 これは、ほとんどのシステムで推奨されるデフォルトのログレベルです。 |
--v=3 |
変更に関するより詳細なログレベルを表示します |
--v=4 |
デバックにむいたログレベルで表示します |
--v=6 |
要求されたリソースを表示します |
--v=7 |
HTTPリクエストのヘッダを表示します |
--v=8 |
HTTPリクエストのコンテンツを表示します |
--v=9 |
HTTPリクエストのコンテンツをtruncationなしで表示します |
次の項目
-
オプションについてはkubectl optionsをご覧ください。
-
またkubectlの利用パターンでは再利用可能なスクリプトでkubectlを利用する方法を学べます。
-
コミュニティ版kubectlチートシートもご覧ください。