すごいぞManaged Kubernetes¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Managed Kubernetes、とくに Amazon EKS が、利用者から見えにくい部分でどれだけ多くの統合を肩代わりしているかを説明するスライド。 Pod ネットワーク、外部公開、永続ストレージ、IAM 連携、ECR からのイメージ取得など、Kubernetes を自前で動かすと設計・導入が必要になる領域を、EKS では AWS の周辺サービスと統合して扱える。 「マネージド」のありがたさを、Kubernetes の基本機能と AWS 側の実装の対応で理解する資料。
本文¶
この資料は、Managed Kubernetes の便利さを「Kubernetes を使えるようにしてくれる」だけでなく、「クラウド上で現実的に運用するための周辺統合をまとめて面倒見てくれる」として説明している。
Kubernetes そのものは、Pod をスケジューリングし、Service や Deployment などの抽象を提供する。 しかし、クラウド上で動かすには、それだけでは足りない。 Pod の IP アドレスはどのネットワークに属するのか。 外部からアクセスする Load Balancer はどう作るのか。 PersistentVolume はどのストレージを使うのか。 Pod から AWS API を呼ぶ権限はどう渡すのか。 プライベートなコンテナレジストリからどうやってイメージを取得するのか。
EKS のような Managed Kubernetes は、こうした周辺課題をクラウドサービスと統合して解く。
PodネットワークとVPC CNI¶
EKS では、AWS VPC CNI によって Pod の IP アドレスが VPC の CIDR から割り当てられる。 つまり、Pod が AWS VPC 内の一員として扱われる。
自前で Kubernetes を構築する場合、クラスタ内 Pod ネットワーク用に VPC とは別の CIDR を設計し、ノード間で Pod 宛通信を通す仕組みを用意する必要がある。 Overlay network を使うのか、ルーティングをどう配るのか、VPC 内の他リソースとどう通信させるのかを考える。
EKS では、VPC CNI がこの統合を担う。 Pod IP が VPC 上のアドレスとして見えるため、AWS のネットワーク機能と合わせやすい。 その代わり、VPC の IP アドレス枯渇やサブネット設計は重要になる。
Ingress と AWS Load Balancer Controller¶
Kubernetes の Ingress は、HTTP/HTTPS の外部公開ルールを表す抽象。 ただし、Ingress リソースを作っただけでは、実際のクラウド Load Balancer が勝手に作られるわけではない。 その変換を行う controller が必要になる。
EKS では AWS Load Balancer Controller を使うことで、Ingress や Service の定義から ALB や NLB を作成できる。 Kubernetes 側ではマニフェストを書き、AWS 側には必要な Load Balancer、Target Group、Listener などが作られる。
自前構築では、この controller の導入、IAM 権限、ALB/NLB との対応、ヘルスチェックやターゲット登録の管理を自分たちで整える必要がある。 Managed Kubernetes でも controller の導入・設定は必要だが、EKS と AWS の標準的な組み合わせとして整備されている。
永続ストレージと CSI Driver¶
Kubernetes の PersistentVolumeClaim は、Pod が永続ストレージを要求するための抽象。 しかし、実際にどのストレージを作るかは CSI Driver が担う。
EKS では、EBS CSI Driver や EFS CSI Driver を使うことで、PVC から EBS や EFS を作れる。 Deployment や StatefulSet は PVC を参照し、Kubernetes は StorageClass と CSI Driver を通じて AWS のストレージを用意する。
自前クラスタでは、CSI Driver の選定、インストール、権限設定、ボリュームのライフサイクル管理を自分たちで整える必要がある。 ストレージの種類によって、ReadWriteOnce、ReadWriteMany、AZ 制約、オンライン拡張の可否も変わる。
資料は、Managed Kubernetes が Kubernetes の抽象とクラウドストレージの実体をつないでいることを強調している。
PodからAWS APIを呼ぶ権限¶
EKS では IRSA、つまり IAM Roles for Service Accounts によって、Kubernetes の ServiceAccount と AWS IAM Role を結びつけられる。 Pod は ServiceAccount を使い、その ServiceAccount に紐づいた IAM Role を使って AWS API を呼べる。
仕組みとしては、EKS クラスタに OIDC Provider を設定し、Pod が持つ ServiceAccount のトークンを使って STS の AssumeRoleWithWebIdentity を呼ぶ。
これにより、ノード全体の IAM Role ではなく、Pod 単位に近い粒度で権限を分けられる。
自前 Kubernetes でも同様の仕組みを組めないわけではないが、OIDC Provider の設定、IAM Trust Policy、ServiceAccount アノテーション、トークン投影などを正しくつなぐ必要がある。
EKS と eksctl は、この設定を扱いやすくしている。
ECRからのイメージ取得¶
ECR はプライベートレジストリであり、イメージを pull するには認証が必要。
通常の Kubernetes では imagePullSecret を用意するなど、レジストリ認証情報の管理が必要になる。
EKS では、EKS 最適化 AMI に ECR Image Credential Provider などの設定が組み込まれており、kubelet が ECR から pull するための認証情報を取得できる。 これにより、ECR を使う標準構成では、利用者が個別に認証情報を配る手間が減る。
マネージドのありがたさ¶
資料のメッセージは、Managed Kubernetes は単にコントロールプレーンを AWS が管理するという話にとどまらない、ということ。 Pod ネットワーク、Load Balancer、Storage、IAM、Registry など、Kubernetes とクラウドの間にある接続面が整えられている。
Kubernetes の学習では、Deployment、Service、Ingress、PVC、ServiceAccount といったリソースを覚える。 しかし、クラウド上で使うには、それらが実際の VPC、ALB、EBS/EFS、IAM、ECR とどう対応するのかを理解する必要がある。 Managed Kubernetes は、その接続を標準化し、利用者の負担を減らす。
要点¶
- EKS は Kubernetes と AWS の各サービスをつなぐ多くの設定を肩代わりしている。
- AWS VPC CNI により、Pod IP は VPC CIDR から割り当てられる。
- AWS Load Balancer Controller により、Ingress や Service から ALB/NLB を作れる。
- EBS/EFS CSI Driver により、PVC から AWS ストレージを使える。
- IRSA により、ServiceAccount と IAM Role を結びつけられる。
- ECR Image Credential Provider により、ECR からのイメージ pull が扱いやすくなる。
- Managed Kubernetes の価値は、見えない統合作業が減ることにある。