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
EKS_on_Fargate
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
suwa
June 03, 2021
Technology
35
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
EKS_on_Fargate
suwa
June 03, 2021
More Decks by suwa
See All by suwa
記念日
suwa3
0
800
Other Decks in Technology
See All in Technology
Oracle MCP Servers Explained
thatjeffsmith
1
490
Introduction to Sansan, inc / Sansan Global Development Center, Inc.
sansan33
PRO
0
3.2k
Android skills に学ぶ
kokiko
0
180
巨大気象データと戦う ― サロゲートモデル学習を高速化する圧縮技術
gpuunite_official
0
270
アクセスキー流出時の対応で再認識した攻撃側と防御側の非対称性について
kazzpapa3
0
210
LLM Internals: 언어 모델의 계보와 알고리즘 진화 (2023~2026)
inureyes
PRO
1
930
研究開発部の紹介 / Sansan R&D Profile
sansan33
PRO
4
24k
パスキーでドライブする アカウント統合(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
250
The Django UUID Story - DjangoCon US 2026
pauloxnet
0
250
内製AIチャットボット開発で学んだ Datadog Agent Observability活用術
mkdev10
0
140
AIにブラウザを触らせて、E2EテストをPlaywrightで書く
koji_kawamura
0
420
ブラウザで変わるID連携(OAuth/OIDC Numa (Immersion) Workshop 2026)
oidfj
PRO
0
240
Featured
See All Featured
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
490
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
280
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Color Theory Basics | Prateek | Gurzu
gurzu
0
440
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.4k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
28
3.6k
Build your cross-platform service in a week with App Engine
jlugia
234
19k
Code Reviewing Like a Champion
maltzj
528
40k
So, you think you're a good person
axbom
PRO
2
2.1k
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2.1k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
950
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
62k
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 が便利でした。
ご清聴ありがとうございます