[aws] EKS Mode/Nodes

안녕하세요. AWS EKS Workshop Study (=AEWS) 3기 모임에서 스터디한 내용을 정리했습니다. 해당 글에서는 Amzaon EKS Mode/Nodes 에 대해 자세히 알아보겠습니다.

 

Fargate

사전학습

K8S Scheduler : 참고[ [CNKCD2024] 쿠버네티스 스케줄러는 노드를 어떻게 선택하는가? (임찬식) - Youtube]

-> 파드 생성 시 : 인증/인가 → Admission → ETCD ⇒ 스케줄러 동작 (노드 선택) ⇒ 이후 pod 에 nodename에 업데이트됨

 

# k8s 배포
kind create cluster --name myk8s --image kindest/node:v1.32.2 --config - <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
EOF

# 파드 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  schedulingGates:
  - name: example.com/foo
  - name: example.com/bar
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.6
  terminationGracePeriodSeconds: 0
EOF

 

kubectl get pod

kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'

# 스케줄링 되기전으로 아직 node가 선택되지 않아서 nodename 없음
kubectl get pod -o yaml | grep -i nodename

 

# To inform scheduler this Pod is ready for scheduling, you can remove its schedulingGates entirely by reapplying a modified manifest:
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: pause
    image: registry.k8s.io/pause:3.6
  terminationGracePeriodSeconds: 0
EOF

# You can check if the schedulingGates is cleared by running:
kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'
kubectl get pod


# 노드 스케줄링되어서 아래 nodename 출력!
kubectl get pod -o yaml | grep -i nodename
    nodeName: myk8s-control-plane
    

# 파드 삭제
kubectl delete pod test-pod

# k8s 삭제
kind delete cluster --name myk8s

 

 

Fargate [공식문서] 

- EKS(컨트롤 플레인) + Fargate(데이터 플레인)의 완전한 서버리스화(=AWS 관리형)

 

테라폼으로 실습 환경 배포 : EKS, fargate profile

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints
tree terraform-aws-eks-blueprints/patterns
cd terraform-aws-eks-blueprints/patterns/fargate-serverless

 

Fargate on EKS 장점

관리의 복잡도가 줄어듦

- 1. Cluster Autoscaler 불필요

- 2. Pod를 사용해도 VM 수준의 격리 가능(VM isolation at Pod Level)

- 3. 기존 애플리케이션의 변경없이 Fargate로 이전할 수 있음

 

 

Fargate on EKS 제약사항

[참고] Faregate 고려사항 : https://docs.aws.amazon.com/eks/latest/userguide/fargate.html#fargate-considerations

- 1. 리소스 상한선 존재(최대 4vCPU, 30GB 메모리)

- 2. Stateful한 워크로드 사용 불가능

- 3. Daemonset을 비롯한 privileged Pod 사용 불가능 

 

즉, Fargate는 Stateless하고 리소스를 크게 요구하지 않으며 특별한 권한이 필요 없는 워크로드에 주로 사용 

 

Auto mode

AWS Auto Mode 주요 아키텍처 구성 요소

• Karpenter 기반 자동 확장: Karpenter는 EC2 인스턴스를 자동으로 프로비저닝하여 클러스터의 컴퓨팅 능력을 동적으로 조정함. 이는 Pod 요청에 따라 인스턴스를 추가하거나 제거함
• Bottlerocket AMI: Auto Mode는 Bottlerocket 기반의 Amazon Machine Image (AMI)를 사용하여 노드를 관리함. 이 AMI는 보안을 강화하고, SELinux를 사용하여 파일 시스템에 대한 접근을 제한함
• 자동 업그레이드 및 보안: 노드는 최대 21일간 사용되며, 이후 자동으로 교체됨. 이는 최신 보안 패치와 OS 업데이트를 보장함
• 네트워킹 및 스토리지: Auto Mode는 네트워킹과 스토리지를 자동으로 구성하고, AWS Elastic Load Balancing과 Amazon EBS CSI 드라이버를 통합함

 

테라폼으로 실습 환경 배포 

variables.tf 수정 : ap-northeast-2 , 10.20.0.0/16

# Get the code 
git clone https://github.com/aws-samples/sample-aws-eks-auto-mode.git
cd sample-aws-eks-auto-mode/terraform

# eks.tf : "system" 은 '전용인스턴스'로 추가하지 않는다
...
  cluster_compute_config = {
    enabled    = true
    node_pools = ["general-purpose"]
  }
...

# Initialize and apply Terraform
terraform init
terraform plan
terraform apply -auto-approve

 

Auto Mode [공식문서] 

특징

1. Kubernetes 클러스터 관리 간소화 : EKS 자동 모드는 최소한의 운영 오버헤드로 프로덕션 준비 클러스터를 제공하여 EKS 관리를 간소화함. EKS 자동 모드를 사용하면 심층적인 EKS 전문 지식이 없이 까다롭고 동적인 워크로드를 자신 있게 실행할 수 있음

2. 애플리케이션 가용성 : EKS 자동 모드는 Kubernetes 애플리케이션의 요구에 따라 EKS 클러스터에서 노드를 동적으로 추가하거나 제거함. 이를 통해 수동 용량 계획의 필요성을 최소화하고 애플리케이션 가용성을 보장

3. 효율성 : EKS 자동 모드는 NodePool 및 워크로드 요구 사항에 의해 정의된 유연성을 준수하면서 컴퓨팅 비용을 최적화하도록 설계됨. 또한 사용되지 않는 인스턴스를 종료하고 워크로드를 다른 노드에 통합하여 비용 효율성을 개선함

4. 보안 : EKS 자동 모드는 노드에 대해 변경 불가능한 것으로 처리되는 AMI를 사용함. 이러한 AMI는 잠긴 소프트웨어를 시행하고, SELinux 필수 액세스 제어를 활성화하고, 읽기 전용 루트 파일 시스템을 제공함. 또한 EKS 자동 모드에서 시작한 노드는 최대 수명이 21일(줄일 수 있음)이며, 그 후에는 자동으로 새 노드로 교체됨. 이 접근 방식은 많은 고객이 이미 채택한 모범 사례에 맞춰 노드를 정기적으로 순환하여 보안 태세를 강화함

5. 자동 업그레이드 : EKS 자동 모드는 구성된 Pod Disruption Budgets(PDB) 및 NodePool Disruption Budgets(NDB)를 존중하면서 Kubernetes 클러스터, 노드 및 관련 구성 요소를 최신 패치로 최신 상태로 유지함. 최대 21일 수명까지 PDB 차단 또는 기타 구성으로 인해 업데이트가 방해받는 경우 개입이 필요할 수 있음

6. 관리되는 구성 요소 : EKS 자동 모드에는 Kubernetes 및 AWS 클라우드 기능이 핵심 구성 요소로 포함되어 있으며, 그렇지 않으면 애드온으로 관리해야 함 여기에는 Pod IP 주소 할당, Pod 네트워크 정책, 로컬 DNS 서비스, GPU 플러그인, 상태 검사기 및 EBS CSI 스토리지에 대한 기본 제공 지원이 포함됨

7. 사용자 지정 가능한 NodePools 및 NodeClasses : 워크로드에 스토리지, 컴퓨팅 또는 네트워킹 구성 변경이 필요한 경우 EKS 자동 모드를 사용하여 사용자 지정 NodePools 및 NodeClasses를 만들 수 있음. 기본 NodePools 및 NodeClasses는 편집할 수 없지만 기본 구성과 함께 새 사용자 지정 NodePools 또는 NodeClasses를 추가하여 특정 요구 사항을 충족할 수 있음.

 

Auto Mode의 이점

• 운영 부담 감소: 클러스터 관리와 관련된 많은 작업이 자동화되어, 사용자는 애플리케이션 개발에 집중할 수 있음
• 비용 최적화: 사용되지 않는 인스턴스를 자동으로 종료하여 비용을 절감할 수 있음
• 보안 강화: 노드의 자동 교체와 최신 보안 패치 적용으로 보안이 강화됨

 

HyBrid Nodes

AWS Hybrid Nodes, 특히 Amazon EKS Hybrid Nodes는 온프레미스 또는 엣지 인프라를 Amazon EKS 클러스터의 노드로 사용할 수 있는 기능

 

주요 기능 및 이점

• 통합된 Kubernetes 관리: AWS는 EKS 클러스터의 컨트롤 플레인을 관리하며, 온프레미스 및 엣지 환경에서 실행되는 하이브리드 노드를 통해 통합된 Kubernetes 운영을 제공함
• 유연한 인프라 활용: 온프레미스 하드웨어나 가상 머신을 EKS 클러스터의 노드로 등록하여 기존 인프라를 최대한 활용할 수 있음
• 중앙 집중식 모니터링 및 로깅: AWS Systems Manager, CloudWatch, GuardDuty 등과 통합되어 중앙 집중식 모니터링과 로깅이 가능함
• 비용 효율성: 선결제 약정이나 최소 요금 없이 시간당 요금만 부과되므로 비용을 효율적으로 관리할 수 있음

 

사용 사례

• 하이브리드 클러스터 구성: 클라우드와 온프레미스를 하나의 클러스터로 통합하여 다양한 워크로드를 효율적으로 관리할 수 있음
• 엣지 환경에서의 활용: 엣지 환경에서 데이터 처리를 통해 지연 시간을 줄이고, 규제 요구 사항을 충족할 수 있음

 

Amazon EKS Hybrid Nodes | EKS Workshop