AWS Summit Tokyo2019の振り返りと、Container Insightsの紹介です。
AWSSummitTokyore:Capコンテナ周りのセッション所感とContainerInsightsの紹介2019/06/20＠AWSLoftTokyo
View Slide
Agenda1. AWSSummitTokyo所感• 全体感• おすすめセッション2. 気になる機能紹介• ContainerInsights• 気になること
1.AWSSummitTokyo所感
全体所感• エンタープライズ感• 革新的な破壊的機能というよりは、これから始めるレイトマジョリティ向けな雰囲気を感じた• いよいよボリュームゾーンの闘いに突入する予感？• コンテナ、Kubernetes周りの機運の高まりを実感• エンタープライズ感とは真逆だが、コンテナ周りのセッションの人気たるや• いよいよ日本でもKubernetes本番事例やTipsが出回り始めた• re:Inventは皆行きたがるのになぜか幕張は遠いと言われる問題…
おすすめセッション• 入門編• C3-02：【初級】AWSコンテナサービス入門• A3-02：KubernetesonAWS（AmazonEKS実践入門）• 実践編• J2-07：AWSのマネージドサービスを活かしたKubernetes運用とAmazonEKSによるクラスタのシングルテナント戦略について• A3-03：サービスメッシュは本当に必要なのか、何を解決するのか
おすすめセッション ~入門編~• C3-02：【初級】AWSコンテナサービス入門• これからコンテナを始めようとする方向けに、コンテナ開発に必要な要素を洗い出した上で、AWSにおけるコンテナ関連サービスを網羅的に説明• A3-02：KubernetesonAWS（AmazonEKS実践入門）• コンテナ動向・背景を説明のうえ、KubernetesとEKSの特徴を整理
おすすめセッション ~実践編1/2~• J2-07：AWSのマネージドサービスを活かしたKubernetes運用とAmazonEKSによるクラスタのシングルテナント戦略について• 流石のユーザ事例セッション• SREが共通基盤を楽に運用していくために取った戦略とは？• 共通基盤といいつつ、共通ではない• 共通SWスタックを用意し、個別に初期構築。その後のk8s運用は開発チームで• SREはあくまで最後の砦。運用代行ではないという発想• どんなアーキテクチャも移行しやすいように設計• あくまで部品でしかなく、常によりよいものに改善しやすいように保つ
おすすめセッション ~実践編2/2~• A3-03：サービスメッシュは本当に必要なのか、何を解決するのか• サービス／システムが成長・拡大するにあたり、様々な問題が発生する• ベースはALB–EC2–RDS構成• マイクロサービス化しよう、となる• モノリスというイメージと、マイクロサービスに期待する内容を整理• ざっくり言えば、ちゃんとトレースしたい• X-Rayが便利• マイクロサービスなりの課題もある• ログの統一化、パフォーマンス測定、サーキットブレーカー• 2つのアプローチ• 共通ライブラリ• プロキシ → これがいわるゆサービスメッシュ• 課題をちゃんと把握する。X-Rayで十分なケースも散見される。• サービスメッシュまで必要になってから考える、でも十分なのでは？• 中の人らしからぬ発言でセッションが終了
7/1再演！！！！• 入門編• C3-02：【初級】AWSコンテナサービス入門• A3-02：KubernetesonAWS（AmazonEKS実践入門）• 実践編• J2-07：AWSのマネージドサービスを活かしたKubernetes運用とAmazonEKSによるクラスタのシングルテナント戦略について• A3-03：サービスメッシュは本当に必要なのか、何を解決するのか申込サイト：https://awssummittokyoosakatechrecap1.splashthat.com/
2.気になる機能紹介
ContainerInsights
の前に…
Kubernetesってご存知ですか？
Kubernetes 超ざっくり• コンテナオーケストレーションツールのひとつ• 全体は非同期分散処理システム• 色々なコンポーネントがそれぞれの役割を全うすることで全体を構成• マイクロサービス？？？• 詳細は割愛• ControlplaneとDataplane• それぞれはN台のサーバでクラスター構成• Controlplane:マスターデータストア、制御関連• Dataplane:実際のコンテナ(Pod)が配置されるエリア• kubectlコマンドで操作• k8s版awscliみたいなもの• ノードを表示する例：kubectlgetnodes• Podを表示する例：kubectlgetpod
ElasticContainerServiceforKubernetes(EKS)• K8sのControlplaneがマネージド• Dataplane• EC2• EKS用のAgentが入っている以外は普通のEC2（ざっくり）• 自分好みにどうぞ• Fargate• 2019年中に対応予定
ElasticContainerServiceforKubernetes(EKS)DataplaneノードControlPlaneSchedulerAPIServer corednsノード ノードcontrollerkubelet kubeproxy kubelet kubeproxy kubelet kubeproxyPod(Container)etcdの情報をもとにDataplaneの各種リソースを管理etcdkubectlクライアントK8sクラスターK8sリソース管理（作成、変更、削除、検索など）ここがマネージド
ContainerInsights概要• KubeConEurope2019でプレビューリリース• Kubernetesクラスター内で動くリソース状況を可視化する機能• 今までは取りたければ独自で導入・設定が必要だった• Pod,Namespace,Serviceなどの単位で集約したメトリクス可視化• ログ管理の機能も併せて提供• AWS公式の安心感• 独自の仕組みを維持・運用しなくていい• CloudWatchアラーム連携できるのが嬉しい• 控えめに言って良い• 最初はいらないでしょって言ってたのにだしてきた• 3/[email protected]でYanivに聞いて、“Ha??”って言われたのに…
ElasticContainerServiceforKubernetes(EKS)DataplaneノードControlPlaneSchedulerAPIServer corednsノード ノードcontrollerkubelet kubeproxy kubelet kubeproxy kubelet kubeproxyPod(Container)etcdの情報をもとにDataplaneの各種リソースを管理etcdkubectlクライアントK8sクラスターK8sリソース管理（作成、変更、削除、検索など）この辺のメトリクス収集が可能になった
ContainerInsights仕組み• CloudWatchAgentコンテナをDaemonSetで動かす1. 同一ノード上の他Podの情報を取得1. ログはFluendDのPodで、ホスト側のボリュームをマウントしている2. 取得した情報（やログ）をCloudWatchへ転送ノード ノード ノードCloudWatchServicePodCloudWatchAgent(FluentD)DS① ① ①②
ContainerInsights有効化する手順• IAMRoleにポリシーアタッチ• CloudWatchAgentServerPolicyを忘れずに• Namespace、サービスアカウント作成• Config作成し、ConfigMapとして登録• クラスター名、リージョン、取得間隔、送信間隔 など…• DaemonSet起動ContainerInsights有効化手順：https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/deploy-container-insights.html
ContainerInsights有効化する手順# Namespace作成curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes-monitoring/cloudwatch-namespace.yamlkubectl apply -f cloudwatch-namespace.yaml# サービスアカウント作成curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes-monitoring/cwagent-serviceaccount.yamlkubectl apply -f cwagent-serviceaccount.yaml# ConfigMap設定、適用curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes-monitoring/cwagent-configmap.yamlkubectl apply -f cwagent-configmap.yaml# Daemon Set起動curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes-monitoring/cwagent-daemonset.yamlkubectl apply -f cwagent-daemonset.yamlK8sへの操作
ContainerInsightsイメージ
ContainerInsights気になることCloudWatch価格：https://aws.amazon.com/jp/cloudwatch/pricing/規模感：116*0.3=$34.8 クラスター=1、Namespace=4 ノード=2、Service=1、Pod=2・ログとしても送信されるCloudWatchLogsにもパフォーマンスデータが送信されるので注意 → GBあたり0.76USD・カスタムメトリクス扱いになる。ノード、Service、Pod辺りが増えやすいので規模感を捉えておく→ 最初の10,000メトリクス 0.30USDCloudWatchLogsとしてもメトリクスデータを送信している特に利用予定がなければ保存期間設定は必須ContainerInsightsで収集されるメトリクス：https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics.html
ContainerInsights気になること• 権限周り• CloudWatchAgentが他Podの情報を抜いているように見える• ノード側でDockerstatsコマンドみたいなのを叩いているような印象だけど、どうやってる？• FluentDは、ノード側でrootしか参照できないファイルを参照しているように見える• ホストマウント先のディレクトリは全ユーザRead権限ついているが、ファイル実体はrootしか参照できないもの• なのになんで参照できるの？• そもそもPodが起動する権限ってなんなん？• ざっくり見るとroot権限で動いているっぽい…• この辺知っている人がいたら教えてください…
まとめ• コンテナ／EKSアツい• 進歩が速いのでキャッチアップを忘れずに• AWSサービスとしては珍しく、ロードマップが公開されている• https://github.com/aws/containers-roadmap/projects/1• OpsJAWSでも取り上げていきたい！• ContainerInsightsはいい• ただ、課金は意識した方がいい。他クラウドは無料だけどね…。• Ha???って言われても出してくる可能性あり• 権限周りは要勉強
ご清聴ありがとうございました
kaojiri
6onoda
nasa9084
uzulla
chiroruxx
hanhan1978
tatematsu_san
jordihofc
hirokiotsuka
mii3king
asazutaiga
you
odasho
jcasabona
jacobian
quramy
danielanewman
cromwellryan
lynnandtonic
eileencodes
kneath
jnunemaker
holman
shpigford
smashingmag