kubectl と kubeconfig の仕組み

この記事ではクラスタを操作するコマンドの kubectl と、その接続先を決めるファイルの kubeconfig の仕組みを、図で説明します。kubectl がどうやって接続するクラスタを選んでいるのか、get・describe・explain の 3 つのコマンドをどう使い分けるのかがわかります。後半では第2回の手順で 2 つのクラスタを作り、コンテキストを切り替えて接続先が変わることを確かめる手順を示します。

kind で検証用クラスタを作った第2回の内容を前提にしています。まだの方は先にこちらをどうぞ。

基本仕様 第2回 kind で検証用のクラスタを作るDocker のコンテナをノードにして、手元のマシンに Kubernetes のクラスタを作るツール kind の仕組みを図で説明します。kind create cluster で何が起きるかを押さえ、シングルノードとマルチノードのクラスタを作って、ノードの正体が Docker のコンテナであることを確かめる手順を紹介します。

以下の図は、kubectl が kubeconfig を読んで接続先のクラスタを選ぶ様子を表しています。後半の「手元で試す」で 2 つのクラスタを作り、kind-multi-node に切り替えたときの例です。

タップで拡大クリックで拡大 （図を拡大表示する）

kubectl はフラグで指定しなければ、kubeconfig の現在のコンテキストが指すクラスタの kube-apiserver に接続します。コンテキストを切り替えれば、同じコマンドでも別のクラスタを操作することになります。

kubectl と kubeconfig とは

kubectl は Kubernetes API を使ってクラスタのコントロールプレーンとやり取りするためのコマンドラインツールです。Kubernetes API はコントロールプレーンの中心にある kube-apiserver が公開している HTTP の API です。利用者もクラスタの各部分も kube-apiserver を通してやり取りします。kube-apiserver はクラスタの窓口になるコンポーネントとして、第2回で名前だけ紹介しました。

参考：Command line tool (kubectl) | Kubernetes、The Kubernetes API | Kubernetes

Docker を使ったことがあれば、docker コマンドと Docker デーモン（dockerd）の関係に近いと考えるとつかみやすいでしょう。docker run などのコマンドを実行すると、docker は Docker API を使って dockerd にコマンドを送り、dockerd がそれを実行します。kubectl も同じく、コマンドを API のリクエストにして kube-apiserver に送ります。

参考：What is Docker? | Docker Docs、The Kubernetes API | Kubernetes

違うのは、kube-apiserver が受け取ったリクエストを自分ですべて実行するわけではない点です。第1回で見たように、Kubernetes に渡すのは望ましい状態です。それを読んで実際に Pod を作ったりコンテナを動かしたりするのは、コントローラーや kubelet です。各コンポーネントの役割は第4回で扱います。

参考：Kubernetes Components | Kubernetes、Controllers | Kubernetes

kubeconfig は クラスタへの接続のしかたを書いた設定ファイル の総称です。kubeconfig という名前のファイルがあるわけではありません。kubectl は既定では $HOME/.kube ディレクトリの config というファイルを kubeconfig として読みます。第2回で kind が接続情報を書き込んだのも、環境変数 KUBECONFIG を設定していなければこのファイルです。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、Quick Start | kind

なぜ kubectl と kubeconfig が必要なのか

kube-apiserver は HTTP の API を公開しているので、REST の呼び出し（URL とメソッドを指定して送る HTTP のリクエスト）で直接操作することもできます。ただし、多くの操作は kubectl のようなコマンドラインツールで行えます。kubectl がコマンドを API のリクエストに組み立ててくれるので、利用者はリクエストの形を覚えずに済みます。

参考：The Kubernetes API | Kubernetes

kube-apiserver に接続するには、少なくとも 2 つの情報が要ります。どこに接続するか（アドレスとポート）と、誰として接続するか（認証情報）です。kube-apiserver は TLS で保護された HTTPS で待ち受けていて、リクエストはまず認証の段階を通ります。認証の方法にはクライアント証明書（利用者が誰かを示す電子的な証明書）やトークン（認証に使う文字列）などがあります。kube-apiserver がリクエストを処理する流れは第40回で扱います。

参考：Controlling Access to the Kubernetes API | Kubernetes

これらは kubectl のフラグ（--server や --token など）でも渡せます。とはいえ、コマンドのたびに渡すのは手間です。しかも第2回のように、クラスタが 2 つ以上になることもあります。kubeconfig にクラスタと利用者の情報をまとめ、組み合わせに名前を付けておけば、名前を指定するだけでクラスタを切り替えられます。公式ドキュメントも、kubeconfig はクラスタ・利用者・Namespace を整理し、クラスタや Namespace をすばやく切り替えるためのものだと説明しています。Namespace は後の「kubeconfig の中身」で説明します。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、kubectl | Kubernetes

kubectl と kubeconfig の仕組み

kubectl のコマンドの形

kubectl のコマンドは次の形で書きます。

$ kubectl [command] [TYPE] [NAME] [flags]

参考：Command line tool (kubectl) | Kubernetes

それぞれの部分の意味を、次の表にまとめます。

参考：Command line tool (kubectl) | Kubernetes

たとえば kubectl get pod pod1、kubectl get pods pod1、kubectl get po pod1 は、どれも同じ結果になります。クラスタで使えるリソースの種類の一覧は kubectl api-resources で表示できます。

この形に当てはまらないコマンドもあります。kubectl config view のように command の後にサブコマンドを続けるものや、kubectl explain pods.spec.restartPolicy のように TYPE の後にフィールド名を . でつなぐものです。

参考：Command line tool (kubectl) | Kubernetes、kubectl api-resources | Kubernetes、kubectl config | Kubernetes、kubectl explain | Kubernetes

get・describe・explain の違い

リソースを見るときによく使うのが、get・describe・explain の 3 つのコマンドです。3 つの違いを次の表にまとめます。

参考：kubectl get | Kubernetes、kubectl describe | Kubernetes、kubectl explain | Kubernetes

kubectl get は同じ種類のリソースを 1 つ以上取り出すときに使います。Namespace に属する種類のリソースでは、-n（--namespace）で Namespace を指定しなければ、現在のコンテキストの Namespace のものだけが表示されます（Namespace は後の「kubeconfig の中身」で説明します）。-o（--output）で表示の形を変えられ、-w（--watch）を付けると、一覧を表示したあとも変化を追い続けます。止めるときは Ctrl+C を押します。

kubectl describe は 1 つのリソースに関係するさまざまな情報をまとめて見せるコマンドです。そのために kube-apiserver の API を何回か呼び出すことがあります。たとえば kubectl describe node はノードそのものの情報に加えて、そのノードで動いている Pod の概要や、そのノードについてのイベントも表示します。イベントはクラスタのどこかで起きた出来事の報告です。イベントを使って原因を調べる方法は第41回で扱います。

参考：Command line tool (kubectl) | Kubernetes、kubectl get | Kubernetes、kubectl describe | Kubernetes、kubectl | Kubernetes、Event | Kubernetes API Reference

kubectl explain が表示する説明は、kubectl に組み込まれたものではありません。接続先のクラスタから OpenAPI の形式で取り出したもの です。OpenAPI はクラスタが提供している API の仕様を書き表す形式で、Kubernetes のクラスタは自分が提供する API の仕様を公開しています。フィールドは pods.spec.containers のように、リソースの種類からフィールド名を . でつないで指定します。--recursive を付けると、フィールドの中のフィールドまで一覧します。

参考：kubectl explain | Kubernetes、The Kubernetes API | Kubernetes

kubectl get の -o に指定できる主な形式を、次の表にまとめます。何も指定しなければ、人が読みやすいテキストの形式で表示されます。

参考：Command line tool (kubectl) | Kubernetes

-o yaml で表示される中身（spec と status など）の読み方は、第5回で扱います。

kubeconfig の中身

kubeconfig は接続先のクラスタ、利用者、その 2 つを組み合わせたコンテキストを並べたファイルです。kubeconfig の主な項目を、次の表にまとめます。

参考：kubeconfig (v1) | Kubernetes、Organizing Cluster Access Using kubeconfig Files | Kubernetes、Controlling Access to the Kubernetes API | Kubernetes

コンテキストの cluster と user には、アドレスや認証情報そのものではなく clusters と users に付けた名前を書きます。つまりコンテキストは どのクラスタに、どの利用者として接続するかを名前で指す組み合わせ です。1 つのクラスタや 1 人の利用者を、複数のコンテキストから指すこともできます。users の名前は kubeconfig の中で認証情報を指すために付ける名前です。クラスタの側で利用者の権限をどう扱うかは第38回で扱います。

参考：kubeconfig (v1) | Kubernetes、Configure Access to Multiple Clusters | Kubernetes

コンテキストの namespace は Namespace を指定しないリクエストで使う Namespace で、書かなくても構いません。Namespace は 1 つのクラスタの中でリソースをグループに分ける仕組みです。クラスタには最初から default や kube-system などの Namespace があり、default はほかの Namespace を指定しなかったリソースが入る Namespace です。ただしノードのように、そもそも Namespace に属さない種類のリソースもあります。コンテキストに namespace が無いときにどの Namespace が使われるかは、このメディアで確かめた範囲の公式ドキュメントには明記されていません。default の説明から、default が使われると考えられます。Namespace の仕組みは第37回で扱います。この回ではコンテキストに Namespace も含められる、とだけ覚えておけば十分です。

参考：kubeconfig (v1) | Kubernetes、Namespaces | Kubernetes、Share a Cluster with Namespaces | Kubernetes、Organizing Cluster Access Using kubeconfig Files | Kubernetes

以下の図は、公式ドキュメントの例から 2 つのコンテキストを抜き出して、kubeconfig の中で各項目がどう指しているかを表しています。

タップで拡大クリックで拡大 （図を拡大表示する）

コンテキストが clusters と users の項目を 1 つずつ指し、current-context がコンテキストを 1 つ指します。kubectl はこのつながりをたどって、接続先と認証情報を決めます。

以下は、図と同じ例の kubeconfig を表示したときの出力です。公式ドキュメントでは use-context で dev-frontend に切り替えたあと、例のファイル config-demo を指定して kubectl config --kubeconfig=config-demo view --minify を実行しています。その出力例をそのまま引用します。--minify は現在のコンテキストで使わない情報を表示から除くオプションです。

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
current-context: dev-frontend
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file

参考：Configure Access to Multiple Clusters | Kubernetes、kubectl config view | Kubernetes

current-context が dev-frontend なので、contexts の dev-frontend が使われます。そのコンテキストが指す development のクラスタ（server: https://1.2.3.4）に、developer の利用者として接続します。fake-ca-file などは公式ドキュメントの例の値で、実際には証明書のファイルのパスを書きます。ファイルではなく証明書の中身を Base64 で符号化して書くときは、certificate-authority-data のように -data を付けた項目を使います。kind: Config は、このファイルが kubeconfig であることを表す項目です。preferences は v1.37 時点のリファレンスで v1.34 から非推奨とされ、Kubernetes のどのコンポーネントも使っていない項目です。

参考：Configure Access to Multiple Clusters | Kubernetes、kubeconfig (v1) | Kubernetes

接続先が決まる順番

kubectl は kubeconfig とコマンドラインのフラグから接続先を決めます。決め方には優先順位があり、フラグが kubeconfig の値より優先されます。

以下の図は、kubectl のコマンドを実行してから kube-apiserver にリクエストが届くまでの流れを表しています。

タップで拡大クリックで拡大 （図を拡大表示する）

1 から 4 の順に kubectl の中で接続先が決まり、最後に kube-apiserver にリクエストが届きます。各段階で何を見ているかを、次の表にまとめます。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、kubectl config | Kubernetes

リクエストを受け取った kube-apiserver は、TLS の接続ができたあと、まず認証（誰からのリクエストか）を確かめ、次に認可（その操作をしてよいか）を確かめます。この先の流れは第40回で扱います。

参考：Controlling Access to the Kubernetes API | Kubernetes

第2回で毎回付けた --context は、段階 2 でこの優先順位を使っていたことになります。--context はそのコマンド 1 回だけに効き、kubeconfig は書き換えません。一方、現在のコンテキストを変える kubectl config use-context は、kubeconfig のファイルの current-context を書き換えます。そのため、以降に --context を付けずに実行したコマンドは、すべて切り替えた先のクラスタに接続します。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、kubectl config use-context | Kubernetes

環境変数 KUBECONFIG には複数のファイルを並べられます（Linux と macOS では : 区切り、Windows では ; 区切り）。kubectl はそれらをまとめて 1 つの設定として扱い、同じ項目が複数のファイルにあるときは、先に並べたファイルの値を使います。同じ名前の項目（たとえば同じ名前の利用者）は、最初のファイルの中身だけを使い、ほかのファイルの中身と混ぜ合わせません。kubectl config のコマンドで値を変えると、その項目が書かれているファイルが書き換わります。新しい項目は並べたファイルのうち存在する最初のファイルに書き込まれます。この回の手順では KUBECONFIG は使いません。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、kubectl config | Kubernetes

kubeconfig を見たり書き換えたりするのは kubectl config のサブコマンドです。この回で使うものを次の表にまとめます。

参考：kubectl config | Kubernetes、kubectl config view | Kubernetes

手元で試す

ここまでの内容を、手元の kind のクラスタで試す手順を示します。2 つのクラスタを作り、get・describe・explain を使ったあと、コンテキストを切り替えて接続先が変わることを確かめます。試す環境は次のとおりです。

参考：Release v0.33.0 · kubernetes-sigs/kind、Version Skew Policy | Kubernetes

kind でクラスタを作る手順は、以下の記事で解説しています。この回ではシングルノードとマルチノードの両方のクラスタを使います。

基本仕様 第2回 kind で検証用のクラスタを作るDocker のコンテナをノードにして、手元のマシンに Kubernetes のクラスタを作るツール kind の仕組みを図で説明します。kind create cluster で何が起きるかを押さえ、シングルノードとマルチノードのクラスタを作って、ノードの正体が Docker のコンテナであることを確かめる手順を紹介します。

2 つのクラスタを作る

クラスタを作る前に、現在のコンテキストを確かめます。仕事などでほかのクラスタを使っている場合に、最後に元へ戻すためです。

$ kubectl config current-context

名前が表示されたら控えておきます。名前が表示されなければ、控える必要はありません（現在のコンテキストが無いときの表示は、リファレンスには書かれていません）。

参考：kubectl config current-context | Kubernetes

続けて、第2回と同じ手順でシングルノードとマルチノードのクラスタを作ります。第2回のクラスタが残っていれば、作り直さずにそのまま使えます。kind get clusters で kind と multi-node が表示されるかを確かめてください。

マルチノードのクラスタには第2回と同じ次の設定ファイルを使います。公式ドキュメントの例をそのまま引用しています。kind-multi-node.yaml という名前で、コマンドを実行するディレクトリに保存します。

# three node (two workers) cluster config
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

参考：Quick Start | kind

$ kind create cluster
$ kind create cluster --name multi-node --config kind-multi-node.yaml

第2回で見たとおり、kind は KUBECONFIG を設定していなければ $HOME/.kube/config に接続情報を書き込みます。kind のクラスタ名（kind、multi-node）と、kubeconfig の中のコンテキスト名は別のものです。公式ドキュメントの例では、クラスタ名 kind のコンテキストが kind-kind、クラスタ名 kind-2 のコンテキストが kind-kind-2 です。この例に倣うと、コンテキスト名は kind-kind と kind-multi-node になります。

参考：Quick Start | kind

kubeconfig の中身を見る

kubeconfig にあるコンテキストを一覧します。

$ kubectl config get-contexts

一覧に kind-kind と kind-multi-node が含まれていれば、kind が 2 つのクラスタの接続情報を書き込んでいます。ほかのクラスタの接続情報がもともとあれば、それも並びます。

参考：kubectl config get-contexts | Kubernetes、Quick Start | kind

次に、kubeconfig の設定全体を表示します。

$ kubectl config view

clusters・contexts・users・current-context が並んでいるはずです。kind の Quick Start は、kind が書き込んだ設定を使い、--context kind-kind を付けるだけでクラスタを操作しています。そのため、kind-kind と kind-multi-node のコンテキストと、それぞれが指すクラスタと利用者の項目も書き込まれているはずです。コンテキストに namespace の行が無いこともあります。namespace は省略できる項目だからです。

clusters の server を見比べてみてください。第2回で見たように、kind は既定で kube-apiserver をループバックアドレス 127.0.0.1 の空いているポートからランダムに選んだポートで公開します。そのため、2 つのクラスタの server は、アドレスが同じでポートが違うはずです。

参考：kubectl config view | Kubernetes、kubeconfig (v1) | Kubernetes、Configuration | kind

--raw を付けなければ、証明書のデータ（-data の付いた項目）はそのままの値では表示されないと考えられます。公式ドキュメントの出力例では certificate-authority-data: REDACTED と表示されていますが、同じ例でトークンはそのまま表示されています。手元での伏せ方の表記もこの例と同じとは限りません。--raw を付けるとそのままの値が表示されます。--raw を付けないときも認証情報が含まれることがあるので、出力を人に見せないでください。仕事のクラスタの接続情報も同じファイルにあれば一緒に表示されるので、画面共有のときは特に注意します。

参考：Namespaces Walkthrough | Kubernetes、kubectl config view | Kubernetes

最後に、現在のコンテキストを確かめます。

$ kubectl config current-context

kind がクラスタを作ったときに現在のコンテキストを切り替えるかどうかは、kind の Quick Start には書かれていません（第2回でも触れました）。ここで表示された名前と、クラスタを作る前に控えた名前を比べると、自分の環境で切り替わったかどうかを確かめられます。

参考：kubectl config current-context | Kubernetes、Quick Start | kind

get でノードと Namespace を一覧する

ここからはマルチノードのクラスタを --context で指定して操作します。現在のコンテキストがどちらのクラスタを指していても、同じ結果になるようにするためです。まず、ノードを一覧します。

$ kubectl get nodes --context kind-multi-node

ノードが 3 つ表示されるはずです。NAME 列がノードの名前で、次の describe で使います。STATUS 列は Ready になっているはずです。この列が何を表すかは、次の describe で確かめます。Ready になっていなければ、第2回と同じく少し待ってからもう一度実行します。

参考：kubectl get | Kubernetes、Node Status | Kubernetes

同じ一覧を、-o wide を付けて表示します。

$ kubectl get nodes -o wide --context kind-multi-node

-o wide を付けると、テキストの形式のまま追加の情報が列として加わります。付けなかったときと見比べて、どの列が増えたかを確かめてみてください。

参考：Command line tool (kubectl) | Kubernetes

続けて、Namespace を一覧します。

$ kubectl get namespaces --context kind-multi-node

公式ドキュメントによると、Kubernetes のクラスタには最初から default、kube-node-lease、kube-public、kube-system の 4 つの Namespace があります。一覧にこの 4 つが含まれているはずです。ほかの名前が並んでいても問題ありません。

参考：Namespaces | Kubernetes

describe でノードを詳しく見る

kubectl get nodes の NAME 列に表示された名前を 1 つ選び、そのノードを詳しく表示します。どのノードを選んでも構いませんが、後で説明する kube-apiserver の Pod を見たいときは、コントロールプレーンのノードを選びます。名前で見分けがつかなければ、3 つのノードを順に表示してみてください。<ノードの名前> には選んだ名前を入れます。

$ kubectl describe node <ノードの名前> --context kind-multi-node

get の 1 行に比べて、ずっと多くの情報が表示されます。公式ドキュメントによると、ノードの状態にはアドレス、状態の詳細（Conditions）、資源の量、ノードの情報などが含まれます。Conditions の Ready は、True ならそのノードが正常で Pod を受け入れられる状態であることを表します。表示の中から Ready の行を探し、True になっているかを確かめてください。

参考：Node Status | Kubernetes、kubectl describe | Kubernetes

kubectl describe node は、そのノードで動いている Pod の概要と、そのノードについてのイベントも表示します。コントロールプレーンのノードを選んだ場合は、まだ Pod を作っていなくても、Pod の一覧に kube-apiserver などの Pod が並ぶはずです。第2回で見たとおり、kube-apiserver などは、kubeadm init が /etc/kubernetes/manifests に書き出したマニフェストから、kubelet が起動する Pod です。このように kubelet が直接起動する Pod を static Pod と呼びます。kubelet は static Pod ごとに、kube-apiserver から見える写し（mirror Pod）を作るので、kubectl からも見えます。公式ドキュメントによると、コントロールプレーンのコンポーネントの mirror Pod は kube-system の Namespace にあります。static Pod と mirror Pod は、ここでは名前だけ覚えておけば十分です。ワーカーのノードを選んだ場合は、kube-apiserver の Pod は並ばないはずです。ただし Pod の一覧が空とは限りません。どの Pod が何をしているかは第4回で扱います。

参考：Command line tool (kubectl) | Kubernetes、Static Pods | Kubernetes、kubeadm init | Kubernetes（/etc/kubernetes/manifests へのマニフェストの書き出し。第2回と同じ根拠）

explain でフィールドの意味を調べる

Pod のマニフェストに書けるフィールドを調べます。

$ kubectl explain pods --context kind-multi-node

Pod というリソースの説明と、Pod のフィールドの一覧が表示されます。explain の説明は接続先のクラスタから取り出すので、explain でもクラスタへの接続が必要です。

参考：kubectl explain | Kubernetes

次に、第1回で見た restartPolicy を調べます。

$ kubectl explain pods.spec.restartPolicy --context kind-multi-node

v1.37 時点の API リファレンスでは、Pod の spec.restartPolicy は「One of Always, OnFailure, Never. … Default to Always.」と説明されています。explain はこのフィールドの説明をクラスタから取り出して表示するので、同じ趣旨の説明が表示されると考えられます。restartPolicy は、第1回の Deployment のマニフェストでは template の下の spec（Pod の spec）に書くフィールドでした。第1回で読んだ値と既定値を、クラスタに直接尋ねて確かめられるわけです。

参考：Pod | Kubernetes API Reference、kubectl explain | Kubernetes

ここまでの 3 つのコマンドを、何を知りたいときに使うかで整理すると次のとおりです。

コンテキストを切り替えて接続先を変える

現在のコンテキストを、シングルノードのクラスタに切り替えます。

$ kubectl config use-context kind-kind
$ kubectl config current-context

kubectl config current-context に kind-kind と表示されれば、kubeconfig の current-context が書き換わっています。公式ドキュメントの例でも、use-context のあとに current-context を実行すると、切り替えた先のコンテキストの名前が表示されています。

参考：kubectl config use-context | Kubernetes、Namespaces Walkthrough | Kubernetes

今度は --context を付けずに、ノードを一覧します。あわせて、現在のコンテキストで使う接続情報だけを表示します。

$ kubectl get nodes
$ kubectl config view --minify

ノードは 1 つだけ表示されるはずです。シングルノードのクラスタに接続しているからです。kubectl config view --minify には kind-kind のコンテキストと、そのコンテキストが指すクラスタと利用者だけが表示されます。server のポートを覚えておきます。

参考：kubectl get | Kubernetes、kubectl config view | Kubernetes

マルチノードのクラスタに切り替えて、同じコマンドを実行します。

$ kubectl config use-context kind-multi-node
$ kubectl get nodes
$ kubectl config view --minify

同じ kubectl get nodes なのに、今度はノードが 3 つ表示されるはずです。kubectl config view --minify の server のポートも、さっきとは違うはずです。コマンドは同じでも、現在のコンテキストによって接続先のクラスタが変わります。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、Configuration | kind

最後に、--context と現在のコンテキストの関係を確かめます。現在のコンテキストは kind-multi-node のまま、--context でシングルノードのクラスタを指定します。

$ kubectl get nodes --context kind-kind
$ kubectl config current-context

kubectl get nodes には、ノードが 1 つだけ表示されるはずです。--context が current-context より優先されるからです。そのあとの kubectl config current-context には、kind-multi-node と表示されるはずです。--context はそのコマンドだけに効き、kubeconfig を書き換えないことがわかります。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、kubectl | Kubernetes

片付け

最初に名前を控えた場合は、現在のコンテキストを元に戻します。<控えた名前> には最初に kubectl config current-context で表示された名前を入れます。

$ kubectl config use-context <控えた名前>

参考：kubectl config use-context | Kubernetes

作った 2 つのクラスタを削除し、消えたことを確かめます。

$ kind delete cluster
$ kind delete cluster --name multi-node
$ kind get clusters

kind delete cluster は存在しないクラスタを指定してもエラーを返しません。第2回と同じく、kind get clusters で 2 つのクラスタが表示されなくなったことを確かめます。

参考：Quick Start | kind

続けて、kubeconfig のコンテキストを一覧します。

$ kubectl config get-contexts

kind の Quick Start には、クラスタを削除したときに kubeconfig の項目がどうなるかは書かれていません。一覧に kind-kind や kind-multi-node が残っていたら、kubectl config delete-context で消します。

$ kubectl config delete-context kind-kind
$ kubectl config delete-context kind-multi-node

クラスタと利用者の項目は kubectl config get-clusters・kubectl config get-users で一覧できます。kind のクラスタのものが残っていれば、一覧に表示された名前を指定して kubectl config delete-cluster・kubectl config delete-user で消します。

最初に名前を控えていなかった場合、現在のコンテキストが消したクラスタのコンテキストを指したまま残ることがあります。kubectl config current-context に kind-kind などが表示されたら、kubectl config unset current-context で現在のコンテキストの設定を外します。

$ kubectl config unset current-context

参考：Quick Start | kind、kubectl config | Kubernetes、kubectl config unset | Kubernetes

注意点

kubectl と kubeconfig を使い始めるときにつまずきやすい点と、バージョンで変わる点を、次の表にまとめます。

参考：Organizing Cluster Access Using kubeconfig Files | Kubernetes、kubectl config use-context | Kubernetes、kubectl config view | Kubernetes、Command line tool (kubectl) | Kubernetes、Install and Set Up kubectl on macOS | Kubernetes、Version Skew Policy | Kubernetes

「クラスタを取り違えない」の対策は公式ドキュメントの手順ではなく、このシリーズで決めた進め方です。第4回以降の「手元で試す」節でも、コマンドに --context を付けて、どのクラスタを操作しているかがわかるようにします。

関連記事

describe で見えた kube-apiserver などの Pod が、コントロールプレーンとノードの中で何をしているかについては、以下の記事で解説しています。

基本仕様 第4回 コントロールプレーンとノードの構成クラスタを形づくるコントロールプレーンとノードの構成を図で説明します。kube-apiserver・etcd・kube-scheduler・kube-controller-manager と、kubelet・コンテナランタイム・kube-proxy の役割を押さえ、kind のクラスタで kube-system の Pod を一覧して各コンポーネントと対応づける手順を紹介します。

kubectl explain で調べたフィールドを含め、マニフェストの構造（apiVersion・kind・metadata・spec・status）については、以下の記事で解説しています。

基本仕様 第5回 マニフェストと宣言的 API の仕組みKubernetes に渡すマニフェストの構造と、望ましい状態を書いて任せる宣言的 API の仕組みを図で説明します。apiVersion・kind・metadata・spec・status の役割と、spec と status を誰が書くのかを押さえ、kind のクラスタで kubectl explain を使い、Pod の spec と status を作成直後と数秒後で比べる手順を紹介します。

この回で使った検証用クラスタの作り方は、第2回で解説しています。

基本仕様 第2回 kind で検証用のクラスタを作るDocker のコンテナをノードにして、手元のマシンに Kubernetes のクラスタを作るツール kind の仕組みを図で説明します。kind create cluster で何が起きるかを押さえ、シングルノードとマルチノードのクラスタを作って、ノードの正体が Docker のコンテナであることを確かめる手順を紹介します。