Kubernetes의 애플리케이션 네트워킹 변화 과정
Kubernetes의 네트워킹 스택은 마이크로서비스 아키텍처의 발전과 함께 진화해 왔습니다.
첫 시작 : 단일 Kubernetes 클러스터 환경
단일 클러스터 환경에서는 CoreDNS와 Ingress 리소스를 통해 내부 서비스 간 통신 및 외부 통신을 네이티브 하게 구현합니다. 초기에는 기본 Service 리소스(NodePort, ClusterIP, LoadBalancer)로 시작하여 점차 Ingress를 활용한 경로 기반 라우팅과 SSL/TLS 보안 기능으로 발전했습니다. 이 단계에서는 주로 기본적인 내부 통신과 외부 노출 기능에 중점을 두었습니다.
워크로드의 진화: 멀티 클러스터 환경에서의 네트워킹 과제
멀티 클러스터 환경으로 발전하면서 클러스터 간 통신에 대한 새로운 과제가 등장했습니다. 이 과정에서 두 가지 핵심 기술이 중요해졌습니다.
서비스 디스커버리(Service Discovery)
서비스 디스커버리는 분산 환경에서 서비스의 위치를 동적으로 찾는 메커니즘입니다. 이는 서비스의 IP 주소와 포트 정보를 관리하고, 지속적인 헬스 체크를 수행하며, 서비스 메타데이터를 저장합니다. 클라이언트 사이드 방식에서는 클라이언트가 직접 서비스 레지스트리를 쿼리 하고, 서버 사이드 방식에서는 로드 밸런서가 이 역할을 담당합니다. AWS 환경에서는 VPC Peering, PrivateLink, Transit Gateway 등을 통해 VPC 간 연결을 구현합니다.
서비스 메시(Service Mesh)
마이크로서비스 증가로 인한 네트워크 복잡성과 공통 기능 적용 요구에 대응하기 위해 서비스 메시가 도입되었습니다. AWS AppMesh, Istio, Linkerd 등의 솔루션은 트래픽 관리, 보안, 관찰성을 강화하고 마이크로서비스 간 통신의 복잡성을 추상화합니다.
서비스 메시는 데이터 영역과 제어 영역으로 구성됩니다:
- 데이터 영역: 사이드카 프록시가 서비스 간 통신을 중개하며, 서킷 브레이킹, 재시도 로직 등 복원력 기능을 제공합니다.
- 제어 영역: 서비스 레지스트리 기능을 수행하고, 서비스 자동 검색 및 텔레메트리 데이터 수집을 담당합니다.
이러한 아키텍처는 컨테이너 애플리케이션 옆에 프록시 컨테이너를 배치하여 모든 트래픽을 중개함으로써 네트워크 통신을 표준화하고 관리합니다.
이러한 방식의 애플리케이션 네트워킹의 한계점
Kubernetes에서 Ingress, Service Discovery, Service Mesh는 트래픽 관리에 널리 사용되었지만 여러 한계점을 가지고 있었습니다.
Ingress의 한계
Ingress는 HTTP/HTTPS 트래픽에 최적화되어 있어 gRPC, TCP, UDP와 같은 다른 프로토콜 지원이 제한적이었습니다. 또한 고급 기능(인증, 속도 제한, 트래픽 관리)을 사용하려면 벤더별 사용자 정의 어노테이션이 필요해 이식성과 표준화에 문제가 있었습니다.
Service Mesh의 한계
Service Mesh는 주로 서비스 간 내부 통신에 초점을 맞추어 외부->내부 통신 지원이 제한적이었습니다. Amazon EKS 환경에서는 VPC Peering과 Transit Gateway 설정이 필요했고, 여러 AWS 계정 사용 시 교차 계정 액세스 설정이 복잡했습니다. 또한 사이드카 프록시 배포가 필수적이어서 멀티 VPC 환경에서 네트워크 복잡도가 크게 증가했습니다.
클라우드 환경의 새로운 요구사항
마이크로서비스 확장과 인프라 복잡화로 인해 다음과 같은 새로운 요구사항이 등장했습니다:
- 인프라 담당자, 개발자, DevOps 엔지니어 간의 명확한 책임 분리
- 여러 VPC 또는 멀티 클러스터 환경의 일관된 리소스 관리
- 다양한 컴퓨팅 형태(인스턴스, 컨테이너, 서버리스)를 통합 관리할 수 있는 네트워킹 레이어
Gateway API의 등장
SIG-NETWORK 커뮤니티는 기존 Kubernetes 네트워킹의 한계를 극복하기 위해 Gateway API를 개발했습니다. Gateway API는 역할 기반 설계, 다양한 프로토콜 지원, 표준화된 인터페이스, 그리고 멀티 클러스터 환경에서의 확장성을 목표로 설계되었습니다.
Gateway API의 주요 구성요소
Gateway API는 인프라 관리자와 애플리케이션 개발자 간의 역할과 책임을 명확히 구분하는 계층적 구조를 가집니다.
GatewayClass는 게이트웨이 집합의 공통 구성을 정의하며, 특정 컨트롤러에 의해 관리됩니다. 각 게이트웨이는 자신을 구현하는 컨트롤러의 이름을 포함하는 GatewayClass를 참조해야 합니다.
Gateway는 외부 트래픽을 수신하고 내부 서비스로 라우팅 하는 진입점으로, 하나 이상의 Route 리소스와 연결될 수 있습니다.
Routes는 트래픽을 특정 서비스로 매핑하는 프로토콜별 규칙을 정의합니다. HTTPRoute, TLSRoute, TCPRoute, UDPRoute, GRPCRoute 등 다양한 유형이 있으며, Gateway 리소스에 연결되어 트래픽을 대상 서비스로 전달합니다.
이러한 계층적 구조를 통해 인프라 관리자는 GatewayClass와 Gateway를 관리하며 전체 인프라의 일관성을 유지하고, 애플리케이션 개발자는 Route를 통해 자신의 애플리케이션에 대한 라우팅 규칙을 독립적으로 정의할 수 있습니다.
AWS는 이 구조를 Amazon VPC Lattice와 통합하여 클라우드 네이티브 환경의 네트워킹 요구사항을 효과적으로 충족시킵니다.
Gateway API Controller
Gateway API는 Controller를 통해 동작합니다. 다양한 벤더별 구현체는 공식 문서에서 확인할 수 있으며, AWS에서는 AWS Gateway API Controller를 제공하고 있습니다.
Amazon VPC Lattice란
Amazon VPC Lattice는 AWS에서 제공하는 완전관리형 애플리케이션 네트워킹 서비스로, 다양한 컴퓨팅 환경에서 애플리케이션 서비스를 연결, 보호 및 모니터링하는 통합 솔루션입니다. 단일 VPC 내에서뿐만 아니라 여러 계정과 VPC에 걸쳐 서비스를 연결할 수 있습니다.
현대적인 마이크로서비스 아키텍처에서는 여러 소규모 모듈형 서비스로 애플리케이션이 분할되어 개발 속도와 확장성이 향상되지만, 이로 인해 서비스 간 효율적인 연결과 관리에 대한 네트워킹 문제가 발생합니다. VPC Lattice는 EC2 인스턴스, EKS 컨테이너, Lambda 함수 등 다양한 컴퓨팅 서비스 간에 표준화된 연결 방식을 제공하여 이러한 문제를 해결합니다.
Amazon VPC Lattice 주요 구성 요소
Service
Service는 독립적으로 배포 가능한 소프트웨어 단위로, 다양한 컴퓨팅 환경에서 실행될 수 있습니다. 서비스는 고유한 도메인 이름을 제공하고, 리스너를 통해 들어오는 연결을 처리하며, 라우팅 규칙을 정의합니다. 리스너, 규칙, 대상 그룹으로 구성되어 있으며, HTTP/1.1, HTTP/2, gRPC 등의 프로토콜을 지원합니다.
Service Network
Service Network는 여러 서비스를 논리적으로 그룹화하고 이들 간의 통신을 관리합니다. 여러 VPC와 서비스를 단일 네트워크로 통합하고, 계정 간, 리전 간 서비스 연결을 지원하며, 중앙 집중식 액세스 제어 및 모니터링을 제공합니다.
Auth Policy
Auth Policy는 VPC Lattice 서비스에 대한 액세스를 제어하는 IAM 기반 정책입니다. 서비스 또는 서비스 네트워크 수준에서 적용할 수 있으며, HTTP 메소드, 경로, 헤더 등을 기준으로 세분화된 접근 제어를 설정할 수 있습니다.
Service Directory
Service Directory는 모든 VPC Lattice 서비스를 중앙에서 검색하고 관리할 수 있는 카탈로그입니다. 개발자와 운영팀이 사용 가능한 서비스를 쉽게 찾고 접근할 수 있도록 지원하며, 서비스 메타데이터 관리 및 검색 기능을 제공합니다.
Amazon VPC Lattice의 장점
VPC Lattice는 여러 VPC와 컴퓨팅 환경에 걸친 애플리케이션의 네트워크 구성을 중앙 집중화하고, 별도의 사이드카 프록시 없이도 완전 관리형 서비스를 제공합니다. 복잡한 네트워크 구성을 단순화하고, IAM 및 SigV4를 통해 보안을 쉽게 적용할 수 있으며, CloudWatch, S3, Kinesis Data Firehose와 통합되어 로깅 및 트래픽 분석이 용이합니다.
주요 사용 사례로는 단일 리전 내 애플리케이션 간 연결, 온프레미스에서 AWS 애플리케이션으로의 접근, 여러 AWS 리전에 걸친 애플리케이션 연결, 그리고 다중 계정 간 애플리케이션 연결 등이 있습니다.
[실습 1] - AWS VPC Lattice를 활용하여 Client -> Server(EKS) 통신을 손쉽게!
이번 실습은 서로 다른 두 개의 VPC에 클라이언트 애플리케이션과 서버 애플리케이션을 각각 배포하고, Amazon VPC Lattice를 통해 두 애플리케이션 간 연결을 설정하는 과정을 다룹니다. 서버 애플리케이션은 Amazon EKS 클러스터에 배포되며, 클라이언트는 별도 VPC에서 동작합니다. 두 애플리케이션 간의 통신은 VPC Lattice를 통해 관리되고, Amazon Route 53과 ExternalDNS Add-on을 활용해 커스텀 도메인으로 서비스가 노출되도록 구성합니다.
Terraform 코드 준비 및 프로비저닝
이번 실습은 AWS 공식 GitHub 레포지토리인 terraform-aws-eks-blueprints 프로젝트를 기반으로 진행합니다. 이 레포지토리는 AWS 인프라 환경을 빠르게 구축할 수 있도록 다양한 베스트 프랙티스를 코드로 제공하는 프로젝트입니다. 특히 패턴별로 다양한 예제가 준비되어 있어, 이번 실습처럼 VPC Lattice 통신 구성을 빠르게 실습하는 데 매우 유용합니다.
먼저, 실습 코드를 로컬로 클론 합니다
git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
코드를 클론 한 뒤, 실습에 사용할 예제 디렉터리로 이동합니다
cd terraform-aws-eks-blueprints/patterns/vpc-lattice/client-server-communication
이 예제는 기본적으로 us-west-2 리전을 기준으로 작성되어 있습니다. 따라서, 한국(서울) 리전인 ap-northeast-2로 변경하기 위해 main.tf 파일을 열어 29번째 줄의 region 값을 수정합니다.
아래 명령을 순차적으로 실행하여 실습 인프라를 프로비저닝 합니다.
terraform 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 apply -auto-approve
Terraform을 통해 모든 인프라 리소스가 정상적으로 프로비저닝 되었다면, 클러스터에 연결하기 위해 kubectl 설정을 진행합니다. 다음 명령어를 입력하여 kubeconfig 파일을 업데이트합니다.
aws eks update-kubeconfig --name client-server-communication --alias client-server-communication --region ap-northeast-2
정상적으로 연결되었는지 확인하기 위해, 클러스터의 모든 Pod 상태를 조회합니다.
프로비저닝 된 리소스 확인
Terraform을 통해 인프라를 모두 구축한 뒤, 실제로 어떤 리소스가 생성되었는지 AWS 콘솔을 통해 하나씩 확인해 보겠습니다.
VPC
먼저, AWS Management Console에 접속하여 VPC 서비스를 엽니다. 왼쪽 메뉴에서 Your VPCs 항목을 클릭하면, 이번 실습에서 생성된 VPC 목록을 확인할 수 있습니다.
- client vpc가
10.1.0.0/16CIDR 주소 범위로 구성되어 있습니다. - cluster vpc가
10.0.0.0/16CIDR 주소 범위로 구성되어 있습니다.
Subnet
다음으로, VPC 각각에 구성된 서브넷을 확인합니다.
- client vpc의 서브넷은
private subnet 3개로 구성되어 있습니다. - cluster vpc의 서브넷은
public subnet 3개,private subnet 3개로 구성되어 있습니다.
인스턴스(EC2)
이어서 테스트를 수행할 대상인 워크로드를 한번 확인해 보겠습니다. 아래 그림을 따라 EC2 콘솔로 이동합니다.
- client 측 워크로드로 1개의 ec2 인스턴스가 구성되어 있습니다.
- cluster 측 워크로드로 3개의 ec2 인스턴스(워커 노드)가 구성되어 있습니다
EKS 노드 확인
kubectl get node -A
NAME STATUS ROLES AGE VERSION
ip-10-0-0-25.ap-northeast-2.compute.internal Ready <none> 13m v1.30.9-eks-5d632ec
ip-10-0-22-224.ap-northeast-2.compute.internal Ready <none> 13m v1.30.9-eks-5d632ec
ip-10-0-41-10.ap-northeast-2.compute.internal Ready <none> 13m v1.30.9-eks-5d632ec
Terraform으로 구축한 인프라 리소스(Client/Cluster VPC, 서브넷, EC2 인스턴스, EKS 노드)가 정상적으로 배포된 것을 확인했습니다.
VPC Lattice를 통한 Client to Server 통신 테스트
인프라가 정상적으로 구성되었는지 확인하기 위해, 클라이언트 워크로드에서 서버 워크로드로 실제 네트워크 통신이 가능한지 테스트를 진행합니다.
client 서버에 ssh 접속(sesson-manager)
AWS 콘솔에서 인스턴스 목록을 확인한 후, client라는 이름의 EC2 인스턴스를 선택합니다.
상단에 있는 Connect 버튼을 클릭하고, 이후 Session Manager 탭을 선택한 뒤, 하단의 Connect 버튼을 눌러 SSH 세션을 시작합니다.
Client 애플리케이션에서 Server 애플리케이션으로 통신 테스트
클라이언트 인스턴스에 접속한 후, 터미널에서 서버 애플리케이션으로 HTTP 요청을 전송합니다. 응답을 오는 것으로 보아, 통신이 정상적으로 이루어지는 것을 확인할 수 있습니다.
아래 kubectl 명령을 통해 server pod의 애플리케이션 로그를 확인해 보면 클라이언트에서 서버로 통신이 성공적으로 이루어졌음을 확인할 수 있습니다.
kubectl logs -f deployment/server -n apps --all-containers=true --since=1m
2025/04/26 09:14:25 Receiving %!(EXTRA *http.Request=&{GET / HTTP/1.1 1 1 map[Accept:[*/*] Accept-Encoding:[*] Connection:[close] User-Agent:[VpcLattice-HealthChecker/1.0]] {} <nil> 0 [] true 169.254.171.196 map[] map[] <nil> map[] 169.254.171.196:4719 / <nil> <nil> <nil> 0xc0001a59c0})
어떻게 EC2 파드에서 해당 도메인으로 파드에 통신이 되는 걸까?
client의 터미널에서 nslookup 결과를 보면, 요청하려는 도메인이 내부적으로 VPC Lattice가 생성한 DNS 엔드포인트로 변환되어 IP 주소를 반환하고 있습니다. 이 IP는 클러스터 내부의 서버 Pod와 연결되는 경로를 가리킵니다
VPC Lattice 구성 확인
Amazon VPC Lattice 콘솔에 접속해 Service 항목을 조회하면, nslookup에서 확인한 도메인과 매칭되는 Lattice Service를 찾을 수 있습니다. 이 서비스는 VPC Lattice를 통해 클라이언트 요청을 서버 워크로드로 라우팅 하는 역할을 합니다.
또한, Lattice Target Group 상세 페이지로 이동하면 Registered targets 섹션에서 연결된 IP 주소와 포트 정보를 확인할 수 있습니다.
Amazon VPC Lattice는 클라이언트 요청을 Target Group에 등록된 IP와 포트로 자동으로 전달하며, 이 대상은 EKS 클러스터 내부의 Server Pod임을 의미합니다.
결론적으로, 클라이언트는 복잡한 네트워크 라우팅을 신경 쓰지 않고, Lattice가 제공하는 도메인 이름을 통해 서버 애플리케이션에 접근할 수 있게 되는 것입니다
AWS Gateway API Controller의 동작 체크
앞선 테스트를 통해 클라이언트 워크로드가 서버 워크로드와 통신할 수 있음을 확인했습니다.
이러한 통신 환경을 가능하게 만들기 위해, EKS 클러스터 내에서는 추가적인 리소스 구성이 필요합니다.
바로 GatewayClass, Gateway, HTTPRoute와 같은 Kubernetes 리소스입니다.
이 리소스들은 AWS Gateway API Controller에 의해 관리되며, 생성된 정보를 기반으로 VPC Lattice 네트워크 환경이 자동으로 구축(프로비저닝)됩니다.
AWS Gateway API Controller 로그 확인
AWS Gateway API Controller는 클러스터 내에 생성된 GatewayClass, Gateway, HTTPRoute 리소스를 감지하여, 이에 대응하는 VPC Lattice 설정을 동적으로 구성합니다.
kubectl logs deployment/aws-gateway-api-controller-aws-gateway-controller-chart -n aws-application-networking-system --all-containers=true
로그를 확인하면, 다음과 같은 작업 흐름을 볼 수 있습니다.
• server라는 이름의 Kubernetes Service와 my-services라는 Gateway 리소스를 감지하고, 관련 리소스에 대한 Reconcile 작업을 시작합니다.
• 이후, server-apps라는 이름을 가진 HTTPRoute 리소스(metadata.name과 metadata.namespace 기반)를 기반으로,
server.example.com이라는 커스텀 도메인을 설정하고 VPC Lattice Service를 구성합니다.
• 생성된 VPC Lattice Service에 대해 Listener Rule을 만들고, HTTPRoute 매니페스트에 정의된 PathPrefix를 적용하여 요청 경로를 매핑합니다.
• 또한, backendRefs를 참조하여 대상 그룹(Target Group)을 생성하고, 해당 그룹에 연결된 Service의 Pod IP와 Port를 자동으로 등록합니다
이 과정을 통해 Gateway API 리소스들이 VPC Lattice의 네트워크 구성으로 자연스럽게 변환되고, 별도 수작업 없이 서비스 통신 환경이 구축됩니다.
생성된 리소스 확인
생성된 Gateway API 리소스들을 실제로 조회하여 상태를 확인해 보겠습니다
# GatewayClass 조회
kubectl get gatewayclasses.gateway.networking.k8s.io
NAME CONTROLLER ACCEPTED AGE
amazon-vpc-lattice application-networking.k8s.aws/gateway-api-controller True 27m
# Gateway 조회
kubectl get gateways.gateway.networking.k8s.io -A
NAMESPACE NAME CLASS ADDRESS PROGRAMMED AGE
apps my-services amazon-vpc-lattice True 28m
# HTTPRoute 조회
kubectl get httproutes.gateway.networking.k8s.io -A
NAMESPACE NAME HOSTNAMES AGE
apps server ["server.example.com"] 27m
# AWS Gateway API Controller Pod 상태 확인
kubectl get pod -n aws-application-networking-system
NAME READY STATUS RESTARTS AGE
aws-gateway-api-controller-aws-gateway-controller-chart-74jxn4b 1/1 Running 0 29m
aws-gateway-api-controller-aws-gateway-controller-chart-74kd8fn 1/1 Running 0 29m
Controller의 환경 변수로 확인하는 VPC Lattice 설정
추가로, AWS Gateway API Controller의 환경 변수를 확인하면, VPC Lattice와의 연결 정보가 세팅되어 있는 것도 확인할 수 있습니다.
AWS Gateway API Controller는 EKS 클러스터에 생성된 GatewayClass, Gateway, HTTPRoute 리소스를 모니터링하여, 자동으로 VPC Lattice의 네트워크 구성요소를 생성하고 관리합니다. 이를 통해 개발자는 Kubernetes 리소스만 정의하면 복잡한 네트워크 구성 없이 서비스 간 통신을 쉽게 설정할 수 있습니다.
[실습 2] - AWS VPC Lattice를 활용하여 멀티 클러스터 환경 간 안전한 통신을 손쉽게!
이번 실습에서는 Amazon EKS Blueprints for Terraform: Amazon VPC Lattice - Multi-cluster secure communication 패턴을 활용하여, 멀티 클러스터 환경 간 안전한 통신 방법을 실습합니다.
앞서 단일 클러스터 내에서의 통신을 다뤘다면, 이 패턴에서는 Amazon VPC Lattice와 IAM 기반 인증(authorization)을 활용하여, 서로 다른 VPC에 존재하는 두 개의 EKS 클러스터 간 통신을 안전하게 연결하는 방법을 보여줍니다. 특히 서로 다른 네트워크 대역, 심지어 CIDR이 겹칠 수 있는 환경에서도 통신이 가능하도록 구성하는 것이 핵심입니다.
또한 이 방식을 통해 프라이빗 NAT 게이트웨이나 Transit Gateway와 같은 전통적인 네트워크 구성 없이도 클러스터 간 통신이 가능하다는 점을 강조합니다.
각 클러스터에는 Envoy 사이드카 프록시와 HTTPRoute를 사용해 서비스를 배포하고, Kyverno를 통해 사이드카 주입 및 iptables 설정을 자동화했습니다. 또한 IAM Auth Policy를 통해 통신 권한을 세밀하게 제어하고, AWS Private CA와 Certificate Manager를 활용해 TLS 인증서를 관리했습니다
Terraform 코드 준비 및 프로비저닝
멀티 클러스터 통신 실습을 위해 필요한 인프라를 Terraform을 사용해 프로비저닝 합니다. 이번에는 두 단계로 나누어 진행합니다. 먼저 공통 환경(environment)을 구성하고, 이후 각 클러스터(cluster)를 배포합니다.
environment 프로비저닝
Environment 환경에서는 실습에 필요한 사전 인프라를 준비합니다. 여기에는 Route53, VPC Lattice, IAM Role, ACM 인증서 등이 포함됩니다. 이 리소스들은 이후 클러스터 통신 시 필요한 기반 역할을 하게 됩니다
먼저, 터미널에서 다음 경로로 이동합니다.
cd ~/terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/environment/
이후 main.tf 파일을 열어 7번째 줄의 region 설정을 수정합니다. 기본값은 us-west-2로 되어 있으므로, 이를 서울 리전인 ap-northeast-2로 변경합니다.
수정이 완료되면, 아래 명령어를 실행하여 environment 인프라를 프로비저닝합니다.
terraform init
terraform apply --auto-approve
cluster 프로비저닝
이제 두 개의 EKS 클러스터와 데모 애플리케이션을 구성하는 단계입니다.
먼저 클러스터 관련 코드를 준비하기 위해 아래 경로로 이동합니다.
cd ~/terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/cluster
마찬가지로 main.tf 파일을 열고, 31번째 줄의 region 설정을 ap-northeast-2로 수정합니다.
이어서 아래 명령을 통해 첫 번째 EKS 클러스터를 배포합니다.
./deploy.sh cluster1
# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`
이어서 아래 명령을 통해 두 번째 EKS 클러스터를 배포합니다.
./deploy.sh cluster2
# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`
배포 결과 확인
# eks-cluster1 확인
kubectl --context eks-cluster1 get node A
# eks-cluster2 확인
kubectl --context eks-cluster2 get node A
프로비저닝 된 인프라 확인
Terraform으로 인프라를 구축한 뒤, AWS 콘솔을 통해 실제 리소스가 정상적으로 생성되었는지 확인해 보겠습니다.
Amazon EKS 클러스터 확인
Amazon EKS 콘솔에 접속해 보면 아래와 같이 두 개의 EKS 클러스터가 생성된 것을 확인할 수 있습니다.
Pod Identity 연결 확인
EKS 콘솔 내에서 Access > Pod Identity associations 메뉴로 이동하면, Service Account와 IAM Role 간 연결 상태를 확인할 수 있습니다.
실습 환경에서는 vpc-lattice-sig4-client라는 이름의 IAM Role이, apps 네임스페이스의 default 서비스 어카운트에 연결(associate) 되어 있는 것을 볼 수 있습니다.
IAM Role을 클릭해 보면 IAM 콘솔로 이동하며, 여기서 해당 Role이 부여받은 권한을 확인할 수 있습니다.
특히 이 Role은 ACM Private CA(PCA)에 대한 액세스 권한과, VPC Lattice Service에 요청을 보낼 수 있는 Invoke 권한을 포함하고 있습니다.
IAM Role은 데모 애플리케이션 Pod에 적용되어, TLS 인증서 기반 통신과 Lattice 서비스 호출 권한을 갖추게 됩니다. 이로써 각 클러스터에서 외부로 나가지 않고 안전하게 통신할 수 있는 기반이 마련됩니다.
VPC Lattice 서비스 확인
VPC 콘솔 > PrivateLink and Lattice > Service networks 순으로 콘솔을 이동하면 아래와 같이 VPC Lattice Service network 콘솔로 이동할 수 있습니다.
각 Lattice 서비스가 커스텀 도메인 이름(demo-cluster1.example.com, demo-cluster2.example.com 등)과 매핑되어 있으며, Amazon Route53 Private Hosted Zone에 자동으로 연결되어 있다는 것입니다.
또한, 각 서비스는 TLS 인증을 위해 Private CA를 사용하고 있다는 점도 함께 확인할 수 있습니다.
이러한 구성을 통해, 사용자 정의 도메인을 통한 TLS 보안 통신과 내부 DNS 기반 서비스 디스커버리가 구축된 것을 확인할 수 있습니다.
EKS 클러스터 별 애플리케이션
이제 각각의 EKS 클러스터에 배포된 데모 애플리케이션이 정상적으로 설치되어 있는지 확인해 보겠습니다.
EKS Cluster 1
먼저, eks-cluster-1으로 kubectl 컨텍스트를 전환합니다.
kubectl config use-context eks-cluster1
컨텍스트 전환이 완료되면, 현재 클러스터에 배포된 파드를 조회합니다. 여기서 demo-cluster1-v1이라는 데모 애플리케이션 파드가 정상적으로 생성되어 있음을 확인할 수 있습니다.
이어서, 해당 파드의 상세 구성을 살펴보겠습니다.
구성을 살펴보면, Init Containers를 통해 envoy-sigv4 프록시 컨테이너를 위한 IPTables 설정이 사전에 적용된 것을 볼 수 있습니다. 이 과정을 통해, 이후 envoy-sigv4가 클러스터 외부(즉, VPC Lattice 서비스)로 나가는 트래픽을 적절히 중계할 수 있도록 준비가 완료됩니다.
envoy-sigv4란?
envoy-sigv4는 Amazon VPC Lattice 같은 AWS 서비스에 연결할 때, SigV4 인증을 자동으로 수행해 주는 프록시 컨테이너입니다. 이를 통해 Pod 내부 애플리케이션이 별도의 AWS 인증 로직을 신경 쓰지 않고 외부 서비스와 안전하게 통신할 수 있게 됩니다
EKS Cluster 2
이번에는 두 번째 클러스터인 eks-cluster-2로 kubectl 컨텍스트를 전환합니다.
kubectl config use-context eks-cluster2
컨텍스트를 변경한 후, 해당 클러스터에 배포된 파드 목록을 조회합니다.
여기서도 demo-cluster2-v1과 같은 데모 애플리케이션 파드가 정상적으로 생성된 것을 확인할 수 있습니다.
통신 테스트 및 동작방식 확인
제 두 클러스터 간 통신이 정상적으로 이루어지는지 직접 테스트하고, 그 과정에서 IAMAuthPolicy의 동작 방식까지 확인해 보겠습니다.
Cross-Cluster 통신 테스트
먼저, eks-cluster-1에 배포된 pod-1에서 eks-cluster-2의 pod-2로 HTTP 요청을 전송합니다.
테스트 결과, 요청이 성공적으로 전달되었습니다.
동일 클러스터 내 통신 테스트
이 경우에는 요청이 실패합니다. 오류 메시지를 보면, AccessDeniedException이 발생하며, 접근이 거부된 것을 확인할 수 있습니다.
이는 실습 환경에 적용된 IAMAuthPolicy 설정에 의해 의도된 동작입니다.
IAMAuthPolicy를 통한 권한 제어
IAMAuthPolicy는 각 요청에 대해, 클러스터 이름이 eks-cluster2이고, 네임스페이스가 apps일 때만 VPC Lattice Service Invoke를 허용하도록 설정되어 있습니다
즉, eks-cluster-1의 Pod은 eks-cluster-2의 서비스로만 트래픽을 보낼 수 있으며, 자기 자신이나 다른 대상에는 접근할 수 없습니다. 이처럼 통신 가능 대상을 세밀하게 제어할 수 있는 점이 VPC Lattice의 강력한 보안 기능 중 하나입니다.
IAMAuthPolicy는 Gateway, HTTPRoute, GRPCRoute를 통해 이동하는 트래픽에 대해서만 권한 부여를 수행할 수 있습니다. 클라이언트가 직접 k8s 서비스 DNS로 트래픽을 전송하는 경우에는 권한 부여가 적용되지 않습니다.
IAMAuthPolicy란?
Amazon VPC Lattice 환경에서 서비스 간 통신을 IAM 정책처럼 관리할 수 있도록 해주는 Kubernetes 리소스입니다.
즉, “누가 누구에게 통신할 수 있는지”를 Kubernetes 객체 형태로 정의하여,
서비스 접근 제어를 IAM 정책 방식으로 통합 관리할 수 있게 해 줍니다.
Kyverno의 역할
Kyverno는 Kubernetes 네이티브 정책 관리 도구로, 이 실습에서 중요한 보안 기능을 제공합니다. Admission Controller를 기반으로 작동하며, Pod 생성 시 자동으로 사이드카 프록시를 주입하는 역할을 수행합니다. 이를 통해 모든 애플리케이션 트래픽이 안전하게 관리될 수 있습니다.
(실습 리소스에는 kyverno가 포함되어 있습니다. 무슨 역할을 하는지 자세히 알아봅시다.)
아래 스크립트를 통해 다음과 같은 핵심 초기화 작업을 수행합니다
1. 트래픽 제어
- iptable 규칙을 통해 모든 애플리케이션 트래픽이 envoy 프록시를 통과하도록 강제합니다
- 이를 통해 직접적인 외부 통신을 차단하고 모든 트래픽을 중앙에서 관리할 수 있습니다
2. 인증서 관리
- envoy 컨테이너는 부팅 시 Private Certificate Authority(PCA)에서 인증서를 자동으로 검색합니다
- 이 인증서를 통해 VPC Lattice 서비스와의 안전한 통신이 가능해집니다
3. 초기화 프로세스 : Launch.sh 스크립트는 다음과 같은 핵심 초기화 작업을 수행합니다:
- PCA 인증서 획득
- SigV4 서명 설정
- VPC Lattice 서비스 연결 초기화
이 데모에서 사용된 envoy 프록시, iptables 및 http-server 이미지를 만드는 데 사용된 Dockerfile은 여기에서 찾을 수 있습니다.
이러한 구성으로 인해 애플리케이션은 안전하게 VPC Lattice 서비스와 통신할 수 있으며, 모든 트래픽이 중앙에서 관리되고 모니터링될 수 있습니다.
'AWS > EKS' 카테고리의 다른 글
| ML Infra with EKS : AI 워크로드에 대한 컨테이너 사용 (1) | 2025.04.20 |
|---|---|
| AWS EKS 업그레이드, In-place부터 Blue/Green 마이그레이션까지 (1) | 2025.04.02 |
| EKS 서버리스 서비스 간략히 알아보기(Fargate & EKS AutoMode) (0) | 2025.03.23 |
| EKS Karpenter 기본 사용(Node AutoScaling) (1) | 2025.03.05 |
| EKS 기본 스토리지(EBS + EFS CSI Driver, Instance Store) (0) | 2025.02.23 |
