Today Keys : lattice, vpc, service, eks, api, gateway, controller, kubernetes
이번 포스팅은 서로 다른 VPC 및 AWS 계정에 걸쳐 서비스 간의 네트워크 연결 및 애플리케이션 계층 라우팅을 자동으로 관리해주는 Amazon VPC Lattice에 대한 아홉 번째 포스팅입니다.
아홉 번째 포스팅에서는 AWS Gateway API Controller에 대한 내용입니다. AWS Gateway API Controller는 Kubernetes API를 구현한 것으로 EKS Cluster의 Gateway, HTTRoute에 대한 Amazon VPC Lattice 리소스를 프로비저닝하는 역할을 합니다.
Kubernetes Gateway API에 대한 내용과, AWS Gateway API Controller를 배포하는 내용은 이번 포스팅에서 다루지는 않습니다.
아래의 링크를 각각 참고하면 되고, AWS Gateway API Controller 배포는 문서 참고와 함께 배포한 내용에 대해서는 간단하게 포스팅에 포함하지만 세부 설명은 생략합니다.
Kubernetes Gateway API : https://gateway-api.sigs.k8s.io/
Deploying the AWS Gateway API Controller : https://www.gateway-api-controller.eks.aws.dev/deploy/
Deploying the AWS Gateway API Controller
Step 1. 환경 변수 설정
Step 2-1. EKS Node에 접근하기 위해 Key 생성
Step 2-2. EKS Cluster 생성
Step 3. VPC Lattice fleet에서 트래픽을 수신하는 보안 구성 설정
Step 4. IAM OIDC 공급자 생성
Step 5. IAM Policy 생성
Step 6. namespace 생성
Step 7. Policy ARN 확인
Step 8. Pod level permission을 위한 iamserviceaccount 생성
Step 9. Controller Deploy
Step 10. GatewayClass 생성
테스트를 진행하기 전의 현재 배포된 내용을 보면,
zigi-admin, zigi-admin2라는 이름의 2개의 Serivce가 각각 4개의 Pod를 가지고 배포 되어 있습니다.
또한, 테스트를 위한 zigi-ns라는 개별 pod도 있습니다.
zigi-ns pod에서 zigi-admin과 zigi-admin2라는 service를 호출하면 다음과 같은 응답을 받습니다.
zigi-admin은 [ZIGI 1], zigi-admin2는 [ZIGI-2]라는 이름으로 호출된 Pod IP와 호출한 Client IP를 출력합니다.
이제 gateway를 배포해서, VPC Lattice Service Network 를 생성합니다.
Service Network 이름은 'zigi-lattice-svcnw'로 했고, VPC도 바로 Association 합니다.
Console에서 확인해 보면, 'zigi-lattice-svcnw'라는 이름으로 Lattice Service network가 생성된 것을 확인 할 수 있습니다.
다음은 HTTPRoute를 배포해서, VPC Lattice Service를 생성합니다.
Service의 이름은 'zigi-lattice-svc'로 하고,
이 Service가 연결 될 Lattice Service Network를 앞서 만든 'zigi-lattice-svcnw'로,
Service에 연결되는 Target group은 'zigi-admin' 으로 설정합니다.
생성 이후, Console에서 Service를 확인해보면 다음과 같이 Serivce가 생성 되어서, VPC Lattice Service Network에 연결까지 된 것을 볼 수 있습니다.
Target Group도 다음과 같이 정상적으로 생성된 것을 볼 수 있습니다.
등록된 Target을 보면, IP Type으로 각 Pod가 등록되어 있습니다.
VPC Lattice Service의 Domain으로 VPC의 Instance와 EKS Pod에서 각각 서비스를 호출해 보면, Cluster 내/외부에서 모두 정상적으로 Service가 호출되는 것을 볼 수 있습니다.
다음은 Path routing 설정에 대한 테스트 입니다.
api gateway에서는 기본적으로 Path에 대한 Routing을 지원하고 있습니다.
이번 예제에서는 /zigi1과 /zigi2에 대한 Path에 따라서,
각각 zigi-admin과 zigi-admin2 Service로 Routing 되도록 배포합니다.
생성된 Lattice Service를 확인 해보면 다음과 같이 path에 대한 Condition에 따라서 Forward되는 Target이 다르게 설정된 것을 확인 할 수 있습니다.
VPC Lattice Service의 Domain으로 Path를 지정해서, VPC의 Instance와 EKS Pod에서 각각 서비스를 호출해 보면, Cluster 내/외부에서 모두 정상적으로 Service가 호출되는 것을 볼 수 있습니다.
다음은 weight 설정에 대한 테스트 입니다.
api gateway에서는 기본적으로 weight에 대한 Routing도 지원합니다.
이번 예제에서는 /zigi3과 /zigi4에 대해서 각각 weight를 10,50으로 설정하여, 배포합니다.
Console에서 보면, 다음과 같이 Lattice Service에서 Target에 대한 Forward 동작 시 Weight가 설정된 것을 볼 수 있습니다.
Service를 호출해 보면 설정한 Weight에 준하여 zigi-admin4[ZIGI 4]가 더 많이 호출되는 것을 볼 수 있습니다.
지금까지는 Serivce가 올라가 있는 EKS Cluster와 동일한 VPC 및 동일 Cluster 내에서 서비스를 호출을 테스트 했고, 이번에는 다른 계정의 다른 VPC와 다른 EKS Cluster에서 Lattice Service Network에 VPC를 Association하여 Service를 호출 해보겠습니다.
대략적으로 구성을 보면 다음과 같습니다.
현재까지는 ZIGI-VPC2의 EKS Cluster에서 Serivce를 만들어서 Lattice Service Network에 등록하여 서비스를 호출 했지만, 이번에는 ZIGI-VPC1의 Lattice Service Network에 등록해서, ZIGI-VPC1에 있는 Instance와 'zigi-ns'라는 Pod에서 서비스를 호출합니다.
테스트를 위해서 ZIGI-VPC2에서 만든 VPC Lattice Service Network인 'zigi-lattice-svcnw'는 Resource Access Manager를 통해서 ZIGI-VPC1의 계정에 공유를 미리 해 두었습니다.
이제 ZIGI-VPC1에서 'zigi-lattice-svcnw'에 VPC를 Association 합니다.
설정 방식은 최초에 ZIGI-VPC2에서 'zigi-lattice-svcnw'를 생성 할 때와 동일합니다.
zigi-lattice-svcnw에 정상적으로 VPC가 Association된 것을 볼 수 있습니다.
ZIGI-VPC1의 Instance와 EKS Cluster Pod에서 기존에 Path Routing이 적용된 Lattice Service의 호출이 정상적으로 되는 것을 볼 수 있습니다.
마찬가지로 ZIGI-VPC1의 Instance와 EKS Cluster Pod에서 기존에 Target에 Weight가 적용된 Lattice Service의 호출이 정상적으로 되는 것을 볼 수 있습니다.
다른 VPC의 Instance와 EKS Cluster Pod에서 서비스 호출을 VPC간의 Peering이나 Transit Gateway 없이 Lattice Service Network를 통해서 직접 연결이 가능한 것을 확인 할 수 있습니다.
다음은 Custom Doamin과 ACM 인증서를 통한 HTTPS 접근에 대한 테스트입니다.
Custom Domain의 경우, Spec에 'hostnames'를 사용합니다.
ACM 인증서를 적용하여 HTTPS 접근을 위해서 Service 배포 시에 할 것은 parentRefs에 적정한 sectionName을 지정하는 것입니다. 해당 sectionName은 Gateway(Service Network)를 배포할 때 미리 설정해 둔 값입니다.
기존에 배포한 Gateway(Service Network)를 살펴보면, Listeners에 HTTPS Protocol과 함께 인증서 설정을 함께 해 둔 것을 볼 수 있습니다. 참고로, 설정에 사용된 arn은 Custom Domain에 대한 인증서 ARN입니다.
이제 배포된 Lattice Service를 보면, Custom Domain과 ACM 인증서가 설정되어서 배포된 것을 볼 수 있습니다.
Service에 기본 Domain과 Custom Domain을 각각 https로 호출을 하면 정상적으로 서비스 되는 것을 볼 수 있고, EKS Cluster에 있는 pod에서도 동일하게 서비스 되는 것을 확인 할 수 있습니다.
또한 Service Network에 연결된 다른 계정의 Instnace와 Pod에서도 Service에 기본 Domain과 Custom Domain을 각각 https로 호출을 하면 정상적인 응답을 받는 것을 볼 수 있습니다.
