기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
비용 최적화 - 네트워킹
고가용성(HA)을 위한 아키텍처 시스템은 복원력과 내결함성을 달성하기 위한 모범 사례입니다. 실제로 이는 워크로드와 기본 인프라를 지정된 AWS 리전의 여러 가용 영역(AZs)에 분산시키는 것을 의미합니다. Amazon EKS 환경에 이러한 특성이 적용되도록 하면 시스템의 전반적인 신뢰성이 향상됩니다. 이와 함께 EKS 환경은 다양한 구성 요소(예: VPCs), 구성 요소(예: ELBs) 및 통합(예: ECR 및 기타 컨테이너 레지스트리)으로 구성될 수도 있습니다.
고가용성 시스템과 기타 사용 사례별 구성 요소의 조합은 데이터가 전송되고 처리되는 방식에 중요한 역할을 할 수 있습니다. 이로 인해 데이터 전송 및 처리로 인해 발생하는 비용에 영향을 미칩니다.
아래에 설명된 방법은 다양한 도메인 및 사용 사례에 대한 비용 효율성을 달성하기 위해 EKS 환경을 설계하고 최적화하는 데 도움이 됩니다.
포드 간 통신
설정에 따라 포드 간 네트워크 통신 및 데이터 전송은 Amazon EKS 워크로드 실행의 전체 비용에 상당한 영향을 미칠 수 있습니다. 이 섹션에서는 고가용성(HA) 아키텍처, 애플리케이션 성능 및 복원력을 고려하면서 포드 간 통신과 관련된 비용을 완화하기 위한 다양한 개념과 접근 방식을 다룹니다.
가용 영역으로 트래픽 제한
Kubernetes 프로젝트는 초기에 노드에 할당된 kubernetes.io/hostname, topology.kubernetes.io/region 및 topology.kubernetes.io/zone 같은 레이블을 포함한 토폴로지 인식 구문을 개발하여 장애 도메인 및 토폴로지 인식 볼륨 프로비저너 간의 워크로드 배포와 같은 기능을 활성화하기 시작했습니다. Kubernetes 1.17을 졸업한 후 레이블을 활용하여 포드 간 통신을 위한 토폴로지 인식 라우팅 기능도 활성화했습니다.
다음은 비용을 절감하고 지연 시간을 최소화하기 위해 EKS 클러스터의 포드 간 AZ 간 트래픽 양을 제어하는 방법에 대한 몇 가지 전략입니다.
클러스터의 포드 간 AZ 간 트래픽 양(예: 바이트 단위로 전송된 데이터 양)을 세밀하게 확인하려면 이 게시물을 참조
위 다이어그램에서 볼 수 있듯이 서비스는 포드로 향하는 트래픽을 수신하는 안정적인 네트워크 추상화 계층입니다. 서비스가 생성되면 여러 EndpointSlices가 생성됩니다. 각 EndpointSlice에는 실행 중인 노드와 함께 포드 주소의 하위 집합이 포함된 엔드포인트 목록과 추가 토폴로지 정보가 있습니다. Amazon VPC CNI를 사용하는 경우 모든 노드에서 실행되는 데몬 세트인 kube-proxy는 포드 통신 및 서비스 검색을 활성화하는 네트워크 규칙을 유지합니다(대체 eBPF 기반 CNIs kube-proxy를 사용하지 않지만 동등한 동작을 제공할 수 있음). 내부 라우팅의 역할을 수행하지만 생성된 EndpointSlices에서 소비하는 것에 따라 수행됩니다.
EKS에서 kube-proxy는 주로 노드 또는 AZ 배치에 관계없이 클러스터의 모든 포드에서 트래픽 분산을 위해 iptables NAT 규칙(또는 IPVS, NFTables
토폴로지 인식 라우팅 사용(이전 명칭은 토폴로지 인식 힌트)
Kubernetes 서비스에서 토폴로지 인식 라우팅kube-proxy는 적용된 힌트를 기반으로 영역에서 엔드포인트로 트래픽을 라우팅합니다.
아래 다이어그램은 힌트가 있는 EndpointSlices가 영역별 오리진 지점을 기반으로 어떤 대상으로 이동해야 하는지 알 kube-proxy 수 있는 방식으로 구성되는 방법을 보여줍니다. 힌트가 없으면 이러한 할당이나 조직이 없으며 트래픽은 출처에 관계없이 다양한 영역 대상으로 프록시됩니다.
경우에 따라 EndpointSlice 컨트롤러는 다른 영역에 힌트를 적용할 수 있습니다. 즉, 엔드포인트가 다른 영역에서 시작된 트래픽을 제공할 수 있습니다. 그 이유는 서로 다른 영역의 엔드포인트 간에 균등한 트래픽 분산을 시도하고 유지하기 위한 것입니다.
다음은 서비스에 대한 토폴로지 인식 라우팅을 활성화하는 방법에 대한 코드 조각입니다.
apiVersion: v1 kind: Service metadata: name: orders-service namespace: ecommerce annotations: service.kubernetes.io/topology-mode: Auto spec: selector: app: orders type: ClusterIP ports: * protocol: TCP port: 3003 targetPort: 3003
아래 스크린샷은 AZ에서 실행 중인 포드 복제본의 엔드포인트에 힌트를 성공적으로 적용한 EndpointSlice 컨트롤러의 결과를 보여줍니다eu-west-1a.
참고
토폴로지 인식 라우팅은 여전히 베타 버전입니다. 이 기능은 컨트롤러가 영역 간에 엔드포인트를 비례적으로 할당하지만 영역의 노드 리소스가 너무 불균형하여 과도한 과부하를 피할 수 없는 경우 힌트 할당을 건너뛸 수 있으므로 클러스터 토폴로지 전체에 균등하게 분산된 워크로드에서 보다 예측 가능하게 작동합니다. 따라서 포드 토폴로지 분산 제약 조건과 같은 애플리케이션의 가용성을 높이는 예약 제약 조건
트래픽 배포 사용
Kubernetes 1.30에 도입되고 1.33에 정식 출시된 트래픽 분산
다음은 서비스에 대한 트래픽 분산을 활성화하는 방법에 대한 코드 조각입니다.
apiVersion: v1 kind: Service metadata: name: orders-service namespace: ecommerce spec: trafficDistribution: PreferClose selector: app: orders type: ClusterIP ports: * protocol: TCP port: 3003 targetPort: 3003
트래픽 분산을 활성화하면 일반적인 문제가 발생합니다. 대부분의 트래픽이 동일한 영역에서 발생하는 경우 단일 AZ 내의 엔드포인트에 과부하가 걸릴 수 있습니다. 이 오버로드로 인해 다음과 같은 심각한 문제가 발생할 수 있습니다.
-
다중 AZ 배포를 관리하는 단일 Horizontal Pod Autoscaler(HPA)는 여러 AZs. 그러나이 작업은 영향을 받는 영역의 증가된 부하를 효과적으로 해결하지 못합니다.
-
이 상황은 결과적으로 리소스 비효율성을 초래할 수 있습니다. Karpenter와 같은 클러스터 오토스케일러가 여러 AZs에서 포드 스케일 아웃을 감지하면 영향을 받지 않는 AZs에 추가 노드를 프로비저닝하여 불필요한 리소스 할당이 발생할 수 있습니다.
이 문제를 해결하려면:
-
영역별로 자체 HPAs가 있는 별도의 배포를 생성하여 서로 독립적으로 확장합니다.
-
토폴로지 분산 제약 조건을 활용하여 클러스터 전반의 워크로드 분산을 보장함으로써 트래픽이 많은 영역에서 엔드포인트 과부하를 방지하는 데 도움이 됩니다.
Autoscaler 사용: 특정 AZ에 노드 프로비저닝
여러 AZs에서 고가용성 환경에서 워크로드를 실행하는 것이 좋습니다. 이렇게 하면 특히 AZ에 문제가 발생한 경우 애플리케이션의 신뢰성이 향상됩니다. 네트워크 관련 비용을 줄이기 위해 신뢰성을 희생하려는 경우 노드를 단일 AZ로 제한할 수 있습니다.
동일한 AZ에서 모든 포드를 실행하려면 동일한 AZ에서 작업자 노드를 프로비저닝하거나 동일한 AZ에서 실행되는 작업자 노드에서 포드를 예약합니다. 단일 AZ 내에서 노드를 프로비저닝하려면 Cluster Autoscaler(CA)topology.kubernetes.io/zone를 사용하고 작업자 노드를 생성할 AZ를 지정합니다. 예를 들어 아래 Karpenter 프로비저너 코드 조각은 us-west-2a AZ에 노드를 프로비저닝합니다.
Karpenter
apiVersion: karpenter.sh/v1 kind: Provisioner metadata: name: single-az spec: requirements: * key: "topology.kubernetes.io/zone"` operator: In values: ["us-west-2a"]
Cluster Autoscaler(CA)
apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: my-ca-cluster region: us-east-1 version: "1.21" availabilityZones: * us-east-1a managedNodeGroups: * name: managed-nodes labels: role: managed-nodes instanceType: t3.medium minSize: 1 maxSize: 10 desiredCapacity: 1 ...
포드 할당 및 노드 선호도 사용
또는 여러 AZs에서 작업자 노드를 실행하는 경우 각 노드에는 AZ 값이 포함된 topology.kubernetes.io/zonenodeSelector 또는 nodeAffinity를 사용하여 단일 AZ의 노드에 대한 포드를 예약할 수 있습니다. 예를 들어 다음 매니페스트 파일은 AZ us-west-2a에서 실행되는 노드 내의 포드를 예약합니다.
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: nodeSelector: topology.kubernetes.io/zone: us-west-2a containers: * name: nginx image: nginx imagePullPolicy: IfNotPresent
노드로 트래픽 제한
영역 수준에서 트래픽을 제한하는 것만으로는 충분하지 않은 경우가 있습니다. 비용 절감 외에도 상호 통신이 빈번한 특정 애플리케이션 간의 네트워크 지연 시간을 줄여야 하는 요구 사항이 추가될 수 있습니다. 최적의 네트워크 성능을 달성하고 비용을 절감하려면 트래픽을 특정 노드로 제한할 수 있는 방법이 필요합니다. 예를 들어 마이크로서비스 A는 고가용성(HA) 설정에서도 항상 노드 1의 마이크로서비스 B와 통신해야 합니다. 노드 1의 마이크로서비스 A가 노드 2의 마이크로서비스 B와 통신하면 특히 노드 2가 별도의 AZ에 있는 경우 이러한 특성의 애플리케이션에 대해 원하는 성능에 부정적인 영향을 미칠 수 있습니다.
서비스 내부 트래픽 정책 사용
포드 네트워크 트래픽을 노드로 제한하기 위해 서비스 내부 트래픽 정책Local트래픽이 시작된 노드의 엔드포인트로 트래픽이 제한됩니다. 이 정책은 노드-로컬 엔드포인트의 독점적 사용을 지시합니다. 즉, 해당 워크로드에 대한 네트워크 트래픽 관련 비용은 배포가 클러스터 전체인 경우보다 저렴합니다. 또한 지연 시간이 짧아져 애플리케이션의 성능이 향상됩니다.
참고
이 기능은 Kubernetes의 토폴로지 인식 라우팅과 결합할 수 없습니다.
다음은 서비스에 대한 내부 트래픽 정책을 설정하는 방법에 대한 코드 조각입니다.
apiVersion: v1 kind: Service metadata: name: orders-service namespace: ecommerce spec: selector: app: orders type: ClusterIP ports: * protocol: TCP port: 3003 targetPort: 3003 internalTrafficPolicy: Local
트래픽 감소로 인한 애플리케이션의 예기치 않은 동작을 방지하려면 다음 접근 방식을 고려해야 합니다.
-
각 통신 포드에 대해 충분한 복제본 실행
이 예제에서는 마이크로서비스 A 복제본 2개와 마이크로서비스 B 복제본 3개가 있습니다. 마이크로서비스 A의 복제본이 노드 1과 2 사이에 분산되어 있고 마이크로서비스 B의 노드 3에 복제본 3개가 모두 있는 경우 Local 내부 트래픽 정책으로 인해 통신할 수 없습니다. 사용 가능한 노드-로컬 엔드포인트가 없으면 트래픽이 삭제됩니다.
마이크로서비스 B의 노드 1과 2에 복제본 3개 중 2개가 있는 경우 피어 애플리케이션 간에 통신이 이루어집니다. 그러나 통신할 피어 복제본이 없는 마이크로서비스 B의 격리된 복제본이 여전히 있을 것입니다.
참고
일부 시나리오에서는 위 다이어그램에 표시된 것과 같은 격리된 복제본이 여전히 목적(예: 외부 수신 트래픽의 요청 처리)을 제공하는 경우 문제가 되지 않을 수 있습니다.
토폴로지 분산 제약 조건과 함께 서비스 내부 트래픽 정책 사용
토폴로지 분산 제약 조건과 함께 내부 트래픽 정책을 사용하면 여러 노드에서 마이크로서비스를 통신하기 위한 적절한 수의 복제본을 확보하는 데 유용할 수 있습니다.
apiVersion: apps/v1 kind: Deployment metadata: name: express-test spec: replicas: 6 selector: matchLabels: app: express-test template: metadata: labels: app: express-test tier: backend spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: "topology.kubernetes.io/zone" whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: app: express-test
포드 선호도 규칙과 함께 서비스 내부 트래픽 정책 사용
또 다른 접근 방식은 서비스 내부 트래픽 정책을 사용할 때 포드 선호도 규칙을 사용하는 것입니다. 포드 선호도를 사용하면 빈번한 통신으로 인해 스케줄러가 특정 포드를 공동 배치하도록 영향을 미칠 수 있습니다. 특정 포드에 엄격한 예약 제약 조건(requiredDuringSchedulingIgnoredDuringExecution)을 적용하면 스케줄러가 노드에 포드를 배치할 때 포드 코로케이션에 대한 더 나은 결과를 얻을 수 있습니다.
apiVersion: apps/v1 kind: Deployment metadata: name: graphql namespace: ecommerce labels: app.kubernetes.io/version: "0.1.6" ... spec: serviceAccountName: graphql-service-account affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - orders topologyKey: "kubernetes.io/hostname"
Load Balancer서와 포드 통신
EKS 워크로드는 일반적으로 EKS 클러스터의 관련 포드로 트래픽을 분산하는 로드 밸런서가 앞에 위치합니다. 아키텍처는 내부 및/또는 외부 방향 로드 밸런서를 포함할 수 있습니다. 아키텍처 및 네트워크 트래픽 구성에 따라 로드 밸런서와 포드 간의 통신이 데이터 전송 요금에 상당한 영향을 미칠 수 있습니다.
AWS Load Balancer Controller
인스턴스 모드를 사용하면 EKS 클러스터의 각 노드에서 NodePort가 열립니다. 그러면 로드 밸런서가 노드 간에 트래픽을 균등하게 프록시합니다. 노드에 대상 포드가 실행 중인 경우 데이터 전송 비용이 발생하지 않습니다. 그러나 대상 포드가 트래픽을 수신하는 NodePort와 다른 노드와 다른 AZ에 있는 경우 kube-proxy에서 대상 포드로 추가 네트워크 홉이 발생합니다. 이러한 시나리오에서는 교차 AZ 데이터 전송 요금이 발생합니다. 노드 간에 트래픽이 균등하게 분산되므로 kube 프록시에서 관련 대상 포드로의 교차 영역 네트워크 트래픽 홉과 관련된 추가 데이터 전송 요금이 발생할 가능성이 높습니다.
아래 다이어그램은 로드 밸런서에서 NodePort로, 이후에서 다른 AZ의 별도 노드에 있는 kube-proxy 대상 포드로 흐르는 트래픽의 네트워크 경로를 보여줍니다. 다음은 인스턴스 모드 설정의 예입니다.
IP 모드를 사용하는 경우 네트워크 트래픽은 로드 밸런서에서 대상 포드로 직접 프록시됩니다. 따라서이 접근 방식에는 데이터 전송 요금이 부과되지 않습니다.
참고
데이터 전송 요금을 줄이려면 로드 밸런서를 IP 트래픽 모드로 설정하는 것이 좋습니다. 이 설정의 경우 로드 밸런서가 VPC의 모든 서브넷에 배포되었는지 확인하는 것도 중요합니다.
아래 다이어그램은 네트워크 IP 모드에서 로드 밸런서에서 포드로 흐르는 트래픽의 네트워크 경로를 보여줍니다.
컨테이너 레지스트리에서 데이터 전송
Amazon ECR
Amazon ECR 프라이빗 레지스트리로의 데이터 전송은 무료입니다. 리전 내 데이터 전송에는 비용이 들지 않지만 인터넷 및 리전 간 데이터 전송에는 전송 양쪽에 인터넷 데이터 전송 요금이 부과됩니다.
ECRs 기본 제공 이미지 복제 기능을 활용하여 관련 컨테이너 이미지를 워크로드와 동일한 리전에 복제해야 합니다. 이렇게 하면 복제 비용이 한 번 청구되고 동일한 모든 리전(리전 내) 이미지 풀은 무료입니다.
인터페이스 VPC 엔드포인트를 사용하여 리전 내 ECR 리포지토리에 연결하여 ECR(데이터 전송)에서 이미지를 가져오는 것과 관련된 데이터 전송 비용을 추가로 줄일 수 있습니다. ECR의 퍼블릭 AWS 엔드포인트(NAT 게이트웨이 및 인터넷 게이트웨이를 통해)에 연결하는 대체 접근 방식은 데이터 처리 및 전송 비용을 높입니다. 다음 섹션에서는 워크로드와 AWS 서비스 간의 데이터 전송 비용 절감에 대해 자세히 설명합니다.
특히 큰 이미지로 워크로드를 실행하는 경우 사전 캐시된 컨테이너 이미지로 사용자 지정 Amazon Machine Image(AMIs)를 구축할 수 있습니다. 이렇게 하면 컨테이너 레지스트리에서 EKS 작업자 노드로 초기 이미지 가져오기 시간과 잠재적 데이터 전송 비용을 줄일 수 있습니다.
인터넷 및 AWS 서비스로 데이터 전송
인터넷을 통해 Kubernetes 워크로드를 다른 AWS 서비스 또는 타사 도구 및 플랫폼과 통합하는 것이 일반적인 방법입니다. 관련 대상과의 트래픽을 라우팅하는 데 사용되는 기본 네트워크 인프라는 데이터 전송 프로세스에서 발생하는 비용에 영향을 미칠 수 있습니다.
NAT 게이트웨이 사용
NAT 게이트웨이는 NAT(네트워크 주소 변환)를 수행하는 네트워크 구성 요소입니다. 아래 다이어그램은 다른 AWS 서비스(Amazon ECR, DynamoDB 및 S3) 및 타사 플랫폼과 통신하는 EKS 클러스터의 포드를 보여줍니다. 이 예제에서 포드는 별도의 AZs. 인터넷에서 트래픽을 보내고 받기 위해 NAT 게이트웨이가 하나의 AZ의 퍼블릭 서브넷에 배포되므로 프라이빗 IP 주소가 있는 모든 리소스가 인터넷에 액세스할 수 있도록 단일 퍼블릭 IP 주소를 공유할 수 있습니다. 이 NAT 게이트웨이는 인터넷 게이트웨이 구성 요소와 통신하므로 패킷을 최종 대상으로 전송할 수 있습니다.
이러한 사용 사례에 NAT 게이트웨이를 사용하는 경우 각 AZ에 NAT 게이트웨이를 배포하여 데이터 전송 비용을 최소화할 수 있습니다. 이렇게 하면 인터넷으로 라우팅되는 트래픽이 동일한 AZ의 NAT 게이트웨이를 통과하여 AZ 간 데이터 전송을 피할 수 있습니다. 그러나 AZ 간 데이터 전송 비용을 절감할 수 있지만이 설정의 영향은 아키텍처에서 추가 NAT 게이트웨이 비용이 발생한다는 것입니다.
이 권장 접근 방식은 아래 다이어그램에 나와 있습니다.
VPC 종단점 사용
이러한 아키텍처의 비용을 더욱 줄이려면 VPC 엔드포인트를 사용하여 워크로드와 AWS 서비스 간의 연결을 설정해야 합니다. VPC 엔드포인트를 사용하면 인터넷을 통과하는 데이터/네트워크 패킷 없이 VPC 내에서 AWS 서비스에 액세스할 수 있습니다. 모든 트래픽은 내부 트래픽이며 AWS 네트워크 내에 유지됩니다. VPC 엔드포인트에는 인터페이스 VPC 엔드포인트(많은 AWS 서비스에서 지원)와 게이트웨이 VPC 엔드포인트(S3 및 DynamoDB에서만 지원)의 두 가지 유형이 있습니다.
게이트웨이 VPC 엔드포인트
게이트웨이 VPC 엔드포인트와 관련된 시간당 또는 데이터 전송 비용은 없습니다. 게이트웨이 VPC 엔드포인트를 사용할 때는 VPC 경계를 넘어 확장할 수 없다는 점에 유의해야 합니다. VPC 피어링, VPN 네트워킹 또는 Direct Connect를 통해 사용할 수 없습니다.
인터페이스 VPC 엔드포인트
VPC 엔드포인트에는 시간당 요금이 부과
아래 다이어그램은 VPC 엔드포인트를 통해 AWS 서비스와 통신하는 포드를 보여줍니다.
VPCs 간 데이터 전송
경우에 따라 서로 통신해야 하는 개별 VPCs(동일한 AWS 리전 내)에 워크로드가 있을 수 있습니다. 이는 트래픽이 각 VPCs. 이러한 통신은 퍼블릭 서브넷에 EC2 인스턴스, NAT 게이트웨이 또는 NAT 인스턴스와 같은 인프라 구성 요소를 배포하여 활성화할 수 있습니다. 그러나 이러한 구성 요소를 포함한 설정에는 VPCs 안팎으로 데이터를 처리/전송하는 데 요금이 발생합니다. 별도의 VPCs와 주고받는 트래픽이 AZs 간에 이동하는 경우 데이터 전송에 추가 요금이 부과됩니다. 아래 다이어그램은 NAT 게이트웨이와 인터넷 게이트웨이를 사용하여 서로 다른 VPCs의 워크로드 간에 통신을 설정하는 설정을 보여줍니다.
VPC 피어링 연결
이러한 사용 사례의 비용을 줄이기 위해 VPC 피어링을 사용할 수 있습니다. VPC 피어링 연결을 사용하면 동일한 AZ 내에 유지되는 네트워크 트래픽에 대한 데이터 전송 요금이 부과되지 않습니다. 트래픽이 AZs 통과하면 비용이 발생합니다. 그럼에도 불구하고 동일한 AWS 리전 내의 개별 VPC에 있는 워크로드 간의 비용 효율적인 통신에는 VPCs 피어링 접근 방식이 권장됩니다. 그러나 전이적 네트워킹을 허용하지 않으므로 VPC 피어링은 주로 1:1 VPC 연결에 효과적입니다.
아래 다이어그램은 VPC 피어링 연결을 통한 워크로드 통신을 개괄적으로 나타낸 것입니다.
전이적 네트워킹 연결
이전 단원에서 언급했듯이 VPC 피어링 연결은 전이적 네트워킹 연결을 허용하지 않습니다. 3VPCs를 전이적 네트워킹 요구 사항에 연결하려면 Transit Gateway(TGW)를 사용해야 합니다. 이렇게 하면 VPC 피어링의 제한이나 여러 VPC 간에 여러 VPC 피어링 연결이 있는 것과 관련된 운영 오버헤드를 극복할 수 VPCs. 시간당 및 TGW로 전송된 데이터에 대한 요금이 청구
아래 다이어그램은 서로 다른 VPCs의 워크로드 간에 동일한 AWS 리전 내에서 TGW를 통해 흐르는 AZ 간 트래픽을 보여줍니다.
Service Mesh 사용
서비스 메시는 EKS 클러스터 환경에서 네트워크 관련 비용을 줄이는 데 사용할 수 있는 강력한 네트워킹 기능을 제공합니다. 그러나 도입할 경우 서비스 메시가 환경에 도입할 운영 작업과 복잡성을 신중하게 고려해야 합니다.
가용 영역으로 트래픽 제한
Istio의 지리 가중 분포 사용
Istio를 사용하면 라우팅이 발생한 후 트래픽에 네트워크 정책을 적용할 수 있습니다. 이는 지리 가중 분포
참고
위에 자세히 설명된 Istio 대상 규칙을 적용하여 로드 밸런서에서 EKS 클러스터의 포드로 가는 트래픽을 관리할 수도 있습니다. 고가용성 로드 밸런서(특히 Ingress Gateway)에서 트래픽을 수신하는 서비스에 로컬리티 가중치 기반 배포 규칙을 적용할 수 있습니다. 이러한 규칙을 사용하면 영역 오리진, 즉이 경우 로드 밸런서에 따라 트래픽이 이동하는 양을 제어할 수 있습니다. 올바르게 구성하면 서로 다른 AZs의 포드 복제본에 트래픽을 균등하게 또는 무작위로 분산하는 로드 밸런서에 비해 송신 교차 영역 트래픽이 적게 발생합니다.
다음은 Istio에 있는 대상 규칙 리소스의 코드 블록 예제입니다. 아래에서 볼 수 있듯이이 리소스는 eu-west-1 리전에 있는 3개의 서로 다른 AZs에서 들어오는 트래픽에 대한 가중치 기반 구성을 지정합니다. 이러한 구성은 지정된 AZ에서 들어오는 트래픽의 대부분(이 경우 70%)이 시작된 동일한 AZ의 대상으로 프록시되어야 한다고 선언합니다.
apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: express-test-dr spec: host: express-test.default.svc.cluster.local trafficPolicy: loadBalancer: + localityLbSetting: distribute: - from: eu-west-1/eu-west-1a/ + to: "eu-west-1/eu-west-1a/_": 70 "eu-west-1/eu-west-1b/_": 20 "eu-west-1/eu-west-1c/_": 10 - from: eu-west-1/eu-west-1b/_ + to: "eu-west-1/eu-west-1a/_": 20 "eu-west-1/eu-west-1b/_": 70 "eu-west-1/eu-west-1c/_": 10 - from: eu-west-1/eu-west-1c/_ + to: "eu-west-1/eu-west-1a/_": 20 "eu-west-1/eu-west-1b/_": 10 "eu-west-1/eu-west-1c/*": 70** connectionPool: http: http2MaxRequests: 10 maxRequestsPerConnection: 10 outlierDetection: consecutiveGatewayErrors: 1 interval: 1m baseEjectionTime: 30s
참고
분산 대상일 수 있는 최소 가중치는 1%입니다. 그 이유는 기본 대상의 엔드포인트가 비정상이거나 사용할 수 없는 경우 장애 조치 리전과 영역을 유지하기 위한 것입니다.
아래 다이어그램은 eu-west-1 리전에 고가용성 로드 밸런서가 있고 지리 가중 분포가 적용되는 시나리오를 보여줍니다. 이 다이어그램의 대상 규칙 정책은 eu-west-1a에서 오는 트래픽의 60%를 동일한 AZ의 포드로 전송하도록 구성된 반면, eu-west-1a에서 오는 트래픽의 40%는 eu-west-1b의 포드로 이동해야 합니다.
트래픽을 가용 영역 및 노드로 제한
Istio에서 서비스 내부 트래픽 정책 사용
외부 수신 트래픽 및 포드 간 내부 트래픽과 관련된 네트워크 비용을 완화하기 위해 Istio의 대상 규칙과 Kubernetes Service 내부 트래픽 정책을 결합할 수 있습니다. Istio 대상 규칙을 서비스 내부 트래픽 정책과 결합하는 방법은 크게 다음 3가지에 따라 달라집니다.
-
마이크로서비스의 역할
-
마이크로서비스 전반의 네트워크 트래픽 패턴
-
Kubernetes 클러스터 토폴로지에 마이크로서비스를 배포하는 방법
아래 다이어그램은 중첩된 요청의 경우 네트워크 흐름의 모양과 앞서 언급한 정책이 트래픽을 제어하는 방법을 보여줍니다.
-
최종 사용자는 APP A에 요청을 하고, 그러면 APP C에 중첩된 요청을 합니다. 이 요청은 먼저 위의 다이어그램과 같이 AZ 1 및 AZ 2에 인스턴스가 있는 가용성이 높은 로드 밸런서로 전송됩니다.
-
그런 다음 외부 수신 요청은 Istio Virtual Service에 의해 올바른 대상으로 라우팅됩니다.
-
요청이 라우팅된 후 Istio 대상 규칙은 요청이 시작된 위치(AZs 따라 각 AZ로 전송되는 트래픽의 양을 제어합니다.
-
그러면 트래픽이 APP A용 서비스로 이동하고 해당 포드 엔드포인트로 프록시됩니다. 다이어그램에 표시된 것처럼 수신 트래픽의 80%는 AZ 1의 포드 엔드포인트로 전송되고 수신 트래픽의 20%는 AZ 2로 전송됩니다.
-
그런 다음 APP A는 APP C에 내부 요청을 보냅니다. APP C의 서비스에 내부 트래픽 정책이 활성화되어 있습니다(
internalTrafficPolicy`: Local`). -
APP A(NODE 1)에서 APP C로의 내부 요청은 APP C에 사용할 수 있는 노드-로컬 엔드포인트로 인해 성공합니다.
-
APP A(NODE 3)에서 APP C로의 내부 요청은 APP C에 사용할 수 있는 노드-로컬 엔드포인트가 없기 때문에 실패합니다. 다이어그램에서 볼 수 있듯이 APP C에는 NODE 3에 복제본이 없습니다. **
아래 스크린샷은이 접근 방식의 라이브 예제에서 캡처됩니다. 첫 번째 스크린샷 세트는에 대한 성공적인 외부 요청graphql과 노드에 있는 공동 위치 orders 복제본graphql에 대한 성공적인 중첩 요청을 보여줍니다ip-10-0-0-151.af-south-1.compute.internal.
Istio를 사용하면 프록시가 인식하는 모든 [업스트림 클러스터](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminologygraphql 프록시가 인식하는 orders 엔드포인트는 다음 명령을 사용하여 가져올 수 있습니다.
kubectl exec -it deploy/graphql -n ecommerce -c istio-proxy -- curl localhost:15000/clusters | grep orders
... orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_error::0** orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_success::119** orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_timeout::0** orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_total::119** orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**health_flags::healthy** orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**region::af-south-1** orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**zone::af-south-1b** ...
이 경우 graphql 프록시는 노드를 공유하는 복제본의 orders 엔드포인트만 인식합니다. 서비스 주문에서 internalTrafficPolicy: Local 설정을 제거하고 위와 같은 명령을 다시 실행하면 결과가 서로 다른 노드에 분산된 복제본의 모든 엔드포인트를 반환합니다. 또한 각 엔드포인트rq_total의를 검사하면 네트워크 배포가 비교적 균등하게 공유됩니다. 따라서 엔드포인트가 서로 다른 AZs에서 실행되는 업스트림 서비스와 연결된 경우 영역 간이 네트워크 배포로 인해 비용이 증가합니다.
위의 이전 섹션에서 언급한 대로 포드 선호도를 사용하여 자주 통신하는 포드를 공동 배치할 수 있습니다.
... spec: ... template: metadata: labels: app: graphql role: api workload: ecommerce spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - orders topologyKey: "kubernetes.io/hostname" nodeSelector: managedBy: karpenter billing-team: ecommerce ...
graphql 및 orders 복제본graphql이 동일한 노드(ip-10-0-0-151.af-south-1.compute.internal)에 공존하지 않으면 아래 Postman 스크린샷의 200 response code에 명시된 대로에 대한 첫 번째 요청이 성공하는 반면,에 graphql 대한 두 번째 중첩 요청은 로 orders 실패합니다503 response code.
추가 리소스
