EKS on Fargate

Transcript

1. EKS on Fargate ~ALB Ingress Controller デプロイまで~
2. 　　自己紹介 石塚 (Twitter: suwa/ヅカストーン@_Tsuka3) サイボウズ株式会社 SRE 一年前まで趣味でコンテナ技術を嗜む花屋 趣味が高じて未経験からインフラエンジニアに転職 前職では保育園の業務支援システム (CoDMON) を扱う https://github.com/Ishizuka427
3. 　　自己紹介 石塚 (Twitter: suwa/ヅカストーン@_Tsuka3) サイボウズ株式会社 SRE 一年前まで趣味でコンテナ技術を嗜む花屋 趣味が高じて未経験からインフラエンジニアに転職 前職では保育園の業務支援システム (CoDMON) を扱う https://github.com/Ishizuka427 よろしくお願いします
4. EKSとは
5. EKS AWS が提供しているマネージド型の Kubernetes サービスです
6. なぜ EKS なのか？ 条件 - AWS 上でアプリケーションを展開していた - マイクロサービス化を検討していた - 開発環境は Docker 化されていた 小規模のアプリケーションを AWS 上のコンテナで扱うのであれば ECS での運用も候補として有り得たが サービスの種類が多いため、アプリケーションの設定を一元管理できる面で EKS 化を視野に入れて検証を行いました。
7. 下準備 - AWS CLI インストール $ brew install awscli --upgrade --user - 必要に応じて検証用のユーザーを作成 - IAMユーザーのアクセスキー作成 (AWSコンソール) - AWS CLI に AWS 認証情報を設定する $ aws configure AWS CLI を IAM に紐付けます
8. eksctl install AWS がサードパーティー的に保有している brew 形式のリポジトリを インストールします。 $ brew tap weaveworks/tap eksctl をインストールします。 $ brew install weaveworks/tap/eksctl インストールできたか確認。 $ eksctl version
9. create cluster コマンド実行したら約15分待つ。 $ eksctl create cluster \ --name demo-cluster \ --region ap-northeast-1 \ --fargate 内部で Cloud Formation が実行されているため、時間がかかります。 クラスター作成します
10. クラスターの確認 メニューバーにある Docker アイコンから切り替えることができます。
11. ノード一覧を表示 ノード一覧を表示させたところ fargate が動いていました。 $ kubectl get nodes NAME STATUS ROLES AGE VERSION fargate-ip-*.**.***.internal Ready <none> 9d v1.14.8-eks fargate-ip-*.**.***.internal Ready <none> 9d v1.14.8-eks
12. Manifest
13. Object マニフェストファイルは用途によってオブジェクトが何種類かあります シングルファイルにまとめても マルチファイルとして別々にファイルを作成しても OK です。 - Deployment - Service - Ingress - Secret - ServiceAccount etc.. 今回は deployment.yml と service.yml を作成して検証を行います。 Object とは: “record of intent” (意図の記録)
14. 単一の nginx Deployment を作成 作業場所を作成して、その配下に deployment.yml を作成＆編集します。 $ mkdir kube $ cd kube/
16. Create object ~~Deployment~~ $ kubectl apply -f nginx-deployment.yml deployment.extensions/nginx created $ kubectl get pod NAME READY STATUS RESTARTS AGE nginx-954765466-zmj5p 0/1 Pending 0 9s Pod 一覧を表示
17. Service 作成 service.yml を作成＆編集します。
19. Create object ~~Service~~ $ kubectl apply -f nginx-service.yml service/nginx created $ kubectl get service --all-namespaces NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) default kubernetes ClusterIP 10.100.0.1 <none> 443/TCP default nginx ClusterIP 10.100.77.190 10.100.0.1 80/TCP kube-system kube-dns ClusterIP 10.100.0.10 <none> 53/UDP,53/TCP Service 一覧を表示
20. port forward ① service.yml を書かなくても、起動できているかの確認であれば port forward で外部アクセスすることができます。 $ kubectl get pods NAME READY STATUS RESTARTS nginx-954765466-zmj5p 1/1 Running 0
21. port forward ② port forward でローカルから繋げられるようにします。 $ kubectl port-forward nginx-954765466-zmj5p 8080:80 Forwarding from 127.0.0.1:8080 -> 80 Forwarding from [::1]:8080 -> 80 Handling connection for 8080
23. Service の役割 Deployment だけでも port forward することでブラウザからの確認ができました。 Service を作成することで Pod の IP アドレスを 単一のエンドポイントに固定することができます。
24. ハマったところ 実際に Service を作成しようと 先程編集した nginx-service.yml に、外部からアクセスするために spec: type: LoadBalancer を追記し、 yaml を書き換えて起動したところ ブラウザに何も表示されなかった。
25. 何故なのか？
26. LoadBalancer について (引用) Service | Kubernetes https://kubernetes.io/docs/concepts/services-networking/service/#publishi ng-services-service-types > ユーザーのアプリケーションのいくつかの部分において(例えば、frontends など)、ユーザーのクラスターの外部にあるIPアドレス上でServiceを公開した い場合があります。 (〜略〜) > LoadBalancer: クラウドプロバイダーのロードバランサーを使用して、 Serviceを外部に公開します。
27. 今回はAWS (引用) Service | Kubernetes https://kubernetes.io/docs/concepts/services-networking/service/#publishi ng-services-service-types > ユーザーのアプリケーションのいくつかの部分において(例えば、frontends など)、ユーザーのクラスターの外部にあるIPアドレス上でServiceを公開した い場合があります。 (〜略〜) > LoadBalancer: クラウドプロバイダーのロードバランサーを使用して、 Serviceを外部に公開します。 今回は AWS
28. EKS の Fargate はサポート外 (引用) Amazon EKS クラスターで実行されている Kubernetes Services を公開するには どうすればよいです か?https://aws.amazon.com/jp/premiumsupport/knowledge-center/eks-kubernet es-services-cluster/ > 注意 : Amazon EKS は、Load Balancer を通じて Amazon Elastic Compute Cloud (Amazon EC2) インスタンスワーカーノードで実行される ポッドに対して Network Load Balancer と Classic Load Balancer をサポートしています。Amazon EKS は、AWS Fargate で実行されるポッド の Network Load Balancer および Classic Load Balancer をサポー トしていません。
29. ALB Ingress Controller を使おう EC2 上のワーカーノードにおいてはロードバランサーのサポートがあるけれど Fargate の場合はないらしい。 Fargate の場合 ALB Ingress Controller を、使用するのがベストプラクティスとのことです。
30. ALB Ingress Controller
31. ALB Ingress Controller とは？ Ingress リソースがクラスターで作成されると 内部で AWS の ALB など サポートリソースの作成をトリガーするコントローラー。
32. 下準備 使用する VPC のサブネットにタグを付けて そのサブネットを使用できることを ALB Ingress Controller に伝える必要がある。 ※ eksctl を使用してクラスターをデプロイした場合は タグがすでに適用されているため不要。
33. IAM OIDC プロバイダー OpenID Connect プロバイダーを使った認証を有効化。 $ eksctl utils associate-iam-oidc-provider \ --region ap-northeast-1 \ --cluster demo-cluster \ --approve
35. IAM ポリシーの作成 ユーザーに代わって AWS API を呼び出すことを ALB Ingress Controller Pod に許可するための ALBIngressControllerIAMPolicy という IAM ポリシーを作成。 $ aws iam create-policy \ --policy-name ALBIngressControllerIAMPolicy \ --policy-document \ https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-in gress-controller/v1.1.4/docs/examples/iam-policy.json
36. ALB Ingress Controller のセットアップ alb-ingress-controller という名前の Kubernetes サービスアカウントを kube-system 名前空間に作成。 $ kubectl apply -f \ https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-in gress-controller/v1.1.4/docs/examples/rbac-role.yaml ALB Ingress Controller の IAM ロールを作成し サービスアカウントにアタッチする。
37. ALB Ingress Controller をデプロイ ALB Ingress Controller のデプロイマニフェストを編集 クラスター名の行を追加する。 ※ Fargate で ALB Ingress Controller を実行している場合は VPC ID の行と、クラスターの AWS リージョン名も追加する必要がある。 $ kubectl edit deployment.apps/alb-ingress-controller \ -n kube-system
38. 確認 ALB Ingress Controller が実行されていることを get pods で確認。 $ kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE alb-ingress-controller-*** 1/1 Running 0 97s coredns-d784dc748-fmkzx 1/1 Running 0 23h coredns-d784dc748-r28sm 1/1 Running 0 23h
40. サンプルアプリケーション 2048 ALB Ingress Controller の検証として サンプルアプリをデプロイしてみます。 サンプルアプリの名前空間を含む Fargate プロファイルを作成。 $ eksctl create fargateprofile \ --cluster demo-cluster \ --region ap-northeast-1 \ --name alb-sample-app \ --namespace 2048-game
42. apply 以下を $ kubectl apply -f で作成する。 - Kubernetes の名前空間 - Deployment - Service
43. マニフェストファイルをDL $ curl -o 2048-ingress.yaml \ https://raw.githubusercontent.com/kubernetes-sigs/aws-alb-in gress-controller/v1.1.4/docs/examples/2048/2048-ingress.yaml 2048-ingress.yaml ファイル annotations: kubernetes.io/ingress.class: alb alb.ingress.kubernetes.io/scheme: internet-facing alb.ingress.kubernetes.io/target-type: ip <= 追記
44. マニフェストファイルを適用 $ kubectl apply -f 2048-ingress.yaml $ kubectl get ingress/2048-ingress -n 2048-game NAME HOSTS ADDRESS PORTS 2048-ingress * cc*-2048game-2048ingr-*.elb.amazonaws.com 80 しばらくして Ingress リソースが 作成されたことを確認
45. マニフェストファイルを適用 $ kubectl apply -f 2048-ingress.yaml $ kubectl get ingress/2048-ingress -n 2048-game NAME HOSTS ADDRESS PORTS 2048-ingress * cc*-2048game-2048ingr-*.elb.amazonaws.com 80 しばらくして Ingress リソースが 作成されたことを確認
46. デプロイの確認 ブラウザから確認できました
47. 所感 Kubernetes 初心者にとって鬼門だなぁと感じたポイントは k8s、ECS、EKS それぞれの用語の量と複雑さです。 (例: ECS の Service と k8s の Service は別物。など) EKS で作成した　Kubernetes クラスターとは別に Docker Desktop などで作成した Kubernetes クラスターを触りつつ進める と、何か Error があった際にも切り分けや原因究明が容易になり分かりやす かったです。 クラスターの切り替えは Docker アイコンからワンクリックで可能なので Docker Desktop が便利でした。
48. ご清聴ありがとうございます