コンテナと Kubernetes

サーバー1台にアプリを置いて動かす——最初はこれで十分です。 しかし、サービスが育つと次が起きます。

□ 深夜にプロセスが落ちた。誰も気づかず、朝まで停止していた
□ アクセスが増えたので台数を増やしたい。手作業で10台に同じ設定を入れる
□ デプロイのたびに、数分間サービスが止まる
□ 「このサーバーだけ設定が違う」が、誰も理由を知らないまま残っている
□ 1台が壊れた。復旧手順は担当者の頭の中にしかない

これらはすべて「人間が手で管理している」ことが原因です。 台数が増えるほど、手作業は破綻します。

そこで、「あるべき状態」を宣言しておけば、 機械が勝手にその状態を保ち続ける仕組みが求められました。 落ちたら再起動し、増やせと言えば増やし、更新は少しずつ入れ替える。

それがコンテナオーケストレータであり、その事実上の標準が Kubernetes です。

新人が Kubernetes に求められるのは、クラスタを構築することではありません。 自分のサービスが動かない時に、原因を特定できることです。 この章はそこに絞ります。

コンテナのおさらい

Docker を使いこなすで扱ったとおり、コンテナは軽い仮想マシンではなく、隔離されたプロセスです。 ホストのカーネルを共有し、名前空間で見える範囲を、cgroup で使える量を区切っています。

ここで効いてくるのは次の2点です。

• 軽いから、たくさん動かせる。 1台に何十個も載せられるからこそ、機械が配置を決める意味が出る
• cgroup で上限を決められる。 だから Kubernetes は「このコンテナには CPU 0.5、メモリ 512Mi」と宣言できる

イメージとレイヤー

Dockerfile の各命令が1つのレイヤーになり、積み重なってイメージができます。

FROM node:22-alpine        # レイヤー1
WORKDIR /app
COPY package.json pnpm-lock.yaml ./   # レイヤー2
RUN pnpm install --frozen-lockfile    # レイヤー3
COPY . .                              # レイヤー4
RUN pnpm build                        # レイヤー5
CMD ["node", "dist/main.js"]

変わっていないレイヤーはキャッシュが使われます。 だから「変わりにくいものを先に、変わりやすいものを後に」書きます。

上の例で COPY . . を先頭に持ってくると、 コードを1文字直すたびに pnpm install からやり直しになります。

なぜオーケストレータが必要か

コンテナを1つ動かすだけなら docker run で足ります。 しかし実際には、次のことが必要になります。

• 落ちたら自動で再起動する
• 負荷に応じて数を増やす
• どのマシンに配置するか決める
• 新バージョンに順次入れ替える（無停止で）
• アクセス先を1つの窓口にまとめる

これを自動でやるのが Kubernetes です。

宣言的であること

Kubernetes の考え方の核心です。

命令的: 「コンテナを3つ起動しろ」
宣言的: 「常に3つ動いている状態にしろ」   ← Kubernetes はこちら

1つ落ちたら、Kubernetes が勝手に1つ起動して3つに戻します。 あなたは「あるべき状態」を書くだけで、そこへ近づけるのは Kubernetes の仕事です。

命令的（手順を書く）  「コンテナを3つ起動しろ」「1つ落ちたら起動しろ」
宣言的（状態を書く）  「コンテナが常に3つある状態にしておいて」

主要なリソース

関係

Ingress（外からの入口）
    ↓
Service（安定した窓口。Pod が入れ替わっても変わらない）
    ↓ セレクタでラベルが一致する Pod を選ぶ
Pod  Pod  Pod
    ↑ Deployment が「3つ」を維持している

Pod は使い捨てです。落ちれば新しいものが作られ、IP も変わります。 だから直接 Pod を指定せず、Service を通します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api          # ← このラベルの Pod を管理する
  template:
    metadata:
      labels:
        app: api        # ← Pod に付けるラベル
    spec:
      containers:
        - name: api
          image: asia-northeast1-docker.pkg.dev/proj/api:v1.2.3
          ports:
            - containerPort: 8080

Probe — 生きているかの確認

Kubernetes は、Pod が正常かどうかを自分で判断できません。 アプリ側が答える必要があります。

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

障害の読み方

この節が実務で最も使います。

kubectl get pods                    # まず全体を見る
kubectl describe pod <pod-name>     # イベントと状態の詳細
kubectl logs <pod-name>             # アプリのログ
kubectl logs <pod-name> --previous  # 再起動前のログ（クラッシュの原因）

よくある症状と原因

診断の順番

# 1. 状態を見る
kubectl get pods
# api-7d9f8-x2k4l   0/1   CrashLoopBackOff   5   3m
 
# 2. イベントを見る（describe の一番下）
kubectl describe pod api-7d9f8-x2k4l
 
# 3. 落ちる前のログを見る（ここに答えがあることが多い）
kubectl logs api-7d9f8-x2k4l --previous

Service に繋がらない — Endpoints が空

最も気づきにくい障害です。

kubectl get endpoints api
# NAME   ENDPOINTS   AGE
# api    <none>      5m      ← 空！

Service はラベルのセレクタで Pod を選びます。 これが一致していないと、Pod は元気に動いているのにどこにも繋がりません。

# Service
spec:
  selector:
    app: api-server     # ← こちらは api-server
 
# Deployment の Pod
metadata:
  labels:
    app: api            # ← こちらは api。一致していない

エラーもログも出ません。Endpoints が空かどうかを見るのが唯一の手がかりです。

リソース制限

resources:
  requests:              # 最低これだけ確保してほしい（配置の判断に使う）
    cpu: 100m            # 0.1 コア
    memory: 128Mi
  limits:                # これを超えたら制限する
    cpu: 500m
    memory: 512Mi

ConfigMap と Secret

設定をイメージから切り離すための仕組みです。

env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef: { name: api-config, key: log_level }
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef: { name: api-secret, key: db_password }

kubectl get secret api-secret -o jsonpath='{.data.db_password}' | base64 -d

デプロイの流れ

1. コードを push
2. CI がイメージをビルドしてレジストリへ push
3. マニフェストの image タグを新しいものに更新
4. kubectl apply（または Argo CD などが自動で適用）
5. Kubernetes が Pod を順次入れ替える（ローリングアップデート）
6. readinessProbe が OK になった Pod から Service に入る

問題があれば戻します。

kubectl rollout undo deployment/api      # 直前のバージョンに戻す
kubectl rollout status deployment/api    # 進行状況を見る

実務の落とし穴まとめ

1. logs だけ見て --previous を忘れる — CrashLoopBackOff の原因が見えない
2. Service のセレクタ不一致 — Endpoints が空。エラーが出ないので気づきにくい
3. livenessProbe に依存先チェック — DB 不調で全 Pod が再起動する
4. Dockerfile の COPY の順序 — キャッシュが効かずビルドが毎回遅い
5. Secret を暗号化だと思う — Base64 なので誰でも読める
6. kubectl edit で直す — 次のデプロイで消える

まとめ

• コンテナは OS を持たない。中身は Linux
• Dockerfile は変わりにくいものを先に書く（キャッシュ）
• Kubernetes は宣言的。「あるべき状態」を書けば、そこへ近づけてくれる
• Pod は使い捨て。アクセスは Service を通す
• readiness は Service から外れる、liveness は再起動。依存先チェックは readiness へ
• 障害調査は get pods → describe → logs --previous
• 繋がらない時は kubectl get endpoints が空でないか
• OOMKilled は memory limit 超過

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次の章では、こうして動かした複数のサービスを、 どう安全に繋ぐかを扱います。