Kubernetes-Masterclass | Fargate & NLB & ECR

김주혁

Sep 09, 2024

Contents

Fargate NLB ECR

Fargate Fargate 고려사항:Fargate 생성 NLB 탄력적 IP 기반 NLB 배포 ECR

Fargate

Fargate 개념: Fargate는 AWS의 서버리스 컨테이너 실행 플랫폼입니다. Kubernetes의 확장 모델을 사용하여 AWS에서 관리되는 Fargate 컨트롤러가 EKS에서 포드를 스케줄링합니다.

Fargate는 필요에 따라 적절한 크기의 컴퓨팅 용량을 컨테이너에 제공해줍니다.
EKS는 K8s를 Fargate와 통합하여 AWS에 제공하는 업스트림 확장 모델을 사용하여 구축된 컨트롤러를 통해 이 작업을 수행합니다.

이 컨트롤러는 EKS의 Control Plane의 일부로 실행되며 K8s 포드를 Fargate에 스케줄링하는 책임을 집니다.
Fargate 컨트롤러에는 기본 k8s 스케줄러와 함께 실행되는 새로운 스케줄러뿐만 아니라 여러 변형 및 validating admission controller가 포함되 있습니다.
여기서 핵심은 k8s에서 제공하는 업스트림 확장 모델을 사영하여 eks control plane 내에서 fargate 컨트롤러가 존재하며 이 컨트롤러가 fargate에 포드를 스케줄링 한다는 점 입니다.

fargate는 서버에 접근할 수 없고 aws가 자동으로 인스턴스를 관리합니다.

기존 포드와 호환: 기존 Kubernetes 워크플로우 및 서비스를 수정 없이 Fargate에 배포할 수 있습니다. 다만, Fargate 사용 시 여러 제약 사항을 고려해야 합니다.

고가용성 및 격리 환경: Fargate 포드는 고가용성을 위해 격리된 EC2 인스턴스에서 실행되며, 한 포드는 하나의 Fargate 인스턴스를 생성합니다.

비용: 필요한 자원만큼만 사용하고 비용을 지불합니다. Fargate는 AWS 네트워킹 및 보안 통합을 제공하며, 보안이 강화됩니다.

Fargate에서는 한 포드당 하나의 fargate ec2 인스턴스가 생성되며 이를 통해 멀티테넌시 환경에서 특정 클라이언트에게 포드별로 요금을 부과할 수 있습니다.
fargate에는 관리형 노드 및 비관리형 노드와 달리 호스트에 대한 가시성이 없으며 파드만 신경쓰면 됩니다.

배포 옵션: Fargate는 관리형 EC2 노드 그룹 또는 Fargate만을 사용하는 혼합형 배포가 가능합니다. Fargate는 프라이빗 서브넷에서만 실행되며, 관리형 및 비관리형 노드 그룹과 차별화된 관리 방식을 가집니다.

Fargate 고려사항:

Fargate는 GPU, 데몬셋, 상태 저장 애플리케이션을 지원하지 않으며, 프라이빗 서브넷에서만 실행이 가능합니다.

fargate에서 실행되는 파드는 stateful한 application에 적합하지 않습니다.

중요 사항: Fargate 프로필은 프라이빗 서브넷에만 생성할 수 있으며, 퍼블릭 서브넷에는 배포할 수 없습니다.

Fargate 생성


# Get list of Fargate Profiles in a cluster
eksctl get fargateprofile --cluster eksdemo

# Template
eksctl create fargateprofile --cluster <cluster_name> \
                             --name <fargate_profile_name> \
                             --namespace <kubernetes_namespace>


# Replace values
eksctl create fargateprofile --cluster eksdemo \
                             --name fp-demo \
                             --namespace fp-dev

Fargate 프로필 생성:

EKSCTL create fargateprofile 명령어를 사용하여 클러스터 이름과 네임스페이스를 입력해 Fargate 프로필을 생성합니다.
네임스페이스는 필수 요소이며, 해당 네임스페이스로 배포된 애플리케이션의 파드는 자동으로 Fargate 프로필에 할당됩니다.

Fargate 파드 실행 역할:

클러스터에서 Fargate 프로필을 처음 생성할 때, Fargate 파드 실행 역할도 자동으로 생성됩니다.

배포 매니페스트 검토:

NGINX 애플리케이션을 Fargate 환경에서 배포하기 위해 인그레스 로드 밸런서를 사용합니다.
Fargate 파드는 프라이빗 서브넷에서 실행되기 때문에 노드포트 서비스를 사용할 수 없습니다. 대신 IP 타겟 유형을 사용해야 합니다.
Fargate 파드는 알 수 없는 임의의 워커 노드에서 생성되기 때문에 노드포트 서비스를 생성할 수 없습니다.
target type은 ip입니다.


alb.ingress.kubernetes.io/target-type: ip

리소스 요청과 제한:

Fargate 파드는 1:1 비율로 실행되므로, 파드의 CPU 및 메모리 자원을 명시하는 것이 중요합니다. 이를 설정하지 않으면 저메모리 애플리케이션은 문제가 없지만, 고메모리 애플리케이션은 재시작될 수 있습니다.

DNS 설정:

네임스페이스 매니페스트와 인그레스 매니페스트에서 FP Dev.kubancloud.com 같은 DNS 이름을 설정합니다.

NLB

Network Load Balancer 개요:

OSI 모델의 4계층에서 동작하며, TCP, UDP, TLS 프로토콜을 지원합니다.
Application Load Balancer와 달리 7계층 관련 기능은 지원하지 않으며, 여러 네임스페이스 간 로드 밸런싱은 지원하지 않습니다.

AWS Load Balancer Controller:

AWS 에서는 Application Load Balancer, Network Load Balancer, Gateway Load Balancer, Classic Load Balancer를 제공합니다.

이 중에서 Application Load Balancer는 7계층을 지원하며,
Network Load Balancer는 4계층을 지원합니다.
Gateway Load Balancer는 3계층 게이트웨이와 4계층 로드 밸런서를 지원하고,
Classic Load Balancer는 4계층과 7계층을 지원합니다

최신 AWS Load Balancer Controller를 사용하면 최신 ELB와 NLB를 생성할 수 있습니다.
구식 AWS 클라우드 제공자 로드 밸런서 컨트롤러는 기본적인 기능만 제공하며, 더 이상 사용되지 않을 수 있습니다.

AWS Cloud Provider Load Balancer Controller	AWS Load Balancer Controller
AWS Classic LB and Network LB를 만들 수 있는 Legacy Controller	최신의 AWS ALB와 NLB를 생성합니다.
아주 기본적인 Network Load Balancer를 생성합니다.	TCP, UDP & TLS (SSL) and Health Check 를 지원하고, TCP, HTTP & HTTPS도 지원합니다.
이 컨트롤러는 단지 치명적인 버그 수정만 수정될 것이며, 향후 사용하지 않게 될 것입니다.	instance , IP mode를 지원합니다.(For Fagate
이 컨트롤러는 추가적인 새로운 기능이 추가되지 않을 것 입니다.	Internal, External NLB and Custom Subnet Discovery를 지원합니다.
ㅤ	Static Elastic IP와 Access Control을 지원합니다.
ㅤ	25개 이상의 새로운 annotations을 지원합니다.

설정 방법:

Kubernetes 서비스 매니페스트에서 type을 LoadBalancer, load balancer type을 external로 설정합니다.
Fargate 작업을 위한 IP 모드와 인스턴스 모드가 지원됩니다.
Network Load Balancer는 내부 및 외부 로드 밸런서를 지원하며, 사용자 정의 서브넷, 정적 IP, 액세스 제어 기능도 제공합니다.
AWS Load Balancer Controller에서 Kubernetes 서비스의 주석(annotation) 값이 nlb-ip 또는 external로 설정된 경우, 해당 서비스는 외부 로드 밸런서에 의해 관리됩니다. 이 경우, AWS Load Balancer Controller는 Kubernetes 서비스의 설정을 무시하고, 대신 NLB(Network Load Balancer)를 생성하여 트래픽을 처리합니다. 이렇게 설정하는 이유는 AWS의 네트워크 로드 밸런서를 사용하여 IP 주소를 직접 노출하거나, 특정 요구 사항에 맞게 외부 서비스를 설정할 수 있기 때문입니다. 따라서, 이러한 주석이 있을 경우 Kubernetes의 기본 로드 밸런서 매니저는 해당 서비스에 대해 아무런 작업을 수행하지 않습니다.
EKS(Elastic Kubernetes Service) 클러스터의 버전 1.18.18+, 1.19.10+ 및 1.20 이상은 AWS에서 지원됩니다. 각 버전은 보안 및 성능 향상을 위해 정기적으로 업데이트되며, 최신 버전으로 유지하는 것이 권장됩니다.

설정 및 배포:

AWS EKS 클러스터를 생성하고, AWS Load Balancer Controller를 설치하여 Network Load Balancer를 설정합니다.
NGINX 애플리케이션을 배포하고, Kubernetes 서비스 매니페스트를 사용하여 Network Load Balancer를 생성합니다.

탄력적 IP 기반 NLB 배포

탄력적 IP 생성: 퍼블릭 서브넷에서 사용할 EIP 2개를 생성합니다.

💡

탄력적 IP 란? 탄력적 IP(Elastic IP)는 AWS에서 제공하는 고정 IP 주소로, EC2 인스턴스나 다른 리소스에 할당하여 사용할 수 있습니다. 주요 특징은 다음과 같습니다:

고정성: 탄력적 IP는 특정 리소스에 할당되지 않고, 필요에 따라 다른 인스턴스에 재할당할 수 있습니다. 이로 인해 인스턴스가 중지되거나 종료되더라도 IP 주소를 유지할 수 있습니다.유연성: 인스턴스의 장애나 변경에 따라 IP 주소를 쉽게 이동할 수 있어, 서비스의 가용성을 높이는 데 유용합니다.비용: 탄력적 IP를 사용하지 않을 경우, 요금이 발생할 수 있으므로 주의가 필요합니다. 사용 중인 인스턴스에만 요금이 부과됩니다.

탄력적 IP는 특히 서버의 IP 주소가 변경되면 안 되는 경우에 유용하게 사용됩니다.

Kubernetes 매니페스트 업데이트: 생성한 EIP의 할당 ID를 Kubernetes 로드 밸런서 서비스 매니페스트에 추가합니다.

여기서 탄력적 IP 는 콘솔에서 생성한 탄력적 IP의 할당 IP를 의미합니다.


service.beta.kubernetes.io/aws-load-balancer-eip-allocations: eipalloc-068b65c8e0df2b53e, eipalloc-022d66b51f98706c6

NLB 배포: kubectl apply -f 명령어로 NGINX 앱과 탄력적 IP가 적용된 Kubernetes 서비스를 배포합니다.

DNS 확인: nslookup 명령어로 DNS 이름이 생성된 탄력적 IP로 올바르게 매핑되었는지 확인합니다.


nslookup nlbeip201.developerlay.com
Server:         168.126.63.1
Address:        168.126.63.1#53

Non-authoritative answer:
Name:   nlbeip201.developerlay.com
Address: 43.201.238.0
Name:   nlbeip201.developerlay.com
Address: 3.37.219.129

서비스 접근: 브라우저에서 HTTP 및 HTTPS로 애플리케이션에 접속합니다.

클린업: kubectl delete -f 명령어로 배포된 리소스와 탄력적 IP를 삭제합니다.

이로써 탄력적 IP를 사용하는 네트워크 로드 밸런서 설정이 완료되었습니다.

ECR

ECR: AWS의 완전 관리형 Docker 컨테이너 레지스트리. Docker 이미지 저장, 관리 및 배포를 용이하게 하며, Elastic Kubernetes Service (EKS)와 통합되어 개발에서 배포까지의 워크플로를 간소화함.비용: 선불 요금이나 약정 없이 저장된 데이터 양과 인터넷으로의 데이터 전송량에 대해 비용 지불.

ECR 사용 방법

로컬에서 도커 이미지를 빌드하고 ECR에 푸시.
ECR의 이미지를 EKS 배포에서 가져와 사용.
ECR에 푸시된 이미지는 ECS, EKS 및 온프레미스 환경에서도 사용 가능.

ECR의 이점

완전 관리형, 보안, 고가용성, 간소화된 워크플로.

배포 프로세스

단계 1: 로컬에서 도커 이미지 빌드 후 ECR에 푸시하고, Kubernetes 배포 매니페스트에서 ECR 이미지 레포지토리 URL 업데이트.
단계 2: EKS에 배포, 이 과정에서 Kubernetes 배포, 노드 포트 서비스, 인그레스 서비스, 외부 DNS 서비스 사용.
단계 3: 인그레스 서비스를 통해 인터넷에서 접근 가능하도록 설정, ecrdemo.couponcloud.com과 같은 전용 호스트 이름 사용.

네트워크 아키텍처

AWS 클라우드에서 ECR에 푸시된 이미지를 EKS 클러스터가 NAT 게이트웨이를 통해 가져옴.
EKS 클러스터는 퍼블릭 서브넷과 NAT 게이트웨이를 통해 EC2 워커 노드와 통신하며, 프라이빗 서브넷의 관리 노드 그룹에서 노드 포트 서비스를 사용함.

접속 및 테스트

사용자는 ecrdemo.couponcloud.com URL을 통해 접근하고, Route 53을 통해 로드 밸런서 인그레스 서비스로 요청이 전달됨.
인그레스 서비스는 슬래시와 스타(/*) 경로를 설정하여 노드 포트 서비스로 요청을 자동으로 전달하고, 정적 페이지를 제공함.

ECR 용어는 레지스트리, 레포지토리, 정책, 인증, 토큰, 이미지 등을 포함합니다.

레지스트리: AWS 계정에 제공되는 ECR 레지스트리입니다. 우리는 이 레지스트리 내에 여러 개의 이미지 레포지토리를 생성할 수 있습니다.

레포지토리: ECR 이미지 레포지토리는 Docker 이미지와 레포지토리 정책을 포함합니다. 레포지토리 정책을 통해 레포지토리와 그 안의 이미지에 대한 접근을 제어할 수 있습니다. 이는 AWS IAM과 통합되어 있습니다.

인증 토큰: Docker Hub에 로그인할 때 docker login을 사용하고 사용자 이름과 비밀번호를 제공하는 것처럼, AWS ECR 레포지토리에 로그인할 때도 비슷한 절차를 따릅니다. 하지만 명령어는 다를 수 있습니다. Docker 클라이언트는 AWS 사용자로서 Amazon ECR 레지스트리에 인증된 후 이미지를 푸시하거나 풀할 수 있습니다. AWS CLI의 get-login 명령어는 Docker에 전달할 인증 자격 증명을 제공합니다.

이미지: 우리가 로컬에서 빌드한 이미지를 푸시할 수 있습니다. 이 이미지는 레지스트리 내의 레포지토리에 푸시됩니다.

ECR 레포지토리 생성


aws ecr create-repository --repository-name aws-ecr-kubenginx --region us-east-1
aws ecr create-repository --repository-name <your-repo-name> --region <your-region>

AWS Management Console에서 ECR 서비스를 검색하여 엽니다.
'Repositories'를 클릭한 후 'Create Repository'를 클릭합니다.
레포지토리 이름을 입력하고 'Tag Immutability' 및 'Scan on Push' 옵션을 활성화합니다.
'Create Repository'를 클릭하여 레포지토리를 생성합니다.

Docker 이미지 생성 및 푸시


# Build Docker Image
docker build -t <ECR-REPOSITORY-URI>:<TAG> . 
docker build -t 180789647333.dkr.ecr.us-east-1.amazonaws.com/aws-ecr-kubenginx:1.0.0 . 

# Run Docker Image locally & Test
docker run --name <name-of-container> -p 80:80 --rm -d <ECR-REPOSITORY-URI>:<TAG>
docker run --name aws-ecr-kubenginx -p 80:80 --rm -d 180789647333.dkr.ecr.us-east-1.amazonaws.com/aws-ecr-kubenginx:1.0.0

GitHub 리포지토리에서 Docker 이미지를 만들기 위한 파일을 준비합니다.
Dockerfile을 사용하여 NGINX 이미지를 기반으로 새로운 Docker 이미지를 빌드합니다.
docker build -t ECR 레포지토리:태그 . 명령어를 사용하여 이미지를 빌드합니다.
aws ecr get-login-password 명령어로 로그인 비밀번호를 얻고, docker login 명령어로 ECR에 로그인합니다.
docker push 명령어를 사용하여 이미지를 ECR에 푸시합니다.
푸시 후, ECR에서 이미지와 보안 스캔 결과를 확인합니다.