翻訳者のまえがき ：この記事は、Kubernetesクラスターでコマンドを実行するためのコンソールツール-kubectlを使用したCoreOSプロジェクト （出版物の最後のリンクを参照）の2つの資料の翻訳を組み合わせたものです。 Mac OS Xの元の作者によって提供されたリストはLinuxに適合し、YAML形式は他のリストで修正され、すべての資料を読みやすくするために字幕が追加されました。
Kubectlは、Kubernetesユーザーになじみのあるツールで、優れた機能を備えています。 それらをマスターするには時間がかかりますが、多くの人が考えているよりも強力なツールであることがわかります。
kubectl使用する際の機能を改善するための一連のヒントを
kubectlます。 Kubernetes公式ドキュメントセクションの
チートシートも確認してください！
シェルでの自動補完
kubectlは、bashとzshの優れた自動補完機能が組み込まれています。これにより、コマンド、フラグ、ネームスペースやハース名などのオブジェクトの操作が大幅に簡素化されます。 ドキュメントには、それを含めるための
既製の指示があります。 また、以下のGIFアニメーションは、自動補完の仕組みを示しています。
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を使用 する場合の便利なユーティリティ 」主にコンソールツール）。ソース