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

JAWS-UG_SAITAMA_20190420

kaojiri
April 20, 2019

 JAWS-UG_SAITAMA_20190420

JAWS-UGさいたま支部@大崎での発表資料です。

kaojiri

April 20, 2019
Tweet

More Decks by kaojiri

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. 1.Kubernetes(k8s)とは

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. コンテナオーケストレーション
    • 複数のコンテナ(サービス)を”よしな”に配置し、可用性、負荷分散、
    認証/認可、アクセス制御などのガバナンス統制を効かせることが可能
    • 結構たくさんある
    • 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/

    View Slide

  9. ServiceB
    ServiceA
    ServiceG
    ServiceE
    ServiceC
    ServiceF
    ServiceD
    オーケストレーション
    オーケストレーション
    ■Docker単体でホストした場合
    ※横からのイメージ
    ※上からのイメージ
    ServiceA
    ServiceB
    ServiceC
    ServiceD
    ServiceE
    ServiceF
    ServiceG
    ・各Serviceのコンテナは任意のノードに分散して配置
    ・負荷分散やアクセス制御もオーケストレーションレイヤーで実現可能
    ■オーケストレーションした場合

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  13. AWSBlog(DockeronAWS)より引用:https://aws.amazon.com/jp/blogs/news/jp-docker-on-aws-container-service-selection-example/

    View Slide

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

    View Slide

  15. ElasticContainerServicefor
    Kubernetes(EKS)
    • K8sのControlplaneがマネージド
    • 豊富なK8sエコシステムを利用可能
    • Dataplane
    • EC2
    • EKS用のAgentが入っている以外は普通のEC2(ざっくり)
    • 自分好みにどうぞ
    • Fargate
    • 2019年中に対応予定

    View Slide

  16. ElasticContainerServicefor
    Kubernetes(EKS)
    Dataplane
    ノード
    ControlPlane
    Scheduler
    APIServer coredns
    ノード ノード
    controller
    kubelet kubeproxy kubelet kubeproxy kubelet kubeproxy
    Pod(Container)
    etcdの情報をもとにDataplaneの各種リソースを管理
    etcd
    kubectl
    クライアント
    K8sクラスター
    K8sリソース管理
    (作成、変更、削除、検索など)
    ここがマネージド

    View Slide

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

    View Slide

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

    View Slide

  19. 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

    View Slide

  20. 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(k8sonEC2)の場合 ■EKSの場合

    View Slide

  21. 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

    View Slide

  22. EKSの特徴2:IAM認証フロー 1/2
    • 事前準備
    1. aws-iam-authenticatorをインストールする
    2. kubectlの認証設定(kubeconfig)
    1. EKS認証に使用する属性を設定 ※コマンドで自動設定可能
    awseks--regionupdate-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をAmazonEKS用に作成する:https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/create-kubeconfig.html

    View Slide

  23. • 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/2
    AWSSDKforGo(sts):https://docs.aws.amazon.com/sdk-for-go/api/service/sts/

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide