Kubernetes を一から構築する

Kubernetes をソースからビルドする方法は、コンポーネントの学習や、パッチを適用したコンポーネントのテストに適している。本番クラスターには、サポートされたアップグレード手順、証明書のローテーション、バックアップからの復旧、ネットワーク、ストレージ、監視、インシデント対応手順も必要になる。

オブジェクトモデルと API パス #

Kubernetes は、クラスターの操作をリソースに対する CRUD としてモデル化する。各オブジェクトは、 UID、型、その型の中で一意な名前、インデックスを利用した選択のためのラベル、および識別には使われないメタデータのためのアノテーションを持つ。

リソースは API グループに分類される。

コアグループは /api/v1 以下で公開される。
名前付きグループは /apis/<group>/<version> 以下で公開される。

GET /api、GET /apis、/openapi/v3 などのディスカバリーエンドポイントは、クラスターがサポートするリソースを記述する。リソース一覧の各エントリーは、正規名、kind、名前空間のスコープ、verb、および pvc などの短縮名を公開する。

一般的な verb は次のように HTTP メソッドに対応する。

get、list、watch は GET を使用する。
create は POST を使用する。
update は PUT を使用する。
patch は PATCH を使用する。
delete と deletecollection は DELETE を使用する。

このオブジェクトモデルにより、Service は多数の Pod をバックエンドとする安定したエンドポイントになる一方、Pod 自体は一時的な存在であり、再作成されると新しいネットワーク ID を取得する。

バイナリのビルドと記録 #

ドキュメントで指定された Go ツールチェーンを使い、タグが付けられた Kubernetes のソースリビジョンからビルドする。すべてのバイナリについて、ソースコミット、ツールチェーンのバージョン、ビルドフラグ、チェックサムを記録する。選択したコマンドは make WHAT=... でビルドするか、リリース用ビルドプロセスを使用する。コントロールプレーンのホストに出所不明のバイナリをダウンロードしてはならない。

コントロールプレーンの構築 #

奇数台で構成した etcd クォーラムに API の状態を保存する。ピア間およびクライアントとの通信を TLS で保護し、スナップショットからの復元をテストし、クライアントからの直接アクセスを制限する。依存関係に従い、次の順序でコントロールプレーンを起動する。

etcd、証明書、サービスアカウント署名鍵、ネットワーク到達性を確立する。
サーバー証明書、etcd クライアント認証情報、Service CIDR、Admission 設定、監査ポリシーを指定して kube-apiserver を起動する。
個別の ID を使って kube-controller-manager と kube-scheduler を起動する。
初期ブートストラップ専用の管理用 kubeconfig を設定する。
CNI 実装をインストールしてから、kubelet を参加させる。

kubelet には、ノード ID、API エンドポイント、CRI 互換ランタイム、CNI 設定、および整合する Pod CIDR の前提が必要である。Service のルーティングは、kube-proxy または代替データプレーンによって実装される。

コントロールプレーンの各コンポーネントには、個別の役割がある。

etcd はクラスターの状態を保存する。
kube-apiserver は認証済みのすべてのリクエストを受け付ける窓口である。
kube-controller-manager は望ましい状態を実際の状態へと調整する。
kube-scheduler は保留中の Pod を配置するノードを選択する。
kubelet は各ノードを API サーバーの状態と一致させる。
kube-proxy は各ノードで Service のルーティングを実装する。

API リクエストの保護 #

API サーバーは HTTPS リクエストを受け付ける。リクエストは次の段階をたどる。

認証。クライアント証明書、サービスアカウントトークン、または OIDC を通じて、リクエストをユーザー名、UID、グループ、任意の追加属性に関連付ける。
認可。ID、verb、リソース、名前空間、名前を評価する。
Admission。リクエストを検証または変更する。
リクエストによってクラスターの状態が変化する場合、etcd に永続化する。

意図的に設計された代替方式がない限り、Node と RBAC による認可を有効にする。匿名アクセスを無効化し、静的トークンファイルを避け、コンポーネントごとに ID を分離し、秘密鍵をソース管理の対象外に置く。クラスターが運用可能であると判断する前に、 /readyz、DNS、Service のルーティング、リソース制限、ノード障害、証明書の更新、 etcd からの復元を検証する。