kubectlの挙動について: 犬小屋は、終わらない(IT)

2025年11月07日

kubectlの挙動について

質問

kubectlの挙動について詳細に解説してください。
裏で何をしていますか？

解答

とても鋭い質問です。
kubectl は単なる CLI（コマンドラインツール）ではなく、Kubernetes APIサーバへのクライアントとして動作しています。
表向きは「Podを作る」「状態を確認する」コマンドですが、裏では Kubernetes クラスタ内部で複雑な通信やデータ変換を行っています。
以下で、kubectl の 内部挙動を「リクエストの流れ」から詳細に 解説します。

1. kubectl の役割

kubectl は、Kubernetes の中核コンポーネントである APIサーバ（kube-apiserver） に
リクエストを送るための公式クライアントです。

つまり：

kubectl は 「人間 → APIサーバ」間の通訳 のような存在です。

2. kubectl 実行時の全体的な流れ

例：

kubectl apply -f deployment.yaml

実際の裏側で何が起きているか、順を追って説明します。

(1) 設定ファイル（kubeconfig）の読み込み

デフォルトパス：~/.kube/config
内容には以下が含まれています：
- api-server のURL（例：https://10.0.0.1:6443）
- クラスタ名
- 認証情報（証明書・トークン）
- 現在のコンテキスト（current-context）

kubectl は最初にこれを読み込み、
「どのクラスタに」「どんな権限で」アクセスするかを判断します。

(2) コマンドを解析（CLI引数 → REST APIリクエスト化）

例：

kubectl get pods -n default

このコマンドは内部的に以下のように変換されます：

HTTP GET https://<api-server>/api/v1/namespaces/default/podsAuthorization: Bearer <token>Accept: application/json

つまり、kubectl は REST API クライアントとして動作しているのです。

(3) APIサーバとの通信

通信は HTTPS (TLS) を使用して行われます。

通信先：kube-apiserver
認証：
- サービスアカウントトークン
- クライアント証明書
- kubeconfig 内の設定による
認可：
- APIサーバは RBAC (Role-Based Access Control) に基づいてアクセスを判定

(4) APIサーバでの処理（etcdまでの流れ）

APIサーバはリクエストを受け取ると、次のように処理します：

認証・認可チェック
Admission Controller でポリシー検証（例：リソース制限）
etcd（Kubernetes のデータストア）への反映または参照
結果をJSONで返却

(5) kubectl 側で結果の整形・表示

APIサーバから返ってきたJSONデータを、kubectl は整形します。

たとえば：

kubectl get pods -o wide

では、受け取ったJSONをテーブル形式に整えて標準出力に表示します。

出力オプション：

-o json：生データそのまま
-o yaml：人間が読みやすく
-o wide：追加情報を含めた整形出力

3. 「apply」や「create」時の裏側

(例) `kubectl apply -f deployment.yaml`

裏では以下の処理をしています：

YAMLをローカルで読み込み
JSON形式に変換
APIサーバへ PATCH または POST リクエスト送信
- リソースが存在しない場合 → POST（新規作成）
- 既に存在する場合 → PATCH（差分更新）
APIサーバが etcd を更新
Controller Manager や Scheduler が動作し、リソースの状態をDesired Stateに調整

つまり：

kubectl apply は「状態宣言ファイルをAPIサーバに送信するだけ」であり、
実際のPod起動やReplicaSetの調整は Controller によって行われます。

4. 「監視系」コマンド（例：`kubectl get pods -w`）

-w（watch）オプションをつけると、
APIサーバに Watchリクエスト を投げ、リアルタイムにイベントをストリーム受信します。

通信的には：

GET /api/v1/namespaces/default/pods?watch=true

これにより、Podの追加・削除・変更が即座に反映されます。

5. kubectl proxy の仕組み

kubectl proxy を実行すると、ローカルでHTTPサーバを立てます。

ローカルポート（例：8001）で待ち受け
受け取ったHTTPリクエストを、APIサーバに中継（プロキシ）
認証情報を自動的に付与

→ curl http://localhost:8001/api/v1/pods のように、
直接 kubectl 経由で API にアクセスできるようになります。

6. kubectl 内部の構造（ソースコード観点）

kubectl は Go言語 で書かれています。
内部的に client-go ライブラリを使用しています。
client-go は REST API 呼び出し、キャッシュ、Watch処理、認証をすべてカプセル化しており、
他のアプリケーションでも Kubernetes API と通信する際に使われます。

構成イメージ：

kubectl └── client-go      ├── rest      ├── cache      ├── watch      ├── auth      └── transport (TLS通信)

7. まとめ

段階	kubectlの動作	裏側での実際の処理
1	kubeconfig 読み込み	クラスタ情報・認証情報をロード
2	CLIコマンド解釈	REST API リクエストを生成
3	HTTPS 通信	kube-apiserver へ送信
4	APIサーバ処理	etcd の更新・参照、Admission制御
5	結果受信・整形	JSONデータを整えて表示
6	watch モード	ストリーミングで変更検知