Kubernetes and Cloud Native Associate (KCNA) #2 Kubernetes Fundamentals 1: アーキテクチャとコアリソース

#1 で試験の構造を押さえたので、この記事からは出題範囲に入っていきます。最初の到着地は Kubernetes Fundamentals です。このドメイン一つが KCNA の出題比重の 46% で、ほぼ半分を占めるので、ここで得点を確保すれば合格ラインの半分を埋めることになります。分量が大きいだけに 2 編に分けて、この #2 では クラスターアーキテクチャとコアリソース を、次の #3 では API・コンテナ・スケジューリングを扱います。

この記事が問う核心はシンプルです。Kubernetes クラスターがどんな部品で構成されていて、それぞれの部品が何をするのか、そして どのリソースがどの問題を解くのか です。KCNA はこの 2 つを役割マッチングの形で執拗に問います。

クラスターの全体像: control plane と worker node #

Kubernetes クラスターは 2 種類のノードに分かれます。control plane はクラスター全体の頭脳であり、worker node は実際にコンテナ (Pod) を動かす働き手です。この役割分担が Domain 1 の出発点であり、KCNA は「どのコンポーネントが control plane にあって、どのコンポーネントが worker node にあるのか」をよく問います。

小さなクラスターでは control plane と worker が一つのノードに同居することもありますが、本番では control plane を別ノードに分離し、複数台で多重化して可用性を高めます。実務トラック #1 で minikube により立ち上げた単一ノードクラスターも、内部的にはこの 2 つの役割をすべて一つのノードで実行していたものです。

Control plane の構成要素 #

control plane は単一のプログラムではなく、複数のコンポーネントの束です。各コンポーネントの役割を一行で分類できるようにしておく必要があります。

kube-apiserver: すべての通信の関門 #

kube-apiserver はクラスターの正面玄関です。kubectl、コントローラー、kubelet など、すべての構成要素は互いに直接やり取りせず、必ず apiserver を経由して 通信します。apiserver は REST API を公開し、入ってきたリクエストを認証・認可・検証したうえでクラスター状態ストアに記録します。apiserver はクラスターで 唯一 etcd に直接アクセスする コンポーネントでもあります。

etcd: クラスター状態ストア #

etcd はクラスターのすべての状態を収める key-value ストア です。どの Pod がどこで動いているか、どの Deployment が何個のレプリカを望んでいるかといったクラスターの desired state と current state がすべて etcd に入っています。etcd は分散合意アルゴリズム (Raft) で一貫性を保証し、etcd が損傷するとクラスターの記憶全体が消えてしまうので、バックアップが運用の核心になります。

kube-scheduler: Pod 配置の決定 #

kube-scheduler はまだノードに割り当てられていない新しい Pod を見て、どの worker node に載せるかを決定 します。ノードの利用可能リソース (CPU・メモリ)、ノードセレクター、affinity・anti-affinity、taint・toleration といった制約を総合して最適なノードを選びます。scheduler は配置を 決定 するだけで、実際の実行は該当ノードの kubelet が担当します。

kube-controller-manager: reconciliation loop #

kube-controller-manager は複数のコントローラーを一つのプロセスにまとめて動かすコンポーネントです。各コントローラーは desired state と current state を絶えず比較 し、両者が食い違うと現在の状態を望む状態に合わせる reconciliation loop を実行します。たとえば ReplicaSet コントローラーは「レプリカ 3 個」という宣言と実際に動いている Pod 数を比較して、足りなければ新しく作り、余れば削除します。

cloud-controller-manager: クラウド連携 #

cloud-controller-manager は Kubernetes を特定のクラウドプロバイダー (AWS・GCP・Azure など) とつなぐコンポーネントです。LoadBalancer タイプ Service のためのクラウドロードバランサーの作成、ノードのライフサイクル管理、クラウドストレージの連携といった クラウド依存ロジック を本体から分離して担当します。オンプレミスクラスターでは使わないこともあります。

コンポーネントが死ぬと何が起こるのか #

KCNA が好む角度です。コンポーネントごとの障害の影響を知れば、役割を逆から確認できます。

核心は、control plane が止まっても すでに実行中の Pod はすぐには死なない という点です。control plane は変更と調整を担当するので、止まると新しい作業が塞がれるだけで、既存の作業はしばらく回り続けます。

Worker node の構成要素 #

worker node は control plane の決定を受けて実際にコンテナを実行します。3 つの構成要素を覚えておけば十分です。

kubelet: ノードエージェント #

kubelet は各 worker node で動くエージェントです。apiserver から「このノードにこういう Pod を立ち上げろ」という指示を受け、コンテナランタイムに実行を要求し、Pod が正常かどうかを継続的に報告 します。liveness・readiness probe を実行してコンテナの健康状態を点検することも kubelet の仕事です。kubelet はノード上の Pod の実行を保証する責任者です。

kube-proxy: Service ネットワーキング #

kube-proxy は各ノードで Service ネットワーキング を実装します。Service に入ってきたトラフィックを背後にある Pod たちへ分散するために、ノードの iptables (または IPVS) ルールを管理します。おかげでクライアントは個々の Pod の IP を知らなくても、Service の安定した仮想 IP へリクエストを送れます。実際のパケット転送はカーネルのルールが処理し、kube-proxy はそのルールを最新の状態に保ちます。

コンテナランタイム: 実際のコンテナ実行 #

コンテナランタイム はイメージをダウンロードしてコンテナを実際に立ち上げるソフトウェアです。今日の標準は containerd であり、CRI-O も広く使われています。kubelet はこれらのランタイムと CRI (Container Runtime Interface) という標準インターフェースで対話するので、ランタイムを入れ替えても kubelet 側のコードはそのままです。CRI・ランタイムの詳細は Domain 2 を扱う #4 でさらに掘り下げます。

宣言型モデル: 望む状態を宣言すれば合わせてくれる #

Kubernetes を貫く思想が 宣言型 (declarative) モデル です。ユーザーは「この作業をこうしろ」という命令の手順を一つずつ指示しません。代わりに「最終的にこういう状態であってほしい」という desired state を YAML マニフェストで宣言し、Kubernetes が自分でその状態に合わせます。

• desired state。ユーザーが望む状態。例: 「nginx Pod 3 個が常に動いていなければならない」
• current state。今の実際のクラスターの状態。例: 「現在 nginx Pod が 2 個動いている」
• reconciliation loop。コントローラーが両者を絶えず比較して、差があれば current を desired に合わせる過程。上の例では足りない 1 個を新しく生成する

このモデルのおかげで、ノードが死んで Pod が消えてもコントローラーが差を検知して別のノードに Pod を立て直します。ユーザーが復旧手順を命令しなくても システムが自分で望む状態へ戻る 自己治癒がここから生まれます。命令型 (imperative) で kubectl run を直接打つこともできますが、実務と試験のどちらも宣言型マニフェストを基準にします。

コアワークロードリソース #

ここからは何を宣言するのかに移ります。ワークロードリソースは階層構造を成し、上へ行くほど多くのことを自動で処理します。

Pod: 最小デプロイ単位 #

Pod は Kubernetes がデプロイしスケジューリングする 最小単位 です。コンテナを直接ノードに立ち上げるのではなく、常に Pod という殻の中に入れて立ち上げます。一つの Pod の中にはコンテナが 一つ以上 入ることができ、同じ Pod 内のコンテナどうしはネットワーク (同じ IP) とストレージボリュームを共有します。補助コンテナを一緒に置くサイドカーパターンがこの構造の上で動作します。

ただし Pod を直接作って運用することはまれです。Pod 一つだけを立ち上げると、その Pod が死んだときに誰も生き返らせてくれないからです。そのため通常は上位のリソースが Pod を代わりに管理します。

ReplicaSet: レプリカ数の維持 #

ReplicaSet は 指定した個数の同一の Pod が常に動いているよう保証 するリソースです。「レプリカ 3 個」を宣言すると、ReplicaSet コントローラーが reconciliation loop で Pod 数を監視して、一つが死ねば新しく作り、意図せず増えれば削除します。ReplicaSet は label selector で自分が管理する Pod を識別します。

Deployment: ReplicaSet 管理 + ローリングアップデート #

Deployment は ReplicaSet を 一段上から管理 するリソースであり、実務で最もよく使うワークロードリソースです。レプリカの維持は ReplicaSet に委ね、その上に バージョン管理機能 を加えます。新しいイメージで更新すると、Deployment が新しい ReplicaSet を作って Pod を段階的に置き換える ローリングアップデート を実行し、問題が起きれば以前の ReplicaSet へ戻す ロールバック も対応します。

ReplicaSet vs Deployment #

KCNA が好んで問う比較です。両者の境界を明確にしておく必要があります。

一文で整理すると、Deployment は ReplicaSet を管理し、ReplicaSet は Pod を管理 します。更新とロールバックが必要なら Deployment、単純なレプリカ保証だけを見るなら ReplicaSet です。ステートレスではなく安定した識別子と順序が必要なワークロードは StatefulSet を使いますが、この比較は #3 で扱います。Deployment の実習は 実務トラック #4 で確認できます。

Service: Pod 集合の安定した入り口 #

Pod は死んで生まれ変わるたびに IP が変わります。そのため Pod の IP を直接指すと、通信がすぐに切れます。Service は複数の Pod の前に 変わらない仮想 IP と DNS 名 を置いて、背後の Pod が変わってもクライアントが同じアドレスでアクセスできるようにするリソースです。Service は label selector で自分がトラフィックを送る Pod 集合を識別し、その Pod たちへリクエストを分散します。

Service には公開範囲に応じて 3 つの主要なタイプがあります。

• ClusterIP。クラスター内部からのみアクセス可能な既定のタイプ。内部のサービス間通信に使う
• NodePort。各ノードの特定のポートを開いて、クラスター外部からノード IP でアクセスできるようにする
• LoadBalancer。クラウドプロバイダーの外部ロードバランサーを付けてインターネットに公開する。cloud-controller-manager が実際の LB を作成する

Service タイプの違いもよく出題されます。内部専用なら ClusterIP、外部公開なら NodePort もしくは LoadBalancer に分類しておけば十分です。Service の実習は 実務トラック #5 に整理してあります。

Namespace と label/selector #

Namespace: クラスターの論理分割 #

Namespace は一つの物理クラスターを 複数の論理空間に分ける リソースです。チームごと・環境ごと (dev・staging・prod) にリソースを隔離し、同じ名前のリソースを互いに異なる Namespace に置けるようにします。ResourceQuota・RBAC を Namespace 単位でかけて、リソースと権限を分離することもあります。kube-system のような既定の Namespace には Kubernetes 自体の構成要素が入っています。ただし Namespace はあくまで論理的な区画であり、ノードのようなクラスター全域のリソースは Namespace に属しません。

label と selector: ラベルベースのグルーピング #

label はリソースに付ける key-value のタグであり (例: app=nginx、env=prod)、selector はそのラベルでリソース集合を選び出すクエリです。Kubernetes の接続はほとんどがこのラベルベースで行われます。ReplicaSet が管理する Pod を選ぶときも、Service がトラフィックを送る Pod を選ぶときも、すべて selector がラベルを見て対象をまとめます。名前ではなくラベルで緩く接続するこの方式が Kubernetes の柔軟性を生みます。

試験ポイント: コンポーネント役割マッチング #

Domain 1 で最もよく出る形が 「この仕事をするコンポーネントは何か」 または 「このコンポーネントの役割は何か」 を問うマッチング問題です。下の一行要約を覚えておけば、かなりの問題が解けます。

まとめ #

この記事で押さえたこと:

• クラスターは control plane (頭脳) と worker node (働き手) に分かれる。 どのコンポーネントがどちら側にあるかが試験ポイント
• control plane。kube-apiserver (関門)、etcd (状態ストア)、kube-scheduler (配置決定)、kube-controller-manager (reconciliation)、cloud-controller-manager (クラウド連携)
• worker node。kubelet (ノードエージェント)、kube-proxy (Service ネットワーキング)、コンテナランタイム (containerd)
• 宣言型モデル。desired state を宣言すれば reconciliation loop が current state を合わせる。自己治癒の根拠
• ワークロード階層。Deployment が ReplicaSet を管理し、ReplicaSet が Pod を管理する。更新・ロールバックが必要なら Deployment
• Service は label selector で Pod 集合に安定した入り口を提供し (ClusterIP・NodePort・LoadBalancer)、Namespace はクラスターを論理的に分ける

次: Kubernetes Fundamentals 2 #

アーキテクチャとコアリソースを押さえたので、ここからはその上で動作するメカニズムに入っていきます。

#3 Kubernetes Fundamentals 2: API、コンテナ、スケジューリング では、Kubernetes API とオブジェクト構造、コンテナとイメージの基礎、そして scheduler がノードを選ぶ基準 (リソース要求・セレクター・affinity・taint・toleration) まで整理します。あわせて読むとよい実務記事として、K8s 実務トラック #1 がクラスター構造を手で確認する出発点になります。