AWS Fargate

중요

Amazon EKS가 있는 AWS Fargate은 AWS GovCloud(미국 동부) 및 AWSGovCloud(미국 서부)를 제외한 모든 Amazon EKS 지역에서 사용할 수 있습니다.

이 주제에서는 AWS Fargate에서 Amazon EKS를 사용하여 Kubernetes Pods를 실행하는 방법을 설명합니다. Fargate는 컨테이너에 대한 적정 규모의 온디맨드 컴퓨팅 용량을 제공하는 기술입니다. Fargate를 사용하면 컨테이너를 실행하려면 직접 가상 머신 그룹을 프로비저닝, 구성 또는 크기를 조정할 필요가 없습니다. 따라서 서버 유형을 선택하거나, 노드 그룹을 조정할 시점을 결정하거나, 클러스터 패킹을 최적화할 필요가 없습니다.

Fargate에서 시작하는 Pods와 Fargate 프로필에서 실행되는 방법을 제어할 수 있습니다. Fargate 프로필은 Amazon EKS 클러스터의 일부로 정의됩니다. Amazon EKS에서는 Kubernetes에서 제공한 확장 가능한 업스트림 모델을 사용하여 AWS에서 빌드한 컨트롤러를 사용하여 Kubernetes를 Fargate와 통합합니다. 이러한 컨트롤러는 Amazon EKS 관리형 Kubernetes 컨트롤 플레인의 일부로 실행되며 Fargate에 기본 Kubernetes Pods를 예약하는 것을 담당합니다. Fargate 컨트롤러에는 여러 개의 변형 및 검증 승인 컨트롤러 외에도 기본 Kubernetes 스케줄러와 함께 실행되는 새 스케줄러가 포함되어 있습니다. Fargate에서 실행하기 위한 조건을 충족하는 Pod를 시작하면 클러스터에서 실행되는 Fargate 컨트롤러가 해당 Pod를 인식하고 업데이트하고 Fargate에 예약합니다.

이 주제에서는 Fargate에서 실행되는 Pods의 여러 구성 요소에 대해 설명하고 Amazon EKS에서 Fargate를 사용하기 위한 특별한 고려 사항을 살펴봅니다.

AWS Fargate 고려 사항

Amazon EKS에서 Fargate를 사용할 때 고려해야 할 몇 가지 사항이 있습니다.

Fargate에서 실행되는 각 Pod에는 자체 격리 경계가 있습니다. 기본 커널, CPU 리소스, 메모리 리소스 또는 Elastic 네트워크 인터페이스를 다른 Pod와 공유하지 않습니다.
Network Load Balancer 및 Application Load Balancer(ALB)는 IP 대상을 통해서만 Fargate에서 사용할 수 있습니다. 자세한 내용을 알아보려면 Network Load Balancer 생성 및 Amazon EKS 애플리케이션 로드 밸런싱 섹션을 참조하세요.
Fargate 노출 서비스는 노드 IP 모드가 아닌 대상 유형 IP 모드에서만 실행됩니다. 관리형 노드에서 실행 중인 서비스와 Fargate에서 실행 중인 서비스의 연결을 확인하는 권장 방법은 서비스 이름을 통해 연결하는 것입니다.
포드는 Fargate에서 실행되도록 예약된 시간에 Fargate 프로필과 일치해야 합니다. Fargate 프로필과 일치하지 않는 포드는 Pending과 같이 중단될 수 있습니다. 일치하는 Fargate 프로필이 있는 경우 사용자가 생성한 보류 중인 Pods를 삭제하여 Fargate에 다시 예약할 수 있습니다.
DaemonSets는 Fargate에서 지원되지 않습니다. 애플리케이션에 대몬이 필요한 경우 Pods에서 사이드카 컨테이너로 실행되도록 해당 대몬을 다시 구성합니다.
권한 있는 컨테이너(Privileged container)는 Fargate에서 지원되지 않습니다.
Fargate에서 실행되는 포드는 Pod 매니페스트에서 HostPort 또는 HostNetwork를 지정할 수 없습니다.
Fargate Pods의 경우 기본 nofile 및 nproc 소프트 제한은 1,024이고 하드 제한은 65,535입니다.
GPU는 현재 Fargate에서 사용할 수 없습니다.
Fargate에서 실행되는 포드는 인터넷 게이트웨이에 대한 직접 경로가 없고 AWS 서비스에 대한 NAT 게이트웨이 액세스 권한이 있는 프라이빗 서브넷에서만 지원되므로 클러스터의 VPC에 프라이빗 서브넷이 있어야 합니다. 아웃바운드 인터넷 액세스가 없는 클러스터의 경우 프라이빗 클러스터 요구 사항을 참조하십시오.
Vertical Pod Autoscaler를 사용하여 Fargate Pods의 올바른 초기 CPU 및 메모리 크기를 설정한 다음 Horizontal Pod Autoscaler를 사용하여 해당 Pods를 조정할 수 있습니다. Vertical Pod Autoscaler가 더 큰 CPU 및 메모리 조합으로 Pods를 Fargate에 자동으로 다시 배포하도록 하려면 Vertical Pod Autoscaler의 모드를 Auto 또는 Recreate로 설정하여 올바로 작동하게 해야 합니다. 자세한 내용은 GitHub에서 Vertical Pod Autoscaler 설명서를 참조하세요.
VPC에 대해 DNS 확인 및 DNS 호스트 이름을 활성화해야 합니다. 자세한 내용은 VPC에 대한 DNS 지원 보기 및 업데이트를 참조하십시오.
Amazon EKS Fargate는 가상 머신(VM) 내에서 각 포드를 격리하여 Kubernetes 애플리케이션에 대한 심층 방어 기능을 추가합니다. 이 VM 경계를 통해 컨테이너 이스케이프 시 다른 포드에서 사용하는 호스트 기반 리소스에 대한 액세스를 방지하는데, 이 방법은 컨테이너화된 애플리케이션을 공격하고 컨테이너 외부의 리소스에 대한 액세스 권한을 얻는 일반적인 방법입니다.

Amazon EKS를 사용해도 공동 책임 모델에서 책임은 변경되지 않습니다. 클러스터 보안 및 거버넌스 제어의 구성을 신중하게 고려해야 합니다. 애플리케이션을 격리하는 가장 안전한 방법은 항상 별도의 클러스터에서 실행하는 것입니다.
Fargate 프로필은 VPC 보조 CIDR 블록의 서브넷 지정을 지원합니다. 보조 CIDR 블록을 지정할 수도 있습니다. 서브넷에서 사용 가능한 IP 주소의 수는 제한되어 있기 때문입니다. 따라서 클러스터에서 생성할 수 있는 Pods의 수가 제한되어 있습니다. Pods에 다른 서브넷을 사용하여 사용 가능한 IP 주소의 수를 늘릴 수 있습니다. 자세한 내용을 알아보려면 VPC에 IPv4 CIDR 블록 추가를 참조하세요.
Amazon EC2 인스턴스 메타데이터 서비스(IMDS)는 Fargate 노드에 배포된 Pods에는 사용할 수 없습니다. IAM 자격 증명이 필요한 Pods를 Fargate에 배포한 경우 서비스 계정에 대한 IAM 역할을 사용하여 Pods에 할당합니다. Pods가 IMDS를 통해 제공되는 다른 정보에 액세스해야 할 경우 이 정보를 Pod 사양에 하드 코딩해야 합니다. 여기에는 Pod가 배포된 AWS 리전 또는 가용 영역이 포함됩니다.
Fargate Pods은(는) AWS Outposts, AWS Wavelength 또는 AWS 로컬 영역에 배포할 수 없습니다.
Amazon EKS는 정기적으로 Fargate Pods를 패치하여 보안을 유지해야 합니다. 영향을 줄이는 방식으로 업데이트를 시도하지만 Pods가 성공적으로 제거되지 않으면 삭제해야 하는 경우가 있습니다. 중단을 최소화하기 위해 취할 수 있는 몇 가지 조치가 있습니다. 자세한 내용은 Fargate OS 패치 단원을 참조하십시오.
Amazon EKS용 Amazon VPC CNI 플러그인은 Fargate 노드에 설치됩니다. Fargate 노드에서는 호환 가능한 대체 CNI 플러그 인을 사용할 수 없습니다.
Fargate에서 실행되는 Pod은(는) Amazon EFS 파일 시스템을 자동으로 탑재합니다. Fargate 노드에는 동적 영구 볼륨 프로비저닝을 사용할 수 없지만 고정적인 프로비저닝은 사용할 수 있습니다.
Amazon EBS 볼륨을 Fargate Pods에 탑재할 수 없습니다.
Amazon EBS CSI 컨트롤러는 Fargate 노드에서 실행할 수 있지만 Amazon EBS CSI 노드 DaemonSet은(는) Amazon EC2 인스턴스에서만 실행할 수 있습니다.
Kubernetes Job이 Completed 또는 Failed로 표시된 후에도 Job이 생성하는 Pods는 정상적으로 계속 존재합니다. 이 동작을 통해 로그와 결과를 볼 수 있지만 Fargate를 사용하는 경우 나중에 Job을 정리하지 않으면 비용이 발생합니다.

Job이 완료되거나 실패한 후 관련 Pods를 자동으로 삭제하려면 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 # <-- TTL controller
```

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

기존 노드 그룹 업데이트

Fargate로 시작