Kubernetes
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 サイクルでまとめます。
K8s 中級 #4 resources.requests / limits — Pod のリソース要求と上限
[#3](/ja/posts/k8s-intermediate-3) まで外部トラフィックがクラスタの中へ入ってくる道をまとめました。この記事の視点は再び Pod の中に入ってきます — コンテナが CPU とメモリをどう要求し、どう制限を受けるかのモデルです。`resources.requests` はスケジューラがノードを選ぶときに見る値で、`resources.limits` は kubelet がランタイムに強制する上限です。この 2 つの分離、QoS クラス(Guaranteed / Burstable / BestEffort)、CPU throttling と OOMKilled の違い、JVM・Go ランタイムの cgroup 認識、`LimitRange` で namespace のデフォルトをかけるパターンまで 1 サイクルでまとめます。
K8s 中級 #3 Ingress と Ingress Controller — 外部入口
[K8s 基礎 #5](/ja/posts/k8s-basics-5) の LoadBalancer は外部入口の標準ですが、外部公開が必要な Service が数十個あれば、Service ごとにクラウド LoadBalancer を 1 つずつ立てるコスト・管理の負担が急速に膨らみます。ドメインやパスごとにトラフィックを分けなければならない要求も、LoadBalancer 1 段では解けません。この記事ではその負担を 1 か所に集めるオブジェクト `Ingress` と、そのマニフェストを実際のトラフィックに解いてくれる Ingress Controller(nginx / Traefik / GKE Ingress / AWS ALB Controller など)の 2 層モデル、ホスト・パスベースルーティング、`pathType`、TLS 終端、`IngressClass` まで 1 サイクルでまとめます。
K8s 中級 #2 PV / PVC / StorageClass — 永続データモデル
[K8s 基礎 #6](/ja/posts/k8s-basics-6) までマニフェストに埋まっていた設定とシークレットを外部オブジェクトに分離しましたが、もう 1 次元が残っています — データそのものです。コンテナ内のファイルシステムはコンテナが死ねば一緒に消えますが、DB データ・ユーザーアップロード・メトリクス時系列は Pod のライフサイクルの先まで生き残らなければなりません。この記事ではその空白を埋める 3 つのオブジェクト `PersistentVolume`、`PersistentVolumeClaim`、`StorageClass` の三角関係、静的・動的プロビジョニング、`accessModes`、`reclaimPolicy`、`volumeBindingMode`、そして [#1](/ja/posts/k8s-intermediate-1) で短く触れた `volumeClaimTemplates` がその上で実際に何を作り出すのかを 1 サイクルでまとめます。
K8s 中級 #1 StatefulSet / DaemonSet / Job / CronJob — Deployment ではない他のコントローラ
[K8s 基礎 #4](/ja/posts/k8s-basics-4) の Deployment は stateless ワークロードの上に立つコントローラです。同じ Pod が複数互いに同じだと仮定し、消えてもまた立てればいいという単純なモデルです。しかしアイデンティティとディスクが必要な DB、ノードごとに正確に 1 つずつ立つべきエージェント、1 度実行して終わるべきマイグレーション、毎日回るバックアップ — この 4 つは Deployment では表現されません。この記事ではその空白を埋める 4 つのコントローラ StatefulSet、DaemonSet、Job、CronJob を 1 編にまとめます。