はじめに
2020年1月23日に開催されたJAWS-UGコンテナ支部 #16〜EKS on Fargateローンチ記念！EKS祭りだワッショイのブログ枠になります。
当日使用されたハッシュタグは#jawsug_ctと#jawsugです。Twitterで検索すれば開催当時の空気感が見れると思います。また、話題に上がった補足資料的なURLが貼られたりしているのでさらっと眺めておくことをお勧めします。
メインセッションまでを#1、書く余力があったらLT部分を#2で書ければと思ってます…
セッション情報まとめ
| タイトル | 登壇者情報 |
|---|---|
| 今こそ振り返るEKSの基礎 |
濱田孝治 クラスメソッド AWS事業本部コンサルティング部 |
| コンテナうまみつらみ〜Kubernetes初心者がEKSと格闘した1年を振り返る〜 |
多田吉克 （株）いい生活 サービスプラットフォーム開発部 |
| Kubernetesをめぐる冒険 | 坂本諒 Chatwork |
| OSSから理解するEKSとそのエコシステムについて |
太田航平(inductor) ZOZOテクノロジーズ MLOpsチーム エンジニア |
| EKS on Fargate を紹介したい | ミラクル⭐トリバード |
| EKSでのpodとIAM Roleの管理方法を整理 | ジュジュ |
| Kubernetes における Topology（仮） | チェシャ猫 |
| インフラ未経験からCKADに合格するまでの道のり | Masatoshi Tada |
| EKS for EFS | nnao45 |
※ミラクル⭐トリバードことトリさんの登壇資料は探しましたが見つけられなかったので未掲載です。
メインセッション
今こそ振り返るEKSの基礎
登壇者はDevlopers.ioのワッショイでお馴染みのクラスメソッド株式会社の濱田孝治さん
- ekstclは便利
- eksctl create clusterコマンドで色んなAWSリソースをよしなに作ってくれる
- eksctlはすごく便利だけど、これだけ使っているとAWSのリソースに対する理解が深まらない
- EKS運用していくと当然色々やりたいこと増えたり課題が出てくる
- 改めてEKS何もわかってないなと感じる
EKSと長く付き合うにはeksctlをちゃんと理解する必要がある
-
EKSの使い方は2つ
- eksctlを使う方方法
- AWSコンソールを使う方法
-
AWSコンソールでのEKSの開始方法
Amazon EKSサービスロール作成
Amazon EKS はユーザーに代わって他の AWS サービスを呼び出してサービスで使用するリソースを管理します。Amazon EKS クラスターを使用するには、次の IAM ポリシーを持つ IAM ロールを作成する必要があります。
必須ポリシー2種の違い
| AmazonEKSServicePolicy | AmazonEKSClusterPolicy |
|---|---|
| EKSがk8sクラスタを作成〜運用するためのポリシー | k8sクラスタのコントロールプレーンがAWSリソースを操作するためのポリシー |
EKSクラスター用VPC作成
- EKSクラスタ作成前にクラスタで使用するVPCを作成する必要あり
-
クラスタVPCに関する考慮事項※資料ではSGに関する考慮事項のURLが貼られていたので注意
- 2つ以上のAZにサブネットが必要
- パブリックサブネット(インターネット用LB)
- プライベートサブネット(ワーカーノード用)
- プライベートサブネットからインターネットへのアウトバウンド通信には要NATGateway
- VPC IP アドレス指定
- VPC のタグ付け要件
- サブネットのタグ付け要件
- 内部LB用のプライベートサブネットのタグ付け要件
- 外部LB用のパブリックサブネットタグ付けオプション
EKSクラスター作成
- 必須
- Cluster name
- kubernetes version
- Role:EKSサービスロール作成で作成したRole
- VPC:クラスタ用VPC作成で作成したVPC
- Subnet:作成したVPCに所属するSubnetを選択
-
非必須
- Endpoint private accses
- Endpoint pubric accses
- ※Amazon EKS クラスターエンドポイントのアクセスコントロール
- ログ記録
クラスターセキュリティグループ
※Kubernetes 1.14 および eks.3 プラットフォームバージョンを実行している Amazon EKS クラスターから利用可能コントロールプレーンおよびワーカーノードのセキュリティグループ
※Kubernetes バージョン 1.14 および プラットフォームバージョン eks.3 以前の Amazon EKS クラスター対応
kubeconfigの作成
- aws cliでトークン取得が可能
※kubeconfigはkubectlを使ってk8sのAPIサーバと通信してクラスタと接続するための設定ファイル
マネージド型ノードグループの起動
EKS Kubernetes クラスターのノード（Amazon EC2 インスタンス）のプロビジョニングとライフサイクル管理を自動化します
-
- AmazonEC2ContainerRegistryReadOnly
- AmazonEKS_CNI_Policy
- AmazonEKSWorkerNodePolicy
CNI プラグインは、Kubernetes ノードに VPC IP アドレスを割り当て、各ノードのポッドに必要なネットワークを設定します。このプラグインは 2 つの主なコンポーネントで構成されています。
- L-IPAM デーモン
- CNI プラグイン
おすすめ学習マテリアル
コンテナうまみつらみ〜Kubernetes初心者がEKSと格闘した1年を振り返る〜
登壇者は不動産テック企業の(株)いい生活の多田吉克さん
はじめに
- ことの始まりは3月
- CTOから「4月から新規プロジェクトのPMよろしく、EKSで」と言われた
- 4月にPJがスタート
- メンバーは3人でスタート
- がっつりクラウド/コンテナで開発経験のあるメンバーはなし
- EKSの採用は内定状態だった(社内的な事情も込み)
- PoC的な意味も含めてやってみようとなった
PJ概要
- 既存システム(レガシーでオンプレ)に接続するためのオープンで使いやすいAPI作り
- 名前は出島(dejima)と名付けた
- アーキテクチャイメージ
現在の稼働状況
- 21ノード(最大)
- 13マイクロサービス
- 平均して120Podsから最大200Podsまでスケールアウト/イン
デプロイ出来るまで
- eksctlは実はあまり使わずCTOが素振りしてたCFnで作成
- CTO「このCFnを読め、理解しろ、そしてやれ」
- クラスタ作るまでは苦労はあまりなかったがそこからPod何か動かしてみようってところから派生させてった
- サービス公開にはALB Ingress Controllerを使用
- ALB Ingress ControllertのおかげでAWSのリソースの世界をあまり意識しなくて出来た
ALB Ingress Controllertとは
Ingress リソースがクラスターで作成されるたびに、Application Load Balancer (ALB) および必要な AWS サポートリソースの作成をトリガーするコントローラーです。
使いやすいコンテナに仕上げる工夫したこと
- 設定値を注入可能にする
- コマンドクエリ責務分離パターンを拡張して適用
- 同じデータモデルのアプリケーションでも更新系と参照系を別のデプロイメントとして扱った
- アプリケーションのレイヤで更新と参照で別の言語使っていても同じ様にデプロイ出来るメリットが有る
- 更新系と参照系で負荷傾向が違うのでそれぞれに適したチューニングを施せるメリット ###CI/CD
- 社内CIサーバ(Drone.io)とAWS CodeBuildを併用
- nightlyビルド+デプロイ
- 機能性能テストを開発環境で定期実行
- リリースサイクルの高速化に貢献 ###監視系
- メトリクスはPrometheusで収集してGrafanaで可視化
- ログはFluentBit+Firehose+Splunk
- リリース前の話だが、InfluxDBでやっていたが負荷に耐えきれず敢え無く死んでいったのでPrometheusメトリクスの長期保存は断念
初心者だったとき一番辛かったこと
- Envoyのconfigつらかった
- Sidecarの何が嬉しいかを頭では理解できてても、どうやって設定で実現するかよくわからなかった
- やりながら、最悪ソースコード読んだりして肌で理解していった
- ClusterIPの罠
- サービス間の連携はClusterIPを先に構成させてた
- それだとEgressの接続先がClusterIPだと通信が不安定になる
- LBがEnvoyとk8sのServiceの2段あった
- Envoyが細かくヘルスチェックしててもService側のヘルスチェックの律速でしか切替出来なかった
- Service側をHeadHeadless化して解決
- コンテナの恩恵
- 同じEKS内に移設が決まったサービスがいくつかあった
- やってしまえばなんとかなる、で乗り切れた
本番稼働してわかったこと
- Podへのリソース割当
- CPU使用量200くらいで性能劣化するケースも
- 早めにスケールアウトさせて上限に余裕をもたせよう
- CPU不足が気付きにくい
- Podは死んでもリクエストはくる
- ログとメトリクス多すぎ
- k8sはコンポーネントが多いのでログもメトリクスも膨大
今の課題
- 可観測性(ログを削ってるため)
- Prometheus不安定問題
- トレーシングやっていきたい
- Istio導入するか
- クラスターマネジメント
- EC2インスタンスやクラスターバージョン管理など
- Managed Node Group
- Fagateどうするか
- チーム体制と教育
Kubernetesをめぐる冒険
登壇者は2019年で2700kmも走ったChatwork社SREの坂本諒さん
Chatworkの紹介
- ビジネスチャットサービス
- グループチャット、タスク管理、ファイル共有、ビデオ、音声通話
- kubernetesの利用形態
- マルチテナント
- クラスタはSREが作る
- 管理系アプリはSRE
- サービス・アプリはDevチーム
- 導入は2016年で最初のバージョンは1.5
- EKS以前はkube-awsを利用して自前でホスティング
- eksctl登場で色々変わった話
eksctlとkube-awsの比較
- eksctl
- 開発が早い
- 基本的にはクラスタ構成はUpdate出来ない
- kube-aws
- クラスタ構成はUpdate可能
- EKSを利用するのではなくcontroller、etcd含めて作成
- カスタマイズ性が高い
- k8sの設定ファイルが膨大なYAMLに(Prodの686行)
- 長期的に見るとeksctlの方がメリットが大きい
- IAMでユーザ認証可、PodにIAMRole、EKSそのもののメリット
- k8s運用で大変なこと
- バージョンアップ対応(k8sは3ヶ月毎)
- 全部は追従しないにしても半年に1回はやる
- 環境の作り変え頻発
- 手動(ドキュメント対応)では運用負荷が大きすぎる
運用を支援する仕組みが必要
- eksctl
- Varint
- helm,helmfile
- Flux + Argo CDのハイブリット構想
- 原則manifestだけ、1flux - 1repo - 1 branch
- manifest適用であまり変更がないもの(namespace,aws-authなど)
- GUI対応、helm対応で使いやすい
- 半額はありがたいというお話
OSSから理解するEKSとそのエコシステムについて
登壇者はkubernetes.ioやkubernetes-the-hard-wayの日本語化などに貢献しているZOZOテクノロジーズ社の太田航平(inductor)さん
このセッションは「EKS完全に理解した人」向けと前置いてからスタートされました笑
Kubernetesの設計思想
- 宣言的な構成管理
- コントローラーを中心とした高い拡張性←ここにフォーカス
- コンテナを基にした軽量、柔軟、高速なScaling
k8sの持つコンポーネント(マスターコンポーネント)
- kubectl→kubeAPIServerに対してAPIリクエストを投げる
- etcd-ステートが書き込まれる
- 書き込まれたステートに従ってコンテナを配置していく
- デプロイメントコントローラがデプロイメントのリソースを作る
- reconcile loop
- コントローラが定期的にetcdに書かれたステートをウォッチしに行く
- 新しいものを作るのを感知したらクリエイトする
Cloud controller manager(c-c-m)
- k8sが持つインターフェースに従ってコントローラを書いてあげるとAWSやGCPのリソースを管理できるようになる
- k8sの公式のPJじゃなくてCloudプロバイダー達が作っているコミュニティベースのOSS
- k8sと各コミュニティCloudをAPIで繋いでくれる中継役をc-c-mの実装によって実現
- k8sのコントローラとして一定間隔でk8s上で使いたいCloudのリソースとAWSに実際に存在するリソースの整合性を保つ
cloud provider aws
- AWSのリソースをk8s上のリソースとして管理するために必要なコントロール
- kubectlを叩く
- apiserverがetcdにサービス作ってくださいと要求
- c-mがサービスを作ってくださいという要求をウォッチ
- serviceを実際に作成
- c-c-mがAWSのAPIに応えてLBのプロビジョニング
- LBが出来たらservice側と整合性を併せにがっちゃんこする
これによりあたかもk8s上でLBが連携出来たかのように動く
-
EKSはk8sのマスターコンポーネント部分がマネージドになっている
- ここの部分が最近半額になった
- FagateだとENIが居なくなってる
- Containerdが動いている
k8sとAWSのネットワークの連携
- k8sのNW
- k8sは大きく分類するとPod用、Service用、Node用のネットワークがある
- Node用のNWはEC2やFagateに直接アタッチされるVPC配下のNW
- オンプレで言うところの物理NICや仮想NICが刺さってるとこ
- Pod用のNWは論理的に分離されたNW
- Nodeとは完全に隔離されている
- Service用のNWはLBやEngressなどアプリケーションレイヤのロードバランシング
- AWSのNW
- VPC、サブネット、NACL、SG、ENI、Gateway
- k8sとはNWの概念が違う
- 2種類のNW概念を繋いであげる必要がある
- CNI(Container Network Interface)
- CNIはk8s/ContainerのNWを定義する仕様
- 各プロバイダーは仕様に併せて実装
- VPCの世界とk8sの世界を繋いでくれる存在
- ECSもCNIを使っている
k8sとAWSのストレージの連携
- k8sにおけるストレージは、Storageclass、PersistentVolume、persistentvolumeclaim
- AWSにおけるストレージは、EBS、EFS、FSx
- CSI(Container Storage Interface)
- デバイスドライバー
- オープンソースで公開されている
- k8sとAWSのストレージの世界を繋いでくれる
eksctl
- Weavework社が出しているEKSのラッパーツール
- 去年公式ツールに昇格
- 設定の引数をYAMLで記述できるのでIaCも出来る
- DockerComposeのような使用感
- ekcctlがあればログやメトリクスCloudWatchで面倒みさせたり
- ALB Ingress Controllerをeksctl有効化可能
- ACMやRoute53も有効化出来る
- 結果eksctlは凄く便利
- AWSSDK経由でCFnスタックがプロビジョニングされる
- EKSのクラスタやノードはCFnで作成
- EKSのworkloadだけじゃなくクラスタも宣言的に管理
- 構成変更や削除も対応可能
k8sとAWS関連OSS
- SIG AWS
- IAM Authenticater
- CNI/CSI plugin
- external-dns
- AWSが関わるk8s関連OSS
- EKS(ECS)の開発チーム動向