Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EKS on Fargate

EKS on Fargate

ayaka ishizuka

July 27, 2020
Tweet

Other Decks in Technology

Transcript

  1. なぜ EKS なのか? 条件 - AWS 上でアプリケーションを展開していた - マイクロサービス化を検討していた -

    開発環境は Docker 化されていた 小規模のアプリケーションを AWS 上のコンテナで扱うのであれば ECS での運用も候補として有り得たが サービスの種類が多いため、アプリケーションの設定を一元管理できる面で EKS 化を視野に入れて検証を行いました。
  2. 下準備 - AWS CLI インストール $ brew install awscli --upgrade

    --user - 必要に応じて検証用のユーザーを作成 - IAMユーザーのアクセスキー作成 (AWSコンソール) - AWS CLI に AWS 認証情報を設定する $ aws configure AWS CLI を IAM に紐付けます
  3. eksctl install AWS がサードパーティー的に保有している brew 形式のリポジトリを インストールします。 $ brew tap

    weaveworks/tap eksctl をインストールします。 $ brew install weaveworks/tap/eksctl インストールできたか確認。 $ eksctl version
  4. create cluster コマンド実行したら約15分待つ。 $ eksctl create cluster \ --name demo-cluster

    \ --region ap-northeast-1 \ --fargate 内部で Cloud Formation が実行されているため、時間がかかります。 クラスター作成します
  5. ノード一覧を表示 ノード一覧を表示させたところ 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
  6. Object マニフェストファイルは用途によってオブジェクトが何種類かあります シングルファイルにまとめても マルチファイルとして別々にファイルを作成しても OK です。 - Deployment - Service

    - Ingress - Secret - ServiceAccount etc.. 今回は deployment.yml と service.yml を作成して検証を行います。 Object とは: “record of intent” (意図の記録)
  7. 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 一覧を表示
  8. 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 一覧を表示
  9. 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
  10. LoadBalancer について (引用) Service | Kubernetes https://kubernetes.io/docs/concepts/services-networking/service/#publishi ng-services-service-types > ユーザーのアプリケーションのいくつかの部分において(例えば、frontends

    など)、ユーザーのクラスターの外部にあるIPアドレス上でServiceを公開した い場合があります。 (〜略〜) > LoadBalancer: クラウドプロバイダーのロードバランサーを使用して、 Serviceを外部に公開します。
  11. 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 をサポー トしていません。
  12. ALB Ingress Controller とは? Ingress リソースがクラスターで作成されると 内部で AWS の ALB

    など サポートリソースの作成をトリガーするコントローラー。
  13. 下準備 使用する VPC のサブネットにタグを付けて そのサブネットを使用できることを ALB Ingress Controller に伝える必要がある。 ※

    eksctl を使用してクラスターをデプロイした場合は タグがすでに適用されているため不要。
  14. 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
  15. 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 ロールを作成し サービスアカウントにアタッチする。
  16. ALB Ingress Controller をデプロイ ALB Ingress Controller のデプロイマニフェストを編集 クラスター名の行を追加する。 ※

    Fargate で ALB Ingress Controller を実行している場合は VPC ID の行と、クラスターの AWS リージョン名も追加する必要がある。 $ kubectl edit deployment.apps/alb-ingress-controller \ -n kube-system
  17. 確認 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
  18. マニフェストファイルを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 <= 追記
  19. マニフェストファイルを適用 $ 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 リソースが 作成されたことを確認
  20. マニフェストファイルを適用 $ 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 リソースが 作成されたことを確認
  21. 所感 Kubernetes 初心者にとって鬼門だなぁと感じたポイントは k8s、ECS、EKS それぞれの用語の量と複雑さです。 (例: ECS の Service と

    k8s の Service は別物。など) EKS で作成した Kubernetes クラスターとは別に Docker Desktop などで作成した Kubernetes クラスターを触りつつ進める と、何か Error があった際にも切り分けや原因究明が容易になり分かりやす かったです。 クラスターの切り替えは Docker アイコンからワンクリックで可能なので Docker Desktop が便利でした。