JAWS-UGさいたま支部＠大崎での発表資料です。
AWSでkubernetesことはじめ2019/04/20＠JAWS-UGさいたま支部
View Slide
Agenda1. Kubernetes(k8s)とは• Dockerとかオーケストレーションツールの必要性みたいな話• k8s動作の仕組み（ざっくり）2. AWSのオーケストレーションサービス• ECS/EKS ざっくり3. EKSことはじめ• 特徴• VPC統合• IAM認証• ほしい機能• EKS利用にあたって（私見）4. まとめ
1.Kubernetes(k8s)とは
Docker使ってますか？• 可搬性• IaaSに依存しないので、ハイブリッド、マルチクラウド化しやすい• dockerbuildでパッケージング化（AWSに依存しないAMIみたいなもの）• 役割の明確化• お見合いしがちなレイヤーを明確にAPチームに• OSやミドルのインストール、設定• 安全なデプロイ• IaaSレイヤーを抽象化することで、環境依存バグの発生を抑止• テスト環境では動いたけど本番環境では動かない みたいな話
コンテナを使わない場合OS(カーネル)OS(カーネル以外)実行ランタイム(Javaなど)ミドルウェア（Tomcatなど)アプリケーション アプリチームが準備して管理インフラチームが準備して管理プロジェクト体制や会社によってまちまち ・初期導入は各SW主管部や設定導入 ・維持運用はアプリチーム とかがよくあるパターン？
コンテナを使う場合OS(カーネル)OS(カーネル以外)実行ランタイム(Javaなど)ミドルウェア（Tomcatなど)アプリケーションアプリチームが準備して管理インフラチームが準備して管理コンテナランタイム実行ランタイムより上位はアプリチームが準備した方が効率が良い(※)(※)Dockerの（セキュアな）ベースイメージをインフラチームが準備して開発者に提供するケースは十分あり
増えてくると辛い問題• 単一のコンテナや単一のサービス内でホストするなら問題なし• ひとつのサービス内で複数のコンテナが連携して動作するような構成を取りたい場合、Dockercomposeが便利• 独自のローカルネットワークを構築して通信可能• 可用性確保の課題• 単一コンテナであってもMulti-AZで複数VMに負荷分散• 個別にEC2とかロードバランサを設定する必要あり• サービスの成長への備え• サービスが増え、コンテナの種類やスケール数が増えたらどうする？• インフラ管理、デプロイメント管理などが指数関数的に辛くなる…
コンテナオーケストレーション• 複数のコンテナ（サービス）を”よしな”に配置し、可用性、負荷分散、認証／認可、アクセス制御などのガバナンス統制を効かせることが可能• 結構たくさんある• DockerSwarm• CoreOSfleet• RancherLabsRancher• MesosMarathon• GoogleBorg->CNCFkubernetes 等• 主導権争いの末、kubernetesが事実上のデファクトに• 以下資料がとってもわかりやすい• GKEを用いたレガシーシステムからのリプレース事例(P24-35)@GoogleCloudKubernetesDay• https://cloudplatformonline.com/rs/248-TPC-286/images/Google_Cloud_Kubernetes_Day_Session02.pdf• CNCFもk8sをGraduateにKubernetesIsFirstCNCFProjectToGraduate:https://www.cncf.io/blog/2018/03/06/kubernetes-first-cncf-project-graduate/
ServiceBServiceAServiceGServiceEServiceCServiceFServiceDオーケストレーションオーケストレーション■Docker単体でホストした場合※横からのイメージ※上からのイメージServiceAServiceBServiceCServiceDServiceEServiceFServiceG・各Serviceのコンテナは任意のノードに分散して配置・負荷分散やアクセス制御もオーケストレーションレイヤーで実現可能■オーケストレーションした場合
kubernetes動作の仕組み（超ざっくり）• 全体は非同期分散処理システム• 色々なコンポーネントがそれぞれの役割を全うすることで全体を構成• マイクロサービス？？？• 詳細は割愛• ControlplaneとDataplane• それぞれはN台のサーバでクラスター構成• Controlplane:マスターデータストア、制御関連• Dataplane:実際のコンテナ(Pod)が配置されるエリア• kubectlコマンドで操作• k8s版awscliみたいなもの• ノードを表示する例：kubectlgetnodes• Podを表示する例：kubectlgetpod
kubernetes動作の仕組み（イメージ）DataplaneノードControlPlaneSchedulerAPIServer corednsノード ノードcontrollerkubelet kubeproxy kubelet kubeproxy kubelet kubeproxyPod(Container)etcdの情報をもとにDataplaneの各種リソースを管理etcdkubectlクライアントK8sクラスターK8sリソース管理（作成、変更、削除、検索など）
2.AWSのオーケストレーションサービス
AWSBlog(DockeronAWS)より引用：https://aws.amazon.com/jp/blogs/news/jp-docker-on-aws-container-service-selection-example/
ElasticContainerService(ECS)• ControlplaneがAWS独自方式でマネージド• AWS連携が豊富• Dataplane• EC2• ECS用のAgentが入っている以外は普通のEC2（ざっくり）• 自分好みにどうぞ• Fargate• Dataplaneを抽象化。利用者は本当にコンテナ（タスク）に注力できる• お作法はある
ElasticContainerServiceforKubernetes(EKS)• K8sのControlplaneがマネージド• 豊富なK8sエコシステムを利用可能• Dataplane• EC2• EKS用のAgentが入っている以外は普通のEC2（ざっくり）• 自分好みにどうぞ• Fargate• 2019年中に対応予定
ElasticContainerServiceforKubernetes(EKS)DataplaneノードControlPlaneSchedulerAPIServer corednsノード ノードcontrollerkubelet kubeproxy kubelet kubeproxy kubelet kubeproxyPod(Container)etcdの情報をもとにDataplaneの各種リソースを管理etcdkubectlクライアントK8sクラスターK8sリソース管理（作成、変更、削除、検索など）ここがマネージド
どっちを使うべきなの？議論はまた別途
3.EKSことはじめ・特徴（VPC統合、IAM認証）・ほしい機能・意識すること
EKSの特徴1:VPC統合 ～概要～• 同一VPCのクラスター外から、Podに直接ルーティング可能• 本来K8sは、VPCなどのクラスター外のネットワークとは別の独自ネットワークを構成するので、クラスター外からの通信は明示的にアクセスポイントを設けないと疎通できない• 独自のCNIプラグインでPodにVPCのIPアドレスをアサイン• ノードのセカンダリIPをPodに割り当ててノードのメインNICとブリッジ• 通信制御はセキュリティグループで• ただし、ノード単位での設定になるので厳密ではない• 厳密にやりたい場合• Nodeselectorそれに見合ったセキュリティグループをアタッチする• NetworkPolicyを定義する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 PodEKSクラスター(VPC統合)VPC(192.168.0.0/16)クラスター外のインスタンスPod Pod Pod明示的なアクセスポイントを設けないと通信できない Defaultでルーティング可能（SGで制御）■普通のk8s(k8sonEC2)の場合 ■EKSの場合
EKSの特徴2:IAM認証概要• クラスターへの認証(kubectlの認証)をIAMで実施できる• aws-iam-authenticatorを使う公式Docより引用：https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/managing-auth.htmlaws-iam-authenticator：https://github.com/kubernetes-sigs/aws-iam-authenticator
EKSの特徴2:IAM認証フロー 1/2• 事前準備1. aws-iam-authenticatorをインストールする2. kubectlの認証設定(kubeconfig)1. EKS認証に使用する属性を設定 ※コマンドで自動設定可能awseks--regionupdate-kubeconfig--name2. aws-iam-authenticatorを使用するように設定するaws-iam-authenticatorのインストール：https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/install-aws-iam-authenticator.htmlkubeconfigをAmazonEKS用に作成する：https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/create-kubeconfig.html
• kubectlコマンド実行のたびに行われる処理1. kubectlは、aws-iam-authenticatorのtokenコマンドを使ってtokenを作成する• Tokenの内容は以下• SDKforGoのsts.GetCallerIdentityRequestで生成されるURLにPreSignし、base64エンコードした文字列• プレフィックスにk8s-aws-v1.を付加した文字列• Client側はこの仕組みを利用するための権限は不要• クレデンシャルかRoleが設定されていればいい2. kubectlは、EKSのControlPlane（のAPIServer）にリクエストを投げる3. EKS側はtokenをもとにsts.GetCallerIdentityリクエストを発行し、認証する• このリクエスト(token)を生成できるのはそのクレデンシャルを持っている人しか生成できない、という発想4. EKS側はtokenから取得したユーザID（ARN）とk8s側のRBACの設定を検証し、認可を行う• RBAC側の設定は手動で設定・メンテする必要がある• EKSクラスター作成時、クラスターを作成したIAMUser（Role）が自動的に管理者登録されるEKSの特徴2:IAM認証フロー 2/2AWSSDKforGo(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クラスターを作成する（IAMRoleでEKSクラスターを作成する）• Cloud9インスタンスにIAMRoleをアタッチする
ほしい機能1/2• Podレベルのセキュリティグループ、IAMRole• ノード単位だと全体に必要な権限や通信設定が必要になってしまう• Taints／Tolerationsやサービスメッシュでできるけど、出来てほしい• Podレベルのメトリクス取得• kubectltopメトリクスのCloudWatch連携• 先日、とある有識者に「何で必要なの？いらなくね？Cattle,notPets!!!」って言われたけど、やっぱほしい• 標準メトリクスでよろしく*Gitops:weaveworks社が提唱したk8sのCI/CDパイプラインのコンセプトhttps://www.weave.works/technologies/gitops/
ほしい機能2/2• マネージドGitOps*パイプライン• CodeBuild/CodeDeploy辺りでk8sマニフェストapply対応とかあると嬉しい• Logの取り込みフィルタリング ※k8sに限った話じゃない• 送りまくると課金が無視できない• Agent側じゃなくてエンドポイント側でやりたい• 設定変更時に再配布、再起動は嫌• GCPStackdriverLoggingはできる（らしい）• クラスターへの課金• 機能じゃないけど…• FargateforEKSはよ！！*Gitops:weaveworks社が提唱したk8sのCI/CDパイプラインのコンセプトhttps://www.weave.works/technologies/gitops/
EKS利用にあたって意識すること（私見）• AWS依存を少なく使う• EKSのAWS連携機能で良しなにやってくれることはあるが、AWSリソース管理とk8sリソース管理は分離した方がいい• リソースのライフサイクルが違うケースがあるのでつらみがでてくる• ELB連携とか• CloudWatchとか、AppMesh,X-Rayとかは別。サービスコア部分は、という意味• 分離しておけば万が一AWSが死んでも移行が容易• AKS、GKEに移行しやすい• ロックインを許容するなら、ECSでいんじゃね？説• ここはまた別途（2回目）
まとめ• コンテナオーケストレーションってのが必要になってきた• k8sはOSS事実上のデファクト• 仕組みをざっくり理解• AWSのオーケストレーションサービスもある• ECS/EKS• EKSの特徴を抑える• VPC統合、IAM連携を少しDive• 欲しい機能もまだまだある• EKS?ECS議論は別途やりたい
ご清聴ありがとうございました
kaojiri
.png){kind=icon}
pharma_x_tech
yusuke0519
zakiyama
trycycle
line_developers
globis_gdp
oracle4engineer
vividtone
non97
okada_fuutass
mixi_engineers
tacck
palkan
dotmariusz
bryan
shpigford
bcantrill
csswizardry
frogandcode
chriscoyier
trishagee
jensimmons
jrom
tenderlove