Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EKSクラスタをいい感じに作ろうとしたら令和になった話(前編) / We tried to build EKS cluster nicely

ykoma
May 24, 2019

EKSクラスタをいい感じに作ろうとしたら令和になった話(前編) / We tried to build EKS cluster nicely

ykoma

May 24, 2019
Tweet

More Decks by ykoma

Other Decks in Technology

Transcript

  1. Ameba広告システム規模 •150,000+ RPS 配信面からの広告リクエスト、計測リクエスト SSPからのbidリクエスト 運用管理画面からのAPIリクエスト etc … •50+ Micro

    services 運用開始から丸4年以上が経過 モジュールや機能が大量に追加 (運用開始当初は両手で足りる程度だった)
  2. インフラ刷新計画 AWS account X AWS account Y AWS account Z

    App A App B App C App D App E Before After App A App B App C App D App E
  3. EKS •Amazon Elastic Container Service for Kubernetes •AWSが提供する「マネージドKubernetesコントロールプレー ン」 masterノード、Etcdなどの面倒をAWSが見てくれる

    masterノードのマイナーバージョンアップはAWSが適用してく れる ClusterRoleとIAMロールやIAMユーザとの連携
  4. IAM User と IAM Role •IAM User キーとシークレットの文字列の組み合わせで認証する方式。 IAM Userに紐付けられたPolicyに沿って、AWSリソースに対してアクセスが可能。

    【メリット】 AWSの外からも簡単に利用できる 【デメリット】 アプリケーションから使用する際に、キーとシークレットをソースコード上やconfigファイル等にべた書きさ れることが多く、流出によるセキュリティリスクをはらむ。
  5. IAM User と IAM Role •IAM Role EC2などのAWSリソースに対して、AWSリソースの操作権限を与える方式。 【メリット】 キーやシークレットの管理が不要なため、

    ソースコード管理のミスによる流出リスクが 低減される 【デメリット】 EC2など適用可能なAWSリソースが限られて いる AWS Black Belt Techシリーズ AWS IAM より引用 https://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam
  6. EC2とIAM Role EC2 for App X EC2 for App Y

    S3 Y DynamoDB X DynamoDB X の操作可能なポ リシーを持ってい るよ IAM Role X S3 Y の操作可能なポ リシーを持ってい るよ IAM Role Y EC2に対し、それぞれに適したIAM Roleを設定 →それぞれのRoleには、AssumeRole Policyを適切に設 定しておく IAM
  7. EC2とIAM Role EC2 for App X EC2 for App Y

    S3 Y DynamoDB X IAM Role X IAM Role Y STS Assume Roleによって、セッション情報を取得 IAM sts:assume-role sts:assume-role
  8. EC2とIAM Role EC2 for App X EC2 for App Y

    S3 Y DynamoDB X IAM Role X IAM Role Y 取得したセッション情報を使って各リソースにアクセス →EC2インスタンスからRoleで指定されたPolicyに沿ったアクセ ス制御ができる IAM AWS-STS
  9. Kiamの仕組み 図はBluematadorのブログより引用 https://www.bluematador.com/blog/iam- access-in-kubernetes-kube2iam-vs-kiam • Kiam Agent ◦ Daemonset (on

    Worker) ◦ PodのIAMへのリクエストメタデータAPIへ のリクエストをiptablesでフックしてKiam ServerとgRPC通信でRoleのセッション情 報をやり取り • Kiam Server ◦ Daemonset (on Master) ◦ masterノードに強力なIAM Roleを持たせ ておく ◦ Agent経由で、Podの代わりにIAMと通信 してセッション情報を取得
  10. KiamをEKSに導入。しかし… • Helm chartのデフォルト状態では、Kiam ServerもKiam AgentもただのDaemonsetと してWorkerノードにapplyされる • しかし、Kiam Serverは、masterノードで動

    かすことが想定されている ◦ ServerとAgentのPodが同一ノード上にい ると、iptablesの競合で動作しない ◦ EKSはmasterノードがマネージドサービス として隠蔽されている 詰んだか…
  11. Kiam Server専用ノードで解決 • Kiam Server専用のWorkerノードを用意 ◦ Kiam ServerはnodeSelectorで専用ノードで動作 ◦ Kiam

    Agentはaffinityで専用ノード以外で動作 ◦ 専用ノードのEC2に、必要なすべてのRoleをAssumedできるIAM Roleを割り当て • 注意点 ◦ Kiam以外のものは、基本的にnodeSelectorなりaffinityなりを指定する必要がある (Kiam Server専用ノードで他のPodが起動しないように) Worker for Kiam Server Worker for general App A App B Kiam Agent App C App D Kiam Server IAM
  12. まとめ • アプリケーションからAWSリソースにアクセスするときは、 IAM UserよりIAM Roleを • KubernetesでIAM連携するためにKiamを導入 ◦ Kiamを使うとPodレベルでIAM

    Roleを割り当てられる • EKSに導入するときにはKiam Serverを専用ノードに • 形ができたときには令和になってた