AWS Fargate로 컴퓨팅 관리 간소화

AWS Fargate로 컴퓨팅 관리 간소화

Amazon EKS에서 AWS Fargate로 Kubernetes Pod를 실행하는 방법을 설명합니다.

출처: 문서

본문

이 주제는 Amazon EKS를 사용해 AWS Fargate에서 Kubernetes Pod를 실행하는 방법을 논의합니다. Fargate는 컨테이너에 온디맨드, 적정 규격의 컴퓨팅 용량을 제공하는 기술입니다. Fargate를 사용하면 컨테이너를 실행하기 위해 가상 머신 그룹을 직접 프로비저닝, 구성 또는 확장할 필요가 없습니다. 또한 서버 유형을 선택하고, 노드 그룹을 언제 확장할지 결정하고, 클러스터 패킹을 최적화할 필요도 없습니다.

Fargate 프로필로 어떤 Pod가 Fargate에서 시작되는지, 어떻게 실행되는지 제어할 수 있습니다. Fargate 프로필은 Amazon EKS 클러스터의 일부로 정의됩니다. Amazon EKS는 Kubernetes가 제공하는 업스트림 확장 가능 모델을 사용하여 AWS가 구축한 컨트롤러로 Kubernetes와 Fargate를 통합합니다. 이 컨트롤러는 Amazon EKS 관리형 Kubernetes 컨트롤 플레인의 일부로 실행되며 네이티브 Kubernetes Pod를 Fargate에 스케줄하는 역할을 담당합니다. Fargate 컨트롤러에는 기본 Kubernetes 스케줄러와 함께 실행되는 새 스케줄러와 여러 변경(mutating) 및 검증(validating) admission 컨트롤러가 포함됩니다. Fargate에서 실행하기 위한 기준을 충족하는 Pod를 시작하면 클러스터에서 실행 중인 Fargate 컨트롤러가 Pod를 인식, 업데이트한 다음 Fargate에 스케줄합니다.

이 주제는 Fargate에서 실행되는 Pod의 다양한 구성 요소를 설명하고 Amazon EKS와 함께 Fargate를 사용할 때의 특별한 고려 사항을 지적합니다.

AWS Fargate 고려 사항

Amazon EKS에서 Fargate를 사용할 때 고려할 몇 가지 사항은 다음과 같습니다.

• Fargate에서 실행되는 각 Pod는 자체 컴퓨팅 경계를 갖습니다. 다른 Pod와 기본 커널, CPU 리소스, 메모리 리소스 또는 탄력적 네트워크 인터페이스를 공유하지 않습니다.
• Network Load Balancer와 Application Load Balancer(ALB)는 IP 대상으로만 Fargate와 함께 사용할 수 있습니다. 자세한 내용은 "네트워크 로드 밸런서 생성" 및 "Application Load Balancer로 애플리케이션 및 HTTP 트래픽 라우팅"을 참고하세요.
• Fargate에 노출된 서비스는 노드 IP 모드가 아니라 대상 유형 IP 모드에서만 실행됩니다. 관리형 노드에서 실행되는 서비스와 Fargate에서 실행되는 서비스 사이의 연결을 확인하는 권장 방법은 서비스 이름으로 연결하는 것입니다.
• Pod는 Fargate에서 실행되도록 스케줄될 때 Fargate 프로필과 일치해야 합니다. Fargate 프로필과 일치하지 않는 Pod는 Pending으로 멈출 수 있습니다. 일치하는 Fargate 프로필이 존재한다면, 생성한 pending Pod를 삭제해 Fargate에 다시 스케줄할 수 있습니다.
• Daemonset은 Fargate에서 지원되지 않습니다. 애플리케이션에 daemon이 필요하면 해당 daemon을 Pod의 사이드카 컨테이너로 실행하도록 재구성하세요.
• 권한 있는(privileged) 컨테이너는 Fargate에서 지원되지 않습니다.
• Fargate에서 실행되는 Pod는 Pod 매니페스트에 HostPort나 HostNetwork를 지정할 수 없습니다.
• Fargate Pod의 기본 nofile 및 nproc 소프트 한도는 1024, 하드 한도는 65535입니다.
• GPU는 현재 Fargate에서 사용할 수 없습니다.
• Fargate에서 실행되는 Pod는 프라이빗 서브넷에서만 지원됩니다(인터넷 게이트웨이에 직접 경로가 없고 NAT 게이트웨이로 AWS 서비스에 액세스). 따라서 클러스터의 VPC에는 프라이빗 서브넷이 있어야 합니다. 아웃바운드 인터넷 액세스가 없는 클러스터는 "인터넷 액세스가 제한된 프라이빗 클러스터 배포"를 참고하세요.
• "Vertical Pod Autoscaler로 Pod 리소스 조정"을 사용해 Fargate Pod의 초기 정확한 CPU 및 메모리 크기를 설정한 다음, "Horizontal Pod Autoscaler로 Pod 배포 확장"을 사용해 해당 Pod를 확장할 수 있습니다. Vertical Pod Autoscaler가 더 큰 CPU와 메모리 조합으로 Pod를 Fargate에 자동 재배포하게 하려면 Vertical Pod Autoscaler의 모드를 Auto 또는 Recreate로 설정해 올바르게 작동하도록 하세요. 자세한 내용은 GitHub의 Vertical Pod Autoscaler 문서를 참고하세요.
• VPC에 대해 DNS 확인과 DNS 호스트 이름이 활성화되어 있어야 합니다. 자세한 내용은 "VPC의 DNS 지원 보기 및 업데이트"를 참고하세요.
• Amazon EKS Fargate는 각 Pod를 Virtual Machine(VM) 내에 격리하여 Kubernetes 애플리케이션에 심층 방어(defense-in-depth)를 추가합니다. 이 VM 경계는 컨테이너 탈출(container escape) 시 다른 Pod가 사용하는 호스트 기반 리소스에 대한 액세스를 방지합니다. 컨테이너 탈출은 컨테이너화된 애플리케이션을 공격하고 컨테이너 외부의 리소스에 접근하는 일반적인 방법입니다.
• Amazon EKS 사용은 공동 책임 모델에 따른 책임을 변경하지 않습니다. 클러스터 보안과 거버넌스 제어의 구성을 신중히 고려해야 합니다. 애플리케이션을 격리하는 가장 안전한 방법은 항상 별도의 클러스터에서 실행하는 것입니다.
• Fargate 프로필은 VPC 보조 CIDR 블록의 서브넷 지정을 지원합니다. 보조 CIDR 블록을 지정하고 싶을 수 있습니다. 이는 서브넷에 사용 가능한 IP 주소 수가 제한되어 있기 때문입니다. 결과적으로 클러스터에 만들 수 있는 Pod 수도 제한됩니다. Pod에 다른 서브넷을 사용하면 사용 가능한 IP 주소 수를 늘릴 수 있습니다. 자세한 내용은 "VPC에 IPv4 CIDR 블록 추가"를 참고하세요.
• Amazon EC2 인스턴스 메타데이터 서비스(IMDS)는 Fargate 노드에 배포된 Pod에 사용할 수 없습니다. Fargate에 배포된 Pod 중 IAM 자격 증명이 필요한 Pod가 있다면 서비스 계정용 IAM 역할을 사용해 Pod에 할당하세요. Pod가 IMDS를 통해 제공되는 다른 정보에 액세스해야 한다면 이 정보를 Pod 사양에 하드 코딩해야 합니다. 여기에는 Pod가 배포된 AWS 리전이나 가용 영역이 포함됩니다.
• Fargate Pod는 AWS Outposts, AWS Wavelength 또는 AWS Local Zones에 배포할 수 없습니다.
• Amazon EKS는 Fargate Pod를 안전하게 유지하기 위해 주기적으로 패치해야 합니다. 영향을 줄이는 방식으로 업데이트를 시도하지만, Pod가 성공적으로 축출되지 않으면 삭제해야 하는 경우가 있습니다. 중단을 최소화하기 위해 취할 수 있는 몇 가지 조치가 있습니다. 자세한 내용은 "AWS Fargate OS 패치 이벤트에 대한 작업 설정"을 참고하세요.
• Amazon VPC CNI plugin for Amazon EKS가 Fargate 노드에 설치됩니다. Fargate 노드가 있는 Amazon EKS 클러스터에는 대체 CNI 플러그인을 사용할 수 없습니다.
• Fargate에서 실행되는 Pod는 수동 드라이버 설치 단계 없이 Amazon EFS 파일 시스템을 자동으로 마운트합니다. Fargate 노드에서는 동적 영구 볼륨 프로비저닝을 사용할 수 없지만, 정적 프로비저닝은 사용할 수 있습니다.
• Amazon EKS는 Fargate Spot을 지원하지 않습니다.
• Fargate Pod에 Amazon EBS 볼륨을 마운트할 수 없습니다.
• Fargate 노드에서 Amazon EBS CSI 컨트롤러를 실행할 수 있지만, Amazon EBS CSI 노드 DaemonSet은 Amazon EC2 인스턴스에서만 실행할 수 있습니다.
• 버전 롤백: Fargate 워커 노드에 대해서는 버전 롤백이 지원되지 않습니다. Fargate를 사용하는 클러스터의 컨트롤 플레인은 롤백할 수 있지만, 컨트롤 플레인과 같은 Kubernetes 버전을 실행하는 Fargate Pod는 ERROR 상태의 kubelet 버전 불일치 통찰력(insight)을 트리거합니다. 컨트롤 플레인 버전과 일치하는 부 버전의 Fargate Pod가 있다면 롤백하기 전에 해당 Pod를 삭제하세요. 그런 다음 컨트롤 플레인을 롤백하세요. 재배포 시 남은 어떤 Pod든 롤백된 버전으로 실행됩니다. 또는 --force를 사용해 통찰력 검사를 우회할 수 있지만, kubelet 버전 불일치 위반으로 진행하면 예상치 못한 동작이 발생할 수 있습니다. 자세한 내용은 "클러스터를 이전 Kubernetes 버전으로 롤백"을 참고하세요.
• Kubernetes Job이 Completed 또는 Failed로 표시된 후 Job이 만드는 Pod는 일반적으로 계속 존재합니다. 이 동작을 통해 로그와 결과를 볼 수 있지만, Fargate에서는 이후 Job을 정리하지 않으면 비용이 발생합니다.
• Job이 완료 또는 실패한 후 관련 Pod를 자동으로 삭제하려면 TTL(time-to-live) 컨트롤러를 사용해 기간을 지정할 수 있습니다. 다음 예제는 Job 매니페스트에 .spec.ttlSecondsAfterFinished를 지정하는 것을 보여줍니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh", "-c", "sleep 10"]
      restartPolicy: Never
  ttlSecondsAfterFinished: 60 #

더 알아보기 (Learn more)

• 공식 문서