kubectlコンソールユーティリティを使用してKubernetesを操作する場合の便利なコマンドとヒント

翻訳者のまえがき ：この記事は、Kubernetesクラスターでコマンドを実行するためのコンソールツール-kubectlを使用したCoreOSプロジェクト （出版物の最後のリンクを参照）の2つの資料の翻訳を組み合わせたものです。 Mac OS Xの元の作者によって提供されたリストはLinuxに適合し、YAML形式は他のリストで修正され、すべての資料を読みやすくするために字幕が追加されました。



Kubectlは、Kubernetesユーザーになじみのあるツールで、優れた機能を備えています。 それらをマスターするには時間がかかりますが、多くの人が考えているよりも強力なツールであることがわかります。 kubectl



使用する際の機能を改善するための一連のヒントをkubectl



ます。 Kubernetes公式ドキュメントセクションのチートシートも確認してください！

シェルでの自動補完

kubectl



は、bashとzshの優れた自動補完機能が組み込まれています。これにより、コマンド、フラグ、ネームスペースやハース名などのオブジェクトの操作が大幅に簡素化されます。 ドキュメントには、それを含めるための既製の指示があります。 また、以下のGIFアニメーションは、自動補完の仕組みを示しています。

 #        Bash source <(kubectl completion bash) # …           .bashrc mkdir ~/.kube kubectl completion bash > ~/.kube/completion.bash.inc printf "\n# Kubectl shell completion\nsource '$HOME/.kube/completion.bash.inc'\n" >> $HOME/.bashrc source $HOME/.bashrc #  —        Zsh source <(kubectl completion zsh)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

KUBECONFIG



を使用した構成とコンテキストのKUBECONFIG

Kubernetes構成のマージは、多くのKubernetesクラスターと対話する場合によく使用されるパターンです。 さまざまな構成で作業する場合、コンテキストの概念が使用され、特定のターゲットクラスターを検索するためにkubectl



が使用するパラメーターがkubectl



ます。 しかし、コンテキストで目的の結果を達成するのは難しい場合があります。 生活を簡素化するには、 KUBECONFIG



環境KUBECONFIG



使用します。これにより、マージ中に使用される構成ファイルを指定できます。 公式ドキュメントで KUBECONFIG



詳細をお読みください。



たとえば、異なるクラスター用に2つのKubernetes構成があり、それらをマージする必要があるとします。



最初のクラスターの構成：

 $ kubectl config view --minify > cluster1-config
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 apiVersion: v1 clusters: - cluster: certificate-authority: cluster1_ca.crt server: https://cluster1 name: cluster1 contexts: - context: cluster: cluster1 user: cluster1 name: cluster1 current-context: cluster1 kind: Config preferences: {} users: - name: cluster1 user: client-certificate: cluster1_apiserver.crt client-key: cluster1_apiserver.key
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のクラスターの構成：

 $ cat cluster2-config
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 apiVersion: v1 clusters: - cluster: certificate-authority: cluster2_ca.crt server: https://cluster2 name: cluster2 contexts: - context: cluster: cluster2 user: cluster2 name: cluster2 current-context: cluster2 kind: Config preferences: {} users: - name: cluster2 user: client-certificate: cluster2_apiserver.crt client-key: cluster2_apiserver.key
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それらのマージはKUBECONFIG



を使用してKUBECONFIG



できます。 このようなマージの利点は、コンテキストを動的に切り替えることができることです。 コンテキストとは、クラスターとユーザーの説明を含む「マップ」のほか、クラスターを認証して対話するために構成を参照できる名前です。 --kubeconfig



フラグを使用すると、各ファイルのコンテキストを確認できます。

 $ kubectl --kubeconfig=cluster1-config config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster1 cluster1 cluster1 $ kubectl --kubeconfig=cluster2-config config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster2 cluster2 cluster2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各構成ファイルには単一のコンテキストが含まれているため、互いに競合することはありません。 KUBECONFIG



を介して2つのファイルをマージすると、両方のコンテキストが表示されます。 現在のコンテキストを保存するには、 cluster-merge



という名前の新しい空のファイルを作成します。

 $ export KUBECONFIG=cluster-merge:cluster-config:cluster2-config dcooley@lynx ~ $ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster1 cluster1 cluster1 cluster2 cluster2 cluster2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

KUBECONFIG



からエクスポートされたファイルのリストは、厳密な順序でダウンロードされます。 したがって、選択されるcurrent-context



は、最初の構成でcurrent-context



として指定されたcurrent-context



に対応します。 コンテキストをcluster2



変更すると、現在の（ *



）記号がリスト内のこのコンテキストに移動し、 kubectl



がこの（2番目の）コンテキストに適用され始めます。

 $ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * cluster1 cluster1 cluster1 cluster2 cluster2 cluster2 $ kubectl config use-context cluster2 Switched to context "cluster2". $ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE cluster1 cluster1 cluster1 * cluster2 cluster2 cluster2 $ cat cluster-merge
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 apiVersion: v1 clusters: [] contexts: [] current-context: cluster2 kind: Config preferences: {} users: []
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

current-context



正しい値を維持するためだけに残りcurrent-context



。 Kubernetesコンテキストを使用して、さまざまな方法でそれらをマージできます。 たとえば、すべてのkubectl



実行可能コマンドのネームスペース（ kubectl



kube-system



）を定義するコンテキスト（ cluster1_kube-system



）を作成できます。

 $ kubectl config set-context cluster1_kube-system --cluster=cluster1 --namespace=kube-system --user=cluster1 Context "cluster1_kube-system" set. $ cat cluster-merge
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 apiVersion: v1 clusters: [] contexts: - context: cluster: cluster1 namespace: kube-system user: cluster1 name: cluster1_kube-system current-context: cluster2 kind: Config preferences: {} users: []
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいコンテキストは次のように使用できます。

 $ kubectl config use-context cluster1_kube-system Switched to context "cluster1_kube-system". $ kubectl get pods NAME READY STATUS RESTARTS AGE default-http-backend-fwx3g 1/1 Running 0 28m kube-addon-manager-cluster 1/1 Running 0 28m kube-dns-268032401-snq3h 3/3 Running 0 28m kubernetes-dashboard-b0thj 1/1 Running 0 28m nginx-ingress-controller-b15xz 1/1 Running 0 28m
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Kubernetes APIの学習

Kubernetes APIが提供する機能の詳細については、 swagger.json



ファイルをリクエストしてswagger.json



。

 $ kubectl proxy $ curl -O 127.0.0.1:8001/swagger.json
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

http://localhost:8001/api/



して、Kubernetes APIで使用可能なパスを確認することもできます。



swagger.json



はJSONドキュメントであるため、 jq



表示できます。 jq



ユーティリティは、比較やその他の操作を可能にする軽量のJSONファイルハンドラーです。 詳細はこちら 。



swagger.json



を表示すると、Kubernetes APIを理解するのに役立ちます。 これは複雑なAPIであり、その機能はグループに分けられているため、理解が難しくなっています。

 $ cat swagger.json | jq '.paths | keys[]' "/api/" "/api/v1/" "/api/v1/configmaps" "/api/v1/endpoints" "/api/v1/events" "/api/v1/namespaces" "/api/v1/nodes" "/api/v1/persistentvolumeclaims" "/api/v1/persistentvolumes" "/api/v1/pods" "/api/v1/podtemplates" "/api/v1/replicationcontrollers" "/api/v1/resourcequotas" "/api/v1/secrets" "/api/v1/serviceaccounts" "/api/v1/services" "/apis/" "/apis/apps/" "/apis/apps/v1beta1/" "/apis/apps/v1beta1/statefulsets" "/apis/autoscaling/" "/apis/batch/" "/apis/certificates.k8s.io/" "/apis/extensions/" "/apis/extensions/v1beta1/" "/apis/extensions/v1beta1/daemonsets" "/apis/extensions/v1beta1/deployments" "/apis/extensions/v1beta1/horizontalpodautoscalers" "/apis/extensions/v1beta1/ingresses" "/apis/extensions/v1beta1/jobs" "/apis/extensions/v1beta1/networkpolicies" "/apis/extensions/v1beta1/replicasets" "/apis/extensions/v1beta1/thirdpartyresources" "/apis/policy/" "/apis/policy/v1beta1/poddisruptionbudgets" "/apis/rbac.authorization.k8s.io/" "/apis/storage.k8s.io/" "/logs/" "/version/"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のコマンドは、Kubernetesクラスターで使用でき、アクセスできるAPIについて説明しています。 次の例のコマンドは、管理者ユーザーの下で実行されます。 RBACアクセス制御を有効にしている場合、出力は異なる場合があります。

 $ kubectl api-versions apps/v1beta1 authentication.k8s.io/v1beta1 authorization.k8s.io/v1beta1 autoscaling/v1 batch/v1 batch/v2alpha1 certificates.k8s.io/v1alpha1 coreos.com/v1 etcd.coreos.com/v1beta1 extensions/v1beta1 oidc.coreos.com/v1 policy/v1beta1 rbac.authorization.k8s.io/v1alpha1 storage.k8s.io/v1beta1 v1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

kubectl explain



コマンドを使用すると、さまざまなAPIコンポーネントが何をするのかをより深く理解できます。

 $ kubectl explain You must specify the type of resource to explain. Valid resource types include: * all * certificatesigningrequests (aka 'csr') * clusters (valid only for federation apiservers) * clusterrolebindings * clusterroles * componentstatuses (aka 'cs') * configmaps (aka 'cm') * daemonsets (aka 'ds') * deployments (aka 'deploy') * endpoints (aka 'ep') * events (aka 'ev') * horizontalpodautoscalers (aka 'hpa') * ingresses (aka 'ing') * jobs * limitranges (aka 'limits') * namespaces (aka 'ns') * networkpolicies * nodes (aka 'no') * persistentvolumeclaims (aka 'pvc') * persistentvolumes (aka 'pv') * pods (aka 'po') * poddisruptionbudgets (aka 'pdb') * podsecuritypolicies (aka 'psp') * podtemplates * replicasets (aka 'rs') * replicationcontrollers (aka 'rc') * resourcequotas (aka 'quota') * rolebindings * roles * secrets * serviceaccounts (aka 'sa') * services (aka 'svc') * statefulsets * storageclasses * thirdpartyresources error: Required resource not specified. See 'kubectl explain -h' for help and examples.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

kubectl explain deploy



試してください。 explain



コマンドは、さまざまなレベルのネストで機能します。これにより、依存オブジェクトも参照できます。

 $ kubectl explain deploy.spec.template.spec.containers.livenessProbe.exec RESOURCE: exec <Object> DESCRIPTION: One and only one of the following should be specified. Exec specifies the action to take. ExecAction describes a "run in container" action. FIELDS: command <[]string> Command is the command line to execute inside the container, the working directory for the command is root ('/') in the container's filesystem. The command is simply exec'd, it is not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

kubectl



を介したポッドの操作

次のすべての例では、Kubernetes APIを使用してポッドについて学習します。 適切なデータを取得する1つの方法は、クエリを作成し、 jsonpath



観点から必要な式を理解することjsonpath



。 たとえば、 kubectl get pods --all-namespaces -o json



を実行すると、すべての出力が表示されます。この出力から、ポッドを時間で並べ替える例に必要なデータをフィルターで除外できます（以下を参照）。



実行中のアプリケーションがない場合は、例をよく理解するために、run = shopラベルでポッドを作成し、ポート80でサービスとして実行できます。

 $ kubectl run shop --replicas=2 --image quay.io/coreos/example-app:v1.0 --port 80 --expose
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、 jsonpath



を使用して何を行うかを確認できます。 詳細については、 公式ドキュメントから入手できます 。

作成時間でKubernetesの炉床をフィルタリングする

 $ kubectl get pods --all-namespaces --sort-by='.metadata.creationTimestamp' -o jsonpath='{range .items[*]}{.metadata.name}, {.metadata.creationTimestamp}{"\n"}{end}'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ラベルセレクターでKubernetesポッドを検索し、そのログを表示します

名前空間（ your-namespace



）と、必要なポッドの検索に役立つラベルのリクエストを指定し、これらのポッドのログを取得します。 唯一のものではない場合、ログはすべての炉床から並行して取得されます。

 $ ns='<your-namespace>' label='<yourkey>=<yourvalue>' kubectl get pods -n $ns -l $label -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' | xargs -I {} kubectl -n $ns logs {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ラベルセレクターでKubernetesポッドを検索し、接続します

名前空間（ your-namespace



）と、必要なポッドを見つけるのに役立つラベルのリクエストを指定し、名前で（見つかった最初のポッドに）接続します。 8080



を希望の炉床ポートに置き換えます。

 $ ns='<your-namespace>' label='<yourkey>=<yourvalue>' kubectl -n $ns get pod -l $label -o jsonpath='{.items[1].metadata.name}' | xargs -I{} kubectl -n $ns port-forward {} 8080:80
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

kubectl



によるノード（ノード）のkubectl

jq



とJSON出力の組み合わせにより、作成時までにすべてのリソースをフィルタリングするなど、複雑なクエリを作成できます。

Kubernetesの炉の数を数える

多くの場合、高レベルの統計はデバッグに役立ちます。 このコマンドは、各ノードのすべての囲炉裏の数をカウントします。

 $ kubectl get pods --all-namespaces -o json | jq '.items[] | .spec.nodeName' -r | sort | uniq -c
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ラベルフィルタリングノード

ラベルクエリはノードにも使用できます。 このアプローチは、特定の制限を必要とする展開を構成するときによく使用されます。 セレクターの詳細については、 kubectl explain deployment.spec.selector



出力を参照してください。

 $ kubectl get nodes -l 'master' or kubectl get nodes -l '!master'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Kubernetesオブジェクトの--show-labels



引数を使用して、すべてのラベルを表示できます。

 $ kubectl get nodes --all-namespaces --show-labels
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各ノードのすべての炉床のリスト

Kubernetesノードの名前と、このノードで実行されている炉床のすべての名前のリストを含むJSONドキュメントが生成されます。 デバッグ時に非常に便利なコマンド：

 $ kubectl get pods --all-namespaces -o json | jq '.items | map({podName: .metadata.name, nodeName: .spec.nodeName}) | group_by(.nodeName) | map({nodeName: .[0].nodeName, pods: map(.podName)})'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Kubernetesホストの外部IPの取得

 $ kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name} {.status.addresses[?(@.type=="ExternalIP")].address}{"\n"}{end}'
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注 ：ブログで、コンソールからのKubernetesの操作に関するCoreOSの別の記事の翻訳を読んでください：「 CoreOSからのファブリックと統合を使用したKubernetesノードへのSSHアクセスの自動化 」、 および 「 Kubernetesを使用 する場合の便利なユーティリティ 」主にコンソールツール）。

ソース

• Kubernetes kubectlのヒントとコツ （CoreOSのDuffie Cooley、2017年5月15日）
• 「 Kubectl Unix Pipes：複数のクラスターを簡単に管理する 」（CoreOSのDuffie Cooley、2017年6月8日）