AWSでkubernetesことはじめ 2019/04/20 ＠JAWS-UGさいたま支部 

Agenda 1. Kubernetes(k8s)とは • Dockerとかオーケストレーションツールの必要性みたいな話 • k8s動作の仕組み（ざっくり） 2. AWSのオーケストレーションサービス • ECS￿/￿EKS　ざっくり 3. EKSことはじめ • 特徴 • VPC統合 • IAM認証 • ほしい機能 • EKS利用にあたって（私見） 4. まとめ 

1.￿Kubernetes(k8s)とは 

Docker使ってますか？ • 可搬性 • IaaSに依存しないので、ハイブリッド、マルチクラウド化しやすい • docker￿buildでパッケージング化（AWSに依存しないAMIみたいなもの） • 役割の明確化 • お見合いしがちなレイヤーを明確にAPチームに • OSやミドルのインストール、設定 • 安全なデプロイ • IaaSレイヤーを抽象化することで、環境依存バグの発生を抑止 • テスト環境では動いたけど本番環境では動かない　みたいな話 

コンテナを使わない場合 OS(カーネル) OS(カーネル以外) 実行ランタイム(Javaなど) ミドルウェア（Tomcatなど) アプリケーション アプリチームが準備して管理 インフラチームが準備して管理 プロジェクト体制や会社によってまちまち 　・初期導入は各SW主管部や設定導入 　・維持運用はアプリチーム　 とかがよくあるパターン？ 

コンテナを使う場合 OS(カーネル) OS(カーネル以外) 実行ランタイム(Javaなど) ミドルウェア（Tomcatなど) アプリケーション アプリチームが準備して管理 インフラチームが準備して管理 コンテナランタイム 実行ランタイムより上位はアプリチーム が準備した方が効率が良い(※) (※)Dockerの（セキュアな）ベースイメージをインフラチーム が準備して開発者に提供するケースは十分あり 

増えてくると辛い問題 • 単一のコンテナや単一のサービス内でホストするなら問題なし • ひとつのサービス内で複数のコンテナが連携して動作するような構成を取りた い場合、Docker￿composeが便利 • 独自のローカルネットワークを構築して通信可能 • 可用性確保の課題 • 単一コンテナであってもMulti-AZで複数VMに負荷分散 • 個別にEC2とかロードバランサを設定する必要あり • サービスの成長への備え • サービスが増え、コンテナの種類やスケール数が増えたらどうする？ • インフラ管理、デプロイメント管理などが指数関数的に辛くなる… 

コンテナオーケストレーション • 複数のコンテナ（サービス）を”よしな”に配置し、可用性、負荷分散、 認証／認可、アクセス制御などのガバナンス統制を効かせることが可能 • 結構たくさんある • Docker￿Swarm • CoreOS￿fleet • Rancher￿Labs￿Rancher • Mesos￿Marathon • Google￿Borg￿->￿CNCF￿kubernetes　等 • 主導権争いの末、kubernetesが事実上のデファクトに • 以下資料がとってもわかりやすい • GKEを用いたレガシーシステムからのリプレース事例(P24-35)@GoogleCloud￿Kubernetes￿Day • https://cloudplatformonline.com/rs/248-TPC-286/images/Google_Cloud_Kubernetes_Day_Session02.pdf • CNCFもk8sをGraduateに Kubernetes￿Is￿First￿CNCF￿Project￿To￿Graduate￿:￿https://www.cncf.io/blog/2018/03/06/kubernetes-first-cncf-project-graduate/ 

Service￿B Service￿A Service￿G Service￿E Service￿C Service￿F Service￿D オーケストレーション オーケストレーション ■Docker単体でホストした場合 ※横からのイメージ ※上からのイメージ Service￿A Service￿B Service￿C Service￿D Service￿E Service￿F Service￿G ・各Serviceのコンテナは任意のノードに分散して配置 ・負荷分散やアクセス制御もオーケストレーションレイヤーで実現可能 ■オーケストレーションした場合 

kubernetes動作の仕組み（超ざっくり） • 全体は非同期分散処理システム • 色々なコンポーネントがそれぞれの役割を全うすることで全体を構成 • マイクロサービス？？？ • 詳細は割愛 • Control￿planeとData￿plane • それぞれはN台のサーバでクラスター構成 • Control￿plane:￿マスターデータストア、制御関連 • Data￿plane:￿実際のコンテナ(Pod)が配置されるエリア￿ • kubectlコマンドで操作 • k8s版aws￿cliみたいなもの • ノードを表示する例：kubectl￿get￿nodes • Podを表示する例：kubectl￿get￿pod 

kubernetes動作の仕組み（イメージ） Data￿plane ノード Control￿Plane Scheduler APIServer coredns ノード ノード controller kubelet kubeproxy kubelet kubeproxy kubelet kubeproxy Pod(Container) etcdの情報をもとにData￿planeの各種リソースを管理 etcd kubectl クライアント K8sクラスター K8sリソース管理 （作成、変更、削除、検索など） 

2.￿AWSのオーケストレーションサービス 

AWS￿Blog(Docker￿on￿AWS)より引用：￿https://aws.amazon.com/jp/blogs/news/jp-docker-on-aws-container-service-selection-example/ 

Elastic￿Container￿Service￿(ECS) • Control￿planeがAWS独自方式でマネージド • AWS連携が豊富 • Data￿plane • EC2 • ECS用のAgentが入っている以外は普通のEC2（ざっくり） • 自分好みにどうぞ • Fargate • Data￿planeを抽象化。利用者は本当にコンテナ（タスク）に注力できる • お作法はある 

Elastic￿Container￿Service￿for￿ Kubernetes￿(EKS) • K8sのControl￿planeがマネージド • 豊富なK8sエコシステムを利用可能 • Data￿plane • EC2 • EKS用のAgentが入っている以外は普通のEC2（ざっくり） • 自分好みにどうぞ • Fargate • 2019年中に対応予定 

Elastic￿Container￿Service￿for￿ Kubernetes￿(EKS) Data￿plane ノード Control￿Plane Scheduler APIServer coredns ノード ノード controller kubelet kubeproxy kubelet kubeproxy kubelet kubeproxy Pod(Container) etcdの情報をもとにData￿planeの各種リソースを管理 etcd kubectl クライアント K8sクラスター K8sリソース管理 （作成、変更、削除、検索など） ここがマネージド 

どっちを使うべきなの？議論はまた別途 

3.￿EKSことはじめ ・特徴（VPC統合、IAM認証） ・ほしい機能 ・意識すること 

EKSの特徴1￿:￿VPC統合　￿～概要～ • 同一VPCのクラスター外から、Podに直接ルーティング可能 • 本来K8sは、VPCなどのクラスター外のネットワークとは別の独自ネ ットワークを構成するので、クラスター外からの通信は明示的にアク セスポイントを設けないと疎通できない • 独自のCNIプラグインでPodにVPCのIPアドレスをアサイン • ノードのセカンダリIPをPodに割り当ててノードのメインNICとブリッジ • 通信制御はセキュリティグループで • ただし、ノード単位での設定になるので厳密ではない • 厳密にやりたい場合 • Node￿selectorそれに見合ったセキュリティグループをアタッチする • Network￿Policyを定義する amazon-vpc-cni-k8s：https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md 公式Doc（ポッドネットワーキング）：https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/pod-networking.html 

EKSの特徴1￿:￿VPC統合　￿～イメージ～ K8sクラスター(172.31.0.0/16) VPC(192.168.0.0/16) クラスター外のインスタンス Pod Pod Pod EKSクラスター(VPC統合) VPC(192.168.0.0/16) クラスター外のインスタンス Pod Pod Pod 明示的なアクセスポイントを設けないと通信できない Defaultでルーティング可能（SGで制御） ■普通のk8s(k8s￿on￿EC2)の場合 ■EKSの場合 

EKSの特徴2:￿IAM認証￿概要 • クラスターへの認証(kubectlの認証)をIAMで実施できる • aws-iam-authenticatorを使う 公式Docより引用：https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/managing-auth.html aws-iam-authenticator：￿https://github.com/kubernetes-sigs/aws-iam-authenticator 

EKSの特徴2:￿IAM認証￿フロー　1/2 • 事前準備 1. aws-iam-authenticatorをインストールする 2. kubectlの認証設定(kubeconfig) 1. EKS認証に使用する属性を設定　※コマンドで自動設定可能 aws￿eks￿--region￿￿update-kubeconfig￿--name￿ 2. aws-iam-authenticatorを使用するように設定する aws-iam-authenticatorのインストール：￿https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/install-aws-iam-authenticator.html kubeconfig￿を￿Amazon￿EKS￿用に作成する：https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/create-kubeconfig.html 

• kubectlコマンド実行のたびに行われる処理 1. kubectlは、aws-iam-authenticatorのtokenコマンドを使ってtokenを作成する • Tokenの内容は以下 • SDK￿for￿Go￿の￿sts.GetCallerIdentityRequestで生成されるURLにPreSignし、base64エンコードした文字列 • プレフィックスにk8s-aws-v1.を付加した文字列 • Client側はこの仕組みを利用するための権限は不要 • クレデンシャルかRoleが設定されていればいい 2. kubectlは、EKSのControl￿Plane（のAPI￿Server）にリクエストを投げる 3. EKS側はtokenをもとにsts.GetCallerIdentityリクエストを発行し、認証する • このリクエスト(token)を生成できるのはそのクレデンシャルを持っている人しか生成できない、という発想 4. EKS側はtokenから取得したユーザID（ARN）とk8s側のRBACの設定を検証し、認可を行う • RBAC側の設定は手動で設定・メンテする必要がある • EKSクラスター作成時、クラスターを作成したIAM￿User（Role）が自動的に管理者登録される EKSの特徴2:￿IAM認証￿フロー　2/2 AWS￿SDK￿for￿Go(sts)￿:￿https://docs.aws.amazon.com/sdk-for-go/api/service/sts/ 

EKSの特徴2:￿IAM認証￿あるある • 事象 • 画面からクラスターつくるとCloud9でkubectlが通らない • EKSクラスターには、画面で作成した際のIAMユーザがAdminとして登録される が、Cloud9からkubectlを叩く際、Cloud9のテンポラリクレデンシャルを使用 してアクセスすることになるため • 解決策 • テンポラリクレデンシャルをしない • 明示的にEKSクラスターを作ったIAMユーザのクレデンシャルを設定する • CLIでEKSクラスターを作成する（IAM￿RoleでEKSクラスターを作成する） • Cloud9インスタンスにIAM￿Roleをアタッチする 

ほしい機能￿1/2 • Podレベルのセキュリティグループ、IAM￿Role • ノード単位だと全体に必要な権限や通信設定が必要になってしまう • Taints／Tolerationsやサービスメッシュでできるけど、出来てほしい • Podレベルのメトリクス取得 • kubectl￿topメトリクスのCloudWatch連携 • 先日、とある有識者に「何で必要なの？いらなくね？￿Cattle,￿not￿Pets!!!￿」って言わ れたけど、やっぱほしい • 標準メトリクスでよろしく *￿Gitops￿:￿weaveworks社が提唱したk8sのCI/CDパイプラインのコンセプト￿https://www.weave.works/technologies/gitops/ 

ほしい機能￿2/2 • マネージドGitOps*パイプライン • Code￿Build￿/￿Code￿Deploy辺りでk8sマニフェストapply対応とかあると嬉しい • Logの取り込みフィルタリング　※k8sに限った話じゃない • 送りまくると課金が無視できない • Agent側じゃなくてエンドポイント側でやりたい • 設定変更時に再配布、再起動は嫌 • GCP￿Stackdriver￿Loggingはできる（らしい） • クラスターへの課金 • 機能じゃないけど… • Fargate￿for￿EKSはよ！！ *￿Gitops￿:￿weaveworks社が提唱したk8sのCI/CDパイプラインのコンセプト￿https://www.weave.works/technologies/gitops/ 

EKS利用にあたって意識すること（私見） • AWS依存を少なく使う • EKSのAWS連携機能で良しなにやってくれることはあるが、 AWSリソース管理とk8sリソース管理は分離した方がいい • リソースのライフサイクルが違うケースがあるのでつらみがでてくる • ELB連携とか • CloudWatchとか、App￿Mesh,￿X-Rayとかは別。サービスコア部分は、という意味 • 分離しておけば万が一AWSが死んでも移行が容易 • AKS、GKEに移行しやすい • ロックインを許容するなら、ECSでいんじゃね？説 • ここはまた別途（2回目） 

まとめ • コンテナオーケストレーションってのが必要になってきた • k8sはOSS事実上のデファクト • 仕組みをざっくり理解 • AWSのオーケストレーションサービスもある • ECS/EKS • EKSの特徴を抑える • VPC統合、IAM連携を少しDive • 欲しい機能もまだまだある • EKS?ECS議論は別途やりたい 

ご清聴ありがとうございました