#Kubernetes
136 件の記事
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 編にまとめます。
K8s 基礎 #7 Namespace とラベル — クラスタの整理法
シリーズを追っている間、1 つの事実が静かに通り過ぎました — 今まで作った Pod、Deployment、Service、ConfigMap、Secret が全て default namespace 1 か所に入っていたという点。そして [#4](/ja/posts/k8s-basics-4) の selector からラベルもずっと見ていましたが整理はしていませんでした。この記事はその 2 つの道具 — Namespace とラベル — でクラスタを人が読める形に整える方法を扱い、シリーズ 7 編の到達点で次のトラック (K8s 中級) を短く予告します。
K8s 基礎 #6 ConfigMap と Secret — 設定の分離
[#5](/ja/posts/k8s-basics-5) まで作ったマニフェストには 1 つ違和感が残っています — イメージタグ・ポート・ドメインのような値がマニフェストに直接書かれたままという点。この記事ではその空白を埋める 2 つのオブジェクト ConfigMap と Secret を整理します。12-factor の「設定は環境に置く」を K8s でどう解くか、env / envFrom / volume の 3 つの注入方式、Secret は本当の暗号化ではないという 1 行、設定が変わったとき Pod 再起動が必要な理由までを 1 サイクル追います。
K8s 基礎 #5 Service — ClusterIP / NodePort / LoadBalancer
[#4](/ja/posts/k8s-basics-4) で Pod 3 つを立てるところまでは来ましたが、その 3 つにトラフィックをどう流すかが空いています。Pod IP は毎回変わり、同じ Deployment の 3 つの Pod 間に負荷分散も無く、外部ブラウザからのアクセスは全くできません。この記事はその空白を埋める抽象 — Service の安定 IP・DNS、selector・Endpoints の動作、ClusterIP / NodePort / LoadBalancer 3 タイプの選び方までを 1 サイクル追います。