AWS SummitTokyo2019-reCap_20190620

Transcript

1. AWS￿Summit￿Tokyo￿re:Cap コンテナ周りのセッション所感と Container￿Insightsの紹介 2019/06/20 ＠AWS￿Loft￿Tokyo

2. Agenda 1. AWS￿Summit￿Tokyo所感 • 全体感 • おすすめセッション 2. 気になる機能紹介 •

   Container￿Insights • 気になること

3. 1.￿AWS￿Summit￿Tokyo所感

4. 全体所感 • エンタープライズ感 • 革新的な破壊的機能というよりは、これから始めるレイトマジョリティ向け な雰囲気を感じた • いよいよボリュームゾーンの闘いに突入する予感？ • コンテナ、Kubernetes周りの機運の高まりを実感

   • エンタープライズ感とは真逆だが、コンテナ周りのセッションの人気たるや • いよいよ日本でもKubernetes本番事例やTipsが出回り始めた • re:Inventは皆行きたがるのになぜか幕張は遠いと言われる問題…

5. おすすめセッション • 入門編 • C3-02：【初級】AWS￿コンテナサービス入門 • A3-02：Kubernetes￿on￿AWS（Amazon￿EKS実践入門） • 実践編 •

   J2-07：AWSのマネージドサービスを活かした￿Kubernetes￿運用と Amazon￿EKS￿によるクラスタのシングルテナント戦略について • A3-03：サービスメッシュは本当に必要なのか、何を解決するのか

6. おすすめセッション　~入門編~ • C3-02：【初級】AWS￿コンテナサービス入門 • これからコンテナを始めようとする方向けに、コンテナ開発に必要な要素を 洗い出した上で、AWSにおけるコンテナ関連サービスを網羅的に説明 • A3-02：Kubernetes￿on￿AWS（Amazon￿EKS実践入門） • コンテナ動向・背景を説明のうえ、KubernetesとEKSの特徴を整理

7. おすすめセッション　~実践編￿1/2~ • J2-07：AWSのマネージドサービスを活かした￿Kubernetes￿運用と Amazon￿EKS￿によるクラスタのシングルテナント戦略について • 流石のユーザ事例セッション • SREが共通基盤を楽に運用していくために取った戦略とは？ • 共通基盤といいつつ、共通ではない

   • 共通SWスタックを用意し、個別に初期構築。その後のk8s運用は開発チームで • SREはあくまで最後の砦。運用代行ではないという発想 • どんなアーキテクチャも移行しやすいように設計 • あくまで部品でしかなく、常によりよいものに改善しやすいように保つ

8. おすすめセッション　~実践編￿2/2~ • A3-03：サービスメッシュは本当に必要なのか、何を解決するのか • サービス／システムが成長・拡大するにあたり、様々な問題が発生する • ベースはALB￿–￿EC2￿–￿RDS構成 • マイクロサービス化しよう、となる •

   モノリスというイメージと、マイクロサービスに期待する内容を整理 • ざっくり言えば、ちゃんとトレースしたい • X-Rayが便利 • マイクロサービスなりの課題もある • ログの統一化、パフォーマンス測定、サーキットブレーカー • 2つのアプローチ • 共通ライブラリ • プロキシ　→　これがいわるゆサービスメッシュ • 課題をちゃんと把握する。X-Rayで十分なケースも散見される。 • サービスメッシュまで必要になってから考える、でも十分なのでは？ • 中の人らしからぬ発言でセッションが終了

9. 7/1￿再演！！！！ • 入門編 • C3-02：【初級】AWS￿コンテナサービス入門 • A3-02：Kubernetes￿on￿AWS（Amazon￿EKS実践入門） • 実践編 •

   J2-07：AWSのマネージドサービスを活かした￿Kubernetes￿運用と Amazon￿EKS￿によるクラスタのシングルテナント戦略について • A3-03：サービスメッシュは本当に必要なのか、何を解決するのか 申込サイト：￿https://awssummittokyoosakatechrecap1.splashthat.com/

10. 2.￿気になる機能紹介

11. Container￿Insights

12. の前に…

13. Kubernetesってご存知ですか？

14. Kubernetes　超ざっくり • コンテナオーケストレーションツールのひとつ • 全体は非同期分散処理システム • 色々なコンポーネントがそれぞれの役割を全うすることで全体を構成 • マイクロサービス？？？ •

    詳細は割愛 • Control￿planeとData￿plane • それぞれはN台のサーバでクラスター構成 • Control￿plane:￿マスターデータストア、制御関連 • Data￿plane:￿実際のコンテナ(Pod)が配置されるエリア￿ • kubectlコマンドで操作 • k8s版aws￿cliみたいなもの • ノードを表示する例：kubectl￿get￿nodes • Podを表示する例：kubectl￿get￿pod

15. Elastic￿Container￿Service￿for￿ Kubernetes￿(EKS) • K8sのControl￿planeがマネージド • Data￿plane • EC2 • EKS用のAgentが入っている以外は普通のEC2（ざっくり）

    • 自分好みにどうぞ • Fargate • 2019年中に対応予定

16. 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リソース管理 （作成、変更、削除、検索など） ここがマネージド

17. Container￿Insights

18. Container￿Insights￿概要 • KubeCon￿Europe2019でプレビューリリース • Kubernetesクラスター内で動くリソース状況を可視化する機能 • 今までは取りたければ独自で導入・設定が必要だった • Pod,￿Namespace,￿Serviceなどの単位で集約したメトリクス可視化 •

    ログ管理の機能も併せて提供 • AWS公式の安心感 • 独自の仕組みを維持・運用しなくていい • CloudWatchアラーム連携できるのが嬉しい • 控えめに言って良い • 最初はいらないでしょって言ってたのにだしてきた • 3/13￿Build￿with￿Containers!@AWSでYanivに聞いて、 “Ha??”って言われたのに…

19. 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リソース管理 （作成、変更、削除、検索など） この辺のメトリクス収集が可能になった

20. Container￿Insights￿仕組み • CloudWatchAgentコンテナをDaemon￿Setで動かす 1. 同一ノード上の他Podの情報を取得 1. ログはFluendDのPodで、ホスト側のボリュームをマウントしている 2. 取得した情報（やログ）をCloudWatchへ転送 ノード

    ノード ノード CloudWatch Service￿Pod CloudWatchAgent(FluentD)￿DS ① ① ① ②

21. Container￿Insights￿有効化する手順 • IAM￿Roleにポリシーアタッチ • CloudWatchAgentServerPolicyを忘れずに • Namespace、サービスアカウント作成 • Config作成し、ConfigMapとして登録 •

    クラスター名、リージョン、取得間隔、送信間隔　など… • Daemon￿Set起動 Container￿Insights有効化手順： https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/deploy-container-insights.html

22. Container￿Insights￿有効化する手順 # Namespace作成 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cloudwatch-namespace.yaml kubectl apply -f

    cloudwatch-namespace.yaml # サービスアカウント作成 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cwagent-serviceaccount.yaml kubectl apply -f cwagent-serviceaccount.yaml # ConfigMap設定、適用 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cwagent-configmap.yaml <設定変更 → とりあえずクラスター名だけ設定すれば動く> kubectl apply -f cwagent-configmap.yaml # Daemon Set起動 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cwagent-daemonset.yaml kubectl apply -f cwagent-daemonset.yaml K8sへの操作

23. Container￿Insights￿イメージ

24. Container￿Insights￿気になること CloudWatch価格：https://aws.amazon.com/jp/cloudwatch/pricing/ 規模感：116￿*￿0.3￿=￿$34.8 　クラスター=1、Namespace=4 　ノード=2、Service=1、Pod=2 ・ログとしても送信される CloudWatchLogsにもパフォーマンスデータが送信されるので注意 　→　GB￿あたり￿0.76￿USD ・カスタムメトリクス扱いになる。ノード、Service、Pod辺りが増えやすいので規模感を捉えておく →　最初の￿10,000￿メトリクス

    0.30￿USD CloudWatchLogsとしてもメトリクスデータ を送信している 特に利用予定がなければ保存期間設定は必須 Container￿Insightsで収集されるメトリクス：https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics.html

25. Container￿Insights￿気になること • 権限周り • CloudWatchAgentが他Podの情報を抜いているように見える • ノード側でDocker￿statsコマンドみたいなのを叩いているような印象だけど、どうやってる？ • FluentDは、ノード側でrootしか参照できないファイルを参照しているように見える •

    ホストマウント先のディレクトリは全ユーザRead権限ついているが、ファイル実体はrootしか 参照できないもの • なのになんで参照できるの？ • そもそもPodが起動する権限ってなんなん？ • ざっくり見るとroot権限で動いているっぽい… • この辺知っている人がいたら教えてください…

26. まとめ • コンテナ／EKSアツい • 進歩が速いのでキャッチアップを忘れずに • AWSサービスとしては珍しく、ロードマップが公開されている • https://github.com/aws/containers-roadmap/projects/1 •

    OpsJAWSでも取り上げていきたい！ • Container￿Insightsはいい • ただ、課金は意識した方がいい。他クラウドは無料だけどね…。 • Ha???って言われても出してくる可能性あり • 権限周りは要勉強

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