Kubernetes 航海術

サーバーの単位が、どんどん小さくなった

アプリを動かす「入れ物」は、この20年でだいたい3段階に小さくなりました。

Noteコンテナの正体は「魔法の軽量VM」ではなく、Linux カーネルの namespace（見える範囲の分離）と cgroup（使える資源の制限）で閉じ込められた、ただのプロセスです。この事実は 8 章のセキュリティで効いてきます。

コンテナは便利、でも「数」が敵になる

Docker などでコンテナを 1 個動かすのは簡単です。問題はその先。実際のサービスは、コンテナが 3 個で済むことはまずありません。Web が 10 個、API が 20 個、バッチが 5 個、それがサーバー 8 台に散らばる。そうなると、こういう仕事が毎日発生します。

• 配置：この新しいコンテナ、どのサーバーの空きに置く？ メモリ足りてる？
• 復旧：夜中に 1 個落ちた。誰が気づいて、誰が起こす？
• 増減：昼にアクセスが 5 倍。手で 20 個起動して、夜に手で止める？
• 更新：新バージョンに差し替えたい。全部同時に止めたらサービス断。1個ずつ？
• 通信：コンテナは再起動のたびに IP が変わる。呼び出す側はどうやって見つける？
• 秘密情報：DB のパスワード、どうやって安全に渡す？

これを全部、人間の代わりに 24 時間やってくれる係が必要になります。それがコンテナオーケストレーションで、その事実上の標準が Kubernetes（略して K8s。K と s の間に 8 文字あるから）です。

HistoryGoogle が社内で 10 年以上使っていた Borg というシステムの設計思想を受け継ぎ、2014 年に OSS 化。2015 年から CNCF（Cloud Native Computing Foundation）が管理する中立プロジェクトになりました。特定ベンダーのものではない、というのが普及した大きな理由です。

命令するのではなく、宣言する

従来のサーバー管理は命令的（imperative）でした。「起動しろ」「コピーしろ」「再起動しろ」と、手順を順番に指示する。シェルスクリプトの世界です。

Kubernetes は宣言的（declarative）です。手順を指示しません。代わりに「あるべき状態（desired state）」だけを書いて渡します。

この違いは、エアコンの操作に例えるとわかりやすいです。命令的は「暖房を強で 10 分回して、止めて、また回して…」と手で調整すること。宣言的は「室温 25 ℃」と設定すること。あとは機械が測って、足りなければ働き、達したら止まる。Kubernetes はデータセンター用のサーモスタットです。

収束させ続ける ── コントロールループ

その「測って、差分を埋める」動作を reconciliation loop（調整ループ） と呼びます。Kubernetes の中身は、突き詰めるとこのループの集合体でしかありません。

Note「Pod を消したのに復活する！」は初心者あるある。それは Deployment が「3個」と宣言しているからで、消すべきは Pod ではなく宣言のほう（Deployment）です。

すべては API オブジェクト

では「宣言」はどこに渡すのか。Kubernetes API サーバーです。Kubernetes を使うというのは、実質的に REST API を叩いて、オブジェクトを CRUD することだと思ってください。kubectl コマンドも、Web UI も、CI/CD も、全部この API の client でしかありません。

そのオブジェクトを書く形式が YAML（マニフェスト）です。ほぼ全部のマニフェストが、この 4 つのフィールドを持ちます。

manifest の骨格

spec が「あなたの希望」、それに対して Kubernetes が実況を書き込む status というフィールドがあります。spec と status の差分を埋めるのが Kubernetes の仕事── 2 章はこれだけ覚えて帰ってください。

登場人物 6 人

Noteマネージドサービス（EKS / GKE / AKS）を使うと、左半分（コントロールプレーン）はクラウド事業者が運用してくれて、あなたはノードだけ気にすればよくなります。最初はこれが圧倒的に楽です。

kubectl apply を押してから Pod が動くまで

全体像が入ったところで、1 本の流れを追ってみましょう。ここが繋がると一気に「わかった」感が出ます。

Pod ── 最小単位

Kubernetes はコンテナを直接扱いません。必ず Pod という箱に入れて扱います。Pod は 1 個以上のコンテナのグループで、中のコンテナは同じ IP・同じ localhost・同じボリュームを共有します。つまり Pod の中は「1台のマシンの中」のような世界です。

基本は「1 Pod = 1 コンテナ」。2 個目を同居させるのは、本体と一心同体で動く補助役（ログ収集・プロキシなど、いわゆる サイドカー）を入れるときだけです。

NotePod は使い捨てです。壊れたら直さず、捨てて新しく作る。IP も名前も変わる。この「家畜であってペットではない（cattle, not pets）」感覚が、従来のサーバー運用との一番大きな精神的ギャップです。

Deployment ── 実務で一番書くやつ

Pod を直接作ることは、実務ではほぼありません。死んだら復活しないからです。代わりに Deployment を書きます。階層はこうなっています。

deployment.yaml ── 実務で最初に書くファイル

Service ── 変わり続ける IP に、固定の住所を与える

Pod は死んで生き返るたびに IP が変わります。呼ぶ側が追いかけるのは不可能。そこで Service が、その集団に安定した仮想 IP と DNS 名を与えて、届いた通信をラベルの合う Pod に振り分けます。Kubernetes 内蔵のロードバランサだと思ってください。詳しくは 5 章で。

設定と秘密 ── ConfigMap / Secret

設定値をイメージに焼き込むと、環境ごとにイメージを作り直すハメになります。だから外に出します。

• ConfigMap：設定値（URL、フラグ、設定ファイルそのもの）。環境変数かファイルとして Pod に渡す。
• Secret：パスワード、API キー、証明書。使い方は ConfigMap とほぼ同じ。

そのほかの主要な kind

3 つの大原則

1. すべての Pod は固有の IP を持つ（コンテナごとではなく Pod ごと）
2. すべての Pod は、ノードをまたいでも NAT なしで直接通信できる（＝クラスタ全体が一つのフラットな LAN に見える）
3. この「平らな LAN」を実際に作るのは Kubernetes 本体ではなく、CNI プラグイン（Calico、Cilium、Flannel など）という差し替え可能な部品

Docker に慣れていると「ポートフォワードは？」となりますが、Kubernetes ではその発想が要りません。Pod 同士は最初から直接話せます。問題は「相手の IP がコロコロ変わる」ことだけ。それを解決するのが Service です。

名前で呼べる ── クラスタ内 DNS

クラスタには DNS（CoreDNS）が内蔵されていて、Service を作ると自動で名前が登録されます。だからアプリのコードには IP ではなく名前を書けます。

Note「Service の ClusterIP」は、実はどのネットワークインターフェースにも存在しない仮想 IPです。各ノードの kube-proxy が iptables / IPVS にルールを書いて、その宛先を実 Pod の IP へ書き換えているだけ。だから ping は通らないのに通信はできる、という状況が起こります。

Ingress、そしてその後継

Service（LoadBalancer）を公開したい URL の数だけ作ると、クラウドの LB がその数だけ生えて高くつきます。Ingress は「1 つの入口で受けて、ホスト名やパスで内部の Service に振り分ける」ための仕組みです。実体としては NGINX や Traefik などの Ingress Controller を別途インストールして使います。

なお近年は、より表現力の高い後継仕様 Gateway API への移行が進んでいます。新規で学ぶなら「Ingress が今の主流、Gateway API が次」という位置づけで覚えておけば十分です。

手元にクラスタを立てる

本物のサーバーは要りません。Docker さえ入っていれば、以下のどれかで 1 コマンドです。

最初の 10 分

起動から公開・確認・削除まで

Tipsalias k=kubectl はほぼ全員が入れています。あわせて kubectl completion による補完と、コンテキスト/Namespace を切り替える kubens / kubectx を入れると生存率が上がります。

覚えるべきコマンドは、実質これだけ

無停止で更新する（ローリングアップデート）

Deployment の image を書き換えて apply するだけで、Kubernetes は新しい Pod を 1 つ作り、健康を確認してから、古い Pod を 1 つ消すという入れ替えを、サービスを止めずに繰り返します。

健康診断（Probe）── 自動復旧の要

Kubernetes が「この Pod は生きている」と判断する基準は、あなたが教える必要があります。プロセスが残っていても、中でデッドロックしていれば無意味だからです。

Notereadiness を書かないと、まだ起動途中の Pod に本番トラフィックが流れ込み、ローリングアップデートのたびに一瞬 500 が出ます。「デプロイすると数秒エラーが出る」の原因はだいたいこれ。

資源の宣言（requests / limits）

• requests：「最低これだけ必要」。スケジューラはこの値だけを見て配置を決めます。実使用量ではありません。
• limits：「これ以上は使わせない」。CPU は超えると絞られ（throttling）、メモリは超えると即 kill（OOMKilled）されます。

これを書かない Pod は、ノードのメモリを食い尽くして隣の無関係な Pod を巻き込んで落とすことがあります。マルチテナントなクラスタでは、Namespace 単位で ResourceQuota / LimitRange を敷いて強制するのが定石です。

自動で増減させる（HPA）

これで CPU 使用率が 70% を超えたら Pod が増え、下がれば減ります（metrics-server が必要）。さらに Pod を置くノード自体が足りなくなったら、Cluster Autoscaler や Karpenter がクラウドの VM 自体を増やします。「Pod のオートスケール」と「ノードのオートスケール」は別レイヤーの別部品、というのは混同しやすいポイントです。

RBAC ── 誰が何をしてよいか

Kubernetes の認可は RBAC（Role-Based Access Control） です。構造はシンプルで、4 つのオブジェクトの組み合わせだけです。

• Role（Namespace 内）／ ClusterRole（クラスタ全体）＝ 許可する動詞と対象（例：pods を get, list）
• RoleBinding ／ ClusterRoleBinding ＝ その Role を「誰に」割り当てるか（ユーザー、グループ、ServiceAccount）

NetworkPolicy ── 既定は「全許可」であることを知る

5 章で見たとおり、Pod は全員フラットに通信できます。これは裏を返せば、1 つの Pod を踏まれたら、そこから DB Pod にも管理系 Pod にも自由に到達できるということです。NetworkPolicy を 1 枚も置いていないクラスタは、内部が完全にフラットな LAN と同じです。

まず入れるべき「既定拒否」ポリシー

NoteNetworkPolicy を実際に適用するのは CNI プラグインです。CNI が非対応だと、マニフェストを書いても静かに無視されます（＝守れているつもりで守れていない）。Calico や Cilium ならまず問題ありません。

コンテナからホストへ ── 脱出の温床になる設定

1 章で触れたとおり、コンテナは分離されたプロセスにすぎません。次の設定は、その分離を自ら壊すものです。

これらを組織的に禁止する標準機能が Pod Security Standards（privileged / baseline / restricted の 3 段階）です。Namespace にラベルを 1 行貼るだけで強制できます。より細かい条件を書きたい場合は、OPA Gatekeeper や Kyverno といったポリシーエンジンを Admission Webhook として挟みます。

防御側として押さえるチェックリスト

• 監査ログ（Audit Log）を有効化し、SIEM に送る。誰がいつ何の API を叩いたかは、ここにしか残らない。
• ServiceAccount トークンの自動マウントを切る（automountServiceAccountToken: false）。API を叩かない Pod に身分証を持たせない。
• イメージは固定タグではなくダイジェスト（@sha256:...）で指定し、CI で脆弱性スキャンと署名検証（cosign / Sigstore）を通す。
• ランタイム検知：Falco や eBPF ベースの製品で、コンテナ内の異常な exec・シェル起動・想定外の外向き通信を検知する。
• ベンチマーク：CIS Kubernetes Benchmark を kube-bench で、権限設定の穴を kubectl-who-can や rbac-tool で定期点検する。

マニフェストが増えすぎる問題 ── Helm と Kustomize

YAML は環境（開発/検証/本番）ごとに微妙に違うだけの、ほぼ同じファイルが量産されがちです。その解決策が 2 つあります。

Kubernetes を拡張する ── CRD と Operator

3 章で見たとおり、Kubernetes は「API サーバー＋ループを回す人」の集合でした。ならば自分で新しい kind を追加し、自分でループを書けばいい ── これが CRD（Custom Resource Definition） と Operator です。

たとえば PostgreSQL Operator を入れると、kind: PostgresCluster という自作の種類が使えるようになり、バックアップやフェイルオーバーといった「運用担当者の知識」までコードとしてループに組み込めます。Kubernetes が単なるコンテナ実行基盤を超えて「あらゆる運用の共通プラットフォーム」と呼ばれるのは、この拡張性が理由です。

GitOps ── Git が唯一の正

宣言的であるということは、「あるべき状態」が全部ファイルであるということ。ならばそれを Git に置き、Git の内容とクラスタの状態を突き合わせて自動で収束させるのが自然です（2 章のループを、クラスタの外にもう一段かけるイメージ）。Argo CD や Flux がその役目を担います。人が本番に kubectl apply しなくなるので、変更履歴と承認が Git の Pull Request に一本化される ── 監査の観点でも強力です。

そのほか、名前だけ知っておくと会話に困らないもの

NoteCNCF の全体図（Cloud Native Landscape）には数百のプロダクトが並んでいて、初見では確実に酔います。あれは「カタログ」であって「必修リスト」ではありません。必要になってから 1 つずつ引けば十分です。

おすすめの学習順

1. kind でクラスタを立てて、6 章の 10 分コースをそのまま実行する。特に「Pod を消して復活を見る」ところまで必ずやる。理屈より先に、この一回の体験が効きます。
2. 自分の書いた小さな Web アプリをコンテナ化して載せる。Deployment + Service + Ingress の 3 枚だけ書く。ここで大抵 ImagePullBackOff と CrashLoopBackOff に出会えるので、describe と logs の練習になります。
3. ConfigMap / Secret / Probe / resources を足していく。1 つずつ足しては壊し、kubectl explain でフィールドを引く。
4. 意図的に壊して観察する。ノードを止める、メモリ制限を極端に下げて OOMKilled を起こす、readiness を落として Service から外れる様子を見る ── 復旧の挙動を目で確認すると、2 章のループが腹落ちします。
5. セキュリティを締める。NetworkPolicy で既定拒否にして通信が切れることを確認し、必要な穴だけ開ける。RBAC を絞って can-i で検証する。

資格を軸にするなら、実技試験の CKA（管理者）／CKAD（開発者）／CKS（セキュリティ）があります。特に CKS は 8 章の内容をそのまま実技で問う試験なので、学習の地図として優秀です。

用語集