Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
JAWS-UG_SAITAMA_20190420
Search
kaojiri
April 20, 2019
Technology
1
190
JAWS-UG_SAITAMA_20190420
JAWS-UGさいたま支部@大崎での発表資料です。
kaojiri
April 20, 2019
Tweet
Share
More Decks by kaojiri
See All by kaojiri
コンテナ監視って何見るの?~初心者編~
kaojiri
8
5.5k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
910
AWS SummitTokyo2019-reCap_20190620
kaojiri
1
70
OpsJAWS-JAWSUG-KANAZAWA_20181123
kaojiri
1
270
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
1.6k
組織を意識したAWS構成管理プロセスを考える_20180112
kaojiri
0
720
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.7k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
1.1k
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
2.9k
Other Decks in Technology
See All in Technology
自社サービスのための独自リリース版Redmine「RedMica」の取り組み
vividtone
0
1.3k
技術的負債解消の取り組みと専門チームのお話
bengo4com
0
330
Fediverse Discovery Providers overview
andypiper
0
160
CRTO/CRTL/OSEPの比較・勉強法とAV/EDRの検知実験
chayakonanaika
1
1.1k
Functional TypeScript
naoya
11
4.8k
「認証認可」という体験をデザインする ~Nekko Cloud認証認可基盤計画
logica0419
2
430
『GRANBLUE FANTASY Relink』ソフトウェアラスタライザによる実践的なオクルージョンカリング
cygames
0
140
フルカイテン株式会社 採用資料
fullkaiten
0
32k
ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure
takumakume
0
130
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
220
事前準備が肝!AI活用のための業務改革
layerx
PRO
1
370
フロントエンド・オブザーバビリティを支える要素技術を学ぼう
sadnessojisan
2
180
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
How to train your dragon (web standard)
notwaldorf
85
5.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
227
52k
Designing for Performance
lara
604
68k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Six Lessons from altMBA
skipperchong
26
3.3k
The Cost Of JavaScript in 2023
addyosmani
42
5.6k
Practical Orchestrator
shlominoach
185
10k
Building an army of robots
kneath
302
42k
Speed Design
sergeychernyshev
22
430
Fashionably flexible responsive web design (full day workshop)
malarkey
401
65k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
166
48k
Transcript
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に依存しないので、ハイブリッド、マルチクラウド化しやすい • 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/
ServiceB ServiceA ServiceG ServiceE ServiceC ServiceF ServiceD オーケストレーション オーケストレーション ▪Docker単体でホストした場合
※横からのイメージ ※上からのイメージ ServiceA ServiceB ServiceC ServiceD ServiceE ServiceF ServiceG ・各Serviceのコンテナは任意のノードに分散して配置 ・負荷分散やアクセス制御もオーケストレーションレイヤーで実現可能 ▪オーケストレーションした場合
kubernetes動作の仕組み(超ざっくり) • 全体は非同期分散処理システム • 色々なコンポーネントがそれぞれの役割を全うすることで全体を構成 • マイクロサービス??? • 詳細は割愛 •
ControlplaneとDataplane • それぞれはN台のサーバでクラスター構成 • Controlplane:マスターデータストア、制御関連 • Dataplane:実際のコンテナ(Pod)が配置されるエリア • kubectlコマンドで操作 • k8s版awscliみたいなもの • ノードを表示する例:kubectlgetnodes • Podを表示する例:kubectlgetpod
kubernetes動作の仕組み(イメージ) Dataplane ノード ControlPlane Scheduler APIServer coredns ノード ノード controller
kubelet kubeproxy kubelet kubeproxy kubelet kubeproxy Pod(Container) etcdの情報をもとにDataplaneの各種リソースを管理 etcd kubectl クライアント 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を抽象化。利用者は本当にコンテナ(タスク)に注力できる • お作法はある
ElasticContainerServicefor Kubernetes(EKS) • K8sのControlplaneがマネージド • 豊富なK8sエコシステムを利用可能 • Dataplane • EC2
• EKS用のAgentが入っている以外は普通のEC2(ざっくり) • 自分好みにどうぞ • Fargate • 2019年中に対応予定
ElasticContainerServicefor Kubernetes(EKS) Dataplane ノード ControlPlane Scheduler APIServer coredns ノード ノード
controller kubelet kubeproxy kubelet kubeproxy kubelet kubeproxy Pod(Container) etcdの情報をもとにDataplaneの各種リソースを管理 etcd kubectl クライアント 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 Pod EKSクラスター(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.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認証に使用する属性を設定 ※コマンドで自動設定可能 awseks--region<region>update-kubeconfig--name<cluster_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
• 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/
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議論は別途やりたい
ご清聴ありがとうございました