Amazon VPC Lattice for Amazon EKS 워크샵 내용을 정리합니다.
워크샵 제공해주신 AWS 관계자님 & CloudNET@ 가시다님 감사합니다.
VPC Lattice 등장 배경
여러 EKS 사용의 워크로드
- Service Discovery : 애플리케이션 끼리 통신을 하기 위해선 가장 먼저 내가 통신하고 싶은 서비스 혹은 마이크로 서비스가 어디에 있는지를 아는 것이 선행 되어야 함
- Service Mesh : 마이크로 서비스가 늘어나면서 네트워크 복잡성 증가 및 공통 기능 적용(서킷브레이커, 재시도 로직, 타임아웃, 인증 등)의 요구사항 이 생김
분홍색 ) 은 프록시 컨테이너로 네트워크 통신을 제어하기 위해 구성
이러한 방식의 애플리케이션 네트워킹의 한계점
Ingress와 Service Discovery, Service Mesh는 Kubernetes에서 트래픽 라우팅을 관리하는 대표적인 방식이었지만, 다음과 같은 한계점을 가지고 있었습니다.
Ingress의 한계
- HTTP(S) 중심으로 설계되어 gRPC, TCP, UDP 등 비 L7 프로토콜 지원에 제약 존재
- 인증 및 트래픽 관리 같은 고급 기능을 사용하려면 벤더별로 별도의 설정이 필요하여 표준화가 어려움
Service Mesh의 한계
- 내부(동-서) 트래픽 관리에 최적화되어 외부(북-남) 트래픽 처리에 한계 존재
- 모든 서비스에 사이드카 프록시가 필수로 배포되어야 하며, 클러스터나 VPC가 많아질수록 관리가 어려워짐
프라 구성이 복잡해짐에 따라 아래와 같은 요구사항이 등장
- 팀별 명확한 역할 분리 필요(인프라, 개발자, DevOps 등)
- 여러 VPC와 클러스터 환경에서 리소스를 통합하여 일관성 있게 관리할 필요성 증가
- 인스턴스, 컨테이너, 서버리스 등 다양한 컴퓨팅 환경을 한 번에 관리할 수 있는 통합된 네트워킹 계층이 요구됨
Gateway API 등장
이러한 한계를 극복하기 위해 SIG-NETWORK 커뮤니티에서 Gateway API가 고안되었습니다. Gateway API는 다음과 같은 목표를 가지고 설계되었습니다.
- 역할 기반 설계: 인프라 관리자, 클러스터 운영자, 애플리케이션 개발자 각각의 요구사항을 반영할 수 있도록 설계되었습니다.
- 범용성: HTTP, HTTPS, gRPC 등 다양한 프로토콜을 지원하고 확장성 있게 설계되었습니다.
- 표준화: Kubernetes Ingress와 같이 포터블한 표준 API가 되도록 설계되었습니다.
- 확장성: 멀티 클러스터 환경 및 다양한 VPC 간의 원활한 네트워크 통합이 가능하도록 설계되었습니다.
Gateway API 구성요소
각 담당별로 영역을 분리하여 설계되었습니다.
- 공통 구성을 가진 게이트웨이 집합을 정의하며, 이 클래스를 구현하는 컨트롤러에 의해 관리됩니다.
- 게이트웨이는 각기 다른 컨트롤러에 의해 다양한 구성으로 구현될 수 있습니다. 게이트웨이는 반드시 해당 클래스를 구현하는 컨트롤러의 이름을 포함하는 GatewayClass를 참조해야 합니다.
- 외부 트래픽을 수신하고 내부 서비스로 라우팅하는 진입점을 정의합니다.
- 하나 이상의 Route 리소스와 연결될 수 있습니다.
- 트래픽을 특정 서비스로 매핑하는 프로토콜 별 규칙을 정의합니다.
- HTTPRoute, TLSRoute, TCPRoute, UDPRoute, GRPCRoute 등이 있습니다.
- Gateway 리소스에 연결되어 트래픽을 대상 서비스로 전달합니다.
쿠버네티스 1.28버전 이상부터는 ingress가 더이상 업데이트되지 않으며, 1.31 버전에서는 Gateway API가 표준이되고 있음
Gateway API 관리도 다른 Kubernetes 컴포넌트와 마찬가지로 Controller를 통해 동작합니다.
AWS에서도 AWS에서는 AWS Gateway API Controller를 제공하고 있습니다.
Amazon VPC Lattice
Amazon VPC Lattice 는 AWS에서 제공하는 완전관리형 애플리케이션 네트워킹 서비스로, 다양한 컴퓨팅 환경에서 애플리케이션 서비스를 연결, 보호 및 모니터링하는 통합 솔루션입니다. VPC Lattice는 단일 VPC 내에서는 물론, 계정 간 여러 VPC에 걸쳐 서비스를 연결하는 데 활용할 수 있습니다.
Lattice를 사용하면 얻을 수 있는 주요 이점은 다음과 같습니다.
- 여러 VPC, EC2 인스턴스, 컨테이너, 서버리스로 구성한 애플리케이션의 네트워크 구성을 중앙 집중화 할 수 있습니다.
- 별도의 사이드카 프록시를 구성할 필요가 없습니다. (+ 완전 관리형 서비스)
- 복잡한 네트워크 구성을 단순화 해서 쉽게 사용할 수 있습니다.
- IAM 및 SigV4를 통해 각 애플리케이션으로의 보안 구성을 손쉽게 적용 할 수 있습니다.
- CloudWatch, S3, Kinesis Data Firehose를 통해 쉽게 로깅, 트래픽 패턴 분석 등을 수행할 수 있습니다.
Amazon VPC Lattices의 구성은 다음과 같습니다.
서비스
특정 작업이나 기능을 제공하는 독립적으로 배포 가능한 소프트웨어 단위입니다. 서비스는 EC2 인스턴스, ECS/EKS/Fargate 컨테이너에서 실행되거나, 계정 또는 가상 사설 클라우드(VPC) 내에서 Lambda 함수로 실행될 수 있습니다. VPC Lattice 서비스는 대상 그룹, 리스너, 규칙으로 구성됩니다.
대상 그룹(Target group)
애플리케이션이나 서비스를 실행하는 리소스 모음(대상이라고도 함)입니다. 이는 Elastic Load Balancing에서 제공하는 대상 그룹과 유사하지만, 서로 호환되지 않습니다. 지원되는 대상 유형에는 EC2 인스턴스, IP 주소, Lambda 함수, 애플리케이션 로드 밸런서, Amazon ECS 작업, Kubernetes Pod 등이 있습니다.
경청자(Listener)
연결 요청을 확인하고 대상 그룹의 대상으로 라우팅하는 프로세스입니다. 프로토콜과 포트 번호를 사용하여 리스너를 구성합니다.
규칙(Rule)
VPC Lattice 대상 그룹의 대상으로 요청을 전달하는 리스너의 기본 구성 요소입니다. 각 규칙은 우선순위, 하나 이상의 작업, 그리고 하나 이상의 조건으로 구성됩니다. 규칙은 리스너가 클라이언트 요청을 라우팅하는 방식을 결정합니다.
서비스 네트워크
서비스 및 리소스 구성 모음에 대한 논리적 경계입니다. 클라이언트는 서비스 네트워크와 연결된 VPC에 있을 수 있습니다. 동일한 서비스 네트워크에 연결된 클라이언트와 서비스는 권한이 있는 경우 서로 통신할 수 있습니다.
Auth Policy
Auth Policy는 VPC Lattice 서비스에 대한 액세스를 제어하는 IAM 기반 정책입니다. 이를 통해 특정 IAM 보안 주체나 역할이 서비스에 접근할 수 있는지 여부를 세밀하게 제어할 수 있습니다.
Service Directory
Service Directory는 모든 VPC Lattice 서비스를 중앙에서 검색하고 관리할 수 있는 카탈로그입니다. 개발자와 운영팀이 사용 가능한 서비스를 쉽게 찾고 접근할 수 있도록 지원합니다.
Gateway API 구성 요소와 VPC Lattice 오브젝트 간 매핑 관계
실습 1 Simple Client to Server communication
두 개의 개별 VPC를 배포하며, 그중 하나에서는 클라이언트 애플리케이션을, 다른 하나에서는 서버 애플리케이션을 실행합니다.
서버 애플리케이션은 EKS 클러스터 내부에 배포되고 Amazon VPC Lattice를 통해 클라이언트 애플리케이션에 노출되어 두 애플리케이션 간의 연결을 설정합니다.
또한 Amazon Route53과 external-dns 프로젝트를 사용하여 노출된 서비스에 대한 사용자 지정 도메인 이름을 구성하는 방법을 시연합니다.
# git clone repo
git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git
cd terraform-aws-eks-blueprints/patterns/vpc-lattice/client-server-communication
# 테라폼 초기화
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파드 확인
aws eks update-kubeconfig --name hsh --alias hsh --region ap-northeast-2
kubectl get pods -A
apps server-6d44dd47-5qr7t 1/1 Running 0 6m46s
apps server-6d44dd47-dlxmh 1/1 Running 0 6m46s
aws-application-networking-system aws-gateway-api-controller-aws-gateway-controller-chart-77lf89x 1/1 Running 0 78m
aws-application-networking-system aws-gateway-api-controller-aws-gateway-controller-chart-77vxjhf 1/1 Running 0 78m
external-dns external-dns-57ff8bdbd5-dv48d 1/1 Running 1 (5m22s ago) 78m
kube-system aws-node-9qxqz 2/2 Running 0 79m
kube-system aws-node-kq8tx 2/2 Running 0 79m
kube-system aws-node-rjr55 2/2 Running 0 79m
kube-system coredns-5b9dfbf96-6t6xf 1/1 Running 0 83m
kube-system coredns-5b9dfbf96-qrlng 1/1 Running 0 83m
kube-system kube-proxy-4lq27 1/1 Running 0 79m
kube-system kube-proxy-hcsj9 1/1 Running 0 79m
kube-system kube-proxy-rztkf 1/1 Running 0 79m- 예제 애플리케이션(server) 배포 확인
- gateway 컨트롤러 구성 확인
테라폼 코드 확인
GatewayAPI addon 및 예제 애플리케이션 배포
|
구분
|
중요한 이유
|
|
Gateway API Controller 설치
|
VPC Lattice 네트워킹 통합 핵심
|
|
IAM 정책(vpc-lattice:*)
|
Controller가 리소스 생성 가능
|
|
클러스터 SG 인바운드 허용
|
VPC Lattice와 통신을 위한 필수 인바운드 트래픽 허용
|
|
데모 앱 배포
|
Gateway Controller 기능 검증 목적
|
################################################################################
# EKS Addons (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
}
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 applications
################################################################################
resource "helm_release" "demo_application" {
name = "demo-application"
chart = "./charts/demo-application"
create_namespace = true
namespace = "apps"
depends_on = [module.addons]
}
################################################################################
# Update cluster security group to allow access from VPC Lattice
################################################################################
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"
}Client 구성 코드 확인
- AWS SSM Manager 활성화
- VPC Endpoint 구성
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
}
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
}
Lattice 구성
클러스터 VPC와 클라이언트 VPC를 VPC Lattice로 연결하고, Private DNS를 세팅해서 서비스 통신 기반을 만들게 구성
################################################################################
# VPC Lattice service network
################################################################################
resource "aws_vpclattice_service_network" "this" {
name = "my-services-hsh"
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"
}
################################################################################
# Custom domain name for VPC lattice service
# Records will be created by external-dns using DNSEndpoint objects which
# are created by the VPC Lattice gateway api controller when creating HTTPRoutes
################################################################################
resource "aws_route53_zone" "primary" {
name = "example.com"
vpc {
vpc_id = module.client_vpc.vpc_id
}
tags = local.tags
}
Gateway 명세 확인
데모 애플리케이션을 확인하면 각 구성 컴포넌트를 확인할 수 있습니다.
AWS 콘솔 구성 확인
로드밸런서가 아닌 VPC Lattice를 통해 구성됩니다.
AWS에서는 아래와 같이 확인이 가능합니다.
PrivateLink and Lattice > Lattice services & service Newtorks 를 찾아 클릭하여 리소스를 확인하겠습니다.
Registered targets 섹션을 보면 IP address와 Port 번호를 통해 VPC Lattice Service로의 라우팅 대상을 확인할 수 있습니다.
VPC Lattice를 통한 Client to Server 통신 테스트
client EC2 ssm 접속하여 네트워크 통신테스트 진행
curl -i http://server.example.com로그 확인
kubectl logs -f deployment/server -n apps --all-containers=true --since=1m
엔드포인트 구성을 확인하면 Lattice 서비스와 연결되어있습니다
실습1 리소스 정리
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
실습 2 Multi Cluster secure communication
이 패턴에서는 Amazon VPC Lattice와 IAM authorization을 사용하여 서로 다른 VPC에 있는 두 EKS 클러스터 간의 안전한 멀티 클러스터 통신 방식을 보여줍니다.
CIDR 겹쳐도 문제 없음: 서로 다른 VPC의 IP 대역이 겹치더라도, VPC Lattice가 트래픽을 라우팅해주기 때문에 통신이 가능합니다.
네트워크 인프라 단순화: 기존에 필요했던 Private NAT Gateway나 Transit Gateway 같은 복잡한 네트워킹 구성이 필요 없습니다.
통신 보안 강화: 통신은 TLS 인증서(AWS Private CA와 ACM을 이용해 발급)로 보호됩니다.
Route53 Private Hosted Zone을 통해 내부 DNS 이름으로 서비스 연결이 이뤄진다.
Envoy + Kyverno 사용: 각 Pod에 Envoy 프록시를 자동으로 사이드카로 붙여주고, Envoy가 IAM SigV4 인증을 사용해서 Lattice 서비스에 안전하게 접근합니다.
환경 프로비저닝
실습에 필요한 사전 환경(Route53, VPC Lattice, IAM Role, ACM 등)을 프로비저닝 합니다.
cd terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/environment/
terraform init
terraform apply --auto-approvecluster 프로비저닝
cd ../cluster/
# vpc-lattice/cross-cluster-pod-communication/cluster
# 클러스터1 배포
./deploy.sh cluster1
# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`
# 클러스터2 배포
./deploy.sh cluster2
# 배포 완료 후, 아래 명령으로 kubectl config 설정을 완료합니다.
eval `terraform output -raw configure_kubectl`
구성 확인
AWS EKS를 조회하면 클러스터가 2개 구성된 것을 확인할 수 있습니다.
또한, 클러스터 1에 vpc-lattice-sig4-client라는 IAM role이 apps라는 네임스페이스의 default라는 Service account에 associate 된 것을 확인할 수 있습니다.
IAM role은 ACM의 PCA에 대한 여러 액세스 권한과 VPC Lattice Service에 대한 invoke 권한이 설정되어 있습니다.
해당 Pod Identity 및 IAM role은 데모 애플리케이션 Pod에 적용됩니다.
VPC Lattice를 확인하면 서비스 네트워크와 서비스 구성을 확인할 수 있습니다.
연결된 Service가 Private Hosted Zone에 associate 되어있고 PCA를 사용하고 있는 것을 확인할 수 있습니다.
클러스터 애플리케이션 확인
aws eks update-kubeconfig --name eks-cluster1 --region ap-northeast-2
kubectl get po -A
NAMESPACE NAME READY STATUS RESTARTS AGE
apps demo-cluster1-v1-6986475f95-2gsnc 2/2 Running 0 119m
aws-application-networking-system aws-gateway-api-controller-aws-gateway-controller-chart-9fnwtc8 1/1 Running 0 123m
aws-application-networking-system aws-gateway-api-controller-aws-gateway-controller-chart-9fxcrhd 1/1 Running 0 123m
external-dns external-dns-5c6f9b9b87-h9qj6 1/1 Running 19 (50m ago) 123m
kube-system aws-node-5cktv 2/2 Running 0 120m
kube-system aws-node-k7988 2/2 Running 0 120m
kube-system aws-node-sr5br 2/2 Running 0 121m
kube-system coredns-5fc547d667-hsnnh 1/1 Running 0 120m
kube-system coredns-5fc547d667-sthbn 1/1 Running 0 120m
kube-system eks-pod-identity-agent-fbx28 1/1 Running 0 121m
kube-system eks-pod-identity-agent-ltjbt 1/1 Running 0 121m
kube-system eks-pod-identity-agent-pndsp 1/1 Running 0 121m
kube-system kube-proxy-bmb8d 1/1 Running 0 120m
kube-system kube-proxy-tfv94 1/1 Running 0 120m
kube-system kube-proxy-tsh5d 1/1 Running 0 120m
kyverno kyverno-admission-controller-54b8bdb86f-26r2k 1/1 Running 0 123m
kyverno kyverno-background-controller-64fcf87c7b-ss5cw 1/1 Running 0 123m
kyverno kyverno-cleanup-admission-reports-29094840-rwp7g 0/1 Completed 0 8m59s
kyverno kyverno-cleanup-cluster-admission-reports-29094840-8f2ls 0/1 Completed 0 8m59s
kyverno kyverno-cleanup-controller-5b4b8f645b-6qnhx 1/1 Running 0 123m
kyverno kyverno-reports-controller-55b9787f78-xlngt 1/1 Running 0 123m예제 애플리케이션인 demo-cluster1를 확인하면 envoy-sigv4 컨테이너를 위한 IPTables 세팅이 수행 및 envoy-sigv4 컨테이너를 확인할 수 있습니다.
통신 테스트
통신테스트를 위해 eks-cluster1의 데모 애플리케이션에서 eks-cluster2의 데모 애플리케이션으로 간단한 요청을 전송하겠습니다.
kubectl exec -ti -n apps deployments/demo-cluster1-v1 -c demo-cluster1-v1 \
-- curl demo-cluster2.example.com
통신이 잘 됩니다.
다음은 eks-cluster1의 데모 애플리케이션에서 eks-cluster1의 데모 애플리케이션으로 통신을 요청하겠습니다.
kubectl exec -ti -n apps deployments/demo-cluster1-v1 -c demo-cluster1-v1 \
-- curl demo-cluster1.example.com통신이 안되는 이유는 eks-cluster1의 IAMAuthPolicy 호출 설정 때문입니다.
IAMAuthPolicy는 VPC Lattice의 Service Network 또는 Service에 첨부되는 IAM Policy 문서로, 주체(principal)가 첨부된 Service Network의 Service 또는 특정 첨부된 Service에 접근하는 권한을 제어합니다.
권한을 확인하면 Invoke 대상이 eks-cluster2 와 apps 네임스페이스로만 호출되도록 설정된 것을 확인할 수 있습니다.
kubectl 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::170698194833:root"
},
"Action": "vpc-lattice-svcs:Invoke",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/eks-cluster-name": "eks-cluster2",
"aws:PrincipalTag/kubernetes-namespace": "apps"
}
}
}
]
}IAMAuthPolicy의 적용 대상은 다음의 명령어를 통해 확인할 수 있습니다.
kubectl describe IAMAuthPolicy demo-cluster1-iam-auth-policy -n apps
위와 같이 (Target Ref)이 demo-cluster1 라는 이름을 가진, apps 네임스페이스의 HTTPRoute 리소스가 대상임을 확인할 수 있습니다.
대상이 되는 리소스는 아래와 같이 조회할 수 있습니다.
kubectl describe HTTPRoute demo-cluster1 -n apps
...
Rules:
Backend Refs:
Group:
Kind: Service
Name: demo-cluster1-v1
Port: 80
Weight: 1
Matches:
Path:
Type: PathPrefix
Value: /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.255.217
IPs: 172.20.255.217
Port: <unset> 80/TCP
TargetPort: 8090/TCP
Endpoints: 10.0.39.136:8090이렇게 IAMAuthPolicy를 사용하면 멀티 클러스터 간에 각 애플리케이션에 대한 액세스 제어를 쉽게 구성할 수 있습니다.
실습 2 리소스 정리
클러스터 정리
./destroy.sh cluster2
./destroy.sh cluster1환경 정리
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 terraform-aws-eks-blueprints/patterns/vpc-lattice/cross-cluster-pod-communication/environment/
terraform destroy -auto-approv'Cloud' 카테고리의 다른 글
| EKS 파드로 노드 관리하기 (0) | 2025.04.12 |
|---|---|
| EKS Version Upgrade (0) | 2025.04.02 |
| EKS Fargate & AutoMode (0) | 2025.03.23 |
| EKS Security (2) | 2025.03.16 |
| EKS Karpenter (0) | 2025.03.09 |