누구나 한번 쯤은 슈뢰딩거의 고양이에 대해서 들었거나 관련 밈을 보셨을 겁니다.
그래도 혹시 모르시는 분들을 위해 간단히 알려드리죠.
고양이를 보이지 않는 상자에 넣고, 그 속에 50:50 확률로 고양이를 죽이는 독극물을 넣었을 때 고양이는 죽을까요? 살까요?
일반 세계에서는 죽었다, 살았다 라고 표현하지만 양자역학 세계에서는 이를 죽음과 삶이 중첩된 상태라고 표현합니다.
즉, 살아있으면서 죽어있다 라고 합니다.
오늘 글에서 소개할 Fargate (파게이트) 또한 슈뢰딩거의 고양이와 비슷한 개념입니다. (나만 그렇게 생각할수도..)
Fargate 는 무엇일까?
우리는 보통 AWS 를 이용해서 애플리케이션을 배포한다고 하면 EC2 를 통해 인스턴스를 생성하고, 그 인스턴스 내부에 컨테이너나 직접 프로세스로 띄우게 됩니다.
EC2 인스턴스 클러스터를 관리하고, 인스턴스 유형을 선택하고, 컨테이너의 일정을 관리하고, 클러스터 사용률을 최적화해야했습니다.
하지만 Fargate 를 사용하면 이런 번거로운 작업에서 벗어날 수 있죠.
Fargate 또한 EC2 인스턴스처럼 애플리케이션을 컨테이너로 실행시켜줍니다. 다만, EC2 와 다르게 컨테이너를 실행시켜줄 수 있는 환경을 프로비저닝 할 필요가 없습니다. 즉, Fargate 를 사용한다면 인스턴스 프로비저닝 없이 바로 애플리케이션을 컨테이너로 실행시킬 수 있죠.
여기서 살짝 이런 의문을 가질 수 있습니다.
컨테이너를 실행할 가상 머신이나 컴퓨팅 리소스가 없는데 어떻게 그게 가능하지?
사실 Fargate 또한 EC2 인스턴스 위에서 실행됩니다. 하지만 이 인스턴스는 사용자가 생성한 것이 아니고, AWS 에서 관리하는 인스턴스입니다. AWS 가 관리하는 인스턴스 위에서 실행되기 때문에 사용자는 인스턴스를 신경 쓸 필요가 없는 거죠.
사용자가 인스턴스를 직접 관리 하지 않기 때문에 마침 인스턴스가 없는 환경에서 컨테이너가 실행되는 듯한 느낌을 줍니다.
그리고 이러한 느낌을 AWS 에선 서버리스 라고 지칭하죠.
노드가 있는데요 없어요!
그래서 Fargate 는 서버리스 컨테이너 컴퓨팅 엔진이라고 볼 수 있습니다.
Fargate 의 장점은 아래와 같습니다.
- 서버를 관리하지 않고도 컨테이너를 배포하고 관리할 수 있다 (여기서 서버는 EC2)
- ECS, EKS 와 호환되며 필요한 컨테이너(파드) 사양에 맞게 실행 가능하다
- 인프라가 아닌 애플레케이션에 집중할 수 있다
EKS 에서의 Fargate
그럼 실제로 Fargate 가 어떻게 동작하는 지 EKS 환경에서 확인해보죠!
렛츠두더코드!
테스트 환경
- Terraform v1.2.7
- EKS v1.23
EKS 환경에서 Fargate 를 사용하려면 EKS 에서 파드를 실행시킬 수 있도록 IAM Role 을 생성하고, 이를 Role 을 부여하여 Fargate 프로필을 활성화 하면 됩니다.
Fargate 프로필은 Fargate 를 이용하여 파드 배포를 가능케 해준다고 생각하시면 됩니다. 여기 참고
테라폼으로 진행할 것이기 때문에 따로 AWS 웹에서 해줄 것은 없습니다. EKS 모듈을 참조하려면 여기 !
terraform main.tf 아래와 같이 Fargate 프로필 관련 부분을 추가했습니다.
# Active Fargate Profile
fargate_profiles = {
default = {
name = "default"
selectors = [
{
namespace = "default"
labels = {
WorkerType = "fargate"
}
}
]
tags = {
Owner = "kingbj0429"
}
timeouts = {
create = "20m"
delete = "20m"
}
}
}
이후 terraform apply 를 통해 EKS 에 적용시켜보죠.
Fargate 프로필에 필요한 IAM Role 이 생성되었고,
# module.eks.module.fargate_profile["default"].aws_iam_role_policy_attachment.this["arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy"] will be created
+ resource "aws_iam_role_policy_attachment" "this" {
+ id = (known after apply)
+ policy_arn = "arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy"
+ role = (known after apply)
}
# module.eks.module.fargate_profile["default"].aws_iam_role_policy_attachment.this["arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"] will be created
+ resource "aws_iam_role_policy_attachment" "this" {
+ id = (known after apply)
+ policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
+ role = (known after apply)
}
# module.eks.module.fargate_profile["default"].aws_iam_role.this[0] will be created
+ resource "aws_iam_role" "this" {
+ arn = (known after apply)
+ assume_role_policy = jsonencode(
{
+ Statement = [
+ {
+ Action = "sts:AssumeRole"
+ Effect = "Allow"
+ Principal = {
+ Service = "eks-fargate-pods.amazonaws.com"
}
+ Sid = ""
},
]
+ Version = "2012-10-17"
}
)
+ create_date = (known after apply)
+ description = "Fargate profile IAM role"
+ force_detach_policies = true
+ id = (known after apply)
+ managed_policy_arns = (known after apply)
+ max_session_duration = 3600
+ name = (known after apply)
+ name_prefix = "default-"
+ path = "/"
+ tags = {
+ "Owner" = "kingbj0429"
}
+ tags_all = {
+ "Owner" = "kingbj0429"
}
+ unique_id = (known after apply)
+ inline_policy {
+ name = (known after apply)
+ policy = (known after apply)
}
}
Fargate 프로필이 활성화되었습니다.
# module.eks.module.fargate_profile["default"].aws_eks_fargate_profile.this[0] will be created
+ resource "aws_eks_fargate_profile" "this" {
+ arn = (known after apply)
+ cluster_name = "eks"
+ fargate_profile_name = "default"
+ id = (known after apply)
+ pod_execution_role_arn = (known after apply)
+ status = (known after apply)
+ subnet_ids = [
+ "subnet-xxxx",
+ "subnet-xxxx",
+ "subnet-xxxx",
+ "subnet-xxxx",
]
+ tags = {
+ "Owner" = "kingbj0429"
}
+ tags_all = {
+ "Owner" = "kingbj0429"
}
+ selector {
+ labels = {
+ "WorkerType" = "fargate"
}
+ namespace = "default"
}
+ timeouts {
+ create = "20m"
+ delete = "20m"
}
}
그럼 실제로 생성되었는지 AWS 웹에서 확인해보겠습니다.
우선 생성된 IAM Role 입니다.
Policy 는 AmazonEKS_CNI_Policy 와 AmazonEKSFargatePodExecutionRolePolicy 입니다.
이 두개의 Policy 는 AWS 관리형이기 때문에 AWS 에서 쉽게 정책 내용을 확인할 수 있습니다.
그리고 생성된 프로필을 확인해줍니다.
포드 선택기는 다음과 같습니다.
default 네임스페이스에 WorkerType: fargate 레이블을 가진 파드를 배포하게 되면 워커노드가 아닌 Fargate 에서 실행됩니다.
포드 선택기와 같은 구성 요소를 확인하려면 여기 참조 !
다 정상적으로 생성된 것 같으니 한번 파드도 실행해보죠.
네임스페이스는 default, WorkerType: fargate 레이블을 가지는 파드 yaml 입니다.
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: fargate-pod
WorkerType: fargate
name: fargate-pod
spec:
containers:
- image: nginx
name: fargate-pod
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
특이점이 있다면 Node 가 워커노드가 아닌 Fargate 입니다.
EKS 웹에서도 노드 정보에 Fargate 가 보입니다.
이렇게 EKS 클러스터 환경에 Fargate 를 실행시켜보았습니다.
이외 알아두면 좋은 정보
메모리 정하기
vCPU 및 메모리 조합을 지정하지 않으면 사용 가능한 가장 작은 조합(.25 vCPU 및 0.5GB 메모리)이 사용됩니다. 여기참고
...
annotations:
CapacityProvisioned: 0.25vCPU 0.5GB
...
Fargate 스토리지
프로비저닝되면 Fargate에서 실행되는 각 pod가 20GB의 컨테이너 이미지 계층 스토리지를 받습니다. 포드 스토리지는 휘발성입니다. pod가 중지된 후에는 스토리지가 삭제됩니다.
AWS EKS에서 Fargate를 사용하면 EBS 볼륨을 직접 마운트하는 것은 불가능합니다. 그러나 EKS에서는 Fargate에서 Amazon EFS(Elastic File System)를 마운트할 수 있습니다.
Amazon EFS는 가용성과 내구성이 뛰어나며 다수의 Fargate 태스크에서 동시에 공유할 수 있습니다. 따라서 여러 Fargate 태스크가 공유하는 데이터가 필요한 경우에는 EFS를 사용하는 것이 좋습니다.
그러나 EFS를 사용할 수 없는 경우에는 Fargate 태스크에서 사용할 수 있는 다른 AWS 스토리지 서비스인 Amazon S3 또는 Amazon DynamoDB를 고려할 수 있습니다.
따라서, EBS를 Fargate에서 마운트하려면 Kubernetes 클러스터에서 EBS 볼륨을 마운트하고, Fargate를 사용하는 워크로드에 대해 이를 참조하는 PV와 PVC(Persistent Volume Claim)을 만들어야 합니다. 그러나 Fargate는 EC2와 달리 작업마다 고유한 인프라를 갖지 않기 때문에 Fargate에서 EBS를 직접 마운트하는 것은 불가능합니다.
GPU 기반의 Fargate
아쉽게도 GPU는 현재 Fargate에서 사용할 수 없습니다.
따라서 GPU 기반의 노드를 Fargate 처럼 유동적으로 사용하고 싶다면 Karpenter 를 이용하면 될 것 같습니다.
그러면 오늘은 여기까지!
'DevOps > Kubernetes' 카테고리의 다른 글
| [Kubernetes] 파드를 보다 안전하게 - SecurityContext (2) | 2023.04.16 |
|---|---|
| [Kubernetes] 지난 밤 너가 한 짓을 알고 있다! - Audit (0) | 2023.04.02 |
| [Kubernetes] PVC로 마음대로 떼었다 붙이는 AWS EBS (0) | 2023.03.06 |
| [Kubernetes] Istio Ingress 에 ALB 를 붙여보자 ! (0) | 2023.02.12 |
| [Kubernetes] 인증/인가와 ETCD 사이 그 녀석 - Admission Controller (0) | 2023.01.24 |
