Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
EKS on Fargate
ayaka ishizuka
July 27, 2020
Technology
0
540
EKS on Fargate
ayaka ishizuka
July 27, 2020
Tweet
Share
Other Decks in Technology
See All in Technology
Devに力を授けたいSREのあゆみ / SRE that wants to empower developers
tocyuki
3
480
モダンデータスタックとかの話(データエンジニアのお仕事とは)
foursue
0
460
Building smarter apps with machine learning, from magic to reality
picardparis
4
3.1k
ニフティでSRE推進活動を始めて取り組んできたこと
niftycorp
2
580
testing journey / テストが嫌いでIT業界を離れるはずだったのに〜テスト嫌いが現場で品質改善を実施するまでの物語〜
aki_moon
1
380
runn is a package/tool for running operations following a scenario. / golang.tokyo #32
k1low
1
220
我々はなぜテストをするのか?
kawaguti
PRO
0
550
OSINT/GEOINT ワークショップ 20220514 古橋資料
furuhashilab
2
310
Kubernetesの上に作る、統一されたマイクロサービス運用体験
tkuchiki
1
1.1k
アルプでのAgile Testing / Alp Agile Testing
nametake
0
160
How We Foster Reliability in Diversity
nari_ex
PRO
9
2.9k
[SRE NEXT 2022]ヤプリのSREにおけるセキュリティ強化の取り組みを公開する
mmochi23
1
670
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
56
5.2k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
151
12k
Creatively Recalculating Your Daily Design Routine
revolveconf
207
10k
10 Git Anti Patterns You Should be Aware of
lemiorhan
638
52k
The Language of Interfaces
destraynor
148
20k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
181
15k
Agile that works and the tools we love
rasmusluckow
319
19k
Designing for humans not robots
tammielis
241
23k
Visualization
eitanlees
124
11k
The Power of CSS Pseudo Elements
geoffreycrofte
46
3.9k
Intergalactic Javascript Robots from Outer Space
tanoku
261
25k
KATA
mclloyd
7
8.6k
Transcript
EKS on Fargate ~ALB Ingress Controller デプロイまで~
自己紹介 石塚 (Twitter: suwa/ヅカストーン@_Tsuka3) サイボウズ株式会社 SRE 一年前まで趣味でコンテナ技術を嗜む花屋 趣味が高じて未経験からインフラエンジニアに転職 前職では保育園の業務支援システム (CoDMON)
を扱う https://github.com/Ishizuka427
自己紹介 石塚 (Twitter: suwa/ヅカストーン@_Tsuka3) サイボウズ株式会社 SRE 一年前まで趣味でコンテナ技術を嗜む花屋 趣味が高じて未経験からインフラエンジニアに転職 前職では保育園の業務支援システム (CoDMON)
を扱う https://github.com/Ishizuka427 よろしくお願いします
EKSとは
EKS AWS が提供しているマネージド型の Kubernetes サービスです
なぜ EKS なのか? 条件 - AWS 上でアプリケーションを展開していた - マイクロサービス化を検討していた -
開発環境は Docker 化されていた 小規模のアプリケーションを AWS 上のコンテナで扱うのであれば ECS での運用も候補として有り得たが サービスの種類が多いため、アプリケーションの設定を一元管理できる面で EKS 化を視野に入れて検証を行いました。
下準備 - AWS CLI インストール $ brew install awscli --upgrade
--user - 必要に応じて検証用のユーザーを作成 - IAMユーザーのアクセスキー作成 (AWSコンソール) - AWS CLI に AWS 認証情報を設定する $ aws configure AWS CLI を IAM に紐付けます
eksctl install AWS がサードパーティー的に保有している brew 形式のリポジトリを インストールします。 $ brew tap
weaveworks/tap eksctl をインストールします。 $ brew install weaveworks/tap/eksctl インストールできたか確認。 $ eksctl version
create cluster コマンド実行したら約15分待つ。 $ eksctl create cluster \ --name demo-cluster
\ --region ap-northeast-1 \ --fargate 内部で Cloud Formation が実行されているため、時間がかかります。 クラスター作成します
クラスターの確認 メニューバーにある Docker アイコンから切り替えることができます。
ノード一覧を表示 ノード一覧を表示させたところ 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
Manifest
Object マニフェストファイルは用途によってオブジェクトが何種類かあります シングルファイルにまとめても マルチファイルとして別々にファイルを作成しても OK です。 - Deployment - Service
- Ingress - Secret - ServiceAccount etc.. 今回は deployment.yml と service.yml を作成して検証を行います。 Object とは: “record of intent” (意図の記録)
単一の nginx Deployment を作成 作業場所を作成して、その配下に deployment.yml を作成&編集します。 $ mkdir kube
$ cd kube/
None
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 一覧を表示
Service 作成 service.yml を作成&編集します。
None
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 一覧を表示
port forward ① service.yml を書かなくても、起動できているかの確認であれば port forward で外部アクセスすることができます。 $ kubectl
get pods NAME READY STATUS RESTARTS nginx-954765466-zmj5p 1/1 Running 0
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
None
Service の役割 Deployment だけでも port forward することでブラウザからの確認ができました。 Service を作成することで Pod
の IP アドレスを 単一のエンドポイントに固定することができます。
ハマったところ 実際に Service を作成しようと 先程編集した nginx-service.yml に、外部からアクセスするために spec: type: LoadBalancer
を追記し、 yaml を書き換えて起動したところ ブラウザに何も表示されなかった。
何故なのか?
LoadBalancer について (引用) Service | Kubernetes https://kubernetes.io/docs/concepts/services-networking/service/#publishi ng-services-service-types > ユーザーのアプリケーションのいくつかの部分において(例えば、frontends
など)、ユーザーのクラスターの外部にあるIPアドレス上でServiceを公開した い場合があります。 (〜略〜) > LoadBalancer: クラウドプロバイダーのロードバランサーを使用して、 Serviceを外部に公開します。
今回はAWS (引用) Service | Kubernetes https://kubernetes.io/docs/concepts/services-networking/service/#publishi ng-services-service-types > ユーザーのアプリケーションのいくつかの部分において(例えば、frontends など)、ユーザーのクラスターの外部にあるIPアドレス上でServiceを公開した
い場合があります。 (〜略〜) > LoadBalancer: クラウドプロバイダーのロードバランサーを使用して、 Serviceを外部に公開します。 今回は AWS
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 をサポー トしていません。
ALB Ingress Controller を使おう EC2 上のワーカーノードにおいてはロードバランサーのサポートがあるけれど Fargate の場合はないらしい。 Fargate の場合
ALB Ingress Controller を、使用するのがベストプラクティスとのことです。
ALB Ingress Controller
ALB Ingress Controller とは? Ingress リソースがクラスターで作成されると 内部で AWS の ALB
など サポートリソースの作成をトリガーするコントローラー。
下準備 使用する VPC のサブネットにタグを付けて そのサブネットを使用できることを ALB Ingress Controller に伝える必要がある。 ※
eksctl を使用してクラスターをデプロイした場合は タグがすでに適用されているため不要。
IAM OIDC プロバイダー OpenID Connect プロバイダーを使った認証を有効化。 $ eksctl utils associate-iam-oidc-provider
\ --region ap-northeast-1 \ --cluster demo-cluster \ --approve
None
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
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 ロールを作成し サービスアカウントにアタッチする。
ALB Ingress Controller をデプロイ ALB Ingress Controller のデプロイマニフェストを編集 クラスター名の行を追加する。 ※
Fargate で ALB Ingress Controller を実行している場合は VPC ID の行と、クラスターの AWS リージョン名も追加する必要がある。 $ kubectl edit deployment.apps/alb-ingress-controller \ -n kube-system
確認 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
2048
サンプルアプリケーション 2048 ALB Ingress Controller の検証として サンプルアプリをデプロイしてみます。 サンプルアプリの名前空間を含む Fargate プロファイルを作成。
$ eksctl create fargateprofile \ --cluster demo-cluster \ --region ap-northeast-1 \ --name alb-sample-app \ --namespace 2048-game
None
apply 以下を $ kubectl apply -f で作成する。 - Kubernetes の名前空間
- Deployment - Service
マニフェストファイルを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 <= 追記
マニフェストファイルを適用 $ 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 リソースが 作成されたことを確認
マニフェストファイルを適用 $ 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 リソースが 作成されたことを確認
デプロイの確認 ブラウザから確認できました
所感 Kubernetes 初心者にとって鬼門だなぁと感じたポイントは k8s、ECS、EKS それぞれの用語の量と複雑さです。 (例: ECS の Service と
k8s の Service は別物。など) EKS で作成した Kubernetes クラスターとは別に Docker Desktop などで作成した Kubernetes クラスターを触りつつ進める と、何か Error があった際にも切り分けや原因究明が容易になり分かりやす かったです。 クラスターの切り替えは Docker アイコンからワンクリックで可能なので Docker Desktop が便利でした。
ご清聴ありがとうございます