すごいぞManaged Kubernetes

すごいぞManaged Kubernetes Thursday, April 9, 2026 Haruka Sakihara Kubernetes Novice
Tokyo #40

自己紹介 Haruka Sakihara <主な取得資格> • ネットワークスペシャリスト試験(IPA) • AWS Certified 全13資格
• Google Cloud Certification 10資格 • Microsoft Certified 5資格 <所属> • アクセンチュア株式会社テクノロジーコンサルティング本部 (2021年新卒入社) • クラウドの部署にいます <趣味> • Go言語が好きです • フィギュアスケートとサンリオも好きです <その他表彰> • 2023 Japan AWS Jr.Champion • 2024-25 Japan AWS All Certifications Engineer

Kubernetesを使ってる人は挙手

Managed Kubernetes (EKS/AKS/GKEなど)を使ってる人は挙手

“Managed” Kubernetesのありがたさを本当にわかってますか？？？？

実はマネージドKubernetesがすごいところ • ネットワークの設定が簡単！ • サービスの外部公開が簡単！ • データの永続化が簡単！ • クラウドサービスを触るための権限付与が簡単！ •
コンテナのデプロイが簡単！

クラスタ上にあるPodのネットワーク設定 Kubernetesのクラスターを作って、その上にPodをデプロイすることを考えます。Podにはクラスタ外部・内部と通信するためにIPアドレスが割り振られています。 Kubernetesクラスタ IPアドレス① IPアドレス② IPアドレス③ IPアドレス④

CNI PluginによるVPC統合セルフホストk8sでは、Podに割り振られるIPアドレスはクラスタを形成するEC2インスタンスや VPCのIPアドレス範囲とは完全に別範囲のものが割り振られます。しかし、AWS VPC CNIがプリインストールされているEKSでは、PodのIPはVPCのCIDR範囲内から自動で割り当てられます。 Self-Managed VPC (10.0.0.0/16)
EC2 instance contents Instances 192.168.0.1 192.168.0.2 192.168.0.3 192.168.0.4 192.168.0.5 192.168.0.6 VPCと無関係なIPが割り当てられる

CNI PluginによるVPC統合セルフホストk8sでは、Podに割り振られるIPアドレスはクラスタを形成するEC2インスタンスや VPCのIPアドレス範囲とは完全に別範囲のものが割り振られます。しかし、AWS VPC CNIがプリインストールされているEKSでは、PodのIPはVPCのCIDR範囲内から自動で割り当てられます。 Self-Managed VPC (10.0.0.0/16)
EC2 instance contents Instances 192.168.0.1 192.168.0.2 192.168.0.3 192.168.0.4 192.168.0.5 192.168.0.6 VPCと無関係なIPが割り当てられる EKS VPC (10.0.0.0/16) Amazon EKS 10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 10.0.0.5 10.0.0.6 VPCのCIDR範囲内からIP払い出し EKSクラスタ上のPodネットワークは VPCとシームレスに統合されている

クラスタ上にあるサービスの外部公開 Kubernetes上にサービスをデプロイしたとき、それを外部に公開するためにはIngressと呼ばれる k8sリソースをクラスタにデプロイする必要があります。 Kubernetesクラスタユーザー Ingressを通してユーザーがサービスにアクセスする！

IngressとALBの統合 Self-Managedクラスタですと、ただIngressをデプロイしたとしても対応するクラウドサービスが作成されないので外部公開は一筋縄ではいきません。 AWS LoadBalancer ControllerがインストールされているEKSクラスタであれば、Ingressをデプロイしたら自動的にALBがデプロイされます。 Self-Managed VPC (10.0.0.0/16)
EC2 instance contents (192.168.0.1) (192.168.0.2) Ingressを作ってもそのままだと何も起こらない！！！

IngressとALBの統合 Self-Managedクラスタですと、ただIngressをデプロイしたとしても対応するクラウドサービスが作成されないので外部公開は一筋縄ではいきません。 AWS LoadBalancer ControllerがインストールされているEKSクラスタであれば、Ingressをデプロイしたら自動的にALBがデプロイされます。 Self-Managed VPC (10.0.0.0/16)
EKSはIngressデプロイと連動してALBを作れる！ EC2 instance contents (192.168.0.1) (192.168.0.2) Ingressを作ってもそのままだと何も起こらない！！！ EKS VPC (10.0.0.0/16) EKS Managed Cluster (10.0.0.1) (10.0.0.2) Application Load Balancer 自動作成 PodのIPを直接Targetに設定

クラスタでのデータ永続化 Podはコンテナなので、削除されてしまうとその中にあったデータは消えてしまいます。永続化したいのであれば、Persistant Volumeというリソースを作る必要があります。 Kubernetesクラスタ

クラスタでのデータ永続化 Podはコンテナなので、削除されてしまうとその中にあったデータは消えてしまいます。永続化したいのであれば、Persistant Volumeというリソースを作る必要があります。しかし、k8sクラスタ上で定義されたPersistantVolumeは、実体としてはどこにあるでしょうか？ Kubernetesクラスタデータを永続化するためには Volumeが必要！！！ ↓ このデータはクラウド上のどこにある？

Persistent Volume(PV)とEBS/EFSの統合 EBS CSI DriverやEFS CSI DriverがインストールされたEKSクラスタであれば、PV Claimをデプロイしたらデータが指定のEBSやEFSに保存されるようになります。それがないSelf-Managedクラスタですと、データの永続化のためにCSI
Driverを自力でインストールする必要があります。 AWS Cloud provisioner: ebs.csi.aws.com Storage Classを指定 provisioner: efs.csi.aws.com Amazon EFS Amazon EBS データが連動 EKSならば最初からこの仕組みが入っている！データが連動 Storage Classを指定

Podが使う権限の設定 Podが外部サービスのAPIを叩くときには、適切な権限を持ったServiceAccountと呼ばれるリソースを作成し、それをPodと紐づけることで権限付与を行います。 Kubernetesクラスタ Amazon SQS ②ServiceAccountが持つIAM権限のもと API callができる！ AWS
Identity and Access Management (IAM) ①PodとServiceAccountを紐づける

Podが使う権限の設定 Podが外部サービスのAPIを叩くときには、適切な権限を持ったServiceAccountと呼ばれるリソースを作成し、それをPodと紐づけることで権限付与を行います。 Kubernetesクラスタ Amazon SQS ②ServiceAccountが持つIAM権限のもと API callができる！ AWS
Identity and Access Management (IAM) ①PodとServiceAccountを紐づける Q. ここはどうやって実現している？？

Service AccountとIAM Roleの統合(1/2) EKSにはIAM Roles for Service Accounts(IRSA)という仕組みがあり、k8sのServiceAccountにIAM Role権限を紐づけることができます。 EKS
Cluster AWS Cloud Role IAM OIDC Provider Managed OIDC Provider (https://oidc.eks.region .amazonaws.com) AWS STS ④トークンのsub, aud属性が RoleのAssume Conditionに一致するかを検証 ② AssumeRoleWithWebIdentity Principal: OIDC Federated User Condition: sub=SA & aud=AWS STS ⑤Temp Creds ①IDトークン発行 ③トークン署名検証連携

Service AccountとIAM Roleの統合(2/2) EKSクラスタにはeksctlコマンドで簡単にIAM OIDC Providerを組み込むことができ、これにより IRSAを構成できます。Self-Managedクラスタで同様のことを実現するためには、OIDC Providerを用意したうえでAmazon EKS
Pod Identityを自力で構成する必要があります。 EKS Self-Managed EC2 self-managed Cluster EKS Cluster AWS Cloud AWS Cloud IAM S3 Bucket CloudFront OIDC Provider 自作OIDC Provider (OIDC Configurationと JWKSを公開) AWS STS Managed OIDC Provider (https://oidc.eks.region .amazonaws.com) 自動連携登録自作OIDC Providerの秘密鍵で SA tokenを発行 IAM OIDC Provider AWS STS Managed Control Plane

プライベートレジストリのイメージデプロイ AWS ECRのような、適切な権限を持ったワークロードからでないとPullできないようなイメージを使ってPodを構成することがあります。では、KubernetesクラスタはそのPull権限をどのようにして手に入れたのでしょうか？ KubernetesクラスタこのPull権限はどこから？？？？ Amazon Elastic Container
Registry (Amazon ECR) イメージPull

EKS Cluster Node Image Credential Providerのセットアップ ECRのようなプライベートレジストリを利用する場合、そのPull権限を持つクレデンシャルをPodデプロイを行うkubeletに渡す必要があります。これをするにはImage Credential Providerのセット
アップが必要ですが、EKSのAMIには初めからその設定が備わっています。 EKS Self-Managed EC2 self-managed Cluster AWS Cloud AWS Cloud xxx.dkr.ecr.ap-northeast- 1.amazonaws.comというイメージ名ならECR Image Credential ProviderからイメージPull credsを取得 Amazon Elastic Container Registry (Amazon ECR) Amazon Elastic Container Registry (Amazon ECR) ECRからイメージPull Config ECR Image Credential Provider Program Binary

マネージドKubernetesなら気にせずできることまとめ • クラスタがあるVPCの中から自動でPod IPが払い出される！ • Ingressを作るだけでALBがデプロイできる！ • Persistent VolumeをデプロイするだけでEBS/EFSにデータ永続化ができる！ •
ServiceAccountとIAM Roleの連携が簡単にいい感じにできる！ • 何もしなくてもECRからコンテナイメージをPullできる！ • … and more!

総括マネージドって意外といろいろやってくれてるんやなあ (感謝しようね！！！！)

Thank You ご意見、ご質問ありましたらお気軽にご連絡下さい [email protected] Haruka Sakihara(崎原晴香)

すごいぞManaged Kubernetes

すごいぞManaged Kubernetes

Haruka Sakihara

More Decks by Haruka Sakihara

Other Decks in Technology

Featured

Transcript