[AEWS 3기] 12주차 - Amazon VPC Lattice for Amazon EKS

1. Kubernetes의 애플리케이션 네트워킹 변화 과정

Kubernetes의 네트워킹 스택은 마이크로서비스 아키텍처의 발전과 함께 진화해왔습니다.

 

첫 시작 : 한 개의 Kubernetes 클러스터를 사용할 때

 

1. 단일 클러스터 내부에 배포되는 Kubernetes 서비스들은 클러스터 내부의 DNS 인 CoreDNS 및 Ingress 리소스를 통해서 내부 서비스 간 통신 및 외부로의 통신을 모두 네이티브하게 구현할 수 있음.
2. 사용되는 방법들
   • 경로 기반 라우팅으로 서비스 구조화 및 관리 개선
   • SSL/TLS 종단점 제공을 통한 보안 강화
• 기본 Service 리소스로 시작
• NodePort, ClusterIP, LoadBalancer 타입의 서비스 구현
• Ingress 활용
• 단순한 내부 통신과 외부 노출 기능에 중점

 

워크로드의 진화 : 여러 개의 Kubernetes 클러스터를 사용할 때

 

 

1. 애플리케이션이 진화하고, 조직이 발전하면서 서비스들이 독자적인 VPC 및 Kubernetes 클러스터에 운영되기 시작하면서 클러스터 운영자들은 이런 VPC 간 / 클러스터 간의 애플리케이션 네트워킹에 대해서 고민하게 됨.
   • Service Discovery
   • 서비스의 IP 주소 및 포트 정보를 동적으로 관리
   • 각 서비스 인스턴스를 지속적으로 Health Check
   • 서비스 관련 메타데이터와 구성 정보를 저장하고 관리
   • Service Discovery 패턴
     • 클라이언트가 직접 서비스 레지스트리를 쿼리하여 서비스 위치를 찾는 방식(예: Netflix Eureka, Spring Cloud)
   • 클라이언트 사이드
• 애플리케이션 끼리 통신을 하기 위해선 가장 먼저 내가 통신하고 싶은 서비스 혹은 마이크로 서비스가 어디에 있는지를 아는 것이 선행 되어야 함 → Service Discovery

 

• 서버 사이드
• 로드 밸런서가 서비스 레지스트리를 쿼리하고 클라이언트 요청을 적절한 서비스로 라우팅

 

• 두 개 이상의 여러 VPC 사이에서는?
• AWS의 경우에는 VPC Peering, PrivateLink, AWS Transit Gateway 등의 다양한 옵션을 통해 각 VPC를 연결

 

• 마이크로 서비스가 늘어나면서 네트워크 복잡성 증가 및 공통 기능 적용(서킷브레이커, 재시도 로직, 타임아웃, 인증 등)의 요구사항 이 생김 → Service Mesh
  • AWS AppMesh, Istio, Linkerd 등으로 트래픽 관리, 보안, 관찰성 강화
  • 마이크로서비스 간 통신의 복잡성 추상화
  • 서비스 디스커버리와 로드밸런싱의 고도화 및 자동화 (서비스 메시는 서비스 디스커버리를 기반으로 함)
  • 컨테이너 애플리케이션 앞에 AWS AppMesh, Istio, Linkerd 등의 사이드카 프록시 컨테이너를 배치
• Service Mesh
• 동작 원리

 

• 컨테이너 애플리케이션으로 들어오고 나가는 모든 트래픽은 프록시 컨테이너를 통해 라우팅 되는 방식
• 프록시 컨테이너의 역할
  • 사이드카가 요청을 가로챔 → 요청을 별도의 네트워크 연결로 캡슐화 → 소스 프록시와 대상 프록시 간에 안전하고 암호화된 채널을 설정
  • 서비스 간 로우 레벨 메시징을 처리
  • 서킷 브레이킹, 요청 재시도와 같은 기능을 구현하여 복원력을 높이고 서비스 성능 저하를 방지
  • 메시 내의 모든 서비스를 추적하는 서비스 레지스트리 기능 수행
  • 신규 서비스 자동 검색 기능 및 비활성 서비스 제거 기능 수행
  • 지표, 로그, 분산 추적 정보와 같은 텔레메트리 데이터의 수집 및 집계
• 데이터 영역
• 제어 영역

 

‣

이러한 방식의 애플리케이션 네트워킹의 한계점

Ingress와 Service Discovery, Service Mesh는 Kubernetes에서 트래픽 라우팅을 관리하는 대표적인 방식이었지만, 다음과 같은 한계점을 가지고 있었습니다.

 

Ingress의 한계

• HTTP, HTTPS와 같은 L7 트래픽에 최적화 되어있어 gRPC 및 TPC, UDP와 같은 비 L7 프로토콜에 대한 라우팅 기능이 제한적이었습니다.
• 고급 기능(인증, 속도 제한 정책, 고급 트래픽 관리 등)을 사용하려면 벤더별(AWS, NGINX, HAProxy 등) 사용자 정의 어노테이션이 필요하여 이식성과 표준화에 한계가 존재했습니다.

 

Service Mesh의 한계

• 주로 동-서 트래픽(서비스 간 내부 통신)에 초점을 맞추어 설계되어 북-남 트래픽(외부-내부 통신)에 대한 기능이 제한적이였습니다.
• Amazon EKS의 경우, VPC Peering 및 TGW가 필요 → 점점 늘어나는 설정들과 네트워크 리소스들
• 여러 AWS 계정을 사용할 경우, 각각 교차 계정 액세스 설정이 필요 → 권한 관리의 어려움
• 사이드카 프록시 배포가 필수적이며, 멀티 VPC 클라우드 환경에서 네트워크 복잡도가 증가하였습니다. (멀티 클러스터, 멀티 메시의 수많은 프록시 운영 및 관리의 어려움)

 

또한, 클라우드 환경에서 점차 마이크로 서비스가 확장되고 인프라 구성이 복잡해짐에 따라 아래와 같은 요구사항도 생겨났습니다.

• 다양한 팀 간의 책임 분리(인프라 담당자, 애플리케이션 개발자, DevOps 엔지니어 등)가 필요해졌습니다.
• 여러 VPC 또는 멀티 클러스터 환경에 걸친 리소스들을 일관되게 관리해야 했습니다.
• 다양한 컴퓨팅 형태(인스턴스, 컨테이너, 서버리스 등)를 통합적으로 관리할 수 있는 네트워킹 레이어가 필요했습니다.

 

2. Gateway API의 등장

이러한 한계를 극복하기 위해 SIG-NETWORK 커뮤니티에서 Gateway API가 고안되었습니다. Gateway API는 다음과 같은 목표를 가지고 설계되었습니다.

1. 역할 기반 설계: 인프라 관리자, 클러스터 운영자, 애플리케이션 개발자 각각의 요구사항을 반영할 수 있도록 설계되었습니다.
2. 범용성: HTTP, HTTPS, gRPC 등 다양한 프로토콜을 지원하고 확장성 있게 설계되었습니다.
3. 표준화: Kubernetes Ingress와 같이 포터블한 표준 API가 되도록 설계되었습니다.
4. 확장성: 멀티 클러스터 환경 및 다양한 VPC 간의 원활한 네트워크 통합이 가능하도록 설계되었습니다.

 

‣

2.1. Gateway API의 주요 구성요소

Gateway API는 계층적 구조로 설계되어 인프라 관리자와 애플리케이션 개발자의 역할과 책임을 명확히 구분합니다. 주요 구성 요소는 다음과 같습니다.

 

GatewayClass

• 공통 구성을 가진 게이트웨이 집합을 정의하며, 이 클래스를 구현하는 컨트롤러에 의해 관리됩니다.
• 게이트웨이는 각기 다른 컨트롤러에 의해 다양한 구성으로 구현될 수 있습니다. 게이트웨이는 반드시 해당 클래스를 구현하는 컨트롤러의 이름을 포함하는 GatewayClass를 참조해야 합니다.

 

Gateway

• 외부 트래픽을 수신하고 내부 서비스로 라우팅하는 진입점을 정의합니다.
• 하나 이상의 Route 리소스와 연결될 수 있습니다.

 

Routes

• 트래픽을 특정 서비스로 매핑하는 프로토콜 별 규칙을 정의합니다.
• HTTPRoute, TLSRoute, TCPRoute, UDPRoute, GRPCRoute 등이 있습니다.
• Gateway 리소스에 연결되어 트래픽을 대상 서비스로 전달합니다.

 

이러한 구성 요소의 관계를 도식화하면 다음과 같습니다.

 

이 계층적 구조를 통해 인프라 관리자는 GatewayClass와 Gateway를 관리하며 전체 인프라의 일관성을 유지하고, 애플리케이션 개발자는 다양한 Route를 통해 자신의 애플리케이션에 대한 세부 라우팅 규칙을 독립적으로 정의할 수 있습니다.

AWS는 이러한 계층적 구조를 Amazon VPC Lattice와 통합하여 제공함으로써, 클라우드 네이티브 환경에서의 네트워킹 요구사항을 효과적으로 충족시킵니다.

‣

2.2. Gateway API Controller

Gateway API도 다른 Kubernetes 컴포넌트와 마찬가지로 Controller를 통해 동작합니다. 여러 벤더 별 Gateway API Controller 구현체를 참조하고 싶다면 여기를 확인해보세요. AWS에서는 AWS Gateway API Controller를 제공하고 있습니다.

 

3. Amazon VPC Lattice란

 

Amazon VPC Lattice 는 AWS에서 제공하는 완전관리형 애플리케이션 네트워킹 서비스로, 다양한 컴퓨팅 환경에서 애플리케이션 서비스를 연결, 보호 및 모니터링하는 통합 솔루션입니다. VPC Lattice는 단일 VPC 내에서는 물론, 계정 간 여러 VPC에 걸쳐 서비스를 연결하는 데 활용할 수 있습니다.

Amazon VPC Lattic란 무엇입니까? - Amazon VPC Lattice

 

 

현대적 애플리케이션은 마이크로서비스 아키텍처를 통해 여러 개의 소규모 모듈형 서비스로 분할되어 개발되는 추세입니다. 이러한 접근 방식은 개발 속도와 확장성 측면에서 많은 이점을 제공하지만, 다양한 마이크로서비스 간의 효율적인 연결과 관리에 대한 새로운 네트워킹 문제를 야기합니다. Amazon VPC Lattice는 이러한 과제를 해결하기 위해 네트워크 액세스, 트래픽 관리, 모니터링에 대한 일관된 정책을 정의하여 EC2 인스턴스, EKS 컨테이너, Lambda 서버리스 함수 등 다양한 컴퓨팅 서비스 간에 간단하고 표준화된 연결 방식을 제공합니다.

 

‣

3.1. Amazon VPC Lattice 주요 구성 요소

 

Amazon VPC Lattice는 Service, Service Network, Auth Policy, Service Directory의 네 가지 핵심 구성 요소로 이루어져 있습니다. 각 구성 요소의 특징과 역할을 살펴보겠습니다. 자세한 내용은 이 문서를 참조해주세요.

 

Service

Service는 특정 작업이나 기능을 수행하는 독립적으로 배포가능한 소프트웨어 단위입니다. 이는 어떤 Amazon Virtual Private Cloud(VPC)나 계정에도 존재할 수 있으며, 다양한 유형의 컴퓨팅 환경(가상머신, 컨테이너, 서버리스 함수)에서 실행할 수 있습니다. 서비스 구성은 다음과 같은 요소로 이루어집니다.

• 리스너 : 리스너에서는 Service가 트래픽을 받아들일 포트와 프로포콜을 정의합니다. 지원되는 프로토콜은 HTTP/1.1, HTTP/2, gRPC이며, TLS가 활성화된 Service의 경우 HTTPS도 포함됩니다.
• 규칙 : 리스너의 기본 구성 요소로, 요청을 대상 그룹의 대상들로 전달합니다. 각 규칙은 우선 순위, 하나 이상의 작업, 그리고 리스너가 클라이언트 요청을 라우팅하는 기준이 되는 하나 이상의 조건으로 구성됩니다.
• 대상 그룹 : 애플리케이션이나 서비스를 실행하는 리소스들의 집합으로, 이를 대상 이라고도 합니다. 대상은 EC2 인스턴스, IP주소, Lambda 함수, 또는 Kubernetes Pod가 될 수 있습니다.

 

Service는 다음과 같은 특징을 갖습니다.

• 고유한 VPC Lattice 도메인 네임 제공
• 리스너를 통해 들어오는 연결 처리
• 특정 경로나 헤더 값에 기반한 라우팅 규칙 정의
• EC2, ECS, Lambda 등 다양한 AWS 컴퓨팅 서비스를 대상으로 설정 가능
• 상태 확인을 통한 트래픽 안정성 보장

 

Service Network

Service Network는 VPC Lattice의 핵심 구성 요소로, 여러 서비스를 논리적으로 그룹화하고 이들 간의 통신을 관리합니다. 하나 이상의 VPC를 Service Network에 연결하여 해당 네트워크 내의 서비스 간 통신을 가능하게 합니다.

 

Service Network의 주요 특징은 다음과 같습니다.

• 여러 VPC와 서비스를 단일 네트워크로 통합
• 계정 간, 리전 간 서비스 연결 지원
• 중앙 집중식 액세스 제어 및 모니터링 제공
• VPC 연결을 통한 Service Network 내 서비스에 대한 접근 관리

 

Auth Policy

Auth Policy는 VPC Lattice 서비스에 대한 액세스를 제어하는 IAM 기반 정책입니다. 이를 통해 특정 IAM 보안 주체나 역할이 서비스에 접근할 수 있는지 여부를 세밀하게 제어할 수 있습니다.

 

Auth Policy의 주요 기능은 다음과 같습니다.

• IAM 기반의 세분화된 접근 제어
• 서비스 레벨 또는 서비스 네트워크 레벨에서 적용 가능
• HTTP 메소드, 경로, 헤더 등을 기준으로 조건부 액세스 규칙 설정
• AWS 리소스 간의 안전한 통신 보장

 

Service Directory

Service Directory는 모든 VPC Lattice 서비스를 중앙에서 검색하고 관리할 수 있는 카탈로그입니다. 개발자와 운영팀이 사용 가능한 서비스를 쉽게 찾고 접근할 수 있도록 지원합니다.

 

Service Directory의 핵심 기능은 다음과 같습니다.

• 사용 가능한 모든 서비스의 중앙 집중식 카탈로그 제공
• 서비스 메타데이터 및 설명 관리
• 서비스 검색 및 필터링 기능
• 접근 가능한 서비스에 대한 가시성 제공

 

‣

3.2. Amazon VPC Lattice의 장점

• 여러 VPC, EC2 인스턴스, 컨테이너, 서버리스로 구성한 애플리케이션의 네트워크 구성을 중앙 집중화 할 수 있습니다.
• 별도의 사이드카 프록시를 구성할 필요가 없습니다. (+ 완전 관리형 서비스)
• 복잡한 네트워크 구성을 단순화 해서 쉽게 사용할 수 있습니다.
• IAM 및 SigV4를 통해 각 애플리케이션으로의 보안 구성을 손쉽게 적용 할 수 있습니다.
• CloudWatch, S3, Kinesis Data Firehose를 통해 쉽게 로깅, 트래픽 패턴 분석 등을 수행할 수 있습니다.

 

사용 사례 #1 : 단일 리전의 애플리케이션 간 연결

 

단일 AWS 리전에서 프로덕션, 개발 및 공유 서비스 애플리케이션 네트워킹을 사용하는 일반적인 엔터프라이즈 아키텍처

 

사용 사례 #2 : 온프레미스에서 AWS에 배포된 애플리케이션으로 접근하는 경우

서비스 네트워크 엔드포인트가 있는 하이브리드 인그레스 VPC를 사용하여 온프레미스에서 Prod, Dev 및 Shared 서비스의 서비스 네트워크 접근하기

 

사용 사례 #3 : 여러 AWS 리전에 걸친 애플리케이션 간의 연결

리전 간 액티브-패시브 서비스 접속 구성

 

사용 사례 #3 : 다중 계정 간 애플리케이션의 연결

다중 계정 간 네트워크 연결 구성

‣

3.3. 참고 자료

• Amazon VPC Lattice Docs : https://docs.aws.amazon.com/ko_kr/vpc-lattice/latest/ug/what-is-vpc-lattice.html
• Amazon VPC Lattice Workshop : https://catalog.workshops.aws/handsonwithvpclattice/ko-KR
• Amazon VPC Lattice VPC Lattic의 작동 방식 - Amazon VPC Lattice
• Amazon Web Services Amazon VPC Lattice 정식 출시 – 서비스 간 연결, 보안 및 모니터링 간소화 | Amazon Web Services
• Amazon Web Services Amazon VPC Lattice: 엔터프라이즈 네트워크 아키텍처의 현대화 및 단순화 | Amazon Web Services
• Amazon Web Services Application Networking with Amazon VPC Lattice and Amazon EKS | Amazon Web Services
• AWS Events AWS re:Invent 2022 - [NEW] Introducing Amazon VPC Lattice: Simplifying app networking (NET215)

 

3. AWS Gateway API Controller

AWS Gateway API Controller는 Gateway API에 의해 정의된 사용자 지정 리소스를 확장하여 Kubernetes API를 사용하여 VPC Lattice 리소스를 생성합니다. 이 Controller가 클러스터에 설치되면 Controller는 Gateway API의 리소스(Gateway 및 Route)의 생성을 감시하고 적절한 Amazon VPC Lattice 오브젝트를 프로비저닝 합니다. 이를 통해 사용자는 커스텀 코드를 작성하거나 사이드카 프록시를 관리할 필요 없이 Kubernetes API를 사용하여 VPC Lattice Service, VPC Lattice Service Network 및 Target Group을 구성할 수 있습니다.

 

AWS Gateway API Controller는 Amazon VPC Lattice와 통합되어 다음 작업을 수행할 수 있습니다.

1. VPC 및 계정 전반에 걸친 서비스 간 네트워크 연결을 원활하게 처리합니다.
2. 여러 Kubernetes 클러스터에 걸쳐 있는 VPC Lattice Service를 검색합니다.
3. 서비스 간 통신의 보안을 구성하기 위한 깊이 있는 방어 전략을 구현합니다.
4. 서비스 간 요청/응답 트래픽을 관찰합니다.

 

AWS Gateway API Controller는 오픈소스 프로젝트이며, Amazon의 완전한 지원을 받고있습니다.

 

‣

4.1. Gateway API 구성 요소와 VPC Lattice 오브젝트 간 매핑 관계

 

‣

4.2. Amazon EKS에서 VPC Lattice로 Gateway API를 사용하기 위한 요구사항

• 쿠버네티스 1.28 이상 필요: 공식 문서에서 v1.28부터 기존 Ingress가 Frozen 상태로 전환되었으며, Gateway API를 통한 현대화 아키텍처 구현이 권장
• AWS Gateway API Controller 설치: VPC Lattice 리소스와 쿠버네티스 API 객체 간 매핑을 처리하는 컨트롤러 배포 필요
• AWS Gateway API Controller 설치 및 구성 방법에 대해서는 이 문서를 참조하세요.

 

 

5. Simple Client to Server communication(실습)

💡

이번 실습에서는 Amazon EKS Blueprints for Terraform : Amazon VPC Lattice - Simple Client to Server Communication을 활용합니다.

이 패턴에서는 Terraform을 활용하여 클라이언트 애플리케이션이 한 곳에서 실행되고 서버 애플리케이션이 다른 곳에서 실행되는 두 개의 별개의 VPC를 배포합니다. 서버 애플리케이션은 EKS 클러스터 내에 배포되며 두 애플리케이션 간의 연결을 설정하는 Amazon VPC Lattice를 통해 클라이언트 애플리케이션에 노출됩니다. 또한 Amazon Route53 및 External DNS Add-on을 사용하여 노출된 서비스에 대한 사용자 지정 도메인 이름을 구성하는 방법을 보여줍니다.

 

‣

5.1. Terraform 코드 준비 및 프로비저닝

1. 아래 명령을 통해 실습용 코드를 clone 해주세요. 이 프로젝트의 디렉터리는 실습하기 편한 곳으로 설정해주세요.

git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git

2. 터미널을 통해 terraform-aws-eks-blueprints 프로젝트의 /patterns/vpc-lattice/client-server-communication 디렉터리로 이동해주세요.

cd terraform-aws-eks-blueprints/patterns/vpc-lattice/client-server-communication

3. main.tf 파일 내의 29번째 라인에서 region 값을 ap-northeast-2로 수정해주세요.

3. 아래 명령을 순차적으로 실행하여 실습 인프라를 프로비저닝 해주세요.

terraform init

Terrafrom init 수행

terraform apply -target="module.client_vpc" -auto-approve
terraform apply -target="module.cluster_vpc" -auto-approve
terraform apply -target=aws_route53_zone.primary -auto-approve

terraform apply -target="module.client_sg" -auto-approve
terraform apply -target="module.endpoint_sg" -auto-approve

terraform apply -target="module.client" -auto-approve
terraform apply -target="module.vpc_endpoints" -auto-approve

terraform apply -target="module.eks" -auto-approve
terraform apply -target="module.addons" -auto-approve

Terraform 모듈 프로비저닝

terraform apply -auto-approve

Terraform 나머지 리소스 프로비저닝

5. 모든 인프라가 프로비저닝 완료되었으면 아래 명령을 수행하여 kubectl config 설정을 완료해주세요.

aws eks update-kubeconfig --name client-server-communication --alias client-server-communication --region ap-northeast-2

6. 아래 명령을 수행하여 Amazon EKS 엔드포인트 요청이 정상적으로 수신되는지 확인해보세요.

kubectl get po -A

NAMESPACE                           NAME                                                              READY   STATUS    RESTARTS      AGE
apps                                server-6d44dd47-hhgpx                                             1/1     Running   0             3m12s
apps                                server-6d44dd47-q29nw                                             1/1     Running   0             3m12s
aws-application-networking-system   aws-gateway-api-controller-aws-gateway-controller-chart-8578sk5   1/1     Running   0             17h
aws-application-networking-system   aws-gateway-api-controller-aws-gateway-controller-chart-85glmt4   1/1     Running   0             17h
external-dns                        external-dns-555c676b8-8786s                                      1/1     Running   2 (17h ago)   17h
kube-system                         aws-node-9vpwb                                                    2/2     Running   0             17h
kube-system                         aws-node-d5zsf                                                    2/2     Running   0             17h
kube-system                         aws-node-ss42q                                                    2/2     Running   0             17h
kube-system                         coredns-586b798467-84nw4                                          1/1     Running   0             17h
kube-system                         coredns-586b798467-nx6t9                                          1/1     Running   0             17h
kube-system                         kube-proxy-c4sx2                                                  1/1     Running   0             17h
kube-system                         kube-proxy-hb2gk                                                  1/1     Running   0             17h
kube-system                         kube-proxy-sll4l                                                  1/1     Running   0             17h

 

‣

5.2. Terraform 코드 살펴보기

아래 그림과 같이 IDE를 통해, terraform-aws-eks-blueprints 디렉토리를 엽니다.

이후 페이지 왼쪽 메뉴바의 terraform-aws-eks-blueprints > patterns > vpc-lattice > client-server-communication 순서로 폴더를 엽니다.

 

‣

client.tf 살펴보기

‣

eks.tf 살펴보기

‣

lattice.tf 살펴보기

 

💡

Terraform 용어 가이드

• 모듈(module) : 재사용 가능한 Terraform 코드 블록으로, 여러 리소스를 그룹화하여 하나의 템플릿으로 관리할 수 있습니다.
• 리소스(resource) : Terraform의 핵심 구성 요소로, 실제 인프라 리소스를 생성하거나 관리합니다.
• 데이터(data) : 이미 존재하는 인프라 리소스나 다른 Terraform 코드에서 생성된 리소스 정보를 가져오는 데 사용됩니다.

 

‣

5.3. 프로비저닝 된 인프라 확인

Terraform을 통해 어떤 인프라가 구성되었는지 확인해보겠습니다.

VPC

아래 그림을 따라 VPC 콘솔 로 이동합니다.

 

그 다음, 왼쪽의 Your VPCs 메뉴를 클릭하여 VPC 목록을 확인합니다.

 

 

 

→ 내 실습환경 캡쳐화면

 

• client vpc가 10.1.0.0/16 CIDR 주소 범위로 구성되어 있습니다.
• cluster vpc가 10.0.0.0/16 CIDR 주소 범위로 구성되어 있습니다.

 

Subnets

서브넷도 함께 확인해보겠습니다. 왼쪽 메뉴의 Subnets 메뉴를 클릭하여 서브넷 목록을 확인합니다.

 

 

→ 내 실습 캡쳐 화면

 

• client vpc의 서브넷은 private subnet 3개로 구성되어 있습니다.
• cluster vpc의 서브넷은 public subnet 3개, private subnet 3개로 구성되어 있습니다.

 

구성된 워크로드 확인

이어서 테스트를 수행할 대상인 워크로드를 한번 확인해보겠습니다. 아래 그림을 따라 EC2 콘솔 로 이동합니다.

 

그 다음, 왼쪽의 Instances 메뉴를 클릭하여 EC2 목록을 확인합니다.

 

 

 

→ 내 실습 캡쳐 화면

• client 측 워크로드로 1개의 ec2 인스턴스가 구성되어 있습니다.
• cluster 측 워크로드로 3개의 ec2 인스턴스(워커 노드)가 구성되어 있습니다.

 

아래와 같이 kubectl 명령을 수행하면 EKS cluster의 워커 노드를 확인해볼 수 있습니다.

kubectl get nodes

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-21-217.ec2.internal   Ready    <none>   17h   v1.30.9-eks-5d632ec
ip-10-0-37-205.ec2.internal   Ready    <none>   17h   v1.30.9-eks-5d632ec
ip-10-0-7-174.ec2.internal    Ready    <none>   17h   v1.30.9-eks-5d632ec

 

‣

5.4. VPC Lattice를 통한 Client to Server 통신 테스트

간단한 테스트를 통해 client 워크로드에서 cluster의 워크로드로 통신이 가능한지 한번 테스트 해보겠습니다.

 

client 서버에 ssh 접속

아래 그림과 같이 client라는 이름의 EC2 인스턴스를 선택하고, 상단의 Connect 버튼을 클릭합니다.

 

그 다음, Session Manager 탭을 클릭하고, 하단의 Conenct 버튼을 클릭합니다.

 

아래와 같이 터미널 화면으로 접속되면 성공입니다.

 

 

 

→ 내 실습 캡쳐 화면

💡

Tips

AWS에서는 Systems Manager Session Manager 라는 기능을 통해 인바운드 포트를 열고 배스천 호스트를 유지 관리하거나 SSH 키를 관리할 필요 없이 IAM 기반으로 EC2 인스턴스에 안전하게 쉘에 접속할 수 있습니다.

참고 : AWS Systems Manager Session Manager를 사용하여 안전하게 인스턴스 액세스 제어하기

‣

5.5. client 애플리케이션에서 cluster 애플리케이션으로 http 요청 전송

client에서 cluster의 server pod로 요청이 잘 수행되는지 명령을 수행해보겠습니다. 이 과정에서 VPC Lattice로 구성된 서비스 네트워크를 사용해보겠습니다.

아래 그림처럼 한 쪽에는 client의 터미널을, 다른 한 쪽에는 kubectl 명령을 수행할 터미널을 준비해주세요.

 

client의 터미널에서는 아래 명령을 수행하여 네트워크 통신 테스트를 수행합니다.

curl -i http://server.example.com

HTTP/1.1 200 OK
date: Sun, 27 Apr 2025 01:56:45 GMT
content-length: 52
content-type: text/plain; charset=utf-8

Requsting to Pod(server-6d44dd47-hhgpx): server pod

 

아래 kubectl 명령을 통해 server pod의 애플리케이션 로그를 실시간으로 모니터링 하겠습니다.

kubectl logs -f deployment/server -n apps --all-containers=true --since=1m

...
71.197 map[] map[] <nil> map[] 169.254.171.197:3547 / <nil> <nil> <nil> 0xc000198e80})
2025/04/27 01:56:45 Receiving %!(EXTRA *http.Request=&{GET / HTTP/1.1 1 1 map[Accept:[*/*] User-Agent:[curl/8.3.0] X-Amzn-Lattice-Network:[SourceVpcArn=arn:aws:ec2:us-east-1:517206134011:vpc/vpc-02814df366a2fe53c] X-Amzn-Lattice-Target:[ServiceArn=arn:aws:vpc-lattice:us-east-1:517206134011:service/svc-0c7363794cfdb9bd4; ServiceNetworkArn=arn:aws:vpc-lattice:us-east-1:517206134011:servicenetwork/sn-0a9c2d300e05d3283; TargetGroupArn=arn:aws:vpc-lattice:us-east-1:517206134011:targetgroup/tg-0d49bf394bda5151b] X-Amzn-Source-Vpc:[vpc-02814df366a2fe53c] X-Forwarded-For:[10.1.5.171]] {} <nil> 0 [] false server.example.com map[] map[] <nil> map[] 169.254.171.199:17042 / <nil> <nil> <nil> 0xc000198f40})

 

결과는 아래와 같습니다.

 

동작하는 모습

 

어떻게 이런 동작이 가능한걸까요? client의 터미널에서 아래와 같이 nslookup 명령을 수행해보겠습니다.

nslookup server.example.com

Server:         10.1.0.2
Address:        10.1.0.2#53

Non-authoritative answer:
server.example.com      canonical name = server-apps-0c7363794cfdb9bd4.7d67968.vpc-lattice-svcs.us-east-1.on.aws.
Name:   server-apps-0c7363794cfdb9bd4.7d67968.vpc-lattice-svcs.us-east-1.on.aws
Address: 169.254.171.161
Name:   server-apps-0c7363794cfdb9bd4.7d67968.vpc-lattice-svcs.us-east-1.on.aws
Address: fd00:ec2:80::a9fe:aba1

dig server.example.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.13.11 <<>> server.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43377
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server.example.com.            IN      A

;; ANSWER SECTION:
server.example.com.     300     IN      CNAME   server-apps-0c7363794cfdb9bd4.7d67968.vpc-lattice-svcs.us-east-1.on.aws.
server-apps-0c7363794cfdb9bd4.7d67968.vpc-lattice-svcs.us-east-1.on.aws. 60 IN A 169.254.171.161

;; Query time: 3 msec
;; SERVER: 10.1.0.2#53(10.1.0.2)
;; WHEN: Sun Apr 27 01:57:52 UTC 2025
;; MSG SIZE  rcvd: 148

즉, Amazon VPC Lattice의 네트워크 구성을 통해서 이런 환경이 구성된 건데요, 한번 VPC Lattice의 구성된 내용을 자세히 살펴보겠습니다.

 

‣

5.6. Amazon VPC Lattice 확인

아래 그림과 같이 VPC 콘솔 로 다시 접근합니다.

 

그 다음, 왼쪽 메뉴바에서 PrivateLink and Lattice > Lattice services 를 찾아 클릭합니다.

그럼 아래와 같이 VPC Lattice Service를 조회할 수 있습니다.

 

→ 내 실습 화면 캡쳐

 

‣

5.7. Amazon VPC Lattice Target Group 확인

VPC Lattice Service의 세부 항목 중, Routing 섹션을 클릭하면 아래와 같은 Listener 규칙과 함께 대상 그룹을 확인할 수 있습니다. 대상 그룹의 세부 내용을 보기 위해서 아래 그림과 같이 Listener rules > Action > Forward to 순서로 찾아 대상 그룹을 클릭합니다.

 

→ 내 실습 화면 캡쳐

 

아래는 대상 그룹 상세 페이지 입니다. 여기의 Registered targets 섹션을 보면 IP address와 Port 번호를 통해 VPC Lattice Service로의 라우팅 대상을 안내하고 있습니다.

 

 

 

→ 내 실습 화면 캡쳐

 

아래 kubectl 명령을 수행하면, 해당 IP address와 일치하는 server pod의 IP 목록을 조회할 수 있습니다.

# 위에서 vpc lattice의 tagrget groups의 registered targets에 있는 ip list와 일치!!
kubectl get po -n apps -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE                          NOMINATED NODE   READINESS GATES
server-6d44dd47-hhgpx   1/1     Running   0          13m   10.0.32.211   ip-10-0-37-205.ec2.internal   <none>           <none>
server-6d44dd47-q29nw   1/1     Running   0          13m   10.0.11.118   ip-10-0-7-174.ec2.internal    <none>           <none>

 

이어서 아래 명령을 수행하면, server pod에서 사용하는 service의 정보 및 Port 번호를 조회할 수 있습니다.

# 위에서 vpc lattice의 tagrget groups의 registered targets에 Port와 일치!!
kubectl get svc -n apps

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
server   ClusterIP   172.20.195.132   <none>        8090/TCP   14m

이를 통해 VPC Lattice로 구성된 DNS 엔드포인트는 EKS 클러스터 내의 server pod로 라우팅 된다는 것을 알 수 있습니다.

 

‣

5.8. AWS Gateway API Controller의 동작 체크

이렇게 VPC Lattice를 통해 EKS 클러스터 내의 server pod로 라우팅 할 수 있는 환경을 구성하기 위해서는 EKS 클러스터 내에 GatewayClass, Gateway, Route 리소스를 생성해야 합니다.

AWS Gateway API Controller는 생성된 GatewayClass, Gateway, Route 리소스를 참조하여 필요한 VPC Lattice 네트워크 환경을 구성하게 됩니다.

아래 kubectl 명령을 수행하여, AWS Gateway API Controller의 로그를 lattice.log라는 파일로 저장합니다.

kubectl logs deployment/aws-gateway-api-controller-aws-gateway-controller-chart -n aws-application-networking-system --all-containers=true > lattice.log

 

그리고 아래의 vi 명령을 통해 로그를 조회하면, AWS Gateway API Controller의 동작을 확인 해볼 수 있습니다.

vi lattice.log

# reconcile 동작
{"level":"info","ts":"2025-04-27T01:49:22.781Z","logger":"controller.service","caller":"controllers/service_controller.go:76","msg":"reconcile","name":"server"}
{"level":"info","ts":"2025-04-27T01:49:22.781Z","logger":"controller.service","caller":"controllers/service_controller.go:97","msg":"reconciled","name":"server"}
{"level":"info","ts":"2025-04-27T01:49:22.798Z","logger":"controller.gateway","caller":"controllers/gateway_controller.go:122","msg":"reconcile","name":"my-services"}
{"level":"info","ts":"2025-04-27T01:49:22.798Z","logger":"controller.gateway","caller":"controllers/gateway_controller.go:152","msg":"GatewayClass is not found","name":"my-services","gwclass":"default/amazon-vpc-lattice"}
{"level":"info","ts":"2025-04-27T01:49:22.798Z","logger":"controller.gateway","caller":"controllers/gateway_controller.go:133","msg":"reconciled","name":"my-services"}
...
{"level":"info","ts":"2025-04-27T01:49:22.805Z","logger":"controller.gateway","caller":"controllers/gateway_controller.go:122","msg":"reconcile","name":"my-services"}
{"level":"info","ts":"2025-04-27T01:49:22.805Z","logger":"controller.gateway-class","caller":"controllers/gatewayclass_controller.go:59","msg":"reconcile","name":"amazon-vpc-lattice"}
{"level":"info","ts":"2025-04-27T01:49:22.816Z","logger":"controller.route","caller":"controllers/route_controller.go:152","msg":"reconcile","name":"server"}
{"level":"info","ts":"2025-04-27T01:49:22.816Z","logger":"controller.route","caller":"controllers/route_controller.go:265","msg":"Found aws-vpc-lattice for Route for server, apps"}
{"level":"info","ts":"2025-04-27T01:49:22.816Z","logger":"controller.route","caller":"controllers/route_controller.go:311","msg":"reconcile, adding or updating","name":"server"}
{"level":"debug","ts":"2025-04-27T01:49:22.816Z","logger":"runtime.events","caller":"recorder/recorder.go:104","msg":"Adding/Updating Reconcile","type":"Normal","object":{"kind":"HTTPRoute","namespace":"apps","name":"server","uid":"febc3797-a6fc-4020-9a7f-b036f6cbbaea","apiVersion":"gateway.networking.k8s.io/v1beta1","resourceVersion":"212887"},"reason":"Reconcile"}
...

# gateway 생성
{"level":"debug","ts":"2025-04-27T01:49:22.805Z","logger":"controller.gateway","caller":"eventhandlers/gatewayclass.go:59","msg":"Found matching gateway, my-services-apps"}
{"level":"info","ts":"2025-04-27T01:49:22.805Z","logger":"controller.gateway","caller":"controllers/gateway_controller.go:122","msg":"reconcile","name":"my-services"}
{"level":"info","ts":"2025-04-27T01:49:22.805Z","logger":"controller.gateway-class","caller":"controllers/gatewayclass_controller.go:59","msg":"reconcile","name":"amazon-vpc-lattice"}
{"level":"info","ts":"2025-04-27T01:49:22.816Z","logger":"controller.route","caller":"controllers/route_controller.go:152","msg":"reconcile","name":"server"}
{"level":"info","ts":"2025-04-27T01:49:22.816Z","logger":"controller.route","caller":"controllers/route_controller.go:265","msg":"Found aws-vpc-lattice for Route for server, apps"}
{"level":"info","ts":"2025-04-27T01:49:22.816Z","logger":"controller.route","caller":"controllers/route_controller.go:311","msg":"reconcile, adding or updating","name":"server"}
{"level":"debug","ts":"2025-04-27T01:49:22.816Z","logger":"runtime.events","caller":"recorder/recorder.go:104","msg":"Adding/Updating Reconcile","type":"Normal","object":{"kind":"HTTPRoute","namespace":"apps","name":"server","uid":"febc3797-a6fc-4020-9a7f-b036f6cbbaea","apiVersion":"gateway.networking.k8s.io/v1beta1","resourceVersion":"212887"},"reason":"Reconcile"}
{"level":"info","ts":"2025-04-27T01:49:22.819Z","logger":"controller.route","caller":"eventhandlers/gateway.go:52","msg":"Received Update event for Gateway my-services-apps"}
...

# route 등록
{"level":"debug","ts":"2025-04-27T01:49:22.842Z","logger":"controller.route","caller":"gateway/model_build_listener.go:26","msg":"Building Listener for Route server-apps"}
{"level":"debug","ts":"2025-04-27T01:49:22.842Z","logger":"controller.route","caller":"gateway/model_build_listener.go:113","msg":"Added listener server-apps to the stack (ID id-30e2286f178f6d12b81339b408a83399dfca872e50a93aa718b1bdc94a4891ae)"}
{"level":"debug","ts":"2025-04-27T01:49:22.842Z","logger":"controller.route","caller":"gateway/model_build_lattice_service.go:84","msg":"Building rules for 1 listeners"}
{"level":"debug","ts":"2025-04-27T01:49:22.842Z","logger":"controller.route","caller":"gateway/model_build_rule.go:35","msg":"Processing 1 rules"}
{"level":"debug","ts":"2025-04-27T01:49:22.842Z","logger":"controller.route","caller":"gateway/model_build_rule.go:47","msg":"Processing rule match"}
...

# backendRefs에 대한 targetgroup 등록
{"level":"debug","ts":"2025-04-27T01:49:22.842Z","logger":"controller.route","caller":"gateway/model_build_targetgroup.go:264","msg":"Added target group for backendRef server to the stack id-b1f433eb1062459d83ecc72bb9f59a128477f4a7a1c6d08c13722d7753d4a76d"}
{"level":"debug","ts":"2025-04-27T01:49:22.842Z","logger":"controller.route","caller":"gateway/model_build_targets.go:87","msg":"Processing targets for service server-apps"}
{"level":"debug","ts":"2025-04-27T01:49:22.843Z","logger":"controller.route","caller":"gateway/model_build_rule.go:91","msg":"Added rule 1 to the stack (ID id-cacff8032077c3ab8b8514ececd7b8a91f2d8d58fb8d09df36f5b02048b45c9a)"}
{"level":"debug","ts":"2025-04-27T01:49:22.843Z","logger":"controller.route","caller":"controllers/route_controller.go:294","msg":"stack: {\"id\":\"apps/server\",\"resources\":{\"AWS::VPCServiceNetwork::Listener\":{\"id-30e2286f178f6d12b81339b408a83399dfca872e50a93aa718b1bdc94a4891ae\":{\"spec\":{\"stackserviceid\":\"server-apps\",\"k8sroutename\":\"server\",\"k8sroutenamespace\":\"apps\",\"port\":80,\"protocol\":\"HTTP\"}}},\"AWS::VPCServiceNetwork::Rule\":{\"id-cacff8032077c3ab8b8514ececd7b8a91f2d8d58fb8d09df36f5b02048b45c9a\":{\"spec\":{\"stacklistenerid\":\"id-30e2286f178f6d12b81339b408a83399dfca872e50a93aa718b1bdc94a4891ae\",\"pathmatchvalue\":\"/\",\"pathmatchexact\":false,\"pathmatchprefix\":true,\"matchedheaders\":null,\"method\":\"\",\"priority\":1,\"action\":{\"ruletarget\":[{\"stacktargetgroupid\":\"id-b1f433eb1062459d83ecc72bb9f59a128477f4a7a1c6d08c13722d7753d4a76d\",\"svcimporttg\":null,\"latticetgid\":\"\",\"weight\":1}]},\"createtime\":\"2025-04-27T01:49:22.843116705Z\"}}},\"AWS::VPCServiceNetwork::Service\":{\"server-apps\":{\"spec\":{\"RouteName\":\"server\",\"RouteNamespace\":\"apps\",\"RouteType\":\"http\",\"servicenetworkhnames\":[\"my-services\"],\"customerdomainname\":\"server.example.com\",\"customercertarn\":\"\"},\"isdeleted\":false}},\"AWS:VPCServiceNetwork::TargetGroup\":{\"id-b1f433eb1062459d83ecc72bb9f59a128477f4a7a1c6d08c13722d7753d4a76d\":{\"spec\":{\"vpcid\":\"vpc-0354d26b8b07b7db5\",\"type\":\"IP\",\"port\":80,\"protocol\":\"HTTP\",\"protocolversion\":\"HTTP1\",\"ipaddresstype\":\"IPV4\",\"healthcheckconfig\":null,\"k8sclustername\":\"client-server-communication\",\"k8ssourcetype\":\"HTTPRoute\",\"k8sservicename\":\"server\",\"k8sservicenamespace\":\"apps\",\"k8sroutename\":\"server\",\"k8sroutenamespace\":\"apps\",\"k8sprotocolversion\":\"HTTP1\"},\"isdeleted\":false}},\"AWS:VPCServiceNetwork::Targets\":{\"id-b617a531446235a189f2738e8cd9e6603752ac4ad5031d9eb5400f33d0c67d62\":{\"spec\":{\"stacktargetgroupid\":\"id-b1f433eb1062459d83ecc72bb9f59a128477f4a7a1c6d08c13722d7753d4a76d\",\"targetlist\":null}}}}}"}
...
{"level":"debug","ts":"2025-04-27T01:49:22.965Z","logger":"cloud","caller":"aws/cloud.go:65","msg":"response","serviceName":"tagging","operation":"GetResources","params":"{\n  ResourceTypeFilters: [\"vpc-lattice:targetgroup\"],\n  TagFilters: [\n    {\n      Key: \"application-networking.k8s.aws/ClusterName\",\n      Values: [\"client-server-communication\"]\n    },\n    {\n      Key: \"application-networking.k8s.aws/ServiceName\",\n      Values: [\"server\"]\n    },\n    {\n      Key: \"application-networking.k8s.aws/ServiceNamespace\",\n      Values: [\"apps\"]\n    },\n    {\n      Key: \"application-networking.k8s.aws/SourceTypeKey\",\n      Values: [\"HTTPRoute\"]\n    },\n    {\n      Key: \"application-networking.k8s.aws/ProtocolVersion\",\n      Values: [\"HTTP1\"]\n    },\n    {\n      Key: \"application-networking.k8s.aws/RouteName\",\n      Values: [\"server\"]\n    },\n    {\n      Key: \"application-networking.k8s.aws/RouteNamespace\",\n      Values: [\"apps\"]\n    }\n  ]\n}"}
{"level":"debug","ts":"2025-04-27T01:49:22.968Z","logger":"cloud","caller":"aws/cloud.go:65","msg":"response","serviceName":"VPC Lattice","operation":"ListServiceNetworks","params":"{\n\n}"}
{"level":"debug","ts":"2025-04-27T01:49:23.103Z","logger":"cloud","caller":"aws/cloud.go:65","msg":"response","serviceName":"VPC Lattice","operation":"ListTagsForResource","params":"{\n  ResourceArn: \"arn:aws:vpc-lattice:us-east-1:517206134011:servicenetwork/sn-0a9c2d300e05d3283\"\n}"}
...

 

아래 로그의 내용처럼 EKS 클러스터 내에 GatewayClass, Gateway, Route에 대한 오브젝트가 추가되면 AWS Gateway API Controller에서 이를 감지하여 조정(reconcile)합니다.

설명은 아래와 같습니다.

• 로그를 보면, server라는 이름의 service와 my-services라는 이름의 gateway의 생성을 감지하여, reconcile 작업을 수행하는 것을 확인할 수 있습니다.
• 이어서 server-apps라는 이름(HTTPRoute의 metadata.name 및 metadata.namespace를 사용)으로 구성된 Route 대상에 라우팅 하기 위해 server.example.com이라는 사용자 지정 도메인 이름을 세팅하고, VPC Lattice Service를 구성합니다.
• 그리고 VPC Lattice Service에 대해 Listener rule을 생성하고 HTTPRoute 매니페스트 내용에 맞춰 PathPrefix를 구성하고, backendRefs에 대한 대상 그룹을 생성합니다.
• 대상 그룹에는 Service를 참조하여 라우팅 대상 Pod의 IP 주소 및 Port 번호를 세팅합니다.

 

💡

이번 실습에서 적용된 GatewayClass, Gateway, Route 명세서는 ‘ > eks.tf 살펴보기’를 참고해주세요.

 

이렇게 우리는 AWS Gateway API Controller가 GatewayClass, Gateway, Route 리소스를 참조하여 VPC Lattice 네트워크 환경을 구성하여 정상적으로 통신이 가능한 환경을 구성했다는 것을 확인할 수 있습니다.

‣

5.9. 실습 리소스 정리

terraform destroy -target="module.client_vpc" -auto-approve
terraform destroy -target="module.cluster_vpc" -auto-approve
terraform destroy -target=aws_route53_zone.primary -auto-approve

terraform destroy -target="module.client_sg" -auto-approve
terraform destroy -target="module.endpoint_sg" -auto-approve

terraform destroy -target="module.client" -auto-approve
terraform destroy -target="module.vpc_endpoints" -auto-approve

terraform destroy -target="module.eks" -auto-approve
terraform destroy -target="module.addons" -auto-approve

terraform destroy -auto-approve

 

5. Multi Cluster secure communication(실습)

‣

6.0. 실습 환경

💡

이번 실습에서는 Amazon EKS Blueprints for Terraform : Amazon VPC Lattice - Multi-cluster secure communication을 활용합니다.

 

이번 섹션에서는 조금 더 심화 과정으로, 멀티 클러스터 환경 간에서 Amazon VPC Lattice를 활용한 안전한 통신 방법에 대해 실습을 진행합니다.

 

이 패턴에서는 Amazon VPC Lattice와 IAM authorization을 사용하여 서로 다른 VPC에 있는 두 EKS 클러스터 간의 안전한 멀티 클러스터 통신 방식을 보여줍니다.

• 이 솔루션에서는 Service Discovery가 어떻게 이루어지는지를 설명하고, VPC Lattice가 겹치는 CIDR을 가진 EKS 클러스터 간 통신을 어떻게 용이하게 하는지 강조합니다.
• 이를 통해 프라이빗 NAT 게이트웨이와 Transit Gateway와 같은 네트워킹 구조가 필요하지 않도록 하는 방법을 소개합니다.
• 클러스터 간 통신을 안전하게 수행하기 위해, 인증서 관리자(ACM)에서 발행하고 AWS Private CA에서 지원하는 TLS 인증서로 보호되는 Amazon Route53 Private Hosted Zone을 사용하여 Amazon VPC Lattice를 통해 설정됩니다.
• 이를 위해 Kyverno를 사용하여 Envoy SigV4 proxy 컨테이너를 Pod에 추가하고, 여기에 PCA를 주입합니다.

 

주요 컴포넌트

 

인프라 구성

• 두 개의 VPC: VPC cluster 1과 VPC cluster 2가 독립적으로 구성
• 두 개의 EKS 클러스터: 각 VPC에 EKS Cluster 1과 EKS Cluster 2 배포
• VPC Lattice: 두 VPC 간의 서비스 통신을 위한 중앙 관리형 연결 서비스

 

애플리케이션 구성

1. EKS Cluster 1 애플리케이션:
• App1 Service가 Pod로 배포됨
• Envoy sidecar 프록시를 통한 서비스 메시 구성
• HTTP Route를 통한 외부 트래픽 라우팅
2. EKS Cluster 2 애플리케이션:
• App2 Service가 Pod로 배포됨
• 마찬가지로 Envoy sidecar 프록시와 HTTP Route 구성

 

정책 및 보안

• Kyverno: 각 클러스터에 적용된 정책 관리 도구로 사이드카 주입 등을 관리
• IAM Auth Policy: 두 클러스터 간의 인증 및 권한 정책 설정
• Private Certificate Authority: 중앙 인증서 관리
• Certificate Manager: *.example.com 도메인을 위한 인증서 관리

 

네트워킹

• AWS Gateway API Controller: 각 클러스터의 API 트래픽 제어
• DNS 구성:
• ExternalDNS를 통한 DNS 레코드 관리
• demo-cluster1.example.com 및 demo-cluster2.example.com으로 각 클러스터 서비스 노출
• Amazon Route 53을 통한 도메인 관리

 

주요 흐름 및 프로세스

1. VPC Lattice를 통해 HTTPS 트래픽이 두 클러스터 간에 라우팅됨
2. 각 클러스터의 IAM Auth Policy가 접근 권한을 제어
3. Pod Identity 기능을 통해 Envoy SigV4 proxy 컨테이너에 ACM에 대한 권한 및 VPC Lattice service invoke 권한 부여
4. AWS Gateway API Controller가 각 클러스터의 인그레스 트래픽을 관리
5. ExternalDNS가 자동으로 DNS 레코드를 생성하여 서비스 디스커버리 지원

 

‣

6.1. Terraform 코드 준비 및 프로비저닝

⚠️

‣

[확장하기] 만약, 실습 1의 단계를 먼저 수행하지 않았을 경우 아래 과정을 먼저 준비해주세요.

 

‣

6.1.1. environment 프로비저닝

 

 

 

environment의 Terraform을 통해 구성되는 내용들

environment 환경에서는 실습에 필요한 사전 환경(Route53, VPC Lattice, IAM Role, ACM 등)을 프로비저닝 합니다.

자세한 내용은 아래 코드를 파악하여 확인해보겠습니다.

 

environment :Terraform 코드 살펴보기

‣

environment 디렉터리

 

인프라 프로비저닝을 위해 아래 내용을 진행합니다.

 

1. 아래 명령을 수행하여 cross-cluster-pod-communication/environment/ 디렉터리로 이동합니다.

cd terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/environment/

2. main.tf 파일을 열고, 7번째 라인의 region을 ap-northeast-2로 수정합니다.

 

2. 아래 명령을 수행하여 environment의 인프라를 프로비저닝 합니다.

terraform init
terraform apply --auto-approve

 

‣

6.1.2. cluster 프로비저닝

이어서 cluster 환경에서는 실습에 사용할 두 개의 EKS 클러스터 및 데모 애플리케이션을 구성합니다.

자세한 내용은 아래 코드를 파악하여 확인해보겠습니다.

 

cluster :Terraform 코드 살펴보기

‣

cluster 디렉터리

 

인프라 프로비저닝 및 데모 애플리케이션 배포를 위해 아래 내용을 진행합니다.

 

1. 아래 명령을 수행하여 cross-cluster-pod-communication/cluster/ 디렉터리로 이동합니다.

cd ../cluster/

2. main.tf 파일을 열고, 31번째 라인의 region을 ap-northeast-2로 수정합니다.

 

2. 이어서 아래 명령을 통해 첫번째 EKS 클러스터를 배포합니다.

./deploy.sh cluster1

# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`

4. 이어서 아래 명령을 통해 두번째 EKS 클러스터를 배포합니다.

./deploy.sh cluster2

# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`

 

‣

6.2. 프로비저닝 된 인프라 및 애플리케이션 확인

Terraform을 통해 어떤 인프라가 구성되었는지 확인해보겠습니다.

‣

6.2.1. Amazon EKS 클러스터

Amazon EKS 콘솔에 접속해보면 아래와 같이 두 개의 EKS 클러스터가 생성된 것을 확인할 수 있습니다.

 

eks-cluster1을 들어가보겠습니다.

Access > Pod Identity associations 순으로 콘솔을 이동하면 아래와 같은 내용을 확인할 수 있습니다.

vpc-lattice-sig4-client라는 IAM role이 apps라는 네임스페이스의 default라는 Service account에 associate 된 것을 확인할 수 있습니다.

 

해당 IAM role을 클릭해보면 아래와 같이 IAM 콘솔로 이동하여 자세히 확인할 수 있습니다.

이 IAM role은 ACM의 PCA에 대한 여러 액세스 권한과 VPC Lattice Service에 대한 invoke 권한이 설정되어 있습니다.

 

 

위의 에서 확인한 바와 같이 해당 Pod Identity 및 IAM role은 데모 애플리케이션 Pod에 적용됩니다.

 

‣

6.2.2. VPC Lattice

VPC 콘솔 > PrivateLink and Lattice > Service networks 순으로 콘솔을 이동하면 아래와 같이 VPC Lattice Service network 콘솔로 이동할 수 있습니다.

 

 

 

VPC 콘솔 > PrivateLink and Lattice > Lattice services 순으로 콘솔을 이동하면 아래와 같이 VPC Lattice의 Service 콘솔로 이동할 수 있습니다. 각 Service가 커스텀 도메인 명에 매핑된 것을 확인할 수 있습니다.

 

 

 

→ 내 실습 환경 캡쳐

 

그리고 아래와 같이 각 Service가 Private Hosted Zone에 associate 되어있고 PCA를 사용하고 있는 것을 확인할 수 있습니다.

 

‣

Route53 Private Hosted Zone

 

 

→ 내 실습 환경 캡쳐

‣

AWS Certificate Manager(ACM)

 

 

 

→ 내 실습 환경 캡쳐

‣

6.2.3. EKS 클러스터 별 애플리케이션

아래 명령을 수행하여 eks-cluster1으로 context를 스위칭 할 수 있습니다.

kubectl config use-context eks-cluster1
Switched to context "eks-cluster1".

 

eks-cluster1의 Pod 목록을 조회하기 위해 아래 명령을 수행합니다.

kubectl get po -A

NAMESPACE                           NAME                                                              READY   STATUS      RESTARTS   AGE
apps                                demo-cluster1-v1-65fb578f8f-28c6w                                 2/2     Running     0          32m
aws-application-networking-system   aws-gateway-api-controller-aws-gateway-controller-chart-5f2zwmw   1/1     Running     0          35m
aws-application-networking-system   aws-gateway-api-controller-aws-gateway-controller-chart-5fmwlkq   1/1     Running     0          35m
external-dns                        external-dns-5c6f9b9b87-mxgmv                                     1/1     Running     0          35m
kube-system                         aws-node-7tz74                                                    2/2     Running     0          33m
kube-system                         aws-node-jdl64                                                    2/2     Running     0          33m
kube-system                         aws-node-pc6sw                                                    2/2     Running     0          33m
kube-system                         coredns-5fc547d667-2nlz4                                          1/1     Running     0          33m
kube-system                         coredns-5fc547d667-ldxgf                                          1/1     Running     0          33m
kube-system                         eks-pod-identity-agent-jps4d                                      1/1     Running     0          33m
kube-system                         eks-pod-identity-agent-rfjhb                                      1/1     Running     0          33m
kube-system                         eks-pod-identity-agent-v6qln                                      1/1     Running     0          33m
kube-system                         kube-proxy-4gh9v                                                  1/1     Running     0          33m
kube-system                         kube-proxy-7d6ls                                                  1/1     Running     0          33m
kube-system                         kube-proxy-tthps                                                  1/1     Running     0          33m
kyverno                             kyverno-admission-controller-54b8bdb86f-ht4ql                     1/1     Running     0          36m
kyverno                             kyverno-background-controller-64fcf87c7b-wdwjw                    1/1     Running     0          36m
kyverno                             kyverno-cleanup-admission-reports-29095670-cd28n                  0/1     Completed   0          9m1s
kyverno                             kyverno-cleanup-cluster-admission-reports-29095670-tmgr7          0/1     Completed   0          9m1s
kyverno                             kyverno-cleanup-controller-5b4b8f645b-7944l                       1/1     Running     0          36m
kyverno                             kyverno-reports-controller-55b9787f78-kwjwx                       1/1     Running     0          36m

 

이어서 아래 명령을 통해 데모 애플리케이션 Pod(demo-cluster1-v1)의 구성을 확인해보겠습니다.

kubectl describe po demo-cluster1-v1-65fb578f8f-28c6w -n apps 
Name:             demo-cluster1-v1-65fb578f8f-28c6w
Namespace:        apps
Priority:         0
Service Account:  default
Node:             ip-10-0-24-212.ap-northeast-2.compute.internal/10.0.24.212
Start Time:       Sun, 27 Apr 2025 16:26:29 +0900
Labels:           app=demo-cluster1-v1
                  pod-template-hash=65fb578f8f
Annotations:      vpc-lattices-svcs.amazonaws.com/agent-inject: true
Status:           Running
IP:               10.0.18.13
IPs:
  IP:           10.0.18.13
Controlled By:  ReplicaSet/demo-cluster1-v1-65fb578f8f
Init Containers:
  iptables-init:
    Container ID:  containerd://edd7640548a774663e2a1b349a498ab9754c2640e9479ccf69a28a73096f351a
    Image:         public.ecr.aws/seb-demo/iptables:v1
    Image ID:      public.ecr.aws/seb-demo/iptables@sha256:32f68e35a3c5925c7ee4cc664411063579418975e99754e0b9a53b1405b49e03
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/sh
      -c
      iptables -t nat -N EGRESS_PROXY; iptables -t nat -A OUTPUT -p tcp -d 169.254.171.0/24 -j EGRESS_PROXY; iptables -t nat -A EGRESS_PROXY -m owner --gid-owner 0 -j RETURN; iptables -t nat -A EGRESS_PROXY -p tcp -j REDIRECT --to-ports 8080; iptables -t nat -L -n -v;
      
...

 

Init Containers를 통해 envoy-sigv4 컨테이너를 위한 IPTables 세팅이 수행되었습니다.

 

그리고 아래와 같이 envoy-sigv4 컨테이너와 데모 애플리케이션 컨테이너가 잘 배포되어 있습니다.

 

(Optional) 만약 eks-cluster2 클러스터의 Pod 목록도 함께 조회하고 싶다면, 아래 명령을 수행하세요.

kubectl config use-context eks-cluster2
Switched to context "eks-cluster2".

kubectl get po -A
NAMESPACE                           NAME                                                              READY   STATUS      RESTARTS   AGE
apps                                demo-cluster2-v1-6dd9649486-nb5b7                                 2/2     Running     0          9m5s
aws-application-networking-system   aws-gateway-api-controller-aws-gateway-controller-chart-7cfkkcz   1/1     Running     0          21m
aws-application-networking-system   aws-gateway-api-controller-aws-gateway-controller-chart-7cstdbz   1/1     Running     0          21m
external-dns                        external-dns-594fd4bffb-xdrlt                                     1/1     Running     0          21m
kube-system                         aws-node-g6kb9                                                    2/2     Running     0          19m
kube-system                         aws-node-pd58r                                                    2/2     Running     0          19m
kube-system                         aws-node-q9lgh                                                    2/2     Running     0          18m
kube-system                         coredns-5fc547d667-j7zl6                                          1/1     Running     0          19m
kube-system                         coredns-5fc547d667-nvg98                                          1/1     Running     0          19m
kube-system                         eks-pod-identity-agent-5xxt6                                      1/1     Running     0          19m
kube-system                         eks-pod-identity-agent-lb5fk                                      1/1     Running     0          19m
kube-system                         eks-pod-identity-agent-rxmqg                                      1/1     Running     0          19m
kube-system                         kube-proxy-7crgb                                                  1/1     Running     0          19m
kube-system                         kube-proxy-k4dbd                                                  1/1     Running     0          19m
kube-system                         kube-proxy-nfsrb                                                  1/1     Running     0          19m
kyverno                             kyverno-admission-controller-54b8bdb86f-49dlc                     1/1     Running     0          14m
kyverno                             kyverno-background-controller-64fcf87c7b-24zvq                    1/1     Running     0          14m
kyverno                             kyverno-cleanup-admission-reports-29095680-f8258                  0/1     Completed   0          57s
kyverno                             kyverno-cleanup-cluster-admission-reports-29095680-vqv8b          0/1     Completed   0          57s
kyverno                             kyverno-cleanup-controller-5b4b8f645b-f4t8m                       1/1     Running     0          14m
kyverno                             kyverno-reports-controller-55b9787f78-r2tgf                       1/1     Running     0          14m

 

‣

6.3. 통신 테스트 및 동작방식 확인

‣

6.3.1. 동작 방식 확인

이제 두 클러스터 간 연결성을 확인하기 위해 아래의 명령을 실행해보겠습니다.

kubectl --context eks-cluster1 \
  exec -ti -n apps deployments/demo-cluster1-v1 -c demo-cluster1-v1 \
  -- curl demo-cluster2.example.com
 

이 명령은 eks-cluster1의 데모 애플리케이션에서 eks-cluster2의 데모 애플리케이션으로 간단한 요청을 전송합니다.

 

예상되는 응답은 아래와 같습니다.

Requsting to Pod(demo-cluster2-v1-6dd9649486-nb5b7): Hello from demo-cluster2-v1

 

그럼 이번에는 아래의 명령을 실행해보겠습니다.

kubectl --context eks-cluster1 \
  exec -ti -n apps deployments/demo-cluster1-v1 -c demo-cluster1-v1 \
	-- curl demo-cluster1.example.com

이 명령은 eks-cluster1의 데모 애플리케이션에서 그대로 eks-cluster1의 데모 애플리케이션으로 요청을 수행합니다.

 

그러면 아래와 같은 권한 오류 메시지를 확인할 수 있습니다. → 실패! → 이유는? IAMAuthPolicy CR에 의해서 권한이 막혀있음

AccessDeniedException: User: arn:aws:sts::[AWS_ACCOUNT]:assumed-role/vpc-lattice-sigv4-client/eks-eks-cluste-demo-clust-4f7d25ef-bf0d-4eaf-b54f-5c9863c59729 is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:ap-northeast-2:[AWS_ACCOUNT]:service/svc-097ea52678cf1ef5b/ because no service-based policy allows the vpc-lattice-svcs:Invoke action%

 

이렇게 에러가 발생하는 이유는, eks-cluster1의 IAMAuthPolicy에서 eks-cluster2 으로만 호출 가능하도록 했기 때문입니다.

 

IAMAuthPolicy란?

IAMAuthPolicy는 Gateway API의 직접 정책 연결(Direct Policy Attachment)을 구현(implements)하는 GEP-713: 메타리소스 및 정책 연결입니다. IAMAuthPolicy는 Gateway, HTTPRoute 또는 GRPCRoute에 연결될 수 있습니다. (Gateway Enhancement Proposal:GEP - 게이트웨이 개선 제안)

• 메타리소스란? - 표준 방식으로 객체(object)의 동작을 확장하는 Kubernetes 객체를 메타리소스 라고 합니다.

IAMAuthPolicy는 VPC Lattice의 Service Network 또는 Service에 첨부되는 IAM Policy 문서로, 주체(principal)가 첨부된 Service Network의 Service 또는 특정 첨부된 Service에 접근하는 권한을 제어합니다.

💡

참고

IAMAuthPolicy는 Gateway, HTTPRoute, GRPCRoute를 통해 이동하는 트래픽에 대해서만 권한 부여를 수행할 수 있습니다. 클라이언트가 직접 k8s 서비스 DNS로 트래픽을 전송하는 경우에는 권한 부여가 적용되지 않습니다.

 

참고 링크

• Amazon Web Services Implement AWS IAM authentication with Amazon VPC Lattice and Amazon EKS | Amazon Web Services
• Amazon VPC Lattice 인증 정책을 사용하여 VPC Lattice 서비스에 대한 액세스 제어 - Amazon VPC Lattice
• IAMAuthPolicy - AWS Gateway API Controller

아래 명령을 실행해보겠습니다.

kubectl --context eks-cluster1 \
  get IAMAuthPolicy -n apps demo-cluster1-iam-auth-policy  \
  -o json | jq ".spec.policy | fromjson"
  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::[AWS_ACCOUNT]:root"
      },
      "Action": "vpc-lattice-svcs:Invoke",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/eks-cluster-name": "eks-cluster2",
          "aws:PrincipalTag/kubernetes-namespace": "apps"
        }
      }
    }
  ]
}

위의 정책 내용을 해석하면 아래와 같습니다.

• VPC Lattice Serivce를 invoke하는 액션 중에서 클러스터 명(eks-cluster-name)이 eks-cluster2 여야하고, 네임스페이스가 apps일 때에만 Invoke를 허용한다.

 

아래 명령을 통해 IAMAuthPolicy의 자세한 내용을 확인해보겠습니다.

kubectl --context eks-cluster1 describe IAMAuthPolicy demo-cluster1-iam-auth-policy -n apps
Name:         demo-cluster1-iam-auth-policy
Namespace:    apps
Labels:       app.kubernetes.io/managed-by=Helm
Annotations:  application-networking.k8s.aws/iam-auth-policy-resource-id: svc-097ea52678cf1ef5b
              application-networking.k8s.aws/iam-auth-policy-resource-type: Service
              meta.helm.sh/release-name: demo-cluster1
              meta.helm.sh/release-namespace: apps
API Version:  application-networking.k8s.aws/v1alpha1
Kind:         IAMAuthPolicy
Metadata:
  Creation Timestamp:  2025-04-27T07:26:29Z
  Finalizers:
    application-networking.k8s.aws/iam-auth-policy
  Generation:        1
  Resource Version:  2886
  UID:               3688f2ce-2803-421f-b747-06f5b286d21c
Spec:
  Policy:  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
              "AWS": "arn:aws:iam::715841333265:root"
            },
            "Action": "vpc-lattice-svcs:Invoke",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/eks-cluster-name": "eks-cluster2",
                    "aws:PrincipalTag/kubernetes-namespace": "apps"
                }
            }
        }
    ]
}

  Target Ref:
    Group:      gateway.networking.k8s.io
    Kind:       HTTPRoute
    Name:       demo-cluster1
    Namespace:  apps
Status:
  Conditions:
    Last Transition Time:  2025-04-27T07:26:34Z
    Message:               
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
Events:                    <none>

 

해당 IAMAuthPolicy의 적용 대상(Target Ref)이 demo-cluster1 라는 이름을 가진, apps 네임스페이스의 HTTPRoute 리소스임을 확인할 수 있습니다.

 

대상이 되는 HTTPRoute를 조회하기 위해 아래 명령을 수행합니다.

kubectl --context eks-cluster1 describe HTTPRoute demo-cluster1 -n apps   
           
Name:         demo-cluster1
Namespace:    apps
Labels:       app.kubernetes.io/managed-by=Helm
Annotations:  application-networking.k8s.aws/lattice-assigned-domain-name:
                demo-cluster1-apps-097ea52678cf1ef5b.7d67968.vpc-lattice-svcs.ap-northeast-2.on.aws
              meta.helm.sh/release-name: demo-cluster1
              meta.helm.sh/release-namespace: apps
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         HTTPRoute
Metadata:
  Creation Timestamp:  2025-04-27T07:26:29Z
  Finalizers:
    httproute.k8s.aws/resources
  Generation:        1
  Resource Version:  3625
  UID:               4e261671-c1fd-426e-aeb0-c7b3a1cfa8b2
Spec:
  Hostnames:
    demo-cluster1.example.com
  Parent Refs:
    Group:         gateway.networking.k8s.io
    Kind:          Gateway
    Name:          lattice-gateway
    Namespace:     lattice-gateway
    Section Name:  http-listener
    Group:         gateway.networking.k8s.io
    Kind:          Gateway
    Name:          lattice-gateway
    Namespace:     lattice-gateway
    Section Name:  https-listener-with-custom-domain
  Rules:
    Backend Refs:
      Group:   
      Kind:    Service
      Name:    demo-cluster1-v1
      Port:    80
      Weight:  1
    Matches:
      Path:
        Type:   PathPrefix
        Value:  /
Status:
  Parents:
    Conditions:
      Last Transition Time:  2025-04-27T07:28:50Z
      Message:               
      Observed Generation:   1
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2025-04-27T07:28:50Z
      Message:               
      Observed Generation:   1
      Reason:                ResolvedRefs
      Status:                True
      Type:                  ResolvedRefs
    Controller Name:         application-networking.k8s.aws/gateway-api-controller
    Parent Ref:
      Group:         gateway.networking.k8s.io
      Kind:          Gateway
      Name:          lattice-gateway
      Namespace:     lattice-gateway
      Section Name:  http-listener
    Conditions:
      Last Transition Time:  2025-04-27T07:28:50Z
      Message:               
      Observed Generation:   1
      Reason:                Accepted
      Status:                True
      Type:                  Accepted
      Last Transition Time:  2025-04-27T07:28:50Z
      Message:               
      Observed Generation:   1
      Reason:                ResolvedRefs
      Status:                True
      Type:                  ResolvedRefs
    Controller Name:         application-networking.k8s.aws/gateway-api-controller
    Parent Ref:
      Group:         gateway.networking.k8s.io
      Kind:          Gateway
      Name:          lattice-gateway
      Namespace:     lattice-gateway
      Section Name:  https-listener-with-custom-domain
Events:
  Type    Reason           Age                 From       Message
  ----    ------           ----                ----       -------
  Normal  Retry-Reconcile  44m (x7 over 45m)   httproute  retry reconcile...
  Normal  Reconcile        43m (x10 over 45m)  httproute  Adding/Updating Reconcile
  Normal  DeploySucceed    43m (x3 over 44m)   httproute  Adding/Updating reconcile Done!

 

이 HTTPRoute 설정을 통해 라우팅 되는 대상을 아래와 같이 확인할 수 있습니다.

 

HTTPRoute로 라우팅 되는 대상이 demo-cluster1-v1 이라는 Service임을 알 수 있습니다.

 

마찬가지로 아래 명령을 통해 해당 Service 명세를 확인해보겠습니다.

# Gateway API의 HTTPRoute에서 route 되는 target service이다.
kubectl describe svc demo-cluster1-v1 -n apps

Name:                     demo-cluster1-v1
Namespace:                apps
Labels:                   app.kubernetes.io/managed-by=Helm
Annotations:              meta.helm.sh/release-name: demo-cluster1
                          meta.helm.sh/release-namespace: apps
Selector:                 app=demo-cluster1-v1
Type:                     ClusterIP
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       172.20.190.76
IPs:                      172.20.190.76
Port:                     <unset>  80/TCP
TargetPort:               8090/TCP
Endpoints:                10.0.18.13:8090
Session Affinity:         None
Internal Traffic Policy:  Cluster
Events:                   <none>

 

이 Service를 통해 라우팅 되는 대상이 10.0.26.50:8090 임을 확인할 수 있습니다. (demo-cluster1-v1)

 

이어서 VPC 콘솔 > PrivateLink and Lattice > Lattice service 로 이동하여 demo-cluster1-apps의 체크박스를 클릭하고, Routing 탭을 클릭하면 아래와 같이 라우팅 대상 그룹을 확인할 수 있습니다.

 

 

 

→ 내 실습 환경 캡쳐

 

 

 

→ 내 실습 환경 캡쳐

-> 위에서 describe를 통해서 확인했던 service의 endpoints로 등록된 pod의 ip주소가 registered targets으로 등록이 되어있는것을 볼 수 있다.

 

결과적으로 이 데모 애플리케이션 Pod가 IAMAuthPolicy의 규칙을 적용받고 있음을 확인할 수 있습니다.

이렇게 IAMAuthPolicy를 사용하면 멀티 클러스터 간에 각 애플리케이션에 대한 액세스 제어를 쉽게 구성할 수 있습니다.

 

‣

6.3.2. Kyverno의 역할

이번 실습에서는 Kyverno의 ClusterPolicy를 사용하여 데모 애플리케이션 Pod에 iptables 규칙과 envoy 사이드카 프록시를 주입했습니다:

• iptables 규칙은 애플리케이션에서 envoy 프록시로 트래픽을 라우팅합니다(소스 프로세스 gid가 0인 경우 규칙이 적용되지 않으므로 애플리케이션에 다른 gid를 제공합니다: runAsGroup: 1000).
• envoy 프록시는 시작 시 Private CA 인증서를 검색하여 시작 스크립트를 통해 VPC lattice 서비스를 신뢰하도록 설치합니다:

 

아래 명령을 수행하여 envoy 프록시 컨테이너가 뜰 때 실행하는 스크립트를 참조합니다.

kubectl --context eks-cluster1 \
	exec -it deploy/demo-cluster1-v1 -c envoy-sigv4 -n apps \
	-- cat /usr/local/bin/launch_envoy.sh

📌

이 데모에서 사용된 envoy 프록시, iptables 및 http-server 이미지를 만드는 데 사용된 Dockerfile은 여기에서 찾을 수 있습니다.

 

출력 결과는 아래와 같습니다.

#!/bin/sh

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0

cat /etc/envoy/envoy.yaml.in | envsubst \$AWS_REGION,\$JWT_AUDIENCE,\$JWT_JWKS,\$JWT_ISSUER,\$JWKS_HOST,\$APP_DOMAIN > /etc/envoy/envoy.yaml
aws acm-pca get-certificate-authority-certificate --certificate-authority-arn $CA_ARN --region $AWS_REGION --output text > /etc/pki/ca-trust/source/anchors/internal.pem
update-ca-trust extract

cat /etc/envoy/envoy.yaml
/usr/local/bin/envoy --base-id 1 -l trace -c /etc/envoy/envoy.yaml

‣

설명

1. 환경 변수 치환을 통한 Envoy 구성 파일 생성

cat /etc/envoy/envoy.yaml.in | envsubst \$AWS_REGION,\$JWT_AUDIENCE,\$JWT_JWKS,\$JWT_ISSUER,\$JWKS_HOST,\$APP_DOMAIN > /etc/envoy/envoy.yaml

• 템플릿 파일(envoy.yaml.in)을 읽어서
• 환경 변수들(AWS_REGION, JWT_AUDIENCE, JWT_JWKS, JWT_ISSUER, JWKS_HOST, APP_DOMAIN)을 실제 값으로 대체
• 결과를 Envoy 구성 파일(/etc/envoy/envoy.yaml)로 저장

 

2. AWS 사설 인증 기관(PCA)에서 인증서 가져오기

aws acm-pca get-certificate-authority-certificate --certificate-authority-arn $CA_ARN --region $AWS_REGION --output text > /etc/pki/ca-trust/source/anchors/internal.pem

• AWS 명령줄 도구를 사용하여 지정된 인증 기관(CA)에서 인증서를 가져옴
• $CA_ARN 환경 변수에 지정된 인증 기관의 Amazon 리소스 이름을 사용
• 획득한 인증서를 시스템의 신뢰 저장소 경로에 저장

 

3. 시스템 인증서 신뢰 저장소 업데이트

update-ca-trust extract

• 방금 추가한 인증서를 시스템이 신뢰하도록 CA 신뢰 저장소를 갱신

 

4. 구성 파일 내용 출력 (디버깅 용도)

cat /etc/envoy/envoy.yaml

• 생성된 Envoy 구성 파일의 내용을 출력하여 확인

 

5. Envoy 프록시 실행

/usr/local/bin/envoy --base-id 1 -l trace -c /etc/envoy/envoy.yaml

• Envoy 프록시를 시작
• --base-id 1: 기본 ID 설정 (여러 Envoy 인스턴스 구분용)
• -l trace: 로그 레벨을 trace로 설정하여 상세 로깅 활성화
• -c /etc/envoy/envoy.yaml: 앞서 생성한 구성 파일을 사용

 

이 스크립트의 주요 목적은 AWS VPC Lattice 서비스와 안전하게 통신하기 위해 필요한 인증서를 설정하고, 환경에 맞게 구성된 Envoy 프록시를 실행하는 것입니다. SigV4 인증을 사용하여 AWS 서비스에 대한 요청에 서명하는 프로세스를 자동화합니다.

 

launch_envoy.sh에서 활용한 envoy.yaml.in 스크립트도 함께 살펴보겠습니다. 해당 스크립트는 여기서 참조할 수 있습니다.

 

envoy.yaml.in

static_resources:
  listeners:
  - name: http_connect
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains:
              - "*"
              routes:
              - match:
                  prefix: '/'
                route:
                  cluster: outbound_proxy
          # Ignore traffic to /health and respond with a 200
          http_filters:
          - name: envoy.filters.http.dynamic_forward_proxy
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.dynamic_forward_proxy.v3.FilterConfig
              dns_cache_config:
                name: dynamic_forward_proxy_cache_config
                dns_lookup_family: V4_ONLY
                typed_dns_resolver_config:
                  name: envoy.network.dns_resolver.cares
                  typed_config:
                    "@type": type.googleapis.com/envoy.extensions.network.dns_resolver.cares.v3.CaresDnsResolverConfig
                    use_resolvers_as_fallback: true
                    resolvers:
                    - socket_address:
                        address: "127.0.0.1"
                        port_value: 53
                    dns_resolver_options:
                      use_tcp_for_dns_lookups: true
                      no_default_search_domain: true
          # SigV4 signing configuration
          - name: envoy.filters.http.aws_request_signing
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.aws_request_signing.v3.AwsRequestSigning
              service_name: vpc-lattice-svcs
              region: ${AWS_REGION}
              use_unsigned_payload: true
              match_excluded_headers:
              - prefix: x-envoy
              - prefix: x-forwarded
              - exact: x-amzn-trace-id
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: outbound_proxy
    lb_policy: CLUSTER_PROVIDED
    cluster_type:
      name: envoy.clusters.dynamic_forward_proxy
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.clusters.dynamic_forward_proxy.v3.ClusterConfig
        dns_cache_config:
          name: dynamic_forward_proxy_cache_config
          dns_lookup_family: V4_ONLY
          typed_dns_resolver_config:
            name: envoy.network.dns_resolver.cares
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.network.dns_resolver.cares.v3.CaresDnsResolverConfig
              use_resolvers_as_fallback: true
              resolvers:
              - socket_address:
                  address: "127.0.0.1"
                  port_value: 53
              dns_resolver_options:
                use_tcp_for_dns_lookups: true
                no_default_search_domain: true
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        common_tls_context:
          validation_context:
            trusted_ca:
              filename: /etc/ssl/certs/ca-bundle.crt

‣

설명

이 YAML 파일은 Envoy 프록시의 구성을 정의하며, 특히 AWS VPC Lattice 서비스와의 안전한 통신을 위해 설계되었습니다. 주요 부분별로 설명하겠습니다.

 

1. Listeners (리스너) 구성

listeners:
  - name: http_connect
    address:
      socket_address:
        protocol: TCP
        address: 0.0.0.0
        port_value: 8080

• name: http_connect: 리스너의 이름을 정의
• address: 모든 네트워크 인터페이스(0.0.0.0)의 8080 포트에서 TCP 연결을 수신함

 

2. HTTP 연결 관리자 및 라우팅 설정

filter_chains:
- filters:
  - name: envoy.filters.network.http_connection_manager
    typed_config:
      ...
      route_config:
        name: local_route
        virtual_hosts:
        - name: local_service
          domains: ["*"]
          routes:
          - match: { prefix: '/' }
            route: { cluster: outbound_proxy }

• 모든 도메인(*)에 대한 HTTP 요청을 처리
• 모든 경로(/)로 시작하는 요청을 outbound_proxy 클러스터로 라우팅

 

3. 동적 포워드 프록시 필터

http_filters:
- name: envoy.filters.http.dynamic_forward_proxy
  typed_config:
    ...
    dns_cache_config:
      name: dynamic_forward_proxy_cache_config
      dns_lookup_family: V4_ONLY

• 요청 중 호스트 이름을 동적으로 확인하는 필터
• IPv4 주소만 사용하도록 구성됨
• 로컬 DNS 리졸버(127.0.0.1:53)를 사용

 

4. AWS SigV4 서명 필터

- name: envoy.filters.http.aws_request_signing
  typed_config:
    ...
    service_name: vpc-lattice-svcs
    region: ${AWS_REGION}
    use_unsigned_payload: true
    match_excluded_headers:
    - prefix: x-envoy
    - prefix: x-forwarded
    - exact: x-amzn-trace-id

• AWS Signature Version 4(SigV4) 알고리즘을 사용하여 요청에 서명
• VPC Lattice 서비스(vpc-lattice-svcs)로 가는 요청에 서명
• 환경 변수 ${AWS_REGION}을 통해 AWS 리전 지정
• 특정 헤더는 서명 프로세스에서 제외됨

 

5. 라우터 필터

- name: envoy.filters.http.router
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

• 구성된 라우트에 따라 요청을 업스트림 클러스터로 전달하는 필수 필터

 

6. 클러스터 구성

clusters:
- name: outbound_proxy
  lb_policy: CLUSTER_PROVIDED
  cluster_type:
    name: envoy.clusters.dynamic_forward_proxy
    ...

• outbound_proxy 클러스터는 동적 포워드 프록시로 동작
• 동적으로 호스트를 발견하고 연결 관리

 

7. TLS 설정

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    ...
    common_tls_context:
      validation_context:
        trusted_ca:
          filename: /etc/ssl/certs/ca-bundle.crt

• 업스트림 서비스(VPC Lattice)와 통신할 때 TLS를 사용
• 시스템의 CA 인증서 번들을 사용하여 서버 인증서 검증

요약

1. 8080 포트에서 HTTP 요청 수신
2. 모든 요청을 동적 DNS 조회를 통해 해당 서비스로 전달
3. AWS VPC Lattice로 가는 요청에 SigV4 인증 서명 적용
4. TLS를 사용하여 안전한 통신 보장

 

 

envoy의 Dockerfile

FROM envoyproxy/envoy:distroless-v1.30.0 as envoy

FROM public.ecr.aws/amazonlinux/amazonlinux:latest
RUN yum -y update && \
    yum clean all && \
    rm -rf /var/cache/yum

COPY --from=envoy /usr/local/bin/envoy /usr/local/bin/envoy
RUN yum install -y python3 jq tar bind-utils procps gettext which unzip tar less util-linux
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \
    unzip awscliv2.zip && \
    ./aws/install

COPY envoy.yaml.in /etc/envoy/envoy.yaml.in
COPY launch_envoy.sh /usr/local/bin/launch_envoy.sh

RUN chmod 755 /usr/local/bin/launch_envoy.sh
ENTRYPOINT ["launch_envoy.sh"]

‣

설명

이 Dockerfile은 AWS VPC Lattice와 통신하기 위한 사용자 정의 Envoy 프록시 이미지를 생성합니다. 주요 부분별로 살펴보겠습니다.

 

1. 멀티 스테이지 빌드 설정

FROM envoyproxy/envoy:distroless-v1.30.0 as envoy

FROM public.ecr.aws/amazonlinux/amazonlinux:latest

• 첫 번째 단계: 공식 Envoy 프록시의 distroless 버전을 envoy라는 별칭으로 가져옵니다.
• 두 번째 단계: Amazon Linux를 최종 기본 이미지로 사용합니다.

 

2. 시스템 패키지 업데이트

RUN yum -y update && \
    yum clean all && \
    rm -rf /var/cache/yum

• 시스템 패키지를 최신 상태로 업데이트하고
• 패키지 캐시를 정리하여 이미지 크기를 최적화합니다.

 

3. Envoy 바이너리 복사

COPY --from=envoy /usr/local/bin/envoy /usr/local/bin/envoy

• 첫 번째 단계(distroless Envoy)에서 Envoy 실행 파일만 추출하여 현재 이미지로 복사합니다.

 

4. 필수 도구 설치

RUN yum install -y python3 jq tar bind-utils procps gettext which unzip tar less util-linux

• 다음 도구들을 설치합니다:
• python3: Python 스크립트 실행용
• jq: JSON 처리 도구
• bind-utils: DNS 조회 도구(dig, nslookup 등)
• gettext: 환경 변수 치환 도구(envsubst)
• procps: 프로세스 관리 도구
• 그 외 여러 유틸리티 도구들

 

5. AWS CLI 설치

RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \
    unzip awscliv2.zip && \
    ./aws/install

• AWS 명령줄 인터페이스(CLI) 버전 2를 다운로드하고 설치
• AWS 서비스(특히 인증서 관리)와의 상호작용에 필요합니다.

 

6. Envoy 구성 파일 및 시작 스크립트 복사

COPY envoy.yaml.in /etc/envoy/envoy.yaml.in
COPY launch_envoy.sh /usr/local/bin/launch_envoy.sh

• envoy.yaml.in: 이전에 살펴본 Envoy 구성의 템플릿 파일을 복사
• launch_envoy.sh: 이전에 설명한 시작 스크립트를 복사

 

7. 실행 권한 설정 및 시작점 정의

RUN chmod 755 /usr/local/bin/launch_envoy.sh
ENTRYPOINT ["launch_envoy.sh"]

• 시작 스크립트에 실행 권한을 부여
• 컨테이너가 시작될 때 자동으로 launch_envoy.sh 스크립트를 실행하도록 설정

‣

6.4. 실습 리소스 정리

• 클러스터 정리

cd /workshop/terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/cluster/

./destroy.sh cluster2

./destroy.sh cluster1

 

• environment 환경 정리

SN=$(aws vpc-lattice list-service-networks --query 'items[?name==`lattice-gateway`].id' --output text)
if [ -n "$SN" ]; then
    aws vpc-lattice delete-service-network --service-network-id "$SN"
fi

cd /workshop/terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/environment/

terraform destroy -auto-approve