이 글은 EKS fargate가 무엇이고 원리에 대해 설명합니다.
EKS fargate란?
EKS Fargate는 AWS Fargate로 worker node로 사용하는 방법입니다.
아래 그림처럼 fargateProfiles필드로 fargate profile을 생성할 수 있습니다. fargate node가 아니라 profile이라고 표현한게 매우 중요합니다. fargate profile은 pod가 생성될 때 fargate node에 생성될 지, node group node에 생성할지 결정합니다. fargate profile조건에 맞다면 fargate node가 동적으로 생성됩니다.
이 예제는 eksctl clusterconfig(구성파일)로 fargate profile를 생성했습니다.
fargate node특징
fargate node에는 1개 pod만 실행합니다.
예를 들어 fargate profile 조건에 맞는 pod를 3개 생성하면, fargate node도 3개 생성됩니다.
예제에서 사용한 yaml은 아래와 같습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: fargate-nginx
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: fargate-nginx
template:
metadata:
labels:
app: fargate-nginx
annotations:
CapacityProvisioned: 0.25vCPU 0.5GB
spec:
containers:
- name: fargate-nginx
ports:
- containerPort: 80
장점과 단점
저는 업무로 fargate를 사용하지 않아 장단점을 정확히 모릅니다. 하지만 EKS공식문서를 참고하여 잠시 느꼈던 장점과 단점을 적습니다.
장점
첫번째 장점은 node별로 pod를 1개씩 갖으므로 node리소스가 부족할 때 pod가 제거되지 않습니다. 이는 EKS공식문서에도 언급이 되어 있습니다.
두 번째 장점은 fargate node마다 pod가 사용할 자원만 할당할 수 있어 node운영 비용을 절약할 수 있습니다. fargate node는 1개의 pod만 가질 수 있으므로 pod만 사용할 cpu/memory만 node에 할당하면 됩니다. 그러므로 비용을 아낄 수 있는 상황이 많이 접하게될 것 같습니다.
아래 표에는 Fargate에서 실행되는 pods에 사용할 수 있는 vCPU 및 메모리 조합이 나와 있습니다.
단점
장점보다 단점이 매우 많다는 것을 느꼈습니다. EKS공식문서에서 고려사항을 매우 많이 설명합니다.
눈에 띄는 첫번째 단점은 fargate node는 daemonset을 사용하지 못합니다. 아래 그림에 보이듯이 kube-system namespace에 aws-node, kube-proxy daemonset은 fargate node에 생성되지 않았습니다.
EKS pod에서 EBS를 사용하려면 csi-node daemonset이 해당 node에 실행되야 합니다. 하지만, fargate node는 daemonset을 실행하지 못하므로 EBS 스토리지를 사용할 수 없습니다. 아래 예제는 fargate node에서 실행한 pod가 EBS 스토리지를 사용하려니 bound에러가 발생합니다.
예제에서 사용한 yaml은 아래와 같습니다.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: ebs-sc
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: app
spec:
containers:
- name: app
image: centos
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: ebs-claim
두 번째 단점은 pod 데이터는 휘발성입니다. 데이터를 영구적으로 저장하려면 EFS를 사용해야 합니다. 첫 번째 단점에서 언급한것처럼 farget는 daemonset이 없으므로 EBS 스토리지를 사용하지 못합니다.
원리
EKS는 admission control와 fargate scheduler를 사용하여 fargate pod를 생성합니다.
admission control은 mutant와 valid webhook이 설정되어 있습니다. pod가 fargate profile에 부합되는지 검사하고 부합되면 pod에 fargate profile을 injection합니다.
kubectl get mutatingwebhookconfigurations
fargate scheduler는 fargate API를 사용하여 fargate node와 pod를 스케쥴링합니다.
kubectl -n default describe po
참고자료
- eks 공식문서: https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/fargate-getting-started.html
- 유투브 AWS re:Invent 2019: [REPEAT 1] Amazon EKS under the hood (CON421-R1): https://youtu.be/7vxDWDD2YnM
- 유투브 Amazon ECS를 통한 도커 기반 컨테이너 서비스 구축하기: https://youtu.be/_wyndTR95fU
- 유투브 AWS re:Invent 2020: Amazon EKS on AWS Fargate deep dive: https://youtu.be/9tQFXEhHdn0
- 중국블로그: https://ithelp.ithome.com.tw/articles/10294894
이하여백
'연재 시리즈' 카테고리의 다른 글
EKS 스터디 - 4주차 2편 - pod로깅 (2) | 2023.05.07 |
---|---|
EKS 스터디 - 4주차 1편 - 컨트롤 플레인 로깅 (0) | 2023.05.07 |
EKS 스터디 - 3주차 1편 - EKS가 AWS스토리지를 다루는 원리 (0) | 2023.04.28 |
EKS 스터디 - 2주차 3편 - ALB Controller (2) | 2023.04.23 |
EKS 스터디 - 2주차 2편 - EKS POD IP는 무한대로 할당할 수 있을까? (0) | 2023.04.19 |