| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
- vpc cni
- prometheus
- kiali
- service mesh
- Kind
- loadbalancer
- envoy
- grafana
- Ingress
- Istio
- aws eks
- istio-proxy
- kmesh
- argocd
- docker
- Ambient
- 엠비언트모드
- envoy filter
- Kubernetes
- CICD
- K8S
- vm support
- 데이터 플레인 확장
- Observability
- Jenkins
- CNI
- life of packet
- vagrant
- istio traffic flow
- WSL
- Today
- Total
WellSpring
AEWS 12주차 - Amazon VPC Lattice for Amazon EKS 본문
목차
- 0. 실습환경 구성
- 1. 마이크로 서비스 이해하기
- Amazon EKS에서 VPC Lattice로 Gateway API를 사용하기 위한 요구사항
- 2. 실습
- 1. 주요 컴포넌트
- 2. 주요 흐름 및 프로세스
※ 본 게재 글은 gasida님의 'AEWS' 스터디 중 방신철님의 강의내용과 실습예제 및 AWS 공식 Blueprint - lattice 관련 내용을 참고하여 작성하였습니다.
0. 실습환경 구성
[ 사전 준비 사항 ]
☞ 원활한 실습 진행을 위해 하기 도구를 설치해 주세요.
[ 주의 사항 ]
- AWS 계정에는 기본적으로 VPC 생성 quota가 5로 설정되어 있습니다. 이번 실습에서는 Amazon EKS 클러스터 구성 시, 새로운 VPC를 생성하므로 이 quota에 걸릴 수 있습니다. 따라서 원활한 실습 진행을 위해서는 VPC quota를 늘려주시거나 혹은 2개 이상의 VPC를 생성할 수 있는 환경을 마련해주세요.
- 실습을 원활하게 진행하기 위해 aws cli를 사용하는 IAM User에 충분한 권한이 있도록 설정해주시기 바랍니다. 실습 시에만 AdministratorAccess 권한을 사용하시고, 실습 이후에는 AdministratorAccess 권한을 반드시 제거해주세요.
- 또한, 실습 계정에 대하여 반드시 MFA 설정 및 Credentials 설정이 외부로 노출되지 않도록 안전하게 보관해주세요.
1. 마이크로 서비스 이해하기
1.1 Kubernetes의 애플리케이션 네트워킹 변화 과정
☞ 쿠버네티스의 네트워킹 스택은 마이크로서비스 아키텍처의 발전과 함께 진화해 왔습니다.
1) 단일 클러스터 구성
단일 클러스터 내부에 배포되는 Kubernetes 서비스들은 클러스터 내부의 DNS 인 CoreDNS 및 Ingress 리소스를 통해서 내부 서비스 간 통신 및 외부로의 통신을 모두 네이티브하게 구현할 수 있음
[ 구성 및 특징 ]
- 기본 Service 리소스로 시작
- NodePort, ClusterIP, LoadBalancer 타입의 서비스 구현
- Ingress 활용
- 경로 기반 라우팅으로 서비스 구조화 및 관리 개선
- SSL/TLS 종단점 제공을 통한 보안 강화
- 단순한 내부 통신과 외부 노출 기능에 중점
2) 멀티 클러스터 구성 ( Ingress VS. Service Discovery VS. Service Mesh )
애플리케이션이 진화하고, 조직이 발전하면서 서비스들이 독자적인 VPC 및 Kubernetes 클러스터에 운영되기 시작하면서 클러스터 운영자들은 이런 VPC 간 / 클러스터 간의 애플리케이션 네트워킹에 대해서 고민하게 됨
A. Service Discovery의 등장 배경
- 마이크로서비스 환경, 특히 Kubernetes 기반의 인프라에서는 다음과 같은 상황이 빈번합니다:
- 애플리케이션은 Pod 단위로 실행되며, Pod는 재시작 시마다 IP가 바뀜
- Auto Scaling, Rolling Update, Node 재시작 등으로 인해 서비스 인스턴스의 위치가 동적으로 바뀜
- 수동으로 IP를 관리하거나 config에 직접 주소를 박아 넣는 건 비효율적이고 위험함
☞ 다양한 서비스 간에 구분과 연결 관리를 위해 Service Discovery 가 필요하게 됨
B. Service Discovery의 특징 및 패턴
1. 서비스 레지스트리 기반
- 각 서비스 인스턴스는 자기 정보를 중앙 레지스트리에 등록(register) 합니다.
- 다른 서비스는 이 레지스트리를 통해 동적으로 위치를 조회(discover) 합니다.
- 예: Consul, Eureka, etcd, 그리고 Kubernetes 자체가 가진 CoreDNS
2. 자동 등록 및 해제
- 서비스가 올라오면 자동으로 등록되고, 내려가면 자동 제거됩니다.
- 헬스체크 기반으로 불용 인스턴스는 빠르게 감지되어 제외됩니다.
- 운영자가 별도로 위치를 추적하거나 관리할 필요가 없습니다.
3. 클라이언트/서버 사이드 디스커버리
- Client-side: 서비스 호출자가 직접 레지스트리를 조회하고 인스턴스를 선택 (예: Netflix OSS)
- Server-side: 로드 밸런서나 프록시(Gateway)가 위치를 조회하고 전달 (예: Kubernetes + Istio, Envoy 기반)
☞ 2개 이상의 VPC 구조에서 서비스 연결을 생각해 보자!!
- AWS의 경우에는 VPC Peering, PrivateLink, AWS Transit Gateway 등의 다양한 옵션을 통해 각 VPC를 연결함
C. Service Mesh
☞ 마이크로 서비스가 늘어나면서 네트워크의 복잡성 증가 및 공통 기능 적용(서킷브레이커, 재시도 로직, 타임아웃, 인증 등)의 요구사항 이 생김
1) 서비스 Mesh의 특징
- AWS AppMesh, Istio, Linkerd 등으로 트래픽 관리, 보안, 관찰성 강화
- 마이크로서비스 간 통신의 복잡성 추상화
- 서비스 디스커버리와 로드밸런싱의 고도화 및 자동화 (서비스 메시는 서비스 디스커버리를 기반으로 함)
2) 동작 원리
- 컨테이너 애플리케이션 앞에 AWS AppMesh, Istio, Linkerd 등의 사이드카 프록시 컨테이너를 배치
- 컨테이너 애플리케이션으로 들어오고 나가는 모든 트래픽은 프록시 컨테이너를 통해 라우팅 되는 방식
- 프록시 컨테이너의 역할
- 데이터 영역
- 사이드카가 요청을 가로챔 → 요청을 별도의 네트워크 연결로 캡슐화 → 소스 프록시와 대상 프록시 간에 안전하고 암호화된 채널을 설정
- 서비스 간 로우 레벨 메시징을 처리
- 서킷 브레이킹, 요청 재시도와 같은 기능을 구현하여 복원력을 높이고 서비스 성능 저하를 방지
- 제어 영역
- 메시 내의 모든 서비스를 추적하는 서비스 레지스트리 기능 수행
- 신규 서비스 자동 검색 기능 및 비활성 서비스 제거 기능 수행
- 지표, 로그, 분산 추적 정보와 같은 텔레메트리 데이터의 수집 및 집계
- 데이터 영역
[ 복잡한 서비스 환경에서의 App. Networking 의 한계점 ]
☞ Ingress와 Service Discovery, Service Mesh는 Kubernetes에서 트래픽 라우팅을 관리하는 대표적인 방식이었지만, 다음과 같은 한계점을 가지고 있었습니다.
| 항목 | Ingress | Service Discovery | Service Mesh |
| 프로토콜 지원 | 주로 HTTP/HTTPS (L7), TCP/UDP는 제한적 | 모든 프로토콜 가능 (기본은 위치만 제공) | L4~L7 전부 지원 (gRPC, mTLS, TCP, HTTP 등) |
| 트래픽 제어 | 단순 URL/호스트 기반 라우팅 | 트래픽 분배 불가 | 세분화된 라우팅 (A/B, Canary, Retry 등 가능) |
| 보안 기능 | TLS termination 정도, 세밀한 정책 부족 | 보안 기능 없음 | mTLS, 인증/인가, 접근제어 정책 지원 |
| 관찰 가능성 (Observability) | 일부 로깅, 메트릭 가능, 확장 어려움 | 로깅/메트릭 없음 | 전체 호출 체인의 트레이싱, 모니터링 가능 |
| 설치/구성 복잡도 | 비교적 단순 (컨트롤러 선택이 중요) | Kubernetes는 기본 제공 (CoreDNS 기반) | 복잡함. Sidecar, Control Plane, 설정 수 많음 |
| 성능 오버헤드 | 낮음 (기본 프록시만 운영) | 없음 | 높음 (Pod마다 Envoy Sidecar → CPU/Memory 증가, latency 추가) |
| 확장성 문제 | 많은 라우팅 규칙 시 성능 저하 가능 | 대규모 환경에서도 DNS 수준으로 동작 | Sidecar 수 증가로 리소스 부담, 관리 복잡도 커짐 |
| 디버깅 난이도 | 비교적 단순 (Ingress Pod나 LoadBalancer 확인) | 간단함. DNS 해석만 확인하면 됨 | Sidecar 경유로 네트워크 디버깅 어려움, 복잡한 트래픽 흐름 분석 필요 |
| 제공하는 기능의 범위 | 외부 → 내부 트래픽 라우팅에 초점 | 내부 서비스 위치 조회에 초점 | 서비스 간 트래픽 제어, 보안, 가시성 등 포함한 전반적 제어 |
| 기타 한계 | Ingress Controller마다 기능 차이 큼 (Vendor Lock-in 우려) |
상태 비정상 서비스 제거/탐지 미흡 | 도입 효과 대비 리소스 소비 클 수 있음 경량 서비스에는 과도한 기능 |
[ 각 서비스의 특징 비교 ]
| 항목 | Ingress | Service Discovery | Service Mesh |
| 트래픽 제어 | 기본적인 HTTP 라우팅 | 없음 | 정교한 정책 기반 제어 가능 |
| 프로토콜 지원 | 주로 HTTP | 상관없음 | 모든 L4~L7 |
| 복잡도 | 낮음 | 낮음 | 매우 높음 |
| 보안 기능 | TLS 위주 | 없음 | mTLS, 인증/인가 가능 |
| 리소스 사용 | 낮음 | 낮음 | 높음 (Sidecar 등) |
| 운영 난이도 | 중 | 낮음 | 높음 |
| 모니터링 | 일부 | 부족 | 풍부 (메트릭, 트레이싱 등) |
[ 요약 ]
- Ingress: 외부 트래픽 진입은 가능하나, L7 라우팅에 한정되고 기능 차이가 많음
- Service Discovery: 기초적 위치 탐색에 충실하나, 트래픽 제어나 보안은 취약
- Service Mesh: 강력한 기능 제공하지만, 운영·리소스 복잡도 상당
1.2 Gateway API의 등장
☞ 이러한 한계를 극복하기 위해 SIG-NETWORK 커뮤니티에서 Gateway API가 고안되었습니다. Gateway API는 다음과 같은 목표를 가지고 설계되었습니다.
- 역할 기반 설계: 인프라 관리자, 클러스터 운영자, 애플리케이션 개발자 각각의 요구사항을 반영할 수 있도록 설계되었습니다.
- 범용성: HTTP, HTTPS, gRPC 등 다양한 프로토콜을 지원하고 확장성 있게 설계되었습니다.
- 표준화: Kubernetes Ingress와 같이 포터블한 표준 API가 되도록 설계되었습니다.
- 확장성: 멀티 클러스터 환경 및 다양한 VPC 간의 원활한 네트워크 통합이 가능하도록 설계되었습니다.
[ 주요 구성요소 ]
- 공통 구성을 가진 게이트웨이 집합을 정의하며, 이 클래스를 구현하는 컨트롤러에 의해 관리됩니다.
- 게이트웨이는 각기 다른 컨트롤러에 의해 다양한 구성으로 구현될 수 있습니다. 게이트웨이는 반드시 해당 클래스를 구현하는 컨트롤러의 이름을 포함하는 GatewayClass를 참조해야 합니다.
- 외부 트래픽을 수신하고 내부 서비스로 라우팅하는 진입점을 정의합니다.
- 하나 이상의 Route 리소스와 연결될 수 있습니다.
- 트래픽을 특정 서비스로 매핑하는 프로토콜 별 규칙을 정의합니다.
- HTTPRoute, TLSRoute, TCPRoute, UDPRoute, GRPCRoute 등이 있습니다.
- Gateway 리소스에 연결되어 트래픽을 대상 서비스로 전달합니다.
☞ 이 계층적 구조를 통해 인프라 관리자는 GatewayClass와 Gateway를 관리하며 전체 인프라의 일관성을 유지하고, 애플리케이션 개발자는 다양한 Route를 통해 자신의 애플리케이션에 대한 세부 라우팅 규칙을 독립적으로 정의할 수 있습니다.
AWS는 이러한 계층적 구조를 Amazon VPC Lattice와 통합하여 제공함으로써, 클라우드 네이티브 환경에서의 네트워킹 요구사항을 효과적으로 충족시킵니다.
1.3 Gateway API Controller
Gateway API도 다른 Kubernetes 컴포넌트와 마찬가지로 Controller를 통해 동작합니다. 여러 벤더 별 Gateway API Controller 구현체를 참조하고 싶다면 여기를 확인해보세요. AWS에서는 AWS Gateway API Controller를 제공하고 있습니다.
☞ Amazon VPC Lattice란?
- Amazon VPC Lattice 는 마이크로서비스 간의 통신을 네트워크가 아닌 "서비스 단위"로 관리하도록 설계된, 보안·라우팅·가시성을 통합한 완전 관리형 플랫폼입니다. VPC Lattice는 단일 VPC 내에서는 물론, 계정 간 여러 VPC에 걸쳐 서비스를 연결하는 데 활용할 수 있습니다.
1) 주요 목적
- 간단하고 표준화된 연결 방식을 제공
- 애플리케이션 중심으로 네트워크를 설계할 수 있도록 지원
- VPC, 서브넷, IP 주소에 얽매이지 않고 서비스 간 통신을 구성
- 복잡한 VPC Peering, Transit Gateway, Load Balancer 설정 없이도 서비스 연결 가능
- Zero Trust 보안 모델을 적용한 서비스 간 통신 제공
2) 구성 요소
| 구성 요소 | 설 명 |
| Service Network | 서로 통신할 수 있는 서비스 그룹. 일종의 “서비스 간 통신 허용 영역” |
| Service | 개별 서비스 단위. URL 또는 DNS 이름으로 노출됨 |
| Target Group | 각 서비스가 실제로 트래픽을 라우팅하는 대상 (EC2, ECS, Lambda, IP 등) |
| Auth Policy | 서비스 접근 권한 제어 (IAM 기반) |
| Routing Policy | 서비스 내의 트래픽 분배 및 라우팅 규칙 |
☞ Amazon VPC Lattice는 Service, Service Network, Auth Policy, Service Directory의 네 가지 핵심 구성 요소로 이루어져 있습니다. 각 구성 요소의 특징과 역할을 살펴보겠습니다. 자세한 내용은 이 문서를 참조해주세요.
(1) 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 컴퓨팅 서비스를 대상으로 설정 가능
- 상태 확인을 통한 트래픽 안정성 보장
(2) Service Network
Service Network는 VPC Lattice의 핵심 구성 요소로, 여러 서비스를 논리적으로 그룹화하고 이들 간의 통신을 관리합니다. 하나 이상의 VPC를 Service Network에 연결하여 해당 네트워크 내의 서비스 간 통신을 가능하게 합니다.
Service Network의 주요 특징은 다음과 같습니다.
- 여러 VPC와 서비스를 단일 네트워크로 통합
- 계정 간, 리전 간 서비스 연결 지원
- 중앙 집중식 액세스 제어 및 모니터링 제공
- VPC 연결을 통한 Service Network 내 서비스에 대한 접근 관리
(3) Auth Policy
Auth Policy는 VPC Lattice 서비스에 대한 액세스를 제어하는 IAM 기반 정책입니다. 이를 통해 특정 IAM 보안 주체나 역할이 서비스에 접근할 수 있는지 여부를 세밀하게 제어할 수 있습니다.
Auth Policy의 주요 기능은 다음과 같습니다.
- IAM 기반의 세분화된 접근 제어
- 서비스 레벨 또는 서비스 네트워크 레벨에서 적용 가능
- HTTP 메소드, 경로, 헤더 등을 기준으로 조건부 액세스 규칙 설정
- AWS 리소스 간의 안전한 통신 보장
(4) Service Directory
Service Directory는 모든 VPC Lattice 서비스를 중앙에서 검색하고 관리할 수 있는 카탈로그입니다. 개발자와 운영팀이 사용 가능한 서비스를 쉽게 찾고 접근할 수 있도록 지원합니다.
Service Directory의 핵심 기능은 다음과 같습니다.
- 사용 가능한 모든 서비스의 중앙 집중식 카탈로그 제공
- 서비스 메타데이터 및 설명 관리
- 서비스 검색 및 필터링 기능
- 접근 가능한 서비스에 대한 가시성 제공
3) 주요 특징
1. 서비스 중심 주소 체계
- 서비스 이름으로 라우팅 (my-api.my-network.aws)
- IP 주소, CIDR, Subnet 등 네트워크 계층 고려 없이 연결 가능
2. 계정·VPC 간 통신 지원
- 여러 VPC, 여러 AWS 계정의 서비스들 간에도 보안 연결 지원
- VPC Peering, TGW 없이도 연결 가능
3. 네이티브 보안 정책
- IAM 정책을 통한 세분화된 접근 제어
- mTLS, 인증 헤더 등의 보안 통신 가능
4. 로드밸런싱 및 트래픽 정책 내장
- HTTP 요청 기반의 정교한 라우팅 지원
- Canary, weighted routing 등 기본 지원
5. 통합 관찰성
- CloudWatch, X-Ray 기반 모니터링 및 트레이싱 지원
- 호출 지연, 에러율 등도 서비스 단위로 확인 가능
[ Amazon VPC Lattice의 장점 ]
- 여러 VPC, EC2 인스턴스, 컨테이너, 서버리스로 구성한 애플리케이션의 네트워크 구성을 중앙 집중화 할 수 있습니다.
- 별도의 사이드카 프록시를 구성할 필요가 없습니다. (+ 완전 관리형 서비스)
- 복잡한 네트워크 구성을 단순화 해서 쉽게 사용할 수 있습니다.
- IAM 및 SigV4를 통해 각 애플리케이션으로의 보안 구성을 손쉽게 적용 할 수 있습니다.
- CloudWatch, S3, Kinesis Data Firehose를 통해 쉽게 로깅, 트래픽 패턴 분석 등을 수행할 수 있습니다.
☞ Amazon VPC Lattice 구성사례
사용 사례 #1 : 단일 리전의 애플리케이션 간 연결
사용 사례 #2 : 온프레미스에서 AWS에 배포된 애플리케이션으로 접근하는 경우
사용 사례 #3 : 다중 계정 간 애플리케이션의 연결
1.4 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와 통합되어 다음 작업을 수행할 수 있습니다.
- VPC 및 계정 전반에 걸친 서비스 간 네트워크 연결을 원활하게 처리합니다.
- 여러 Kubernetes 클러스터에 걸쳐 있는 VPC Lattice Service를 검색합니다.
- 서비스 간 통신의 보안을 구성하기 위한 깊이 있는 방어 전략을 구현합니다.
- 서비스 간 요청/응답 트래픽을 관찰합니다.
AWS Gateway API Controller는 오픈소스 프로젝트이며, Amazon의 완전한 지원을 받고있습니다.
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 설치 및 구성 방법에 대해서는 이 문서를 참조하세요.
2. 실습
2.1 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을 사용하여 노출된 서비스에 대한 사용자 지정 도메인 이름을 구성하는 방법을 보여줍니다.
[ Terraform 코드 살펴보기 ]
아래 그림과 같이 IDE를 통해, terraform-aws-eks-blueprints 디렉토리를 엽니다.
이후 페이지 왼쪽 메뉴바의 terraform-aws-eks-blueprints > patterns > vpc-lattice > client-server-communication 순서로 폴더를 엽니다.
▶ client.tf 살펴보기
client.tf 파일을 살펴보겠습니다. 이 파일에서는 VPC Lattice를 통해 EKS Cluster의 애플리케이션으로 요청을 전달하는 클라이언트 역할을 하는 리소스에 대한 명세가 작성되어 있습니다.
client 모듈에서는 프로비저닝 할 EC2 인스턴스에 대한 명세가 적혀있습니다.
- 인스턴스 유형은 t2.micro 입니다.
- AmazonSSMManagedInstanceCore IAM Role을 설정합니다.
- client_sg 모듈을 참조하여 Security Group을 설정합니다.
module "client" {
source = "terraform-aws-modules/ec2-instance/aws"
version = "~> 5.0"
name = "client"
instance_type = "t2.micro"
subnet_id = module.client_vpc.private_subnets[0]
create_iam_instance_profile = true
iam_role_description = "IAM role for client"
iam_role_policies = {
AmazonSSMManagedInstanceCore = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}
vpc_security_group_ids = [module.client_sg.security_group_id]
tags = local.tags
}
이어서 vpc_endpoints 모듈에서는 client에서 Systems Manager를 사용하기 위한 VPC Endpoint를 구성하기 위한 명세가 적혀있습니다.
- VPC Endpoint에서 구성할 서비스는 ssm, ssmmessages, ec2messages 입니다.
- 적용할 서브넷은 client_vpc 모듈을 참조하여 private_subnets을 대상으로 합니다.
- endpoint_sg 모듈을 참조하여 Security Group을 설정합니다.
module "vpc_endpoints" {
source = "terraform-aws-modules/vpc/aws//modules/vpc-endpoints"
version = "~> 5.0"
vpc_id = module.client_vpc.vpc_id
endpoints = { for service in toset(["ssm", "ssmmessages", "ec2messages"]) :
replace(service, ".", "_") =>
{
service = service
subnet_ids = module.client_vpc.private_subnets
private_dns_enabled = true
tags = { Name = "${local.name}-${service}" }
}
}
security_group_ids = [module.endpoint_sg.security_group_id]
tags = local.tags
}
그 다음으로는 client의 EC2 인스턴스와 VPC Endpoint에서 사용할 각각의 Security Group(모듈 client_sg 및 endpoint_sg)에 대한 명세가 적혀있습니다.
- client_sg 모듈에서는 EC2 인스턴스의 Egress 설정이 명세되어 있습니다.
- endpoint_sg 모듈에서는 client_vpc의 모듈을 참조하여 private_subnets_cidr_blocks 값에 대해 443 포트를 허용하는 Ingress 설정이 명세되어 있습니다.
module "client_sg" {
source = "terraform-aws-modules/security-group/aws"
version = "~> 5.0"
name = "client"
description = "Security Group for EC2 Instance Egress"
vpc_id = module.client_vpc.vpc_id
egress_with_cidr_blocks = [
{
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = "0.0.0.0/0"
},
]
tags = local.tags
}
module "endpoint_sg" {
source = "terraform-aws-modules/security-group/aws"
version = "~> 5.0"
name = "ssm-endpoint"
description = "Security Group for EC2 Instance Egress"
vpc_id = module.client_vpc.vpc_id
ingress_with_cidr_blocks = [for subnet in module.client_vpc.private_subnets_cidr_blocks :
{
from_port = 443
to_port = 443
protocol = "TCP"
cidr_blocks = subnet
}
]
tags = local.tags
}
마지막으로, client_vpc 모듈에서는 이 모든 client를 위한 리소스가 구성될 VPC에 대한 내용이 명세되어 있습니다.
- client vpc에 대한 cidr 값은 main.tf 내에 명세되어있는 client_vpc_cidr 값을 참조합니다.
- 가용영역(azs) 값도 마찬가지로 main.tf 내에 명세되어있는 azs 값을 참조합니다.
- terraform의 cidrsubnet 함수는 주어진 대역 내에서 새 비트 수에 따른 서브네팅을 수행합니다.
module "client_vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 5.0"
name = local.name
cidr = local.client_vpc_cidr
azs = local.azs
private_subnets = [for k, v in local.azs : cidrsubnet(local.client_vpc_cidr, 4, k)]
tags = local.tags
}
▶ eks.tf 살펴보기
이번에는 eks.tf 파일을 살펴보겠습니다. 이 파일에서는 VPC Lattice를 통해 서비스를 제공할 EKS 클러스터의 애플리케이션 및 그 인프라에 대한 명세가 작성되어 있습니다.
가장 첫번째로 볼 수 있는 eks 모듈은 EKS 클러스터에 대한 명세입니다.
- EKS 클러스터의 버전은 1.30 입니다.
- EKS 클러스터의 public access를 허용합니다.
- EKS 클러스터의 VPC 정보는 cluster_vpc 모듈을 참조합니다.
- 관리형 노드그룹을 구성하며, m5.large 인스턴스 유형을 사용하고 최소 3개, 최대 10개, 기본 3개의 노드 갯수를 설정합니다.
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "~> 20.11"
cluster_name = local.name
cluster_version = "1.30"
cluster_endpoint_public_access = true
# Give the Terraform identity admin access to the cluster
# which will allow resources to be deployed into the cluster
enable_cluster_creator_admin_permissions = true
vpc_id = module.cluster_vpc.vpc_id
subnet_ids = module.cluster_vpc.private_subnets
eks_managed_node_groups = {
initial = {
instance_types = ["m5.large"]
min_size = 3
max_size = 10
desired_size = 3
}
}
tags = local.tags
}
다음은 cluster_vpc 모듈입니다. 이 모듈에서는 EKS 클러스터가 프로비저닝 될 VPC에 대한 명세가 담겨있습니다.
- 해당 VPC의 cidr 값은 main.tf 내에 명세되어있는 cluster_vpc_cidr 값을 참조합니다.
- NAT Gateway를 한 개만 프로비저닝 합니다.
- Ingress 구성을 위한 elb 태그를 추가합니다.
module "cluster_vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 5.0"
name = local.name
cidr = local.cluster_vpc_cidr
azs = local.azs
private_subnets = [for k, v in local.azs : cidrsubnet(local.cluster_vpc_cidr, 4, k)]
public_subnets = [for k, v in local.azs : cidrsubnet(local.cluster_vpc_cidr, 8, k + 48)]
enable_nat_gateway = true
single_nat_gateway = true
public_subnet_tags = {
"kubernetes.io/role/elb" = 1
}
private_subnet_tags = {
"kubernetes.io/role/internal-elb" = 1
}
tags = local.tags
}
다음은 addons 모듈입니다. 이 모듈에서는 EKS 클러스터에 설치할 EKS Add-on에 대한 명세가 담겨있습니다. 해당 모듈을 통해서 AWS Gateway API Controller를 추가합니다.
module "addons" {
source = "aws-ia/eks-blueprints-addons/aws"
version = "~> 1.16"
cluster_name = module.eks.cluster_name
cluster_endpoint = module.eks.cluster_endpoint
cluster_version = module.eks.cluster_version
oidc_provider_arn = module.eks.oidc_provider_arn
enable_aws_gateway_api_controller = true
aws_gateway_api_controller = {
chart_version = "v1.0.3"
create_namespace = true
namespace = "aws-application-networking-system"
source_policy_documents = [data.aws_iam_policy_document.gateway_api_controller.json]
set = [
{
name = "clusterName"
value = module.eks.cluster_name
},
{
name = "log.level"
value = "debug"
},
{
name = "clusterVpcId"
value = module.cluster_vpc.vpc_id
},
{
name = "defaultServiceNetwork"
value = ""
},
{
name = "latticeEndpoint"
value = "https://vpc-lattice.${local.region}.amazonaws.com"
}
]
wait = true
}
enable_external_dns = true
external_dns_route53_zone_arns = try([aws_route53_zone.primary.arn], [])
external_dns = {
set = [
{
name = "domainFilters[0]"
value = "example.com"
},
{
name = "policy"
value = "sync"
},
{
name = "sources[0]"
value = "crd"
},
{
name = "sources[1]"
value = "ingress"
},
{
name = "txtPrefix"
value = module.eks.cluster_name
},
{
name = "extraArgs[0]"
value = "--crd-source-apiversion=externaldns.k8s.io/v1alpha1"
},
{
name = "extraArgs[1]"
value = "--crd-source-kind=DNSEndpoint"
},
{
name = "crdSourceApiversion"
value = "externaldns.k8s.io/v1alpha1"
},
{
name = "crdSourceKind"
value = "DNSEndpoint"
}
]
}
tags = local.tags
}
data "aws_iam_policy_document" "gateway_api_controller" {
statement {
sid = ""
effect = "Allow"
resources = ["*"] # For testing purposes only (highly recommended limit access to specific resources for production usage)
actions = [
"vpc-lattice:*",
"iam:CreateServiceLinkedRole",
"ec2:DescribeVpcs",
"ec2:DescribeSubnets",
"ec2:DescribeTags",
"ec2:DescribeSecurityGroups",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"tag:GetResources",
]
}
}
다음은 demo_application 리소스 입니다. 이 리소스를 통해서 EKS 클러스터 내에 간단한 데모 애플리케이션을 배포합니다.
- ./charts/demo-application 디렉터리 내의 yaml을 참조하여 데모 애플리케이션을 배포합니다.
- depends_on을 통해 addons 모듈이 구성되고 난 이후에 리소스를 배포하도록 설정합니다.
resource "helm_release" "demo_application" {
name = "demo-application"
chart = "./charts/demo-application"
create_namespace = true
namespace = "apps"
depends_on = [module.addons]
}
데모 애플리케이션에 대한 yaml 명세서를 간단히 살펴보겠습니다. charts/demo-application 폴더를 참조해주세요.
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
name: amazon-vpc-lattice
spec:
controllerName: application-networking.k8s.aws/gateway-api-controller
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
name: my-services
namespace: apps
spec:
gatewayClassName: amazon-vpc-lattice
listeners:
- name: http
protocol: HTTP
port: 80
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
name: server
namespace: apps
spec:
hostnames:
- server.example.com
parentRefs:
- name: my-services
sectionName: http
rules:
- backendRefs:
- name: server
kind: Service
port: 8090
matches:
- path:
type: PathPrefix
value: /
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: server
labels:
app: server
spec:
replicas: 2
selector:
matchLabels:
app: server
template:
metadata:
labels:
app: server
spec:
containers:
- name: server
image: public.ecr.aws/x2j8p8w7/http-server:latest
env:
- name: PodName
value: "server pod"
---
apiVersion: v1
kind: Service
metadata:
name: server
spec:
selector:
app: server
ports:
- protocol: TCP
port: 8090
targetPort: 8090
마지막으로 아래 데이터 및 리소스를 통해 VPC Lattice에 대한 IPv4 주소의 EC2 Prefix List를 생성하고, 이 Prefix List에 대한 Security Group Ingress 규칙을 생성합니다.
data "aws_ec2_managed_prefix_list" "vpc_lattice_ipv4" {
name = "com.amazonaws.${local.region}.vpc-lattice"
}
resource "aws_vpc_security_group_ingress_rule" "cluster_sg_ingress" {
security_group_id = module.eks.node_security_group_id
prefix_list_id = data.aws_ec2_managed_prefix_list.vpc_lattice_ipv4.id
ip_protocol = "-1"
}
▶ lattice.tf 살펴보기
lattice.tf 파일을 열어 VPC Lattice에 대한 구성을 살펴보겠습니다.
우선, VPC Lattice service network를 위한 리소스 명세를 살펴보겠습니다.
- this 리소스에서는 my-services라는 이름의 VPC Lattice service network를 생성합니다.
- cluster_vpc 리소스에서는 앞서 만든 VPC Lattice service network에 cluster vpc를 association 합니다.
- client_vpc 리소스에서는 앞서 만든 VPC Lattice service network에 client vpc를 association 합니다.
- demo_application이 배포되고 난 이후 120초를 기다립니다.
resource "aws_vpclattice_service_network" "this" {
name = "my-services"
auth_type = "NONE"
tags = local.tags
}
resource "aws_vpclattice_service_network_vpc_association" "cluster_vpc" {
vpc_identifier = module.cluster_vpc.vpc_id
service_network_identifier = aws_vpclattice_service_network.this.id
}
resource "aws_vpclattice_service_network_vpc_association" "client_vpc" {
vpc_identifier = module.client_vpc.vpc_id
service_network_identifier = aws_vpclattice_service_network.this.id
}
resource "time_sleep" "wait_for_lattice_resources" {
depends_on = [helm_release.demo_application]
create_duration = "120s"
}
다음으로 VPC Lattice service를 위한 커스텀 도메인을 생성하는 부분을 살펴보겠습니다.
- example.com 이라는 명칭의 public hosted zone을 생성합니다.
- client vpc의 id 값을 hosted zone과 연결합니다.
- 여기서 records는 external-dns에서 HTTPRoute를 생성할 때, VPC Lattice Gateway API Copntroller에서 생성한 DNSEndpoint 객체를 사용해서 생성됩니다.
resource "aws_route53_zone" "primary" {
name = "example.com"
vpc {
vpc_id = module.client_vpc.vpc_id
}
tags = local.tags
}
[ Terraform 용어 가이드 ]
- 모듈(module) : 재사용 가능한 Terraform 코드 블록으로, 여러 리소스를 그룹화하여 하나의 템플릿으로 관리할 수 있습니다.
- 리소스(resource) : Terraform의 핵심 구성 요소로, 실제 인프라 리소스를 생성하거나 관리합니다.
- 데이터(data) : 이미 존재하는 인프라 리소스나 다른 Terraform 코드에서 생성된 리소스 정보를 가져오는 데 사용됩니다.
[ 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로 수정해주세요.
4. 아래 명령어를 순차적으로 실행하여 실습 인프라를 프로비저닝 해주세요.
# 1. Terraform init
terraform init
# 2. Terraform module Provisioning
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
#3. Terraform apply
terraform apply -auto-approve
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[ 실행 결과 - 한 눈에 보기 ]
1. 정상적인 terraform init 수행 했다면 다음 화면을 보게 될 것이다.
2. EKS 구성완료 후, 자원 확인
[ VPC Lattice를 통한 Client to Server 통신 테스트 ]
☞ 간단한 테스트를 통해 client 워크로드에서 cluster의 워크로드로 통신이 가능한지 한번 테스트 해보겠습니다.
Step1. client 서버에 ssh 접속
그 다음, Session Manager 탭을 클릭하고, 하단의 Conenct 버튼을 클릭합니다.
아래와 같이 터미널 화면으로 접속되면 성공입니다.
Step2. client 애플리케이션에서 cluster 애플리케이션으로 http 요청 전송
client에서 cluster의 server pod로 요청이 잘 수행되는지 명령을 수행해보겠습니다. 이 과정에서 VPC Lattice로 구성된 서비스 네트워크를 사용해보겠습니다.
아래 그림처럼 한 쪽에는 client의 터미널을, 다른 한 쪽에는 kubectl 명령을 수행할 터미널을 준비해주세요.
아래 kubectl 명령을 통해 server pod의 애플리케이션 로그를 실시간으로 모니터링 및 통신 테스트를 하겠습니다.
# 1. 모니터링
kubectl logs -f deployment/server -n apps --all-containers=true --since=1m
# 2. 통신 테스트
curl -i http://server.example.com
client의 터미널에서 아래와 같이 nslookup 명령을 수행해보겠습니다.
nslookup server.example.com
그럼 아래와 같이 Amazon VPC Lattice로 구성된 엔드포인트가 조회됩니다.
즉, Amazon VPC Lattice의 네트워크 구성을 통해서 이런 환경이 구성된 건데요, 한번 VPC Lattice의 구성된 내용을 자세히 살펴보겠습니다.
Step3. Amazon VPC Lattice 확인
아래 그림과 같이 VPC 콘솔 로 다시 접근합니다.
그 다음, 왼쪽 메뉴바에서 PrivateLink and Lattice > Lattice services 를 찾아 클릭합니다.
그럼 아래와 같이 VPC Lattice Service를 조회할 수 있습니다.
Step4. 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 목록을 조회할 수 있습니다.
kubectl get po -n apps -o wide
이어서 아래 명령을 수행하면, server pod에서 사용하는 service의 정보 및 Port 번호를 조회할 수 있습니다.
kubectl get svc -n apps
이를 통해 VPC Lattice로 구성된 DNS 엔드포인트는 EKS 클러스터 내의 server pod로 라우팅 된다는 것을 알 수 있습니다.
Step5. 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
아래 로그의 내용처럼 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 번호를 세팅합니다.
[ 실행 결과 - 한 눈에 보기 ]
[ 실습 리소스 정리 ]
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-approve2.2 Multi Cluster secure communication
☞ 이번 실습에서는 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를 주입합니다.
[ More ... ]
1. 주요 컴포넌트
a. 인프라 구성
- 두 개의 VPC: VPC cluster 1과 VPC cluster 2가 독립적으로 구성
- 두 개의 EKS 클러스터: 각 VPC에 EKS Cluster 1과 EKS Cluster 2 배포
- VPC Lattice: 두 VPC 간의 서비스 통신을 위한 중앙 관리형 연결 서비스
b. 애플리케이션 구성
- EKS Cluster 1 애플리케이션:
- App1 Service가 Pod로 배포됨
- Envoy sidecar 프록시를 통한 서비스 메시 구성
- HTTP Route를 통한 외부 트래픽 라우팅
- EKS Cluster 2 애플리케이션:
- App2 Service가 Pod로 배포됨
- 마찬가지로 Envoy sidecar 프록시와 HTTP Route 구성
c. 정책 및 보안
- Kyverno: 각 클러스터에 적용된 정책 관리 도구로 사이드카 주입 등을 관리
- IAM Auth Policy: 두 클러스터 간의 인증 및 권한 정책 설정
- Private Certificate Authority: 중앙 인증서 관리
- Certificate Manager: *.example.com 도메인을 위한 인증서 관리
d. 네트워킹
- AWS Gateway API Controller: 각 클러스터의 API 트래픽 제어
- DNS 구성:
- ExternalDNS를 통한 DNS 레코드 관리
- demo-cluster1.example.com 및 demo-cluster2.example.com으로 각 클러스터 서비스 노출
- Amazon Route 53을 통한 도메인 관리
2. 주요 흐름 및 프로세스
- VPC Lattice를 통해 HTTPS 트래픽이 두 클러스터 간에 라우팅됨
- 각 클러스터의 IAM Auth Policy가 접근 권한을 제어
- Pod Identity 기능을 통해 Envoy SigV4 proxy 컨테이너에 ACM에 대한 권한 및 VPC Lattice service invoke 권한 부여
- AWS Gateway API Controller가 각 클러스터의 인그레스 트래픽을 관리
- ExternalDNS가 자동으로 DNS 레코드를 생성하여 서비스 디스커버리 지원
[ Terraform 코드 준비 및 프로비저닝 ]
▶ [확장하기] 만약, 실습 1의 📌12주차 - Amazon VPC Lattice for Amazon EKS (진행 : 방신철) - Terraform 코드 준비 및 프로비저닝 단계를 먼저 수행하지 않았을 경우 아래 과정을 먼저 준비해주세요.
## 아래 명령어를 수행하기 편한 위치에서 실행!!
git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
[ environment 프로비저닝 ]
[ 인프라 구성 개념도 ]
environment 환경에서는 실습에 필요한 사전 환경(Route53, VPC Lattice, IAM Role, ACM 등)을 프로비저닝 합니다.
자세한 내용은 아래 코드를 파악하여 확인해보겠습니다.
Step1. 아래 명령을 수행하여 cross-cluster-pod-communication/environment/ 디렉터리로 이동합니다.
cd terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/environment/
Step2. main.tf 파일을 열고, 7번째 라인의 region을 ap-northeast-2로 수정합니다.
Step3. 아래 명령을 수행하여 environment의 인프라를 프로비저닝 합니다.
terraform init
terraform apply --auto-approve
▶ 코드 살펴보기 ( environment 디렉터리 )
1) main.tf 살펴보기
아래 region 부분을 수정하여 인프라를 프로비저닝 하고자 하는 리전(이 실습에서는 ap-northeast-2)로 변경할 수 있습니다.
name, region, domain 명으로 로컬 변수를 정의하였습니다.
provider "aws" {
region = local.region
}
locals {
name = "vpc-lattice"
region = "us-west-2" # 이 부분을 ap-northeast-2로 수정
domain = var.custom_domain_name
tags = {
Blueprint = local.name
GithubRepo = "github.com/aws-ia/terraform-aws-eks-blueprints"
}
}
Amazon Route53의 Private Hosted Zone을 구성하는 명세입니다.
Private Hosted Zone을 만들기 위해 필요한 Example VPC라는 이름의 더미 VPC를 만들고 있습니다.
#-------------------------------
# Create Private Hosted Zone
#-------------------------------
resource "aws_route53_zone" "private_zone" {
name = local.domain
vpc {
vpc_id = aws_vpc.example.id
}
#we will add vpc association in other terraform stack, prevent this one to revert this
lifecycle {
ignore_changes = [
vpc,
]
}
force_destroy = true
tags = local.tags
}
#dummy VPC that will not be used, but needed to create private hosted zone
resource "aws_vpc" "example" {
cidr_block = "10.0.0.0/16"
tags = {
Name = "Example VPC"
}
}
VPC Lattice Service 및 ACM을 위한 IAM Role을 만들고, 필요한 Polic를 attach 합니다.
################################################################################
# Create IAM role to talk to VPC Lattice services and get Certificate from Manager
################################################################################
data "aws_iam_policy_document" "eks_assume" {
statement {
effect = "Allow"
principals {
type = "Service"
identifiers = ["pods.eks.amazonaws.com"]
}
actions = ["sts:AssumeRole", "sts:TagSession"]
}
}
resource "aws_iam_role" "vpc_lattice_role" {
name = "${local.name}-sigv4-client"
description = "IAM role for aws-sigv4-client VPC Lattice access"
assume_role_policy = data.aws_iam_policy_document.eks_assume.json
}
resource "aws_iam_role_policy_attachment" "vpc_lattice_invoke_access" {
role = aws_iam_role.vpc_lattice_role.name
policy_arn = "arn:aws:iam::aws:policy/VPCLatticeServicesInvokeAccess"
}
resource "aws_iam_role_policy_attachment" "private_ca_read_only" {
role = aws_iam_role.vpc_lattice_role.name
policy_arn = "arn:aws:iam::aws:policy/AWSCertificateManagerPrivateCAReadOnly"
}2) pca.tf 살펴보기
실습에 필요한 Private CA를 만듭니다.
#-------------------------------
# Associates a certificate with an AWS Certificate Manager Private Certificate Authority (ACM PCA Certificate Authority).
# An ACM PCA Certificate Authority is unable to issue certificates until it has a certificate associated with it.
# A root level ACM PCA Certificate Authority is able to self-sign its own root certificate.
#-------------------------------
# # https://docs.aws.amazon.com/acm-pca/latest/userguide/pca-rbp.html
resource "aws_acmpca_certificate_authority" "this" {
enabled = true
type = "ROOT"
certificate_authority_configuration {
key_algorithm = "RSA_4096"
signing_algorithm = "SHA512WITHRSA"
subject {
common_name = var.custom_domain_name
organization = var.organization
}
}
permanent_deletion_time_in_days = 7
tags = local.tags
}
resource "aws_acmpca_certificate" "this" {
certificate_authority_arn = aws_acmpca_certificate_authority.this.arn
certificate_signing_request = aws_acmpca_certificate_authority.this.certificate_signing_request
signing_algorithm = "SHA512WITHRSA"
template_arn = "arn:aws:acm-pca:::template/RootCACertificate/V1"
validity {
type = "YEARS"
value = 10
}
}
resource "aws_acmpca_certificate_authority_certificate" "this" {
certificate_authority_arn = aws_acmpca_certificate_authority.this.arn
certificate = aws_acmpca_certificate.this.certificate
certificate_chain = aws_acmpca_certificate.this.certificate_chain
}#-------------------------------
# Create certificate in AWS Certificate Manager
#-------------------------------
resource "aws_acm_certificate" "private_domain_cert" {
domain_name = var.custom_domain_name
#validation_method = "DNS"
subject_alternative_names = [
"*.${var.custom_domain_name}"
]
options {
certificate_transparency_logging_preference = "DISABLED"
}
certificate_authority_arn = aws_acmpca_certificate_authority.this.arn
tags = local.tags
}
[ cluster 프로비저닝 ]
이어서 cluster 환경에서는 실습에 사용할 두 개의 EKS 클러스터 및 데모 애플리케이션을 구성합니다.
자세한 내용은 아래 코드를 파악하여 확인해보겠습니다.
인프라 프로비저닝 및 데모 애플리케이션 배포를 위해 아래 내용을 진행합니다.
Step1. 아래 명령을 수행하여 cross-cluster-pod-communication/cluster/ 디렉터리로 이동합니다.
cd ../cluster/
Step2. main.tf 파일을 열고, 31번째 라인의 region을 ap-northeast-2로 수정합니다.
Step3. 이어서 아래 명령을 통해 첫번째 EKS 클러스터를 배포합니다.
./deploy.sh cluster1
# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`
Step4. 이어서 아래 명령을 통해 두번째 EKS 클러스터를 배포합니다.
./deploy.sh cluster2
# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`
▶ 코드 살펴보기 ( cluster 디렉터리 )
1) main.tf
테라폼에서 사용할 공통 변수, 데모 애플리케이션 배포를 위한 helm 설정 등이 정의되어 있습니다.
provider "aws" {
region = local.region
}
data "aws_caller_identity" "current" {}
data "aws_availability_zones" "available" {
#Do not include local zones
filter {
name = "opt-in-status"
values = ["opt-in-not-required"]
}
}
provider "helm" {
kubernetes {
host = module.eks.cluster_endpoint
cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
exec {
api_version = "client.authentication.k8s.io/v1beta1"
command = "aws"
# This requires the awscli to be installed locally where Terraform is executed
args = ["eks", "get-token", "--cluster-name", module.eks.cluster_name]
}
}
}
locals {
name = "eks-${terraform.workspace}"
region = "us-west-2" # 이 부분을 ap-northeast-2로 수정
cluster_vpc_cidr = "10.0.0.0/16"
azs = slice(data.aws_availability_zones.available.names, 0, 3)
domain = data.terraform_remote_state.environment.outputs.custom_domain_name
certificate_arn = data.terraform_remote_state.environment.outputs.aws_acm_cert_arn
acmpca_arn = data.terraform_remote_state.environment.outputs.aws_acmpca_cert_authority_arn
custom_domain = data.terraform_remote_state.environment.outputs.custom_domain_name
app_namespace = "apps"
tags = {
Blueprint = local.name
GithubRepo = "github.com/aws-ia/terraform-aws-eks-blueprints"
}
}
2) eks.tf
EKS 클러스터 생성에 대한 명세 입니다. 클러스터 버전 및 관리형 노드 그룹, VPC 및 서브넷에 대한 정의가 되어있으며, 데모 애플리케이션 배포를 위한 설정(enable_cluster_creator_admin_permissions)을 true로 설정합니다.
################################################################################
# Cluster
################################################################################
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "~> 20.8"
cluster_name = local.name
cluster_version = "1.30"
cluster_endpoint_public_access = true
# Give the Terraform identity admin access to the cluster
# which will allow resources to be deployed into the cluster
enable_cluster_creator_admin_permissions = true
vpc_id = module.vpc.vpc_id
subnet_ids = module.vpc.private_subnets
eks_managed_node_groups = {
initial = {
instance_types = ["m5.large"]
min_size = 3
max_size = 10
desired_size = 3
}
}
tags = local.tags
}
3) vpc.tf
EKS 클러스터를 위한 VPC를 정의합니다.
################################################################################
# Cluster VPC
################################################################################
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "~> 5.0"
name = local.name
cidr = local.cluster_vpc_cidr
azs = local.azs
private_subnets = [for k, v in local.azs : cidrsubnet(local.cluster_vpc_cidr, 4, k)]
public_subnets = [for k, v in local.azs : cidrsubnet(local.cluster_vpc_cidr, 8, k + 48)]
enable_nat_gateway = true
single_nat_gateway = true
public_subnet_tags = {
"kubernetes.io/role/elb" = 1
}
private_subnet_tags = {
"kubernetes.io/role/internal-elb" = 1
}
tags = local.tags
}
[ 프로비저닝 된 인프라 및 애플리케이션 확인 ]
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 권한이 설정되어 있습니다.
위의 📌12주차 - Amazon VPC Lattice for Amazon EKS (진행 : 방신철) - cluster :Terraform 코드 살펴보기 에서 확인한 바와 같이 해당 Pod Identity 및 IAM role은 데모 애플리케이션 Pod에 적용됩니다.
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 Hosted zone
☞ AWS Certificate Manager(ACM)
[ 실습 결과 - 한 눈에 보기 ]
[ EKS 클러스터 별 애플리케이션 ]
1. 아래 명령을 수행하여 eks-cluster1으로 context를 스위칭 할 수 있습니다.
kubectl config use-context eks-cluster1
2. eks-cluster1의 Pod 목록을 조회하기 위해 아래 명령을 수행합니다.
kubectl get po -A
3. 이어서 아래 명령을 통해 데모 애플리케이션 Pod(demo-cluster1-v1)의 구성을 확인해보겠습니다.
kubectl describe po demo-cluster1-v1-7b8b98f676-mq7mp -n apps
☞ Init Containers를 통해 envoy-sigv4 컨테이너를 위한 IPTables 세팅이 수행되었습니다.
☞ 그리고 아래와 같이 envoy-sigv4 컨테이너와 데모 애플리케이션 컨테이너가 잘 배포되어 있습니다.
☞ (Optional) 만약 eks-cluster2 클러스터의 Pod 목록도 함께 조회하고 싶다면, 아래 명령을 수행하세요.
kubectl config use-context eks-cluster2
kubectl get po -A
[ 통신 테스트 및 동작방식 확인 ]
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-578bcfbc7-8vhxl): Hello from demo-cluster2-v1
2. 이번에는 아래의 명령을 실행해보겠습니다.
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의 데모 애플리케이션으로 요청을 수행합니다.
그러면 아래와 같은 권한 오류 메시지를 확인할 수 있습니다.
AccessDeniedException: User: arn:aws:sts::12345678910:assumed-role/vpc-lattice-sigv4-client/eks-eks-cluste-demo-clust-1361ddca-754c-42f7-990c-cc93f2a8d744 is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:us-east-1:12345678910:service/svc-0340c2435f9aff773/ because no service-based policy allows the vpc-lattice-svcs:Invoke action
이렇게 에러가 발생하는 이유는, eks-cluster1의 IAMAuthPolicy에서 eks-cluster2 으로만 호출 가능하도록 했기 때문입니다.
3. 아래 명령어 수행
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::12345678910: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를 허용한다.
kubectl describe IAMAuthPolicy demo-cluster1-iam-auth-policy -n apps
해당 IAMAuthPolicy의 적용 대상(Target Ref)이 demo-cluster1 라는 이름을 가진, apps 네임스페이스의 HTTPRoute 리소스임을 확인할 수 있습니다.
4. 대상이 되는 HTTPRoute를 조회하기 위해 아래 명령을 수행합니다.
kubectl describe HTTPRoute demo-cluster1 -n apps
이 HTTPRoute 설정을 통해 라우팅 되는 대상을 아래와 같이 확인할 수 있습니다.
HTTPRoute로 라우팅 되는 대상이 demo-cluster1-v1 이라는 Service임을 알 수 있습니다.
5. 마찬가지로 아래 명령을 통해 해당 Service 명세를 확인해보겠습니다.
kubectl describe svc demo-cluster1-v1 -n apps
☞ 이 Service를 통해 라우팅 되는 대상이 10.0.26.50:8090 임을 확인할 수 있습니다. (demo-cluster1-v1)
6. 이어서 VPC 콘솔 > PrivateLink and Lattice > Lattice service 로 이동하여 demo-cluster1-apps의 체크박스를 클릭하고, Routing 탭을 클릭하면 아래와 같이 라우팅 대상 그룹을 확인할 수 있습니다.
결과적으로 이 데모 애플리케이션 Pod가 IAMAuthPolicy의 규칙을 적용받고 있음을 확인할 수 있습니다.
이렇게 IAMAuthPolicy를 사용하면 멀티 클러스터 간에 각 애플리케이션에 대한 액세스 제어를 쉽게 구성할 수 있습니다.
[ Kyverno의 역할 ]
이번 실습에서는 Kyverno의 ClusterPolicy를 사용하여 데모 애플리케이션 Pod에 iptables 규칙과 envoy 사이드카 프록시를 주입했습니다:
- iptables 규칙은 애플리케이션에서 envoy 프록시로 트래픽을 라우팅합니다(소스 프로세스 gid가 0인 경우 규칙이 적용되지 않으므로 애플리케이션에 다른 gid를 제공합니다: runAsGroup: 1000).
- envoy 프록시는 시작 시 Private CA 인증서를 검색하여 시작 스크립트를 통해 VPC lattice 서비스를 신뢰하도록 설치합니다:
1. 아래 명령을 수행하여 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
## 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
## 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
## 3. 시스템 인증서 신뢰 저장소 업데이트
update-ca-trust extract
## 4. 구성 파일 내용 출력 (디버깅 용도)
cat /etc/envoy/envoy.yaml
# 5. Envoy 프록시 실행
/usr/local/bin/envoy --base-id 1 -l trace -c /etc/envoy/envoy.yaml
2. launch_envoy.sh에서 활용한 envoy.yaml.in 스크립트도 함께 살펴보겠습니다. 해당 스크립트는 여기서 참조할 수 있습니다.
☞ 이 스크립트의 주요 목적은 AWS VPC Lattice 서비스와 안전하게 통신하기 위해 필요한 인증서를 설정하고, 환경에 맞게 구성된 Envoy 프록시를 실행하는 것입니다. SigV4 인증을 사용하여 AWS 서비스에 대한 요청에 서명하는 프로세스를 자동화합니다.
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 내용 살펴보기
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 인증서 번들을 사용하여 서버 인증서 검증
[ 요약 ]
- 8080 포트에서 HTTP 요청 수신
- 모든 요청을 동적 DNS 조회를 통해 해당 서비스로 전달
- AWS VPC Lattice로 가는 요청에 SigV4 인증 서명 적용
- TLS를 사용하여 안전한 통신 보장
3. 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"]
[ 실습 리소스 정리 ]
1. 클러스터 정리
cd /workshop/terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/cluster/
./destroy.sh cluster2
./destroy.sh cluster1
2. 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
[ 마무리 ]
AWS에서 제공하는 lattice 워크샵을 통해 EKS 자원에 대한 네트웍과 인증 측면에서 관리형 솔루션을 통해 보다 쉽고 안전하게 접근하는 방법에 대해 배워 볼 수 있는 시간이어서 유익했던 것 같다.
[ 참고 링크 모음 ]
☞ Lattice 관련 Docs & Workshop
- 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
- https://docs.aws.amazon.com/ko_kr/vpc-lattice/latest/ug/how-it-works.html
- https://aws.amazon.com/ko/blogs/korea/simplify-service-to-service-connectivity-security-and-monitoring-with-amazon-vpc-lattice-now-generally-available/
- https://aws.amazon.com/ko/blogs/tech/amazon-vpc-vattice-modernize-and-simplify-your-enterprise-network-architectures/
- https://aws.amazon.com/blogs/containers/application-networking-with-amazon-vpc-lattice-and-amazon-eks/
- https://youtu.be/fRjD1JI0H5w?si=jtLssGaVfu8hnNUY
☞ IAM Policy :
- https://aws.amazon.com/ko/blogs/containers/implement-aws-iam-authentication-with-amazon-vpc-lattice-and-amazon-eks/
- https://docs.aws.amazon.com/ko_kr/vpc-lattice/latest/ug/auth-policies.html
- https://www.gateway-api-controller.eks.aws.dev/dev/api-types/iam-auth-policy/#introduction
☞ 도전 과제 모음
- Amazon VPC Lattice Workshop : https://catalog.workshops.aws/handsonwithvpclattice/ko-KR
- AWS Gateway API Controller : https://www.gateway-api-controller.eks.aws.dev/latest/guides/deploy/
- Amazon VPC Lattice with EKS : https://www.eksworkshop.com/docs/networking/vpc-lattice/
'AEWS' 카테고리의 다른 글
| AEWS 11주차 - ML Infra(GPU) on EKS (0) | 2025.04.18 |
|---|---|
| AEWS 10주차 - K8s 시크릿 관리 Update (0) | 2025.04.10 |
| AEWS 9주차 - EKS Upgrade [AWS Workshop] (0) | 2025.04.01 |
| AEWS 8주차 - K8S CI/CD (0) | 2025.03.25 |
| AEWS 7주차 - EKS Mode/Nodes (Fargate, Auto-mode) (0) | 2025.03.17 |
