Kubernetes運用前に勉強していること基礎編03-08

注意
本記事の内容は個人的な勉強・備忘録を目的としており、勤務先や関係者とは一切関係ありません。

---

はじめに

Kubernetesの本番環境での運用を始めるにあたり、個人で勉強している内容を整理した記事です。構築や運用に必要な知識、注意点、実践して学んだことを随時更新していきます。基礎編の想定読者はコンテナの知識があり、Kubernetesでコンテナ運用したいがどうすればいいかを迷っている人です。今回は前回の引き続きで、Kubernetesのリソースカテゴリを学ぶことを目的としています。

勉強中の主な内容

• 基礎編
  • クラウドネイティブとは
  • Kubernetesのアーキテクチャ概要
  • Kubernetesのリソース（今回の話）

Cluster／Metadata APIsについて

カテゴリ	典型ユースケース
Cluster APIs	マルチテナント分離、リソース上限、RBAC、L3/L4 ネットワーク制御
Metadata APIs	動的スケール、可用性担保、API 拡張

Cluster APIs（クラスタ管理）

Kind	主用途 / 重要フィールド	観点
Namespace (Namespace )	テナント分離・RBAC・ResourceQuota の単位	テナントモデルを決めてから作成。削除時は残存リソースに注意（Finalizer）
ResourceQuota (Namespace)	CPU, メモリ, PVC, Service 等	スポットノード＋Karpenterを組み合わせる場合、動的監視が必須
LimitRange (Namespace )	default, defaultRequest, max, min	様々なEC2のインスタンスタイプ系を混在させるなら CPU 単位の粒度を意識
ServiceAccount ( Namespace )	Pod へのトークン発行、RBAC バインド	IRSA で AWS IAM ロールを紐付け、Pod ごとに最小権限を実現
Role / RoleBinding (Namespace)	名前空間内 RBAC	ClusterRole を上書きしないよう明示的 deny を NetworkPolicy と併用
ClusterRole/ClusterRoleBinding (Cluster)	クラスタ横断 RBAC	Operator, Admission Webhook など制御面コンポーネント向け。OIDC issuer URL を IAM に登録し、system:masters を作らない
NetworkPolicy (Namespace)	Ingress/Egress ルール	Security Groups for Pods を有効にすると ENI レイヤで VPC セキュリティグループを Pod に適用可
IAM Roles for Service Accounts (Namespace )	SA‑>IAM OIDC Federation	AWS サービス操作時の長期キー廃止。Pod 起動失敗時は aws-iam-token InitContainer のログを確認
Security Groups for Pods(Namespace)	Pod 単位で VPC SG を割当	L7 Policy 不要・VPC レイヤで DB 等を保護
EKS Add‑ons (Cluster)	マネージドアドオン	Lifecycle を AWS が管理。

Metadata APIs（メタデータ管理リソース）

Kind	主用途 / 重要フィールド	観点
HorizontalPodAutoscaler (Namespace)	spec.metrics	Karpenter の 必用な時にリソース追加する仕組みとリソース目標の設定値を組み合わせて運用すること
PodDisruptionBudget(Namespace)	minAvailable / maxUnavailable	maxUnavailable: 0 はアップグレードを阻害する危険。優先度クラスとの併用を
CustomResourceDefinition (Cluster)	validation, conversion, subresources	cert-manager, ArgoCD など多数の運用系 CRD が入るため衝突監視
MutatingAdmissionWebhook / ValidatingAdmissionWebhook (Cluster)	Pod spec	タイムアウト短縮で API Server 遅延を防止。
APIService (Cluster)	Aggregated APIサーバ登録	バージョン管理とヘルスチェック (/healthz) を実装
AWS Controllers for Kubernetes(Cluster)	AWS リソース CRD + Controller	OIDC 連携の IAM ロールは Controller/IRSA 用・ターゲット用に分離
Karpenter (Cluster)	Provisioner, NodePool, NodeClass	Spot/Mixed family最適化。consolidation で穴埋め再配置

設計・運用のポイント

Cluster APIsの場合

Namespace 戦略と IRSA の統合

EKS では OIDC Provider がクラスタ単位で 1 つ のため、サービスアカウント名と IAM ロール名を環境名/アプリ名/役割で命名し、セキュリティを保つ。

ResourceQuota × Karpenter

Karpenter は PendingPod のリソース要求を読んで最適解の EC2 を即時起動するため、Quota 値を実 CPU/メモリ総量より低く抑える とスケールアウトできず、SLO達成率が低下する。

NetworkPolicy vs. Security Groups for Pods

L3/L4 制御を VPC に寄せると CloudTrail で通信イベントを可観測化でき、GuardDuty で異常検知も可能。
ただし SG×Pod 数が増えると ENI 制限（EC2 インスタンスタイプ依存）がネックになる。

Add‑on ライフサイクル

自己管理アドオン(Amazon Elastic Block Store (EBS) CSI driverなど) → マネージドアドオンに移行すると、IAM → Add‑on 付属ロールに切替

Metadata APIsの場合

HPA 設計の順序

1. アプリケーションの SLOを決める
2. SLO ↔ Pod CPU/メモリ↔リクエスト数 の相関を負荷試験で測定
3. targetUtilization（v1）/targetAverageValue（v2）算出

さらに Karpenter が 1 分以内にノードを用意

Admission Webhook の信頼境界

EKS では Public API endpoint を無効化し Private Clusterにする構成が推奨である。Admission Webhook も Private NLB behind SG で限定公開し、caBundle を ACM PCA でローテーションする。

まとめ

所感としては、EKS でコストパフォーマンスを追求するうえでは、単に Pod やノードのスケール戦略を考えるだけでなく、HPA や Karpenter といった“動的スケールのメタデータ”をどこまで粒度細かく設計できるかが鍵になるという点だ。
実運用では負荷が跳ねた瞬間に必要なリソースを即時に確保しつつ、平常時は無駄を徹底的に絞る必要があり、その判断軸を与えてくれるのが Metadata API 群に埋め込まれた数値や閾値である。
Cluster API 側は、IRSA や Security Groups for Pods など EKS 固有の拡張を意識しておくと、最小権限とネットワーク分離を“クラウド原生”の仕組みで担保でき、オーバーヘッドを抑えつつセキュリティレベルを底上げできる。

結局のところ、コストと可用性を両立させるには、メタデータで動的挙動を制御し、クラスタ管理は EKS に寄り添ってマネージド機能を最大限享受する、という二段構えが最も合理的だと感じた。EKSを利用する最大のメリットはSLO と請求額の両面をリアルタイムに可視化する運用が容易にできる点だと思われる。

補足

過去の記事で記載していた内容を補足として追記しています。

Kubernetesのリソースカテゴリ

Kubernetesのリソースカテゴリは、『Kubernetes完全ガイド第二版』をベースとしている。

カテゴリ	概要
Workload APIs	アプリケーション（コンテナ）の実行を管理するためのリソース
Service APIs	Pod内のコンテナをネットワーク経由で公開し、アクセスを提供するリソース
Config APIs	コンテナで利用する設定や機密情報を管理するためのリソース
Storage APIs	コンテナで利用する永続化データを管理するためのリソース
Cluster APIs	クラスタ内のリソースの運用や管理、セキュリティを制御するリソース
Metadata APIs	クラスタ内の他リソースの操作や動的なメタデータ管理を行うリソース