AEWS 7주차 - EKS Mode/Nodes(EKS Fargate)

본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다.  모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!

 

 

 

 

 

 

 

---

EKS Fargate

 

 

Fargate란?

AWS Fargate는 AWS에서 제공하는 서버리스 컴퓨팅 엔진입니다. Fargate를 사용하면 사용자는 서버를 프로비저닝하거나 관리할 필요 없이 컨테이너를 실행할 수 있습니다. 즉, 인프라 관리의 복잡성을 줄이고 애플리케이션 개발에 집중할 수 있게 해줍니다. Fargate는 Amazon ECS(Elastic Container Service)와 Amazon EKS(Elastic Kubernetes Service)와 함께 사용할 수 있습니다.

 

 

그러면 EKS는 이미 관리형이 아닌가요? 그러면 EKS Fargate는 무엇일까요?

 

https://www.eksworkshop.com/docs/fundamentals/fargate/

 

 

EKS Fargate란?

Amazon EKS Fargate는 Amazon EKS와 Fargate를 결합한 서비스입니다. EKS는 Kubernetes를 관리하는 서비스로, Kubernetes 클러스터를 쉽게 생성하고 운영할 수 있게 해줍니다. EKS Fargate는 Kubernetes 클러스터에서 Fargate를 사용하여 서버리스 방식으로 컨테이너를 실행할 수 있게 합니다. 이를 통해 사용자는 Kubernetes의 이점을 누리면서도 인프라 관리의 부담을 덜 수 있습니다.

 

즉 위와 같이 Worker Node를 고객이 띄워서 관리하지 않고 프로파에 대한 정의만 하면 해당 컨테이너가 작동하여 사용자들은 애플리케이션 개발에만 집중할 수 있습니다.

 

사용한 리소스에 대해서만 비용을 지불하므로, 유휴 상태의 리소스에 대한 비용을 절감할 수 있습니다. 이는 특히 트래픽이 변동하는 애플리케이션에 유리합니다. 

 

그러면 모두가 Fargate를 사용하면 좋은게 아닐까 생각이들지만 아닙니다.

 

우선 Fargate를 사용함에 따라 각 컴퓨팅에 kubelet등 필수적인 부분들을 띄워야하므로 오히려 리소스 및 비용이 추가될 수도 있습니다.

 

이외에도 제약사항에 대해서 스터디에서 너무 잘 작성하셔서 그대로 발췌합니다.

 

• 제약사항 및 고려사항
  • 데몬셋은 Fargate에서 지원되지 않습니다. 애플리케이션에 데몬이 필요한 경우 해당 데몬을 포드에서 사이드카 컨테이너로 실행하도록 재구성합니다.
  • Fargate에서는 특권 컨테이너(Privileged containers)가 지원되지 않습니다.
  • Fargate에서 실행되는 포드는 포드 매니페스트에서 HostPort 또는 HostNetwork를 지정할 수 없습니다.
  • 현재 Fargate에서는 GPU를 사용할 수 없습니다.
  • Can run workloads that require Arm processors 미지원.
  • Can SSH into node 미지원
  • Fargate에서 실행되는 포드는 AWS 서비스에 대한 NAT 게이트웨이 액세스 권한이 있는 private 서브넷에서만 지원됨
  • 포드에는 Amazon EC2 인스턴스 메타데이터 서비스(IMDS)를 사용할 수 없습니다
  • 대체 CNI 플러그인을 사용할 수 없습니다.
  • EFS 동적 영구 볼륨 프로비저닝을 사용할 수 없음.
  • Fargate Spot을 지원하지 않음
  • EBS 볼륨을 Fargate 포드에 마운트할 수 없음
  • Fargate does not currently support Kubernetes topologySpreadConstraints.
  • Can run containers on Amazon EC2 dedicated hosts 미지원
  • Can run AWS Bottlerocket 미지원
  • Fargate Pods run with guaranteed priority, so the requested CPU and memory must be equal to the limit for all of the containers.
  • Fargate는 필요한 Kubernetes 구성 요소(kubelet, kube-proxy, and containerd에 대해 각 Pod의 메모리 예약에 256MB를 추가합니다.
  • 프로비저닝되면 Fargate에서 실행되는 각 Pod는 기본적으로 20 GiB의 임시 저장소를 받게 됩니다. 임시 저장소의 총 양을 최대 175 GiB까지 늘릴 수 있습니다.
  • Fargate의 Amazon EKS는 Fluent Bit 기반의 내장 로그 라우터를 제공합니다. 즉, Fluent Bit 컨테이너를 사이드카로 명시적으로 실행하지 않고 Amazon에서 실행합니다

 

 

fargate profile

 

 

Fargate profile template는 위와 같은 양식을 따릅니다.

 

subnets : pod가 가동될 subnet을 선택합니다.

* 정확하게는 AWS 관리형 서비스이므로 AWS소유의 네트워크에 띄워지고 그에 대한 통신 가능한 ENI가 맞지않을까 싶습니다.

selectors : 노드, namespace 및 labels을 지정합니다.

podExecutionRole : pod가 지닐 IAM Role(권한)에 대해 정의합니다.

 

 

 

Mode 혼합 구성

 

 

뿐만아니라 위와 같이 일반적인 노드 그룹과 Fargate를 혼합하여 구성도 가능합니다.

이를 이용해서 더 유연한 환경 구성이 가능할 것입니다.

 

 

---

EKS Fargate 아키텍처

 

가시다님 스터디 그림

 

 

해당 아키텍처는 AWS EKS Fargate의 작동 방식을 보고 추정하여 도식화한 그림입니다.

 

Fargate를 위해서 Control Plane에는 일반적인 스케쥴러외에 Fargate 스케쥴러가 필요합니다.

그리고 AWS영역에 배포되어 있는 파드와는 (가칭) Fargate-Owned ENI를 통해 사용자가 접근이 가능합니다.

 

이 ENI를 통해 사용자 VPC의 리소스(NGW,IGW)를 통해 외부와의 통신도 가능할 것으로 보입니다.

 

 

가시다님 스터디 그림

 

 

 

물리 아키텍처로는 firecracker-containerd를 통해서 MicroVM을 배포합니다.

 

특징으로는 위에서 언급한 것과 같이 MircroVM마다 'kubelet, kube-proxy, containerd'가 동작해서 256 RAM이 추가로 필요합니다.

-> 지금까지 배포하였던 managed nodegroup에서는 노드에서 공통의 리소스를 사용했었습니다.

 

그리고 위에서 말한 (가칭)Fargate Owned ENI는 Application Container과 직접 매핑이 되어있는 것으로 추정됩니다.

 

 

 

 

이제 배포한 EKS Fargate의 정보들을 확인해봅니다.

 

 

 

 

 

# node 확인 : 노드(Micro VM) 4대
kubectl get csr
kubectl get node -owide

 

 

그리고 pod의 IP를 확인해보면 Node의 IP와 동일합니다.

* MicroVM

 

node/pod IP 비교

 

 

# aws-auth 보다 우선해서 IAM access entry 가 있음을 참고.
# 기본 관리노드 보다 system:node-proxier 그룹이 추가되어 있음.
# fargate profile 이 2개인데, 그 profile 갯수만큼 있음.
kubectl get cm -n kube-system aws-auth -o yaml

 

 

여기에서 system-proxier의 권한을 확인해봅니다.

 

kubectl rbac-tool lookup system:node-proxier
kubectl rolesum -k Group system:node-proxier

 

ClusterRole이고 eks:kube-proxy-fargate와 바인딩이 되어있네요

 

해당 권한들은 rbac툴로 가시성있게 확인이 가능합니다.

 

kubectl get cm -n kube-system kube-proxy-config -o yaml

 

 

coredns 파드를 확인해봅니다.

* 스케쥴러 이름 확인

 

# coredns 파드 상세 정보 확인
kubectl get pod -n kube-system -l k8s-app=kube-dns -o yaml

 

 

 

 

이제 콘솔에서 확인해봅니다.

 

일단 EKS Owned ENI와 (가칭)Fargate Owned ENI는 모두 Cross Account ENI이겠죠?

 

 

인스턴스 소유자가 모두 다른 것을 확인했습니다. 

* 여러 소유자의 인스턴스에 걸쳐서 MicroVM을 할당받고 연결하는 개념인 것 같네요

 

 

이제 kubectl로 간단한 디플로이먼트를 배포하여 보겠습니다.

 

 

Fargate 사양

vCPU	Memory
.25 vCPU	0.5 GB, 1 GB, 2 GB
.5 vCPU	1 GB, 2 GB, 3 GB, 4 GB
1 vCPU	2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB
2 vCPU	Between 4 GB and 16 GB in 1-GB increments
4 vCPU	Between 8 GB and 30 GB in 1-GB increments
8 vCPU	Between 16 GB and 60 GB in 4-GB increments
16 vCPU	Between 32 GB and 120 GB in 8-GB increments

 

 

# 네임스페이스 생성
kubectl create ns study-aews

# 테스트용 파드 netshoot 디플로이먼트 생성 : 0.5vCPU 1GB 할당되어, 아래 Limit 값은 의미가 없음. 
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: netshoot
  namespace: study-aews
spec:
  replicas: 1
  selector:
    matchLabels:
      app: netshoot
  template:
    metadata:
      labels:
        app: netshoot
    spec:
      containers:
      - name: netshoot
        image: nicolaka/netshoot
        command: ["tail"]
        args: ["-f", "/dev/null"]
        resources: 
          requests:
            cpu: 500m
            memory: 500Mi
          limits:
            cpu: 2
            memory: 2Gi
      terminationGracePeriodSeconds: 0
EOF
kubectl get events -w --sort-by '.lastTimestamp'kubectl get events -w --sort-by '.lastTimestamp'

 

neshoot 파드의 IP와 node를 확인해서 IP가 같은지 확인합니다.

 

 

container에 접속해서 인터페이스 및 ip를 확인해봅니다.

 

위에 node ip=pod ip=10.10.9.42임을 기억해보실까요

 

# 파드 내부에 zsh 접속 후 확인
kubectl exec -it deploy/netshoot -n study-aews -- zsh
-----------------------------------------------------
ip -c a
cat /etc/resolv.conf
curl ipinfo.io/ip

 

 

컨테이너의 eh0인터페이스에 해당 노드=파드 ip가 붙어있네요

 

 

이 인터페이스는 콘솔에서 확인이 가능하네요

 

즉 (가칭) Fargate Owned ENI임을 확인했습니다. curl로 IP를 찍으면 그러면 출력되는 IP도 동일할까요?

 

 

이번에는 3.35.38.217입니다.

 

이제는 위의 그림을 이해하셨으면 아시다시피 NAT GW의 IP임을 알 수 있습니다.

해당 네트워크 인터페이스도 콘솔에서 확인이 가능합니다.

 

 

 

여기까지 읽으셨으면 이제 아래의 아키텍처를 이해하시기 쉬우실겁니다.

가시다님 스터디

 

 

 

디플로이먼트와 동일하게 job도 그러면 fargate로 뜰 것 같은데 확인을 해봅니다.

 

#
cat <<EOF | kubectl apply -f -
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox1
  namespace: study-aews
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh", "-c", "sleep 10"]
      restartPolicy: Never
  ttlSecondsAfterFinished: 60 # <-- TTL controller
---
apiVersion: batch/v1
kind: Job
metadata:
  name: busybox2
  namespace: study-aews
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh", "-c", "sleep 10"]
      restartPolicy: Never
EOF

 

# 확인
kubectl get job,pod -n study-aews

 

 

job도 잘 돌아갑니다.

 

다만!!!!!!!!!

 

Fargate는 사용한 컴퓨팅 리소스만큼 과금하는만큼 관리도 중요하죠

 

 

해당 job을 통해 pod가 떴었고 complete을 했지만, node에는 그대로 남아있습니다. 

그러면 해당 컴퓨팅은 안쓰지만, 요금이 계속 부과될 것입니다.

 

이를 주의하면서 리소스를 활용하시면 더욱 비용효율적으로 운여이 가능할 것입니다.

 

# job 삭제
kubectl delete job -n study-aews --all

# netshoot 삭제
kubectl delete deploy netshoot -n study-aews

 

 

삭제하니 초기의 4개 노드만 보입니다.

 

이렇게 AWS EKS Fargate에 대해서 알아보았습니다.

 

제 생각에는 Fargate를 단독 사용하기 보다는 노드 그룹과 혼합하여 적절하게 사용하면 더욱 좋을 것 같습니다.