Kubernetesアーキテクチャ：構成要素と制御の流れ、障害の切り分け

Kubernetesのアーキテクチャは、クラスターの状態を管理するコントロールプレーンと、コンテナ化されたワークロードを実行するワーカーノードに分かれます。利用者がAPIへ望ましい状態を送ると、API Serverが要求を処理し、controller、scheduler、kubeletがAPI上の状態を基にそれぞれの役割を果たします。コンテナランタイムは、kubeletからCRIを通じて受け取った要求を実行します。一台の「マスター」が全コンポーネントへ固定順序で命令する構造ではありません。

本稿では、API要求からPodの実行までをたどり、障害が起きたときにどの境界を調べればよいかを説明します。根拠はKubernetesの公式文書であり、クラウド事業者の内部通信を実測したものではありません。発行者はGuanceです。Guanceの製品文書は収集設定の参照先として扱い、Kubernetesの動作を証明する資料とは区別します。後半の三つの検証手順はすべて未実施で、観測結果や復旧時間はありません。

Podや宣言的管理、Dockerとの関係から確認したい場合は、先にKubernetesとはを参照してください。

論理構成と物理配置を分けて考える

公式のコンポーネント説明では、クラスターをコントロールプレーンと一つ以上のワーカーノードで構成します。自主管理ではチームが配置、アップグレード、復旧を担当し、マネージドサービスではその一部を事業者に任せます。コンポーネントを一台にまとめる構成も、複数ホストや可用性ゾーンに分ける構成もあります。

ネットワーク、ストレージ、クラウドとの連携は、採用する実装によって変わります。本稿の図は論理的な責任分担を表すものであり、EKS、GKE、AKS、プライベートクラスターすべてに共通する物理通信経路ではありません。実際の責任分界はサービス文書と契約で確認します。

コントロールプレーン：意図を保存し、状態を調整する

API Serverは共有状態への入口ですべての処理を実行する司令塔ではありません。Controllerは資源を繰り返し観察し、必要な変更を要求します。schedulerやkubeletもAPI状態を介して独立に動き、再試行や調整は非同期に進みます。

etcdも、任意のアプリや各コンポーネントが直接読み書きしてよい汎用業務データベースではありません。API状態を保持する役割に合わせ、アクセス制御、バックアップ、復旧を別途設計します。

ワーカーノード：Podの宣言を実行に移す

Container RuntimesはCRIの境界を説明しています。Docker Engine自体はCRIを実装しておらず、組み込みdockershimはKubernetes v1.24で削除されました。特定ランタイムやsocketパスを、全バージョンの共通既定値と考えないでください。

kubeletが実行するのは、設定されたprobeだけです。readiness成功はデータの正しさ、外部依存先、利用者の一連の操作の成功を保証しません。アプリのreadiness probeが未設定なら、Ready表示を業務チェック実施済みの証拠にすることもできません。

API要求からPodが動くまで

Deploymentを送信した場合の概念的な流れは、次のようになります。これは通信パケットの完全な順序ではありません。

1. クライアントがkubectlなどで望ましいオブジェクトをAPIへ送る。
2. API Serverが要求を処理し、受理されたAPI状態をetcdに保存する。クライアントがetcdへ直接書くわけではない。
3. ワークロードcontrollerが望ましい状態と現在状態を観察し、必要に応じてReplicaSetやPodを作成・調整する。
4. schedulerがNode未割り当てのPodを見つけ、resource request、制約、方針、利用可能なNodeから配置先を選ぶ。
5. 選ばれたNodeのkubeletが担当Podを確認し、CRIを通じてruntimeへコンテナの準備と実行を要求する。
6. kubeletがコンテナ状態とPod条件を更新し、設定済みprobeを実行する。ほかのコンポーネントと利用者は引き続きAPIから状態を読む。

クライアント → kube-apiserver ↔ etcd（API状態）
                     ↑
          ┌──────────┼──────────┐
          │          │          │
     controller   scheduler   kubelet
     監視/更新    監視/割当   担当Podの監視/状態更新
                                │
                                ▼
                       CRI互換runtime → コンテナ

矢印は公式の機構を整理した論理関係で、実験の通信記録ではありません。障害調査では、オブジェクト変更、Events、コンポーネントのログ・メトリクス、実行層の証拠を同じ時間帯で照合します。一回のstatus表示だけでは、原因コンポーネントを確定できません。

ワークロードの状態とトラフィックの経路

DeploymentはReplicaSetを通じてPodの宣言的更新を管理します。Deployment、ReplicaSet、Podは同じオブジェクトの別名ではありません。Serviceはアクセスの抽象化、EndpointSliceは宛先とその条件を表します。

endpointが存在するだけでリクエスト成功とはいえず、アプリの5xxだけでコントロールプレーン障害ともいえません。資源の識別情報と時刻をそろえ、一段ずつ仮説を確かめます。

通信とセキュリティの境界

コントロールプレーンとNodeの通信は、NodeからAPIへのアクセスと、API Serverからkubelet、Pod、Serviceへの経路を分けています。

• kubeletなどKubernetes APIを使うNode側コンポーネントはAPI Serverと通信する。認証、認可、転送の保護はそれぞれ確認する。
• runtimeは通常、ローカルCRIでkubeletの要求を受ける。runtime自身がKubernetes APIをwatchすると一般化しない。
• 認証成功は、すべてのオブジェクトに対する権限付与を意味しない。
• kubelet API、API ServerからNodeへの接続、トンネル、クラウド固有の接続方式は構成によって異なる。
• ポート、証明書、ServiceAccount、network policy、hardening手順は対象バージョンの文書に従う。

実験の生記録はアクセスを制限し、公開時には認証情報、kubeconfig、秘密鍵、顧客データ、内部アドレスを除きます。記事や画面画像にこれらの秘密情報を載せる必要はありません。

高可用性と障害ドメインを混同しない

コントロールプレーンを複数にしても、アプリの高可用性まで自動的に成立するわけではありません。kubeadmのHAトポロジはstacked etcdとexternal etcdを、複数ゾーンでの実行は障害ドメイン間の配置を扱います。層ごとの検討が必要です。

Pendingには、スケジューリング待ちだけでなく、Node割り当て後のイメージ取得やコンテナ準備も含まれます。一方、ResourceQuota違反ではAPIが403 Forbiddenで作成を拒否し、そもそも調査対象のPodが存在しない場合があります。

この表は調査の入口であり、自動的に根本原因を決めるツリーではありません。同じ症状が複数の境界で起きます。復旧時間や可用性の約束には、契約や固定条件の再現可能な試験が別途必要です。

オブザーバビリティで各層をつなぐ

公式のObservability文書は、コンポーネントとアプリのメトリクス、ログ、Traceを扱います。ログを集中保管するには、コンテナの置換後も残る収集・保持経路が必要です。

まず時間帯、cluster、namespace、workload、Pod UID、Nodeを固定します。オブジェクトの状態とowner関係を調べ、どの調整に差があるかを見ます。Eventsはスケジューリング、イメージ取得、probe変化の手掛かりですが、単独の根拠にはしません。関連コンポーネントのログ・メトリクスで範囲を絞り、修正後はアプリ要求と利用者結果も回復したかを確認します。

GuanceのKubernetes Integration、Prometheus discovery、ServiceMonitor / PodMonitorの対応フィールドは収集設定の入口です。権限、バージョン、属性対応、制限を対象環境で検証する必要があり、文書の存在をあらゆるクラスターでの動作確認と取り違えないでください。

三つの障害検証手順：すべて未実施

目的は障害の境界を切り分けることで、製品性能の比較や自動根本原因分析の証明ではありません。いずれにも実行結果、画面画像、所要時間の記録はありません。

共通の実行条件

非本番の使い捨てkindクラスター、または同等環境を使います。Kubernetes patch、kind、runtime、CNI、ホストOSとarchitectureを固定し、イメージのソースとdigest、manifest、resource constraint、probeを版管理します。コマンド、stdout/stderr、exit code、時刻、object YAML、Events、関連コンポーネントの証拠、cleanup結果を保存し、公開版から機密情報を除きます。さらに別のエンジニアが同じ入力で再実行します。

1. スケジューリングの境界

存在しないNode label、または満たせない条件を要求するPodを送信する計画です。phase、conditions、scheduler Events、候補Nodeを保存し、条件修正後の割り当ても観察します。「Nodeが決まらない」と「Nodeは決まったが実行に失敗した」を分けます。実際のPending状態、Eventの文言、割り当て時間はまだ観測していません。

2. Nodeとruntimeの境界

利用できないイメージdigestまたはtagを使う計画です。container state、Events、kubelet/runtime、registry要求を記録し、既知のイメージに戻します。スケジューリング成功は、イメージ取得やコンテナ起動の成功とは別です。ErrImagePull、ImagePullBackOffなどが実際に発生したという結果はありません。

3. readinessとEndpointSliceの境界

必ず失敗するreadiness probeとServiceを構成し、その後probeを修正する計画です。Pod Ready、probe結果、selector、EndpointSliceのアドレスとready/serving/terminating、ServiceのpublishNotReadyAddresses、実リクエストを記録します。

コンテナ実行、Pod readiness、アドレスの存在、通信対象としての資格、業務応答は別々の事実です。未準備のPodもEndpointSliceに残る場合があり、publishNotReadyAddressesの設定によってendpointがreadyと表示される場合もあります。状態変化の順序や復旧時間は未測定です。

生出力と独立した再実行の記録がそろうまでは「測定済み」「検証済み」や製品優位性の根拠に変えません。公式文書は機構を説明し、実験は記録した条件で観測できた事実を示します。

概念から実装へ進む

定義と適用範囲はKubernetesとはで確認できます。詳細は現行のArchitecture、Components、対象バージョンのsetup・security文書を使ってください。

商用監視の評価ではGuanceのKubernetes監視ソリューションを参照し、検証用クラスターでオブジェクト、メトリクス、ログ、権限と欠落を確認します。製品説明も概念図も、その検証を代替するものではありません。

一次資料

2026年10月27日に公式文書を基に技術的な機構を再確認しました。上記の実験は実施していません。

• Architecture、Components、Controllers
• Scheduler、Pod Lifecycle、Container Runtimes
• Deployment、Service、EndpointSlice、Probes
• ResourceQuota、Control Plane–Node Communication
• HA Topology、Multiple Zones、Observability
• CNCF Kubernetes project