Kubernetes
K8s 実戦 #3 DB 連動 — RDS / Secrets Manager / External Secrets / コネクションプール
[#2](/ja/posts/k8s-practice-2) で外部公開まで作った myshop-api はデータストアが空の殻です。この記事では RDS PostgreSQL を Terraform で立てて、AWS Secrets Manager にマスター秘密を置き、External Secrets Operator でその秘密を K8s Secret に自動同期し、IRSA で静的資格情報なしにアクセスし、PgBouncer でコネクションプールまで載せる運用流れをまとめます。スキーマ移行を Job で自動化するパターンも一緒に押さえます。
K8s 実戦 #2 アプリデプロイの基本構造 — Deployment / Service / Ingress / Helm
[#1](/ja/posts/k8s-practice-1) で立てた空の EKS クラスタに myshop-api を載せる段階です。Deployment / Service / Ingress / ConfigMap / Secret / ServiceAccount / HPA を 1 セットで整理し、AWS Load Balancer Controller で ALB を自動プロビジョニングし、その束を Helm chart で抽象化して dev / prod に同じ chart が異なる values でデプロイされる流れまで 1 サイクルでまとめます。
K8s 実戦 #1 EKS クラスタセットアップ — Terraform / eksctl / IRSA / アドオン
K8s 実戦シリーズの最初の記事です。抽象ではなく実際の運用クラスタを構成する流れを追います。Terraform で VPC と EKS クラスタを定義し、ノードグループと IRSA をセットアップし、必須アドオン(VPC CNI、CoreDNS、kube-proxy、EBS CSI)まで載せる流れです。早いセットアップが必要なときの eksctl オプションも一緒に比較します。6 編全体で使う仮想サービス myshop-api のためのクラスタの出発点を作る最初の記事です。
K8s 上級 #6 GitOps — ArgoCD / Flux
K8s 高級シリーズの最後の記事です。マニフェストの source of truth を git に置き、クラスタ内のコントローラが git を watch して同期する運用モデル — GitOps をまとめます。push モデルと pull モデルの違い、ArgoCD の Application CRD と sync wave、Flux の Source / Kustomization / HelmRelease、ディレクトリ構造パターン、Sealed Secrets / External Secrets で秘密を git に安全に置く道までがこの記事の範囲です。シリーズ最後の記事なので K8s 高級 6 編の振り返りと次のトラック K8s 実戦の予告も一緒に入れます。
K8s 上級 #5 オブザーバビリティ — Prometheus / Grafana / Loki / OpenTelemetry
運用クラスタのオブザーバビリティはメトリクス、ログ、トレースの 3 軸で構成されます。各軸の K8s 標準スタックはほぼ固まっています。メトリクスは Prometheus + kube-state-metrics + node-exporter、ログは Loki(または EFK)、トレースは OpenTelemetry、可視化は Grafana、アラームは Alertmanager。この記事では 3 軸のモデルと各軸の標準コンポーネント、そしてカーディナリティ・保存期間・アラーム設計のような運用原則を 1 サイクルでまとめます。
K8s 上級 #4 CRD と Operator パターン — controller-runtime
K8s が強力な理由の 1 つは自分の API 自体を拡張できる点です。CustomResourceDefinition で新しいオブジェクト種を定義し、controller-runtime でそのオブジェクトに対する reconcile ループを書けば K8s の上に私たちのドメインのオブジェクトが標準リソースのように住むことになります。PostgresCluster、RedisFailover、KafkaBroker のような名前のオブジェクトがその結果物です。この記事では CRD のモデル、controller-runtime ベースの Operator 骨格、ownerReference / finalizer / status subresource まで 1 サイクルでまとめます。
K8s 上級 #3 Admission Controller — OPA Gatekeeper / Kyverno
K8s API サーバはマニフェストを etcd に保存する直前に検査して変形できる段階を持っています。Admission Controller というこの段階が運用クラスタのポリシーエンジンが入る道です。「limits なしのコンテナを拒否」「特定ラベルを強制」「イメージの出所を制限」のようなポリシーをコード 1 行も変えずにマニフェスト次元で防ぎます。この記事では admission 段階の位置、ビルトインコントローラ、ValidatingWebhook と MutatingWebhook、そして 2 つのポリシーエンジン OPA Gatekeeper と Kyverno のモデルを 1 サイクルでまとめます。
K8s 上級 #2 RBAC / ServiceAccount 深掘り — Aggregated ClusterRole / Impersonation / IRSA / Workload Identity
[中級 #7](/ja/posts/k8s-intermediate-7) で RBAC の 4 つのオブジェクトと ServiceAccount のモデルを押さえました。その上に運用クラスタで出会う深さがさらにあります。ClusterRole をラベルで合わせて拡張可能にする Aggregated ClusterRole、別のユーザーの権限で一時的に振る舞う Impersonation、ServiceAccount のトークンが legacy secret から projected token に変わった流れ、そして K8s の ServiceAccount をクラウドの IAM と組み合わせる EKS の IRSA と GKE の Workload Identity まで — 権限モデルの 1 層さらに深い部分をまとめます。
K8s 上級 #1 CNI 深掘り — Calico / Cilium / eBPF
K8s 高級シリーズの最初の記事です。[中級 #7](/ja/posts/k8s-intermediate-7) で NetworkPolicy を扱いながら 1 行残しておきました。「マニフェストは K8s 標準だが、実際にトラフィックを止めるのは CNI プラグインがする。」 その 1 行をほぐすのがこの記事のテーマです。CNI とは何か、同じ K8s マニフェストが Calico の上と Cilium の上でどう違って動くか、eBPF がデータプレーンをどう書き換えるかを 1 サイクルでまとめます。
K8s 中級 #7 RBAC / NetworkPolicy / ResourceQuota — セキュリティとリソースポリシー
K8s 中級シリーズの最後の記事です。[#6](/ja/posts/k8s-intermediate-6) までワークロード運用モデル — コントローラ、永続データ、外部入口、リソースモデル、ヘルスチェック、オートスケーリング — まで整理しました。この記事では 1 つのクラスタの上に複数のチーム・環境が一緒に住むマルチテナント運用の最後の空白を埋める 3 つのオブジェクト `RBAC`、`NetworkPolicy`、`ResourceQuota` を整理します。誰がオブジェクトを作れるか、どんなトラフィックが通るか、どれくらい作れるかの 3 つの次元がすべて namespace 単位ポリシーとして束ねられ、[基礎 #7](/ja/posts/k8s-basics-7) で短く触れた Namespace の本当の価値がこの 3 つで解かれます。シリーズ最後の記事なので、7 編の振り返りと次のトラック(K8s 上級)の予告も合わせて入れます。
K8s 中級 #6 オートスケーリング — HPA / VPA / Cluster Autoscaler
[#5](/ja/posts/k8s-intermediate-5) まで扱ったモデルは単一 Pod のリソースと健康信号の次元でした。しかし運用の負荷は時間帯・ユーザーパターン・イベントに従って揺れ、人が毎回 `replicas` 値を手で合わせることはすぐに限界にぶつかります。この記事ではその空白を埋める 3 つの次元のオートスケーリング — Pod 個数を自動で増減する `HPA`、Pod のリソース要求・上限を自動で推奨・調整する `VPA`、そしてノード自体を自動で追加・削除する `Cluster Autoscaler` を 1 サイクルでまとめます。metrics-server という前提、HPA の `autoscaling/v2` マニフェストとアルゴリズム、scale up・down 非対称の `behavior`、custom metric と KEDA、VPA の 3 コンポーネント、HPA・VPA の衝突、Karpenter まで扱います。
K8s 中級 #5 Health check — liveness / readiness / startup probe
[#4](/ja/posts/k8s-intermediate-4) まで Pod のリソースモデルをまとめたとすれば、この記事は K8s がコンテナの「生存」と「トラフィックを受ける準備」をどう判断するかのモデルです。3 種類の probe — liveness、readiness、startup — がそれぞれ違う役割を担い、誤って設定すると無限再起動ループ・トラフィック取りこぼし・起動失敗のような運用事故に直結します。`httpGet` / `tcpSocket` / `exec` の 3 つの検査方式、`initialDelaySeconds` / `periodSeconds` / `failureThreshold` のような共通パラメータ、liveness に外部依存を入れたときの cascading failure、`terminationGracePeriodSeconds` と PreStop フックが描く graceful shutdown まで 1 サイクルでまとめます。