運用チェックリスト

4部 (EKS 実戦) の最後の章です。第21章 EKS クラスタセットアップ ~ 第25章 モニタリング · アラート までを経て、myshop-api は最初に作った空のクラスタの上に、配備 · DB · CI/CD · 可観測性まで一つの流れがすべて自動化された状態です。この時点でクラスタはよく回っている状態ですが、一年単位で安全に運用する作業 は別の質感の仕事です。K8s は1年にマイナーバージョンが3つずつ出て、AWS は四半期ごとに新しいインスタンスタイプを出し、RDS は定期的に maintenance window が組まれます。本章はその定期運用サイクルを整理します — EKS アップグレード、バックアップ · 復旧、コスト、セキュリティの四つの次元です。

本章の終わりでは、4部の振り返りと本書 1 ~ 4部 (第1 ~ 26章) の振り返りを一つのまとまりとして収めます。その後は 5部 (運用 · デバッグ · コスト) と 6部 (キャップストーン) の本格運用の質感へ移ります。

EKS アップグレード — 1年に一度はマイナーバージョン #

K8s 自体のバージョンポリシーは明確です。

• マイナーバージョン (1.30 → 1.31 → 1.32) — 約4か月周期でリリースされます。
• 各マイナーバージョンのサポート期間 — リリース後 約14か月です。
• EKS のサポート期間 — 標準サポート14か月 + 拡張サポート追加12か月 (有料) です。

運用クラスタが標準サポートの中にとどまるようにするには 1年に最低一度のマイナーアップグレード が必要です。四半期ごとの更新カレンダーで管理するのが標準です。

アップグレードの標準の流れ #

1. リリースノート検討 — 新バージョンの deprecation, removed API
2. dev クラスタで先にアップグレード
3. 1 ~ 2週 dev で回してみる
4. マニフェストの deprecated API を整理
5. アップグレード点検ツール実行 (pluto, kubent)
6. prod コントロールプレーンのアップグレード
7. prod ノードグループのアップグレード (rolling)
8. アドオンのアップグレード (vpc-cni, coredns, kube-proxy, ebs-csi)

各段階で最も時間がかかるのは4段階目 — deprecated API の整理 です。K8s がマイナーバージョンごとに一部の API を削除するので、マニフェストに古い API が入っていると新しいクラスタで拒否されます。

点検ツール — pluto と kubent #

pluto detect-files -d charts/ --target-versions k8s=v1.31

kubent --target-version 1.31

二つのツールが合わさって「自分のマニフェストと自分のクラスタの両方で」deprecated API を見つけてくれます。第20章 GitOps の git 単一ソースモデルのおかげで、pluto がマニフェスト repo 一箇所だけスキャンすれば、すべての環境の deprecated API が一度につかまります。

コントロールプレーンのアップグレード — Terraform 一行 #

module "eks" {
  # ...
  cluster_version = "1.31"   # 1.30 -> 1.31
}

terraform apply が EKS コントロールプレーンのマイナーアップグレードをトリガーします。EKS はコントロールプレーンを無停止でアップグレードします — ユーザーワークロードは影響を受けず、kubectl も継続して作動します。約30分 ~ 1時間ほどかかります。第21章 の Terraform マニフェストで cluster_version 一行を上げることが運用の出発点です。

ノードグループのアップグレード — Rolling vs Blue-green #

ノードグループのアップグレードは二つのパターンがあります。

EKS Managed Node Group の基本は in-place rolling です。EKS が自動で Pod を cordon → drain → 新しいノードを立ち上げ → Pod を新しいノードへ → 旧ノードを削除のサイクルを回します。第22章 アプリ配備の骨格 で作った PodDisruptionBudget が、この時点で決定的です — PDB がないと同じワークロードの Pod が同時に全部下がりうて、ユーザーにはダウンタイムとして見えます。第22章で書いた一つのマニフェスト一行が、1年後のアップグレードでダウンタイムを防ぐ安全線 として機能する形です。

# コントロールプレーンが 1.31 に上がったあと
aws eks update-nodegroup-version \
  --cluster-name myshop-prod \
  --nodegroup-name general \
  --region ap-northeast-2

大規模クラスタでアップグレードの影響が懸念されるなら blue-green パターンが安全です — 新しいノードグループを作り、第13章 オートスケーリング の Karpenter disruption 制御でワークロードを漸進的に移したあと旧グループを空にする流れです。

アドオンのアップグレード #

コントロールプレーンとノードが新バージョンになったあと、アドオンも併せて上げます。

cluster_addons = {
  vpc-cni = {
    most_recent = true   # または明示的なバージョン
  }
  coredns = {
    most_recent = true
  }
  # ...
}

most_recent = true にしておくと、Terraform が K8s バージョンと互換性のある最新のアドオンバージョンへ自動アップグレードします。明示的なバージョンピンが必要な場合は addon_version フィールドを使います。第15章 CNI 深掘り の VPC CNI と 第16章 RBAC / ServiceAccount 深掘り の IRSA OIDC provider が、すべてこのサイクルで併せて更新されます。

バックアップと復旧 — RDS の PITR が1次防御線 #

myshop のデータはほぼすべて RDS にあります。K8s クラスタ自体はマニフェストが git にあるので崩れても再構成できますが、RDS データは一度失うと復旧が難しいです。第20章 GitOps の git 単一ソースモデルのおかげで、クラスタの stateless な部分は本質的に再現可能な状態であり、運用の本当の危険は stateful なシステムに集中します。

自動スナップショット + PITR #

第23章 DB 連携 の Terraform で backup_retention_period = 30 を書いた一行が、次を作り出しました。

• 毎日の自動スナップショット — backup_window (03:00 ~ 04:00 UTC) の時間に自動バックアップが回ります。
• PITR (Point-in-Time Recovery) — 過去30日以内の任意の時刻へ1秒単位の復旧が可能です。

PITR は RDS の最も強力なバックアップ機能です。ユーザーが誤って DELETE FROM orders; を prod に回したとき、その直前の時刻へ5分で新しい RDS インスタンスを復旧してデータを比較できます。

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier myshop-prod \
  --target-db-instance-identifier myshop-prod-recovery \
  --restore-time 2026-05-21T08:30:00Z \
  --db-subnet-group-name myshop-prod \
  --vpc-security-group-ids sg-xxxxx

このコマンドが30分前の時点のデータを持つ新しいインスタンスを作ります。そのインスタンスから損なわれていないデータを SELECT で取得して prod に復元する流れが標準の事故対応です。第30章 アップグレード戦略 §「バックアップと RPO / RTO」で、アップグレード直前のバックアップ点検の質感と併せて押さえます。

復旧訓練 — 四半期点検 #

自動バックアップが回っているのを見て安心することと、実際に復旧が可能なことは異なります。四半期に一度、復旧をシミュレーションしてみるのが標準 です。

1. PITR で新しいインスタンスを復旧 (上のコマンド)
2. 新しいインスタンスのデータを標本確認 (row count, 直近のトランザクション)
3. dev 環境の myshop-api を新しいインスタンスへ向けるよう設定変更
4. 機能テスト (仮想注文の作成, 照会)
5. 新しいインスタンス削除 + 結果の文書化

この訓練で一度でも失敗が出たら、運用優先度1番に組むべきシグナルです。「バックアップがある」ではなく「復旧が検証された」が運用の標準 です。

クラスタの復旧 — Velero #

K8s クラスタ自体の復旧は GitOps repo が1次防御線ですが、etcd 自体にある動的な状態 (ユーザーが作った PVC、ConfigMap の自動更新など) まで保存するには Velero が標準ツールです。

velero install \
  --provider aws \
  --bucket myshop-velero-backups \
  --region ap-northeast-2 \
  --plugins velero/velero-plugin-for-aws:v1.10.0 \
  --backup-location-config region=ap-northeast-2

# 毎日自動バックアップ
velero schedule create daily --schedule="0 2 * * *" --ttl 720h

Velero が etcd から K8s オブジェクト + EBS ボリュームスナップショットを S3 へ定期バックアップします。クラスタをまるごと失ったとき、新しいクラスタで velero restore で復旧できます。第9章 PV / PVC / StorageClass の PV モデルが、本格的なバックアップ対象になる形です。

コスト — 最も速く漏れる領域 #

K8s クラスタのコストは、意図しないと素早く膨らみます。運用クラスタのコスト点検の標準項目を押さえておきます。本格的なコスト最適化は 第28章 コスト最適化 で扱いますが、運用チェックリストの次元で五つの出所を先に整理します。

1. Karpenter + Spot の連携 #

第21章 EKS セットアップ で短く言及した Karpenter が、コストの面で最も大きな節減を作ります。

spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: node.kubernetes.io/instance-type
          operator: NotIn
          values: ["m5.metal"]   # 大きすぎるインスタンスを除外
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s

Karpenter が ワークロードのリソース要求に正確に合うインスタンスを Spot 価格で 立ち上げます。ON_DEMAND 比で約 50 ~ 70 % の節減が一般的で、consolidation で使用量の低いノードを自動統合します。第13章 オートスケーリング で触れた Karpenter の本格運用が、コストの質感へつながる段階です。

2. RDS インスタンスの right-sizing #

RDS コストはインスタンスクラス + ストレージ + IOPS の合計です。インスタンスクラスが最も大きな比重を占めるので、四半期ごとの right-sizing 検討が標準です。

- CPU 使用率の平均が 30% 未満 -> 一段階小さいクラスを検討
- max_connections 使用率 50% 未満 -> プールサイズ / インスタンスの両方を検討
- ストレージ IOPS の max が baseline の 50% 未満 -> gp3 へダウンサイジングを検討

マネージドサービスなので、インスタンスクラスの変更が一度の reboot で終わります。四半期単位の right-sizing が最も大きなコスト節減項目の一つです。第23章 の PgBouncer 導入が、本節の二つ目のシグナル (max_connections 使用率) を自然に下げてくれる質感です。

3. NAT Gateway のデータ転送 #

第21章 で短く触れた NAT Gateway コストは、時間当たり + GB 当たりのデータ転送料金です。private サブネットのワークロードが外部と通信するたびにコストが積み上がり、意外と大きな比重を占める場合が多いです。

- VPC Endpoint 導入 — S3 / ECR / DynamoDB のような AWS サービスは VPC Endpoint で NAT 迂回
- 同じ region の RDS は VPC 内部ルーティングなので NAT 迂回 (VPC peering / Transit Gateway)
- 外部 API を頻繁に呼ぶならキャッシュレイヤー導入

月 $100 ~ $500 の NAT コストが VPC Endpoint 導入でその半分以下に下がることはよくあります。

4. EBS スナップショットと unused リソース #

- 古い EBS スナップショット (RDS 自動スナップショット以外に手動で作ったもの)
- 古い AMI
- 切り離された EBS ボリューム (古いノードグループの残骸)
- 使われていない ALB / NLB (古い Ingress の残骸)
- ECR の古いイメージ (lifecycle policy で自動削除を推奨)

ECR lifecycle policy は Terraform 一枚で整理されます。

resource "aws_ecr_lifecycle_policy" "myshop_api" {
  repository = aws_ecr_repository.myshop_api.name

  policy = jsonencode({
    rules = [
      {
        rulePriority = 1
        description  = "Keep last 30 production tags"
        selection = {
          tagStatus     = "tagged"
          tagPrefixList = ["v"]
          countType     = "imageCountMoreThan"
          countNumber   = 30
        }
        action = { type = "expire" }
      },
      {
        rulePriority = 2
        description  = "Expire untagged after 7 days"
        selection = {
          tagStatus   = "untagged"
          countType   = "sinceImagePushed"
          countUnit   = "days"
          countNumber = 7
        }
        action = { type = "expire" }
      }
    ]
  })
}

第24章 CI / CD のイメージタグ immutable の決定と、この lifecycle policy が併せて回ります — immutable なので同じタグを上書きできず、古いタグを lifecycle で整理するのが唯一の掃除の道です。

5. コスト可視化 — Kubecost / OpenCost #

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost \
  -n opencost --create-namespace

OpenCost が Prometheus メトリックとクラウドのコスト API を連携して ネームスペース · ワークロード単位のコスト を見せてくれます。「myshop ネームスペースが一か月にいくら使っているか、どのワークロードが大半か」が一目で見えます。第7章 Namespace とラベル のラベル標準 (team / env / cost-center) が、本節で本格的なコスト責任分配のキーとして活用されます。コスト責任がチーム単位で落ちる環境ではほぼ標準で、第28章 でより詳しく押さえます。

セキュリティ — 定期点検の標準項目 #

運用クラスタのセキュリティは一度のセットアップではなく、定期点検の積み重ねです。標準項目を三つ押さえておきます。秘密運用の本格的な質感は 第29章 シークレット運用 で扱いますが、運用カレンダーの次元で四つ (CIS Benchmark · イメージスキャン · RBAC audit · admission ポリシー) を先に整理します。

1. CIS Benchmark — kube-bench #

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job-eks.yaml
kubectl logs -l job-name=kube-bench

kube-bench が CIS Kubernetes Benchmark の項目を自動点検します。EKS はコントロールプレーンがマネージドなので、点検項目がノード + ワークロードマニフェストに限定されます。四半期ごとに実行して FAIL 項目を整理するのが標準です。

2. コンテナイメージスキャン — Trivy #

- name: Trivy イメージスキャン
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/myshop-api:${{ steps.meta.outputs.tag }}
    format: sarif
    severity: CRITICAL,HIGH
    exit-code: 1   # CRITICAL 発見時にビルド失敗
    output: trivy-results.sarif

- name: SARIF を GitHub Security タブにアップロード
  uses: github/codeql-action/upload-sarif@v3
  with:
    sarif_file: trivy-results.sarif

Trivy がベースイメージの OS パッケージ + アプリケーション依存の既知の脆弱性 (CVE) をスキャンします。CRITICAL が発見されるとビルド失敗で止め、新しいイメージが ECR に入らないようにします。第24章 CI / CD パイプライン の GitHub Actions ワークフローに一段階として入り、セキュリティ点検が配備パイプラインの自然な一部になります。ECR Enhanced Scanning (有料) も同じ領域を埋めるマネージドオプションです。

3. RBAC 権限の audit #

# すべての ClusterRoleBinding を見る
kubectl get clusterrolebindings -o wide

# 特定の権限が付与された主体を探す
kubectl auth can-i --list --as=system:serviceaccount:myshop:myshop-api

# 外部ツール — krane (Salesforce) または rbac-tool

四半期ごとに RBAC を audit して「使われていない権限」「過度な権限」「古い ServiceAccount の残骸」を整理する流れが標準です。第16章 RBAC / ServiceAccount 深掘り で扱った kubectl auth can-i が日常点検のツールで、第14章 RBAC / NetworkPolicy / ResourceQuota の標準 ClusterRole (view / edit / admin) が audit の基準線になります。

4. ポリシーエンジン — Kyverno で admission を強制 #

第17章 Admission Controller と 第18章 CRD と Operator で扱った Kyverno を導入すると、次のようなポリシーが admission 段階で強制されます。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-from-ecr
spec:
  validationFailureAction: Enforce
  rules:
    - name: ecr-only
      match:
        resources:
          kinds: [Pod]
      validate:
        message: "Images must come from our ECR registry."
        pattern:
          spec:
            containers:
              - image: "123456789012.dkr.ecr.*"

こうしたポリシー 5 ~ 10 個が運用クラスタの標準ガードレールです。他の人が外部イメージや limits のないコンテナを誤って配備しても、admission 段階で拒否されます。第24章 の ArgoCD 自動 sync が導入された環境では、この admission ガードレールが事故防止の最後の保護線になります。

定期運用カレンダー #

上の項目をカレンダーに整理すると次のとおりです。

このカレンダーが一ページに整理されていて、担当者が決まっていることが運用チームの目標です。一度セットアップしたあと「よく回っているから忘れて暮らす」が最も危険なパターン です。

4部の振り返り — EKS 実戦6章が手に残したもの #

4部の6章を一度押さえておきます。

• 第21章 EKS クラスタセットアップ — Terraform で VPC · EKS · ノードグループ · IRSA · 標準アドオンまでを一つのコードベースで整理しました。eksctl の比較と Karpenter の予告も併せてでした。
• 第22章 アプリ配備の骨格 — Deployment + Service + Ingress + ConfigMap + Secret + ServiceAccount + HPA + PDB + Namespace の標準9まとまりを書きました。AWS Load Balancer Controller で ALB の自動プロビジョニング、Helm チャートで dev / prod 環境別の values 分岐までたどりました。
• 第23章 DB 連携 — RDS Terraform、Secrets Manager、External Secrets Operator で秘密の同期、PgBouncer コネクションプール、Helm hook ベースのマイグレーション Job、RDS IAM 認証のより進んだ質感まで束ねました。
• 第24章 CI / CD パイプライン — GitHub Actions OIDC で静的キーなしの ECR push、マニフェスト repo の自動 commit、ArgoCD App of Apps、Argo Rollouts カナリアまでの GitOps パイプラインを一連の流れで整理しました。
• 第25章 モニタリング · アラート — kube-prometheus-stack の一度のインストール、ServiceMonitor + PrometheusRule、4 golden signals、Alertmanager severity 分岐、Loki + CloudWatch の二つの軸までを運用の質感で解きました。
• 本章 (第26章 運用チェックリスト) — EKS アップグレード、PITR バックアップ · 復旧、Karpenter Spot のコスト節減、kube-bench / Trivy / Kyverno セキュリティの定期サイクルを束ねました。

4部の最初の章で固めた仮想シナリオ (myshop-api) が、6章を経て実際の運用クラスタの一連の流れとして完成しました。抽象ではなく具体で EKS を導入 · 運用する視野 が手に入る段階です。

1 ~ 4部の振り返り — 26章が手に残したもの #

本書の 1 ~ 4部、すなわち第1章から第26章までの大きな絵を一度整理します。

[1部 基礎 (1 ~ 7章)]      マニフェスト一枚のモデル — kubectl apply 一度の流れ
[2部 ワークロードと運用    そのマニフェストが運用クラスタで回る深さ
   (8 ~ 14章)]            — StatefulSet, PV, Ingress, ヘルス, リソース, RBAC
[3部 深さ (15 ~ 20章)]    その上に載るポリシー · 拡張 · 観測 · 同期の質感
                          — CNI, IRSA, Admission, CRD, 可観測性, GitOps
[4部 EKS 実戦 (21 ~ 26章)] EKS 上の本物のサービス一連の流れ — myshop-api

各部が次の部の入力になる構造で、第26章までたどってきた時点であれば、次が手に入っています。

• マニフェスト一枚の意図を一行で読める視野
• 新しいクラスタのセットアップ · 拡張 · 運用の決定が頭の中に入っている状態
• 事故発生時にどこから見るべきかを即座に押さえられる感覚
• コスト · セキュリティ · アップグレードの定期サイクルが頭の中にカレンダーとして固まった形

次の章 — 5部の本格運用 #

この時点で myshop-api は、コードから配備 · 運用 · 観測 · 定期サイクルまですべて自動化された状態です。しかし運用の 事故対応 の質感は、自動化では解けない領域です。どんな事故がどんな形で入ってくるのか、そのときどこから見るべきか、どのツールがどんなシグナルを見せてくれるのかの深さは、別の質感で扱わなければなりません。

5部 (運用 · デバッグ · コスト) の4章がその質感を埋めます。

• 第27章 kubectl デバッグパターン — Pod / Service / Ingress / Node の事故タイプ別の診断経路。CrashLoopBackOff、ImagePullBackOff、OOMKilled、OutOfSync のような定番事故の責任追跡法。
• 第28章 コスト最適化 — 本章の5つのコスト出所を本格的に押さえる質感。Spot · Karpenter · right-sizing · Savings Plans の決定ツリー。
• 第29章 シークレット運用 — K8s Secret の base64 の限界、sealed-secrets · external-secrets · SOPS の比較、IRSA + RDS IAM auth の「パスワード0」運用、保存 · 回転 · 注入 · 監査の四つの軸。
• 第30章 アップグレード戦略 — K8s マイナーリリースのサイクル、コントロールプレーン → データプレーン → アドオンの順序、deprecated API の検出 (pluto / kubent / apiserver メトリック)、drain の安全装置 (PDB · terminationGracePeriodSeconds · preStop)、アップグレード前1週 / 当日 / 後1週のチェックリスト。

その後は 6部キャップストーン 第31章 フルスタックアプリ EKS 配備 で本書のすべての質感を一つのプロジェクトに束ね、付録A docker-compose から K8s へ で Docker / docker-compose ユーザーのための移行ガイドで締めくくります。

練習問題 #

1. ご自身の運用シナリオ (または学習用 myshop-api クラスタ) に合わせて §「定期運用カレンダー」の6行を埋め直してみます。各項目に担当者 (またはご自身の役割) · 使うツール · 最後の実行日 · 次の予定日を併せて書きます。埋めたカレンダーが一ページに収まるかを確認し、収まらなければ何を外すべきかを判断します。
2. dev クラスタの EKS バージョンを一段階マイナーアップグレードしてみます。§「アップグレードの標準の流れ」の8段階のうち、どの段階が最も多くの時間を取るかを計測し、deprecated API の整理で pluto と kubent がそれぞれどんな項目をつかんでくれたかを一つの表で比較します。第22章 の PDB がノード rolling 中に実際にどんな保護をしたかを kubectl get events で追跡します。
3. RDS PITR 復旧訓練を §「復旧訓練」の5段階で一度たどってみます。4段階目の機能テストで myshop-api のどのシナリオが最も検証価値が高いかを、ご自身のドメインに合わせて整理し、訓練の結果を 第25章 の Runbook git repo に一ページとして文書化します。次の四半期訓練の改善点も併せて書いておきます。

一行まとめ: 運用クラスタの定期サイクルは、EKS マイナーアップグレード (四半期) + RDS PITR · Velero バックアップと四半期復旧訓練 + Karpenter Spot · OpenCost コスト可視化 + kube-bench · Trivy · Kyverno セキュリティ点検の四つの軸が、毎日 · 毎週 · 毎月 · 四半期 · 半期 · 年のカレンダーに束ねられて回る。「バックアップがある」ではなく「復旧が検証された」が運用の標準であり、一度セットアップしたあと「よく回っているから忘れて暮らす」が最も危険なパターン。4部の6章が仮想シナリオ myshop-api を抽象から具体へ移し、1 ~ 4部の26章が、マニフェスト一枚の意図から四半期運用カレンダーまでを一人の頭の中に自然に束ねる視野を作った。