簡単な例を見てみましょう。

 ➜ ~ kubectl get pods -o custom-columns= 'NAME:metadata.name'  
名前 
 nfs-client-provisioner-54f4485448-kwr45
 nginx-674ff86d-t6gbd

ここでの出力には、すべてのPod名を表示する列が含まれています。Pod名を選択するための式はmeta.nameです。これは、Pod名がPodリソースのmetadataプロパティのnameフィールドで定義されているためです（kubectl explain pod.metadata.nameで確認できます）。

ここで、各ポッドが実行中のノードを表示するなど、出力に列を追加したいとします。その場合は、カスタム列オプションに適切な列指定を追加するだけです。

 ➜ ~ kubectl get pods -o custom-columns= 'NAME:metadata.name,NODE:spec.nodeName'  
名前ノード
nfs-client-provisioner-54f4485448-kwr45 172.27.0.2
 nginx-674ff86d-t6gbd 172.27.0.2

ノード名を選択するための式は `spec.nodeName` です。これは、Pod によってスケジュールされるノードが既に Pod の `spec.nodeName` フィールドに格納されているためです。ただし、Kubernetes リソースフィールドは大文字と小文字が区別されることに注意してください。

このように、リソースの任意のフィールドを出力列として設定できます。リソース仕様を参照し、任意のフィールドを使用してみてください。もちろん、フィールド選択のためのJSONPath式についてある程度の理解が必要です。

JSONPath式

リソースフィールドの選択に使用される式はJSONPathに基づいています。JSONPathはJSONドキュメントからデータを抽出するための言語です（XMLのXPathに似ています）。単一のフィールドを選択することはJSONPathの最も基本的な使用法ですが、リストセレクターやフィルターなど、他にも多くの機能があります。

ただし、`kubectl explain` は JSONPath 機能のサブセットのみをサポートしています。以下に、いくつかの例を通してこれらの使用ルールをまとめます。

リストのすべての要素を選択する

# ポッドの下にあるすべてのコンテナイメージを取得する
➜ ~ kubectl get pods -o custom-columns= 'IMAGES:spec.containers[*].image'  
画像
cnych/nfs-subdir-external-provisioner:v4.0.2
 nginx:最新

リストの特定の要素を選択する

# Podの下の最初のコンテナのイメージを取得する
➜ ~ kubectl get pods -o custom-columns= 'IMAGE:spec.containers[0].image'  
画像
cnych/nfs-subdir-external-provisioner:v4.0.2
 nginx:最新

フィルタ式に一致するリスト要素を選択します。

 ➜ ~ kubectl get pods -o custom-columns= 'DATA:spec.containers[?(@.image!="nginx:latest")].image'  
データ
cnych/nfs-subdir-external-provisioner:v4.0.2
 <なし>

指定した場所の下にあるすべてのフィールドを選択します

➜ ~ kubectl get pods -o custom-columns= 'DATA:metadata.*'  
データ
デフォルト,[map[apiVersion:apps/v1 blockOwnerDeletion: true controller: true kind:ReplicaSet name :nfs-client-provisioner-54f4485448 uid:39912344-d707-4029-8da8-5269cfcae9e9]],4926994155,map[app:nfs-client-provisioner pod-template-hash:54f4485448],2021-07-06T04:08:48Z,nfs-client-provisioner-54f4485448-,[map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:metadata:map[f:generateName:map[] f:labels:map[.:map[] f:app:map[] f:pod-template-hash:map[]] f:ownerReferences:map[.:map[] k:{ "uid" : "39912344-d707-4029-8da8-5269cfcae9e9" }:map[.:map[] f:apiVersion:map[] f:blockOwnerDeletion:map[] f:controller:map[] f:kind:map[] f: name :map[] f:uid:map[]]] f:spec:map[f:containers:map[k:{ "name" : "nfs-client-provisioner" }:map[.:map[] f:env:map[.:map[] k:{ "name" : "NFS_PATH" }:map[.: map[] f: name :map[] f:value:map[]] k:{ "name" : "NFS_SERVER" }:map[.:map[] f: name :map[] f:value:map[]] k:{ "name" : "PROVISIONER_NAME" }:map[.:map[] f: name :map[] f:value:map[]]] f:image:map[] f:imagePullPolicy:map[] f: name :map[] f:resources:map[] f:terminationMessagePath:map[] f:terminationMessagePolicy:map[] f:volumeMounts:map[.:map[] k:{ "mountPath" : "/persistentvolumes" }:map[.:map[] f:mountPath:map[] f: name :map[]]]]] f:dnsPolicy:map[] f:enableServiceLinks:map[] f:restartPolicy:map[] f:schedulerName:map[] f:securityContext:map[] f:serviceAccount:map[] f:serviceAccountName:map[] f:terminationGracePeriodSeconds:map[] f:volumes:map[.:map[] k:{ "name" : "nfs-client-root" }:map[.:map[] f: name :map[] f:nfs:map[.:map[] f:path:map[] f:server:map[]]]]]] manager:kube-controller-manager 操作:更新  time :2021-07-06T04:08:48Z] map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:status:map[f:conditions:map[.:map[] k:{ "type" : "PodScheduled" }:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:message:map[] f:reason:map[] f:status:map[] f:type:map[]]]]] manager:kube-scheduler 操作:更新 時間:2021-07-06T04:08:49Z] map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:metadata:map[f:annotations:map[.:map[] f:tke.cloud.tencent.com/networks-status:map[]]]] manager:multus 操作:更新 時刻:2021-07-06T04:09:24Z] map[apiVersion:v1 fieldsType:FieldsV1 fieldsV1:map[f:status:map[f:conditions:map[k:{ "type" : "ContainersReady" }:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:status:map[] f:type:map[]] k:{ "type" : "Initialized" }:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:status:map[] f:type:map[]] k:{ "type" : "Ready" }:map[.:map[] f:lastProbeTime:map[] f:lastTransitionTime:map[] f:status:map[] f:type:map[]]] f:containerStatuses:map[] f:hostIP:map[] f:phase:map[] f:podIP:map[] f:podIPs:map[.:map[] k:{ "ip" : "172.16.0.87" }:map[.:map[] f:ip:map[]]] f:startTime:map[]]] manager:kubelet 操作:更新 時刻:2021-08-02T23:00:33Z]],nfs-client-provisioner-54f4485448-kwr45,/api/v1/namespaces/デフォルト/pods/nfs-client-provisioner-54f4485448-kwr45,9c445349-42ce -4e38-b20a-41bb47587d7e,マップ[tke.cloud.tencent.com/networks-status:[{
 「名前」 : 「tke-bridge」 、
 「ips」 : [
 「172.16.0.87」  
 ],
 "デフォルト" : true 、
 「DNS」 : {}
 }]]
 ……

位置に関係なく、指定された名前を持つすべてのフィールドを選択します。

 ➜ ~ kubectl get pods -o custom-columns= 'IMAGE:..image'  
画像
cnych/nfs-subdir-external-provisioner:v4.0.2、cnych/nfs-subdir-external-provisioner:v4.0.2
 nginx:最新、nginx:最新

[ ] 演算子は特に重要です。Kubernetes リソースの多くのフィールドはリストであり、この演算子はこれらのリスト内の特定の要素を選択するために使用できます。ワイルドカード [*] と組み合わせて使用​​されることが多く、リスト内のすべての項目を選択できます。

サンプルアプリケーション

カスタム列出力形式の可能性は無限大です。リソースの任意のフィールド、またはフィールドの組み合わせを出力に表示できます。以下にいくつかの例を示しますが、ご自身で探してニーズに合ったものを見つけてください。

ヒント: これらのコマンドを頻繁に使用する場合は、それらのシェル エイリアスを作成できます。

Pod のコンテナ イメージを表示します。

 ➜ ~ kubectl get pods -o custom-columns= 'NAME:metadata.name,IMAGES:spec.containers[*].image'  
名前画像
nfs-client-provisioner-54f4485448-kwr45 cnych/nfs-subdir-external-provisioner:v4.0.2
 nginx nginx
 nginx-674ff86d-t6gbd nginx:最新

このコマンドは、各ポッドのすべてのコンテナイメージの名前を表示します。ポッドには複数のコンテナが含まれる場合があるため、1つのポッドのコンテナイメージは同じ列にカンマ区切りのリストとして表示されます。

ノードの使用可能な領域を表示します。

 ➜ ~ kubectl ノードを取得 \
 -o カスタム列 = 'NAME:metadata.name,ZONE:metadata.labels.failure-domain\.beta\.kubernetes\.io/zone'  
名前ゾーン
172.27.0.2 160001

このコマンドは、Kubernetes クラスターがパブリッククラウド上にデプロイされている場合に、各ノードのアベイラビリティゾーンを表示するため便利です。各ノードのアベイラビリティゾーンは、特別なラベル「failure-domain.beta.kubernetes.io/zone」を通じて取得されます。このラベルは、クラスターがパブリッククラウド インフラストラクチャ上で実行されている場合に自動的に作成され、その値がノードのアベイラビリティゾーン名に設定されます。

タグは Kubernetes リソース仕様の一部ではありませんが、ノードを YAML または JSON として出力すると、タグに関する情報を確認できます。

 kubectl ノードを取得 -o yaml
 ＃または 
 kubectl ノードを取得 -o json

マルチクラスタと名前空間の切り替え

kubectl が Kubernetes API にリクエストを送信する際、kubeconfig ファイルを読み取って必要な接続パラメータを取得し、APIServer にリクエストを送信します。デフォルトの kubeconfig ファイルは ~/.kube/config です。複数のクラスターを使用する場合、kubeconfig ファイルは複数のクラスターの接続パラメータを設定するため、kubectl にどのクラスターに接続するかを伝える手段が必要です。クラスター内には複数の名前空間を設定できます。また、kubectl は kubeconfig ファイルでリクエストに使用する名前空間を特定できるため、kubectl にどの名前空間を使用するかを伝える手段も必要です。

さらに、KUBECONFIG 環境変数で設定したり、--kubeconfig オプションを使用して各 kubectl コマンドのデフォルトの kubeconfig ファイルを上書きしたりすることもできます。

kubeconfig

kubeconfig ファイルは一連のコンテキストで構成され、各コンテキストには次の 3 つの要素が含まれています。

• クラスター: クラスターの API サーバー アドレス。
• ユーザー: クラスター内の特定のユーザーの認証資格情報。
• 名前空間: クラスターに接続するときに使用する名前空間。

ほとんどのユーザーは、kubeconfig ファイルで各クラスターに単一のコンテキストを使用するのが一般的です。ただし、各クラスターが異なるユーザーまたは名前空間を持つ複数のコンテキストを持つことはまれであるため、通常、クラスターとコンテキストは1対1でマッピングされます。

いつでも、次のいずれかのコンテキストを現在のコンテキストとして設定できます。

kubectl は kubeconfig ファイルを読み取る際に、常に現在のコンテキストの情報を使用します。したがって、上記の例では、kubectl は Hare クラスターに接続します。別のクラスターに切り替えるには、kubeconfig ファイルで現在のコンテキストを変更するだけです。

これにより、kubectl は Fox クラスターに接続し、同じクラスター内の別の名前空間に切り替えることができるようになり、現在のコンテキスト内の名前空間要素を変更できるようになります。

上記の例では、kubectl は Fox クラスター内で、以前設定された Test 名前空間ではなく Prod 名前空間を使用するようになりました。理論的には、kubeconfig ファイルを手動で編集することでこれらの変更を行うことができます。kubectl config コマンドには、kubeconfig ファイルを編集するためのサブコマンドも用意されています。

• `kubectl config get-contexts`: すべてのコンテキストを一覧表示します。
• `kubectl config current-context`: 現在のコンテキストを取得します。
• `kubectl config use-context`: 現在のコンテキストを変更します。
• `kubectl config set-context`: コンテキストを変更する要素。

たとえば、それぞれ異なるクラスターに接続する 2 つの kubeconfig ファイルがある場合、次のコマンドを使用して 2 つの kubeconfig ファイルをマージできます。

 ➜ ~ cp $HOME/.kube/config $HOME/.kube/config.backup.$(日付+%Y-%m-%d.%H:%M:%S)
 KUBECONFIG=$HOME/.kube/config:$HOME/.kube/ydzs-config kubectl 構成ビュー  --merge --flatten > $HOME/.kube/merged_kubeconfig && mv $HOME/.kube/merged_kubeconfig $HOME/.kube/config  
 ➜ ~ kubectl config get-contexts
現在   名前クラスター 認証情報 名前空間
cls-9kl736yn-context-デフォルトtke 管理者
* kubernetes-admin@kubernetesローカルkubernetes-adminデフォルト 

上記のコマンドは、2つのkubeconfigファイルをマージします。2つのクラスターと2つのコンテキストがあることがわかります。リソースオブジェクトを操作する際には、`--context`パラメータを使用して操作対象のクラスターを指定できます。

 ➜ ~ kubectl get pods --context=cls-9kl736yn-context-default  
名前準備完了 ステータス 再起動 年齢
nfs-client-provisioner-54f4485448-kwr45 1/1 実行中 1 67日
nginx-674ff86d-t6gbd 1/1 実行中 0 67日
➜ ~ kubectl get pods --context=kubernetes-admin@kubernetes  
名前準備完了 ステータス 再起動 年齢
nginx 1/1 実行中 0 26日

ご覧の通り、このプロセスは非常に面倒です。以下では、これらの変更を自動化するために他のツールを使用します。

クベクト

Kubectxは、クラスターと名前空間を切り替えるための強力なツールです。`kubectx`コマンドと`kubens`コマンドが提供されており、現在のコンテキストと名前空間を個別に変更できます。各クラスターにコンテキストが1つしかない場合、現在のコンテキストを変更するとクラスター自体も変更されます。

kubectl プラグイン管理ツール Krew がすでにインストールされている場合は、次のコマンドを使用して Kubectx プラグインを直接インストールできます。

 kubectl krew インストール ctx
 kubectl krew インストール ns

インストール後、`kubectl ctx` コマンドと `kubectl ns` コマンドを使って操作できます。ただし、この方法ではシェルの自動補完スクリプトはインストールされないことに注意してください。必要であれば、macOS の Homebrew など、別の方法でインストールできます。

 kubectx をインストールします

このインストールコマンドは、bash/zsh/fishの自動補完スクリプトを自動的に設定します。異なるクラスター間を切り替える必要がある場合が多いため、誤ってクラスターを操作してしまう可能性が高くなります。このような場合、プロンプトが表示されるのは非常に便利です。kube-ps1ツールを使用してPS1を変更できます。

ただし、ローカルでoh-my-zshを使用しているため、インストールする必要はありません。~/.zshrcのプラグインにkube-ps1を追加し、カスタマイズして、ソースを再設定するだけで済みます。

プロンプト = '$(kube_ps1)' $プロンプト
KUBE_PS1_PREFIX= "  
 KUBE_PS1_SYMBOL_DEFAULT = ""  
 KUBE_PS1_DIVIDER= "-"  
 KUBE_PS1_SUFFIX= " "  

これで、kubectx コマンドを入力するだけでクラスターを切り替えることができます。

kube-ps1 を設定しているため、現在動作しているクラスターもターミナルの前面に直接表示され、クラスター上で操作する際のエラーを防止します。

kubectx のもう一つの非常に便利な機能は、インタラクティブモードです。このモードでは fzf ツールが必要です（fzf をインストールすると、kubectx のインタラクティブモードが自動的に有効になります）。インタラクティブモードでは、インタラクティブなあいまい検索インターフェースを使用して、ターゲットコンテキストまたは名前空間を選択できます。

kubectlプラグイン

バージョン1.12以降、kubectlはカスタムコマンドでkubectlを拡張できるプラグインメカニズムを提供しています。kubectlプラグインは、kubectl-xという形式の名前を持つシンプルな実行ファイルとして配布されます。kubectl-xには、プラグインを呼び出すための新しいkubectlサブコマンドがプレフィックスとして付加されます。

プラグインをインストールするには、kubectl-x ファイルをPATH内の任意のディレクトリにコピーし、実行可能にするだけです。その後は、kubectl x でプラグインを起動できます。システムに現在インストールされているすべてのプラグインを一覧表示するには、以下のコマンドを使用します。

 kubectlプラグインリスト

Kubectlプラグインはソフトウェアパッケージのように共有・再利用できます。しかし、他のユーザーが共有したプラグインはどこで見つけられるのでしょうか？Krewプロジェクトは、kubectlプラグインの共有、検索、インストール、管理のための統合ソリューションを提供することを目指しています。Krewはkubectlプラグインをインデックス化し、ユーザーはそこからプラグインを選択してインストールできます。もちろん、krew自体もkubectlプラグインであるため、krewのインストールは他のkubectlプラグインのインストールと基本的に同じです。krewの詳細なインストール手順は、GitHubページ（https://github.com/kubernetes-sigs/krew）でご覧いただけます。

重要な krew コマンドをいくつか紹介します。

 # krewインデックスを検索します(オプションの検索クエリを使用)
 kubectl krew search [<クエリ>] 
 
 # プラグインに関する情報を表示する
kubectl krew info <プラグイン> 
 
 # プラグインをインストールする
kubectl krew install <プラグイン> 
 
 #すべてのプラグインを最新バージョンにアップグレードする
kubectl krew アップグレード
 
 # krewでインストールされたすべてのプラグインを一覧表示します
kubectl クルーリスト
 
 # プラグインをアンインストールする
kubectl krew remove <プラグイン>

`kubectl krew list` コマンドは krew でインストールされたプラグインのみを一覧表示しますが、`kubectl plugin list` コマンドは krew でインストールされたプラグインと他の方法でインストールされたプラグインを含むすべてのプラグインを一覧表示することに注意してください。

プラグインを作成する

独自のkubectlプラグインも簡単に作成できます。必要な操作を実行する実行ファイルを作成し、kubectl-xという名前を付けて、上記のようにインストールするだけです。実行ファイルは、Bashスクリプト、コンパイルされたGoプログラム、Pythonスクリプトなど、どのような形式でも構いません。種類は特に問いません。必要なのは、オペレーティングシステムから直接実行できることだけです。

サンプルプラグインを作成しましょう。これまでは、各ポッドのコンテナイメージを一覧表示するために「kubectl」コマンドを使用していました。このコマンドは、「kubectl img」で呼び出せるプラグインに簡単に変換できます。以下の内容を含む「kubectl-img」というファイルを作成するだけです。

 #!/bin/bash
 kubectl get pods -o custom-columns= 'NAME:metadata.name,IMAGES:spec.containers[*].image'  

次に、`chmod +x kubectl-img` を使ってファイルを実行可能にし、PATH 内の任意のディレクトリに移動します。これで、`kubectl img` でプラグインをすぐに使用できるようになります。

 ➜ ~ kubectl 画像
名前画像
nfs-client-provisioner-54f4485448-kwr45 cnych/nfs-subdir-external-provisioner:v4.0.2
 nginx-674ff86d-t6gbd nginx:最新

Kubectlプラグインは、あらゆるプログラミング言語またはスクリプト言語で記述できます。シェルスクリプトを使用する場合、プラグインからkubectlを簡単に呼び出せるという利点があります。また、Kubernetesクライアントライブラリなどの本格的なプログラミング言語を使用すれば、より複雑なプラグインを作成することもできます。Goを使用する場合は、kubectlプラグインの作成用に特別に設計されたcli-runtimeライブラリを使用することもできます。