**이 페이지 개선에 도움 주기** 이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다. # 하이브리드 노드의 개념 *Amazon EKS Hybrid Nodes*를 사용하면 온프레미스 또는 엣지 환경에서 실행되는 물리적 또는 가상 머신을 AWS 클라우드에서 실행되는 Amazon EKS 클러스터에 조인할 수 있습니다. 이 접근 방식은 많은 이점을 제공하지만 단일 네트워크 환경에서 Kubernetes 클러스터를 실행하는 데 익숙한 사용자를 위한 새로운 네트워킹 개념과 아키텍처도 도입합니다. 다음 섹션에서는 EKS Hybrid Nodes의 Kubernetes 및 네트워킹 개념을 자세히 살펴보고 하이브리드 아키텍처를 통해 트래픽이 흐르는 방식을 자세히 설명합니다. 이 섹션에서는 포드, 노드, 서비스, Kubernetes 컨트롤 플레인, kubelet 및 kube-proxy의 개념과 같은 기본 Kubernetes 네트워킹 지식을 숙지해야 합니다. [하이브리드 노드의 네트워킹 개념](hybrid-nodes-concepts-networking.md)부터 시작하여, [하이브리드 노드에 대한 Kubernetes 개념](hybrid-nodes-concepts-kubernetes.md), 마지막으로 [하이브리드 노드의 네트워크 트래픽 흐름](hybrid-nodes-concepts-traffic-flows.md) 순으로 이 페이지를 읽는 것이 좋습니다. **Topics** + [하이브리드 노드의 네트워킹 개념](hybrid-nodes-concepts-networking.md) + [하이브리드 노드에 대한 Kubernetes 개념](hybrid-nodes-concepts-kubernetes.md) + [하이브리드 노드의 네트워크 트래픽 흐름](hybrid-nodes-concepts-traffic-flows.md) # 하이브리드 노드의 네트워킹 개념 이 섹션에서는 EKS Hybrid Nodes용 네트워크 토폴로지를 설계할 때 고려해야 하는 핵심 네트워킹 개념과 제약 조건을 자세히 설명합니다. ## EKS Hybrid Nodes의 네트워킹 개념 ![\[개략적인 하이브리드 노드 네트워크 다이어그램\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-highlevel-network.png) **네트워크 허브로서의 VPC** 클라우드 경계를 통과하는 모든 트래픽은 VPC를 통해 라우팅됩니다. 여기에는 AWS에서 실행되는 EKS 컨트롤 플레인 또는 포드와 해당 포드에서 실행되는 하이브리드 노드 또는 포드 간의 트래픽이 포함됩니다. 클러스터의 VPC는 ​​하이브리드 노드와 나머지 클러스터 사이의 네트워크 허브라고 생각할 수 있습니다. 이 아키텍처를 사용하면 트래픽과 라우팅을 완벽하게 제어할 수 있지만 VPC에 대한 경로, 보안 그룹 및 방화벽을 올바르게 구성하는 것도 사용자의 책임입니다. **VPC에 대한 EKS 컨트롤 플레인** EKS 컨트롤 플레인은 VPC에 **탄력적 네트워크 인터페이스(ENI)**를 연결합니다. 이러한 ENI는 EKS API 서버와의 트래픽을 처리합니다. EKS는 클러스터 생성 시 전달한 서브넷에 ENI를 연결하므로 클러스터를 구성할 때 EKS 컨트롤 플레인 ENI의 배치를 제어할 수 있습니다. EKS는 서브넷에 연결하는 ENI에 보안 그룹을 연결합니다. 이러한 보안 그룹은 ENI를 통해 EKS 컨트롤 플레인을 오가는 트래픽을 허용합니다. 이는 EKS Hybrid Nodes에 중요합니다. 하이브리드 노드와 해당 노드에서 실행되는 포드에서 EKS 컨트롤 플레인 ENI로의 트래픽을 허용해야 하기 때문입니다. **원격 노드 네트워크** 원격 노드 네트워크, 특히 원격 노드 CIDR은 하이브리드 노드로 사용하는 머신에 할당된 IP의 범위입니다. 하이브리드 노드를 프로비저닝하면 해당 노드는 EKS 컨트롤 플레인 및 VPC와 다른 네트워크 도메인인 온프레미스 데이터 센터 또는 엣지 로케이션에 상주합니다. 각 하이브리드 노드에는 VPC의 서브넷과 구별되는 원격 노드 CIDR의 IP 주소 또는 주소가 있습니다. EKS가 kubelet API에 대한 요청과 같이 클러스터 VPC를 통해 하이브리드 노드 IP로 향하는 모든 트래픽을 라우팅하는 것을 알도록 이러한 원격 노드 CIDR로 EKS 클러스터를 구성합니다. `kubelet` API에 대한 연결은 `kubectl attach`, `kubectl cp`, `kubectl exec`, `kubectl logs`, `kubectl port-forward` 명령에서 사용됩니다. **원격 포드 네트워크** 원격 포드 네트워크는 하이브리드 노드에서 실행되는 포드에 할당된 IP의 범위입니다. 일반적으로 이러한 범위로 CNI를 구성하면 CNI의 IP Address Manager(IPAM) 기능이 이러한 범위의 조각을 각 하이브리드 노드에 할당합니다. 포드를 생성하면 CNI는 포드가 예약된 노드에 할당된 조각에서 포드에 IP를 할당합니다. 이러한 원격 포드 CIDR로 EKS 클러스터를 구성하면 EKS 컨트롤 플레인이 웹후크와의 통신과 같이 클러스터의 VPC를 통해 하이브리드 노드에서 실행되는 포드로 향하는 모든 트래픽을 라우팅하는 것을 압니다. ![\[원격 포드 네트워크\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-remote-pod-cidrs.png) **온프레미스에서 VPC로** 하이브리드 노드에 사용하는 온프레미스 네트워크는 EKS 클러스터에 사용하는 VPC로 라우팅해야 합니다. 온프레미스 네트워크를 VPC에 연결하는 데 사용할 수 있는 여러 가지 [네트워크-Amazon VPC 연결 옵션](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html)이 있습니다. 자체 VPN 솔루션을 사용할 수도 있습니다. VPC와 온프레미스 네트워크의 AWS 클라우드 측에서 라우팅을 올바르게 구성하는 것이 중요합니다. 이렇게 하면 두 네트워크 모두 두 네트워크의 연결을 통해 올바른 트래픽을 라우팅할 수 있습니다. VPC에서 원격 노드 및 원격 포드 네트워크로 이동하는 모든 트래픽은 연결을 통해 온프레미스 네트워크(‘게이트웨이’라고 함)로 라우팅되어야 합니다. 일부 서브넷의 라우팅 테이블이 다른 경우 하이브리드 노드의 경로와 해당 노드에서 실행되는 포드로 각 라우팅 테이블을 구성해야 합니다. 이는 EKS 컨트롤 플레인 ENI가 연결된 서브넷과 하이브리드 노드와 통신해야 하는 EC2 노드 또는 포드가 포함된 서브넷에 해당합니다. 온프레미스 네트워크에서 EKS 클러스터의 VPC 및 하이브리드 노드에 필요한 기타 AWS 서비스와의 트래픽을 허용하도록 네트워크를 구성해야 합니다. EKS 클러스터의 트래픽은 게이트웨이를 양방향으로 통과합니다. ## 네트워킹 제약 조건 **완전히 라우팅된 네트워크** 주요 제약 조건은 EKS 컨트롤 플레인과 모든 노드, 클라우드 또는 하이브리드 노드가 **완전히 라우팅**된 네트워크를 구성해야 한다는 것입니다. 즉, 모든 노드가 IP 주소를 기준으로 계층 3에서 서로 연결할 수 있어야 합니다. EKS 컨트롤 플레인과 클라우드 노드는 일반 네트워크(VPC)에 있기 때문에 이미 서로 연결할 수 있습니다. 그러나 하이브리드 노드는 다른 네트워크 도메인에 있습니다. 따라서 하이브리드 노드와 클러스터의 나머지 부분 간에 트래픽을 라우팅하려면 VPC 및 온프레미스 네트워크에서 추가 라우팅을 구성해야 합니다. 하이브리드 노드가 서로 및 VPC에서 연결 가능한 경우 하이브리드 노드는 단일 일반 네트워크 또는 여러 세그먼트 네트워크에 있을 수 있습니다. **라우팅 가능한 원격 포드 CIDR** EKS 컨트롤 플레인이 하이브리드 노드(예: 웹후크 또는 지표 서버)에서 실행되는 포드와 통신하거나 클라우드 노드에서 실행되는 포드가 하이브리드 노드에서 실행되는 포드와 통신하려면(워크로드 동서 통신) 원격 포드 CIDR이 VPC에서 라우팅 가능해야 합니다. 즉, VPC는 게이트웨이를 통해 온프레미스 네트워크로 포드 CIDR로 트래픽을 라우팅할 수 있어야 하며 온프레미스 네트워크는 포드의 트래픽을 올바른 노드로 라우팅할 수 있어야 합니다. VPC의 포드 라우팅 요구 사항과 온프레미스의 포드 라우팅 요구 사항을 구분하는 것이 중요합니다. VPC는 원격 포드로 이동하는 모든 트래픽이 게이트웨이를 통과해야 한다는 것을 알기만 하면 됩니다. 원격 포드 CIDR이 하나만 있는 경우 경로가 하나만 필요합니다. 이 요구 사항은 온프레미스 네트워크의 모든 홉에서 하이브리드 노드와 동일한 서브넷의 로컬 라우터까지 적용됩니다. 이는 각 노드에 할당된 포드 CIDR 조각을 인식해야 하는 유일한 라우터로, 특정 포드에 대한 트래픽이 포드가 예약된 노드로 전달되도록 합니다. 로컬 온프레미스 라우터에서 VPC 라우팅 테이블로 온프레미스 포드 CIDR에 대한 이러한 경로를 전파하도록 선택할 수 있지만 반드시 그럴 필요는 없습니다. 온프레미스 포드 CIDR이 자주 변경되고 VPC 라우팅 테이블을 변경된 포드 CIDR을 반영하도록 업데이트해야 하는 경우 온프레미스 포드 CIDR을 VPC 라우팅 테이블로 전파하는 것이 좋지만 이는 흔하지 않습니다. 온프레미스 포드 CIDR을 라우팅 가능하게 만드는 제약 조건은 선택 사항입니다. 하이브리드 노드에서 웹후크를 실행할 필요가 없거나 클라우드 노드의 포드가 하이브리드 노드의 포드와 통신하는 경우 온프레미스 네트워크에서 포드 CIDR에 대한 라우팅을 구성할 필요가 없습니다. *온프레미스 포드 CIDR을 하이브리드 노드로 라우팅해야 하는 이유는 무엇인가요?* 클라우드 노드에 VPC CNI와 함께 EKS를 사용하는 경우 VPC CNI는 VPC에서 포드에 IP를 직접 할당합니다. 즉, 클라우드 포드와 EKS 컨트롤 플레인 모두 포드 IP에 직접 도달할 수 있으므로 특별한 라우팅이 필요하지 않습니다. 온프레미스 및 클라우드의 다른 CNI에서 실행하는 경우 포드는 일반적으로 격리된 오버레이 네트워크에서 실행되고 CNI는 포드 간 트래픽 전달을 처리합니다. 이는 일반적으로 캡슐화를 통해 수행됩니다. CNI는 포드 간 트래픽을 노드 간 트래픽으로 변환하여 양쪽 끝에서 캡슐화 및 캡슐화 해제를 처리합니다. 이렇게 하면 노드 및 라우터에서 추가 구성이 필요하지 않습니다. 하이브리드 노드를 사용한 네트워킹은 두 가지 토폴로지의 조합을 제공한다는 점에서 독특합니다. EKS 컨트롤 플레인과 클라우드 노드(VPC CNI 사용)는 노드와 포드를 포함한 플랫 네트워크를 기대하는 반면, 하이브리드 노드에서 실행되는 포드는 캡슐화를 위해 VXLAN을 사용하여 오버레이 네트워크에 있습니다(기본적으로 Cilium에서). 온프레미스 네트워크가 VPC로 라우팅될 수 있다고 가정하면 하이브리드 노드에서 실행되는 포드는 EKS 컨트롤 플레인과 클라우드 노드에서 실행되는 포드에 도달할 수 있습니다. 그러나 온프레미스 네트워크의 포드 CIDR에 대한 라우팅이 없으면 네트워크가 오버레이 네트워크에 도달하고 올바른 노드로 라우팅하는 방법을 모르는 경우 온프레미스 포드 IP로 다시 들어오는 모든 트래픽이 결국 삭제됩니다. # 하이브리드 노드에 대한 Kubernetes 개념 이 페이지에서는 EKS Hybrid Nodes 시스템 아키텍처의 기반이 되는 주요 Kubernetes 개념을 자세히 설명합니다. ## VPC의 EKS 컨트롤 플레인 EKS 컨트롤 플레인 ENI의 IP는 `default` 네임스페이스의 `kubernetes` `Endpoints` 객체에 저장됩니다. EKS는 새 ENI를 생성하거나 이전 ENI를 제거할 때 IP 목록이 항상 최신 상태로 유지되도록 이 객체를 업데이트합니다. 이러한 엔드포인트는 `default` 네임스페이스에서도 `kubernetes` 서비스를 통해 사용할 수 있습니다. `ClusterIP` 유형의 이 서비스는 항상 클러스터 서비스 CIDR의 첫 번째 IP 주소를 할당받습니다. 예를 들어 서비스 CIDR `172.16.0.0/16`의 경우 서비스 IP는 `172.16.0.1`이 됩니다. 일반적으로 이 방식으로 포드(클라우드 또는 하이브리드 노드에서 실행되는지 여부에 관계 없음)가 EKS Kubernetes API 서버에 액세스합니다. 포드는 서비스 IP를 대상 IP로 사용하며, 이는 EKS 컨트롤 플레인 ENI 중 하나의 실제 IP로 변환됩니다. 프라이머리 예외는 `kube-proxy`인데, 이는 변환을 설정하기 때문입니다. ## EKS API 서버 엔드포인트 `kubernetes` 서비스 IP가 EKS API 서버에 액세스하는 유일한 방법은 아닙니다. 또한 EKS는 클러스터를 생성할 때 Route53 DNS 이름을 생성합니다. 이는 EKS `DescribeCluster` API 작업을 직접적으로 호출할 때 EKS 클러스터의 `endpoint` 필드입니다. ``` { "cluster": { "endpoint": "https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com", "name": "my-cluster", "status": "ACTIVE" } } ``` 퍼블릭 엔드포인트 액세스 또는 퍼블릭 및 프라이빗 엔드포인트 액세스 클러스터에서 하이브리드 노드는 기본적으로 이 DNS 이름을 인터넷을 통해 라우팅 가능한 퍼블릭 IP로 확인합니다. 프라이빗 엔드포인트 액세스 클러스터에서 DNS 이름은 EKS 컨트롤 플레인 ENI의 프라이빗 IP로 확인됩니다. 이것이 `kubelet`과 `kube-proxy`가 Kubernetes API 서버에 액세스하는 방식입니다. 모든 Kubernetes 클러스터 트래픽이 VPC를 통해 흐르도록 하려면 클러스터를 프라이빗 액세스 모드로 구성하거나 온프레미스 DNS 서버를 수정하여 EKS 클러스터 엔드포인트를 EKS 컨트롤 플레인 ENI의 프라이빗 IP로 확인해야 합니다. ## `kubelet` 엔드포인트 `kubelet`은 여러 REST 엔드포인트를 노출하여 시스템의 다른 부분이 각 노드와 상호 작용하고 정보를 수집할 수 있도록 합니다. 대부분의 클러스터에서 `kubelet` 서버로 전송되는 트래픽의 대부분은 컨트롤 플레인에서 발생하지만, 특정 모니터링 에이전트도 kubelet 서버와 상호 작용할 수 있습니다. 이 인터페이스를 통해 `kubelet`은 로그 가져오기(`kubectl logs`), 컨테이너 내부에서 명령 실행(`kubectl exec`), 포트 포워딩 트래픽(`kubectl port-forward`) 등 다양한 요청을 처리합니다. 이러한 각 요청은 `kubelet`을 통해 기본 컨테이너 런타임과 상호 작용하여 클러스터 관리자와 개발자에게 원활하게 나타납니다. 이 API의 가장 일반적인 소비자는 Kubernetes API 서버입니다. 앞서 언급한 `kubectl` 명령 중 하나를 사용할 때 `kubectl`은 API 서버에 API 요청을 보낸 다음 포드가 실행되고 있는 노드의 `kubelet` API를 직접적으로 호출합니다. 이것이 EKS 컨트롤 플레인에서 노드 IP에 도달할 수 있어야 하는 주된 이유이며, 노드 경로가 잘못 구성되면 포드가 실행 중이더라도 로그나 `exec`에 접근할 수 없는 이유이기도 합니다. **노드 IP** EKS 컨트롤 플레인이 노드와 통신할 때 `Node` 객체 상태(`status.addresses`)에 보고된 주소 중 하나를 사용합니다. EKS 클라우드 노드를 사용하면 노드 등록 중 kubelet이 EC2 인스턴스의 프라이빗 IP를 `InternalIP`로 보고하는 것이 일반적입니다. 이후 Cloud Controller Manager(CCM)가 이 IP를 검증하여 해당 IP가 EC2 인스턴스에 속하는지 확인합니다. 또한 CCM은 일반적으로 인스턴스의 퍼블릭 IP(`ExternalIP`)와 DNS 이름(`InternalDNS` 및 `ExternalDNS`)을 노드 상태에 추가합니다. 그러나 하이브리드 노드용 CCM은 없습니다. EKS Hybrid Nodes CLI(`nodeadm`)를 사용하여 하이브리드 노드를 등록하면 CCM 없이 노드 상태에서 머신의 IP를 직접 보고하도록 kubelet이 구성됩니다. ``` apiVersion: v1 kind: Node metadata: name: my-node-1 spec: providerID: eks-hybrid:///us-west-2/my-cluster/my-node-1 status: addresses: - address: 10.1.1.236 type: InternalIP - address: my-node-1 type: Hostname ``` 머신에 여러 IP가 있는 경우 kubelet은 자체 로직에 따라 IP 중 하나를 선택합니다. `spec.kubelet.flags`의 `nodeadm` 구성에서 전달할 수 있는 `--node-ip` 플래그를 사용하여 선택한 IP를 제어할 수 있습니다. `Node` 객체에 보고된 IP에만 VPC의 경로가 필요합니다. 머신에는 클라우드에서 연결할 수 없는 다른 IP가 있을 수 있습니다. ## `kube-proxy` `kube-proxy`는 각 노드의 네트워킹 계층에서 서비스 추상화 구현을 담당합니다. 또한 Kubernetes Services로 향하는 트래픽에 대한 네트워크 프록시 및 로드 밸런서 역할을 합니다. `kube-proxy`는 Kubernetes API 서버에서 서비스 및 엔드포인트와 관련된 변경 사항을 지속적으로 감시해서 기본 호스트의 네트워킹 규칙을 동적으로 업데이트하여 트래픽이 제대로 전달되도록 합니다. `iptables` 모드에서 `kube-proxy`는 여러 개의 `netfilter` 체인을 프로그래밍하여 서비스 트래픽을 처리합니다. 규칙은 다음과 같은 계층 구조를 형성합니다. 1. **KUBE-SERVICES 체인**: 모든 서비스 트래픽의 진입점입니다. 각 서비스의 `ClusterIP` 및 포트와 일치하는 규칙이 있습니다. 1. **KUBE-SVC-XXX 체인**: 서비스별 체인에는 각 서비스에 대한 로드 밸런싱 규칙이 있습니다. 1. **KUBE-SEP-XXX 체인**: 엔드포인트별 체인에는 실제 `DNAT` 규칙이 있습니다. `default` 네임스페이스의 서비스 `test-server`에서 어떤 일이 발생하는지 살펴보겠습니다. \$1 서비스 클러스터 IP: `172.16.31.14` \$1 서비스 포트: `80` \$1 백업 포드: `10.2.0.110`, `10.2.1.39` 및 `10.2.2.254` `iptables` 규칙을 검사할 때(`iptables-save –0— grep -A10 KUBE-SERVICES` 사용) 1. **KUBE-SERVICES** 체인에서 서비스와 일치하는 규칙을 찾습니다. ``` -A KUBE-SERVICES -d 172.16.31.14/32 -p tcp -m comment --comment "default/test-server cluster IP" -m tcp --dport 80 -j KUBE-SVC-XYZABC123456 ``` + 이 규칙은 172.16.31.14:80을 대상으로 하는 패킷과 일치합니다. + 주석은 이 규칙의 용도를 나타냅니다(`default/test-server cluster IP`). + 일치하는 패킷은 `KUBE-SVC-XYZABC123456` 체인으로 이동합니다. 1. **KUBE-SVC-XYZABC123456** 체인에는 확률 기반 로드 밸런싱 규칙이 있습니다. ``` -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-POD1XYZABC -A KUBE-SVC-XYZABC123456 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-POD2XYZABC -A KUBE-SVC-XYZABC123456 -j KUBE-SEP-POD3XYZABC ``` + 첫 번째 규칙: 33.3%의 확률로 `KUBE-SEP-POD1XYZABC`로 이동합니다. + 두 번째 규칙: 50%의 확률로 나머지 트래픽(전체의 33.3%)이 `KUBE-SEP-POD2XYZABC`로 이동합니다. + 마지막 규칙: 나머지 모든 트래픽(전체의 33.3%)이 `KUBE-SEP-POD3XYZABC`로 이동합니다. 1. 개별 **KUBE-SEP-XXX** 체인이 DNAT(Destination NAT)를 수행합니다. ``` -A KUBE-SEP-POD1XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.0.110:80 -A KUBE-SEP-POD2XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.1.39:80 -A KUBE-SEP-POD3XYZABC -p tcp -m tcp -j DNAT --to-destination 10.2.2.254:80 ``` + 이러한 DNAT 규칙은 대상 IP와 포트를 다시 작성하여 트래픽을 특정 포드로 전달합니다. + 각 규칙은 트래픽의 약 33.3%를 처리하여 `10.2.0.110`, `10.2.1.39` 및 `10.2.2.254` 간에 균일한 로드 밸런싱을 제공합니다. 이러한 멀티 레벨 체인 구조를 통해 `kube-proxy`는 데이터 경로에 프록시 프로세스가 필요 없이 커널 레벨 패킷 조작을 통해 서비스 로드 밸런싱 및 리디렉션을 효율적으로 구현할 수 있습니다. ### Kubernetes 작업에 미치는 영향 노드에서 `kube-proxy`가 손상되면 해당 노드가 서비스 트래픽을 제대로 라우팅할 수 없어 클러스터 서비스에 의존하는 포드에 제한 시간 초과나 연결 실패가 발생합니다. 이는 노드가 처음 등록될 때 특히 방해가 될 수 있습니다. CNI는 포드 네트워킹을 구성하기 전에 노드의 포드 CIDR과 같은 정보를 얻기 위해 Kubernetes API 서버와 통신해야 합니다. 이를 위해 CNI는 `kubernetes` 서비스 IP를 사용합니다. 그러나 `kube-proxy`가 시작되지 못하거나 올바른 `iptables` 규칙을 설정하지 못한 경우 `kubernetes` 서비스 IP로 전송되는 요청은 EKS 컨트롤 플레인 ENI의 실제 IP로 변환되지 않습니다. 따라서 CNI는 충돌 루프에 들어가고 포드 중 어느 것도 제대로 실행되지 않습니다. 포드가 `kubernetes` 서비스 IP를 사용하여 Kubernetes API 서버와 통신한다는 것을 알고 있지만, 이를 작동시키려면 먼저 `kube-proxy`가 `iptables` 규칙을 설정해야 합니다. `kube-proxy`는 API 서버와 어떻게 통신하나요? `kube-proxy`는 Kubernetes API 서버의 실제 IP 또는 해당 IP로 확인되는 DNS 이름을 사용하도록 구성해야 합니다. EKS의 경우 EKS는 클러스터 생성 시 EKS가 생성하는 Route53 DNS 이름을 가리키도록 기본 `kube-proxy`를 구성합니다. 이 값은 `kube-system` 네임스페이스의 `kube-proxy` ConfigMap에서 확인할 수 있습니다. 이 ConfigMap의 내용은 `kube-proxy` 포드에 삽입되는 `kubeconfig`이므로 `clusters–0—.cluster.server` 필드를 확인하세요. 이 값은 EKS `DescribeCluster` API 직접 호출 시 EKS 클러스터의 `endpoint` 필드와 일치합니다. ``` apiVersion: v1 data: kubeconfig: |- kind: Config apiVersion: v1 clusters: - cluster: certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt server: https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com name: default contexts: - context: cluster: default namespace: default user: default name: default current-context: default users: - name: default user: tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token kind: ConfigMap metadata: name: kube-proxy namespace: kube-system ``` ## 라우팅 가능한 원격 포드 CIDR 이 [하이브리드 노드의 네트워킹 개념](hybrid-nodes-concepts-networking.md) 페이지에서는 하이브리드 노드에서 웹후크를 실행하거나 클라우드 노드에서 실행되는 포드가 하이브리드 노드에서 실행되는 포드와 통신하도록 하는 요구 사항을 자세히 설명합니다. 핵심 요구 사항은 온프레미스 라우터가 특정 포드 IP를 담당하는 노드를 알아야 한다는 것입니다. Border Gateway Protocol(BGP), 정적 경로, 주소 확인 프로토콜(ARP) 프록시 등 이를 달성하는 방법에는 여러 가지가 있습니다. 이들은 다음 섹션에서 다룹니다. **Border Gateway Protocol(BGP)** CNI가 이를 지원하는 경우(예: Cilium 및 Calico), CNI의 BGP 모드를 사용하여 노드에서 로컬 라우터로 노드별 포드 CIDR에 대한 경로를 전파할 수 있습니다. CNI의 BGP 모드를 사용할 때 CNI는 가상 라우터 역할을 하므로 로컬 라우터는 포드 CIDR이 다른 서브넷에 속하고 노드가 해당 서브넷의 게이트웨이라고 간주합니다. ![\[하이브리드 노드 BGP 라우팅\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-bgp.png) **정적 경로** 또는 로컬 라우터에서 정적 경로를 구성할 수 있습니다. 이는 온프레미스 포드 CIDR을 VPC로 라우팅하는 가장 간단한 방법이지만 가장 오류가 발생하기 쉽고 유지 관리하기 어렵습니다. 기존 노드와 할당된 포드 CIDR을 사용하여 경로가 항상 최신 상태인지 확인해야 합니다. 노드 수가 적고 인프라가 정적이면 실행 가능한 옵션이며 라우터에서 BGP를 지원할 필요가 없습니다. 이 옵션을 선택하는 경우 IPAM이 결정하도록 하는 대신 각 노드에 할당하려는 포드 CIDR 조각으로 CNI를 구성하는 것이 좋습니다. ![\[하이브리드 노드 정적 라우팅\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-static-routes.png) **주소 확인 프로토콜(ARP) 프록시** ARP 프록시는 온프레미스 포드 IP를 라우팅 가능하게 만드는 또 다른 접근 방식이며, 하이브리드 노드가 로컬 라우터와 동일한 계층 2 네트워크에 있을 때 특히 유용합니다. ARP 프록싱이 활성화되면 노드는 자신이 호스팅하는 포드 IP에 대한 ARP 요청에 응답하는데, 해당 IP가 다른 서브넷에 속하더라도 마찬가지입니다. 로컬 네트워크의 디바이스가 포드 IP에 도달하려고 할 때 먼저 '누가 이 IP를 가지고 있나요?'라는 ARP 요청을 전송합니다. 포드가 자체 MAC 주소로 응답하는 하이브리드 노드 호스팅으로, ‘해당 IP에 대한 트래픽을 처리할 수 있습니다.’라는 메시지가 표시됩니다. 이를 통해 라우터 구성 없이 로컬 네트워크의 디바이스와 포드 간에 직접 경로가 생성됩니다. 이렇게 하려면 CNI가 프록시 ARP 기능을 지원해야 합니다. Cilium에는 구성을 통해 활성화할 수 있는 프록시 ARP에 대한 지원이 내장되어 있습니다. 가장 중요한 고려 사항은 포드 CIDR이 환경 내의 다른 네트워크와 겹치지 않아야 한다는 것입니다. 겹치면 라우팅 충돌이 발생할 수 있습니다. 이 접근 방식에는 다음과 같은 몇 가지 이점이 있습니다. \$1 BGP로 라우터를 구성하거나 정적 경로를 유지할 필요가 없습니다. \$1 라우터 구성을 제어할 수 없는 환경에서 잘 작동합니다. ![\[하이브리드 노드 ARP 프록시\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-arp-proxy.png) ## 포드 간 캡슐화 온프레미스 환경에서 CNI는 일반적으로 캡슐화 프로토콜을 사용하여 물리적 네트워크상에서 작동할 수 있는 오버레이 네트워크를 생성하므로 네트워크를 재구성할 필요가 없습니다. 이 섹션에서는 이러한 캡슐화가 어떻게 작동하는지 설명합니다. 일부 세부 정보는 사용하는 CNI에 따라 다를 수 있습니다. 캡슐화는 원래의 포드 네트워크 패킷을 기본 물리적 네트워크를 통해 라우팅될 수 있는 다른 네트워크 패킷으로 묶습니다. 이를 통해 포드는 물리적 네트워크가 해당 포드 CIDR을 라우팅하는 방법을 알 필요 없이 동일한 CNI를 실행하는 노드 간에 통신할 수 있습니다. Kubernetes에서 가장 일반적으로 사용되는 캡슐화 프로토콜은 VXLAN(Virtual Extensible LAN)이지만 CNI에 따라 `Geneve` 등의 다른 프로토콜도 사용할 수 있습니다. ### VXLAN 캡슐화 VXLAN은 UDP 패킷 내에서 계층 2 이더넷 프레임을 캡슐화합니다. 포드가 다른 노드의 다른 포드로 트래픽을 전송하면 CNI는 다음을 수행합니다. 1. CNI가 포드 A에서 패킷을 가로챕니다. 1. CNI가 원래 패킷을 VXLAN 헤더로 래핑합니다. 1. 그러면 이 래핑된 패킷이 노드의 일반 네트워킹 스택을 통해 대상 노드로 전송됩니다. 1. 대상 노드의 CNI가 패킷을 언래핑하여 포드 B로 전송합니다. VXLAN 캡슐화 중 패킷 구조에는 다음과 같은 일이 일어납니다. 원래 포드 간 패킷: ``` +-----------------+---------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: Pod A IP | Src Port | | | Dst: Pod B MAC | Dst: Pod B IP | Dst Port | | +-----------------+---------------+-------------+-----------------+ ``` VXLAN 캡슐화 후 ``` +-----------------+-------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node A MAC | Src: Node A | Src: Random | VNI: xx | Packet (unchanged | | Dst: Node B MAC | Dst: Node B | Dst: 4789 | | from above) | +-----------------+-------------+--------------+------------+---------------------------+ ``` VXLAN 네트워크 식별자(VNI)는 서로 다른 오버레이 네트워크를 구분합니다. ### 포드 통신 시나리오 **동일한 하이브리드 노드의 포드** 동일한 하이브리드 노드의 포드가 통신하는 경우 일반적으로 캡슐화가 필요하지 않습니다. CNI는 노드의 내부 가상 인터페이스를 통해 포드 간 트래픽을 보내는 로컬 경로를 설정합니다. ``` Pod A -> veth0 -> node's bridge/routing table -> veth1 -> Pod B ``` 패킷은 절대 노드를 벗어나지 않으며 캡슐화가 불필요합니다. **다양한 하이브리드 노드의 포드** 서로 다른 하이브리드 노드의 포드 간 통신에는 캡슐화가 필요합니다. ``` Pod A -> CNI -> [VXLAN encapsulation] -> Node A network -> router or gateway -> Node B network -> [VXLAN decapsulation] -> CNI -> Pod B ``` 이렇게 하면 물리적 네트워크가 포드 IP 라우팅을 이해할 필요 없이 포드 트래픽이 물리적 네트워크 인프라를 통과할 수 있습니다. # 하이브리드 노드의 네트워크 트래픽 흐름 이 페이지에서는 다양한 트래픽 유형에 대한 엔드 투 엔드 네트워크 경로를 보여주는 다이어그램과 함께 EKS Hybrid Nodes의 네트워크 트래픽 흐름을 자세히 설명합니다. 다음 트래픽 흐름이 포함됩니다. + [하이브리드 노드 `kubelet`에서 EKS 컨트롤 플레인으로](#hybrid-nodes-concepts-traffic-flows-kubelet-to-cp) + [EKS 컨트롤 플레인에서 하이브리드 노드로(`kubelet` 서버)](#hybrid-nodes-concepts-traffic-flows-cp-to-kubelet) + [하이브리드 노드에서 실행되는 포드에서 EKS 컨트롤 플레인으로](#hybrid-nodes-concepts-traffic-flows-pods-to-cp) + [하이브리드 노드에서 실행되는 포드에 대한 EKS 컨트롤 플레인(웹후크)](#hybrid-nodes-concepts-traffic-flows-cp-to-pod) + [하이브리드 노드에서 실행되는 포드 간](#hybrid-nodes-concepts-traffic-flows-pod-to-pod) + [클라우드 노드의 포드에서 하이브리드 노드의 포드로(동서 트래픽)](#hybrid-nodes-concepts-traffic-flows-east-west) ## 하이브리드 노드 `kubelet`에서 EKS 컨트롤 플레인으로 ![\[하이브리드 노드 kubelet에서 EKS 컨트롤 플레인으로\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-kubelet-to-cp-public.png) ### 요청 **1. `kubelet` 요청 시작** 하이브리드 노드의 `kubelet`이 EKS 컨트롤 플레인과 통신해야 하는 경우(예: 노드 상태 보고 또는 포드 사양 가져오기), 노드 등록 중 제공된 `kubeconfig` 파일을 사용합니다. 이 `kubeconfig`에는 직접 IP 주소가 아닌 API 서버 엔드포인트 URL(Route53 DNS 이름)이 있습니다. `kubelet`은 엔드포인트(예: `https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com`)에 대한 DNS 조회를 수행합니다. 퍼블릭 액세스 클러스터에서는 AWS에서 실행되는 EKS 서비스에 속하는 퍼블릭 IP 주소(예: `54.239.118.52`)로 확인됩니다. 그런 다음 `kubelet`은 이 엔드포인트에 대한 보안 HTTPS 요청을 생성합니다. 초기 패킷은 다음과 같습니다. ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 52390 (random) | | | Dst: 54.239.118.52 | Dst: 443 | | +--------------------+---------------------+-----------------+ ``` **2. 로컬 라우터 라우팅** 대상 IP가 로컬 네트워크의 일부가 아닌 퍼블릭 IP 주소이므로 `kubelet`은 이 패킷을 기본 게이트웨이(로컬 온프레미스 라우터)로 전송합니다. 라우터는 대상 IP를 검사하고 퍼블릭 IP 주소인지 확인합니다. 퍼블릭 트래픽의 경우 라우터는 일반적으로 인터넷으로의 아웃바운드 트래픽을 처리하는 인터넷 게이트웨이 또는 경계 라우터로 패킷을 전달합니다. 이는 다이어그램에서 생략되며 온프레미스 네트워크 설정 방식에 따라 달라집니다. 패킷은 온프레미스 네트워크 인프라를 통과하여 결국 인터넷 서비스 제공업체의 네트워크에 도달합니다. **3. EKS 컨트롤 플레인으로 전송** 패킷은 AWS의 네트워크에 도달할 때까지 퍼블릭 인터넷과 전송 네트워크를 통해 이동합니다. AWS의 네트워크는 패킷을 적절한 리전의 EKS 서비스 엔드포인트로 라우팅합니다. 패킷이 EKS 서비스에 도달하면 클러스터의 실제 EKS 컨트롤 플레인으로 전달됩니다. 퍼블릭 인터넷을 통한 이 라우팅은 다른 트래픽 흐름에서 볼 수 있는 프라이빗 VPC 라우팅 경로와 다릅니다. 주요 차이점은 퍼블릭 액세스 모드를 사용할 때 온프레미스 `kubelet`(포드가 아님)에서 EKS 컨트롤 플레인으로의 트래픽이 VPC를 통과하지 않고 대신 글로벌 인터넷 인프라를 사용한다는 것입니다. ### 응답 EKS 컨트롤 플레인이 `kubelet` 요청을 처리한 후 응답을 다시 전송합니다. **3. EKS 컨트롤 플레인에서 응답 전송** EKS 컨트롤 플레인은 응답 패킷을 생성합니다. 이 패킷에는 소스로 퍼블릭 IP, 대상으로 하이브리드 노드의 IP가 있습니다. ``` +--------------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 54.239.118.52 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 52390 | | +--------------------+---------------------+-----------------+ ``` **2. 인터넷 라우팅** 응답 패킷은 인터넷 서비스 제공업체가 결정한 라우팅 경로에 따라 온프레미스 네트워크 엣지 라우터에 도달할 때까지 인터넷을 통해 다시 이동합니다. **1: 로컬 전송** 온프레미스 라우터는 패킷을 수신하고 대상 IP(`10.80.0.2`)를 로컬 네트워크에 속하는 것으로 인식합니다. 패킷이 대상 하이브리드 노드에 도달할 때까지 로컬 네트워크 인프라를 통해 패킷을 전달하고, 여기서 `kubelet`이 응답을 수신하고 처리합니다. ## 하이브리드 노드 `kube-proxy`에서 EKS 컨트롤 플레인으로 클러스터에 대해 퍼블릭 엔드포인트 액세스를 활성화하면 반환 트래픽은 퍼블릭 인터넷을 사용합니다. 이 트래픽은 하이브리드 노드의 `kube-proxy`에서 시작되어 EKS 컨트롤 플레인으로 이동하며 `kubelet`에서 EKS 컨트롤 플레인으로 이동하는 트래픽과 동일한 경로를 따릅니다. ## EKS 컨트롤 플레인에서 하이브리드 노드로(`kubelet` 서버) ![\[EKS 컨트롤 플레인에서 하이브리드 노드로\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-cp-to-kubelet.png) ### 요청 **1: EKS Kubernetes API 서버가 요청 시작** EKS Kubernetes API 서버는 노드 객체의 상태에서 노드의 IP 주소(`10.80.0.2`)를 검색합니다. 그런 다음 대상 IP가 구성된 원격 노드 CIDR(`10.80.0.0/16`)에 속하므로 VPC의 ENI를 통해 이 요청을 라우팅합니다. 초기 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 67493 (random) | | | Dst: 10.80.0.2 | Dst: 10250 | | +-----------------+---------------------+-----------------+ ``` **2. VPC 네트워크 처리** 패킷은 ENI를 떠나 VPC 네트워킹 계층으로 들어가고, 이후 라우팅을 위해 서브넷의 게이트웨이로 전달됩니다. **3. VPC 라우팅 테이블 조회** EKS 컨트롤 플레인 ENI가 포함된 서브넷의 VPC 라우팅 테이블에는 원격 노드 CIDR에 대한 특정 경로(다이어그램의 두 번째 경로)가 있습니다. 이 라우팅 규칙에 따라 패킷은 VPC-온프레미스 게이트웨이로 전달됩니다. **4. 교차 경계 전송** 게이트웨이는 설정된 연결(예: Direct Connect 또는 VPN)을 통해 클라우드 경계를 넘어 온프레미스 네트워크로 패킷을 전송합니다. **5. 온프레미스 네트워크 수신** 패킷은 하이브리드 노드가 위치한 서브넷의 트래픽을 처리하는 로컬 온프레미스 라우터에 도착합니다. **6. 최종 전송** 로컬 라우터는 대상 IP(`10.80.0.2`) 주소가 직접 연결된 네트워크에 속하는 것을 식별하고 패킷을 대상 하이브리드 노드로 직접 전달하며, 여기서 `kubelet`이 요청을 수신하고 처리합니다. ### 응답 하이브리드 노드의 `kubelet`이 요청을 처리한 후, 동일한 경로를 역으로 응답을 다시 전송합니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 10250 | | | Dst: 10.0.0.132 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **6. `kubelet` 응답 전송** 하이브리드 노드(`10.80.0.2`)의 `kubelet`은 원본 소스 IP를 대상으로 하는 응답 패킷을 생성합니다. 대상은 로컬 네트워크에 속하지 않으므로 호스트의 기본 게이트웨이인 로컬 라우터로 전송됩니다. **5. 로컬 라우터 라우팅** 라우터는 대상 IP(`10.0.0.132`)가 AWS로 연결되는 게이트웨이를 가리키는 경로를 가진 `10.0.0.0/16`에 속한다고 판단합니다. **4. 교차 경계 반환** 패킷은 동일한 온프레미스를 통해 VPC 연결(예: Direct Connect 또는 VPN)로 다시 이동하며 반대 방향으로 클라우드 경계를 통과합니다. **3. VPC 라우팅** 패킷이 VPC에 도착하면 라우팅 테이블은 대상 IP가 VPC CIDR에 속함을 식별합니다. 패킷은 VPC 내에서 라우팅됩니다. **2. VPC 네트워크 전송** VPC 네트워킹 계층은 EKS 컨트롤 플레인 ENI(`10.0.0.132`)를 사용하여 패킷을 서브넷으로 전달합니다. **1: ENI 수신** 패킷은 Kubernetes API 서버에 연결된 EKS 컨트롤 플레인 ENI에 도달하여 왕복을 완료합니다. ## 하이브리드 노드에서 실행되는 포드에서 EKS 컨트롤 플레인으로 ![\[하이브리드 노드에서 실행되는 포드에서 EKS 컨트롤 플레인으로\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-pod-to-cp.png) ### CNI NAT 사용 안 함 ### 요청 포드는 일반적으로 `kubernetes` 서비스를 통해 Kubernetes API 서버와 통신합니다. 서비스 IP는 클러스터 서비스 CIDR의 첫 번째 IP입니다. 이 규칙을 사용하면 CoreDNS를 사용할 수 있기 전에 실행해야 하는 포드(예: CNI)가 API 서버에 도달할 수 있습니다. 요청은 서비스 IP를 대상으로 하여 포드를 떠납니다. 예를 들어 서비스 CIDR이 `172.16.0.0/16`인 경우 서비스 IP는 `172.16.0.1`이 됩니다. **1: 포드에서 요청 시작** 포드는 임의의 소스 포트에서 API 서버 포트(443)의 `kubernetes` 서비스 IP(`172.16.0.1`)로 요청을 전송합니다. 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. CNI 처리** CNI는 대상 IP가 관리하는 어떤 포드 CIDR에도 속하지 않음을 감지합니다. **발신 NAT가 비활성화**되어 있으므로 CNI는 패킷을 수정하지 않고 호스트 네트워크 스택으로 전달합니다. **3. 노드 네트워크 처리** 패킷은 `netfilter` 후크가 kube-proxy에서 설정한 `iptables` 규칙을 트리거하는 노드의 네트워크 스택으로 들어갑니다. 다음과 같은 순서로 여러 규칙이 적용됩니다. 1. 패킷은 먼저 `KUBE-SERVICES` 체인에 도달합니다. 여기에는 각 서비스의 ClusterIP 및 포트와 일치하는 규칙이 포함됩니다. 1. 일치하는 규칙은 `kubernetes` 서비스(`172.16.0.1:443`으로 전송되는 패킷)에 대한 `KUBE-SVC-XXX` 체인으로 이동합니다. 1. 로드 밸런싱 규칙은 컨트롤 플레인 ENI IP(`10.0.0.132` 또는 `10.0.1.23`)에 대해 `KUBE-SEP-XXX` 체인 중 하나를 무작위로 선택합니다. 1. 선택한 `KUBE-SEP-XXX` 체인에는 대상 IP를 서비스 IP에서 선택한 IP로 변경하는 실제 규칙이 있습니다. 이를 DNAT(Destination Network Address Translation)이라고 합니다. 이러한 규칙이 적용된 후 선택한 EKS 컨트롤 플레인 ENI의 IP가 `10.0.0.132`라고 가정하면 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` 대상 IP가 로컬 네트워크에 없기 때문에 노드는 패킷을 기본 게이트웨이로 전달합니다. **4. 로컬 라우터 라우팅** 로컬 라우터는 대상 IP(`10.0.0.132`)가 VPC CIDR(`10.0.0.0/16`)에 속한다고 판단하고 이를 AWS에 연결하는 게이트웨이로 전달합니다. **5. 교차 경계 전송** 패킷은 설정된 연결(예: Direct Connect 또는 VPN)을 통해 클라우드 경계를 넘어 VPC로 이동합니다. **6. VPC 네트워크 전송** VPC 네트워킹 계층은 EKS 컨트롤 플레인 ENI(`10.0.0.132`)가 위치한 올바른 서브넷으로 패킷을 라우팅합니다. **7. ENI 수신** 패킷은 Kubernetes API 서버에 연결된 EKS 컨트롤 플레인 ENI에 도달합니다. ### 응답 EKS 컨트롤 플레인이 요청을 처리한 후 포드에 응답을 다시 전송합니다. **7. API 서버 전송 응답** EKS Kubernetes API 서버는 원본 소스 IP를 대상으로 하는 응답 패킷을 생성합니다. 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` 대상 IP는 구성된 원격 포드 CIDR(`10.85.0.0/16`)에 속하므로 서브넷의 라우터를 다음 홉으로 사용하여 VPC의 ENI를 통해 전송합니다. **6. VPC 라우팅** VPC 라우팅 테이블에는 원격 포드 CIDR(`10.85.0.0/16`)에 대한 항목이 포함되어 이 트래픽을 VPC-온프레미스 게이트웨이로 전달합니다. **5. 교차 경계 전송** 게이트웨이는 설정된 연결(예: Direct Connect 또는 VPN)을 통해 클라우드 경계를 넘어 온프레미스 네트워크로 패킷을 전송합니다. **4. 온프레미스 네트워크 수신** 패킷이 로컬 온프레미스 라우터에 도착합니다. **3. 노드로 전송** 라우터 테이블에는 `10.85.1.0/24`에 대한 항목이 있고, 다음 홉은 `10.80.0.2`로 패킷을 노드에 전달합니다. **2. 노드 네트워크 처리** 패킷이 노드의 네트워크 스택에서 처리되면 `conntrack`(`netfilter`의 일부)은 패킷을 포드가 처음 설정한 연결과 일치시킵니다. 원래 DNAT가 적용되었으므로 `conntrack`은 EKS 컨트롤 플레인 ENI의 IP에서 `kubernetes` 서비스 IP로 소스 IP를 다시 작성하여 DNAT를 되돌립니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1: CNI 처리** CNI는 대상 IP가 네트워크의 포드에 속함을 식별하고 패킷을 올바른 포드 네트워크 네임스페이스로 전송합니다. 이 흐름은 원격 포드 CIDR이 VPC에서 각 포드를 호스팅하는 특정 노드까지 제대로 라우팅되어야 하는 이유를 보여줍니다. 전체 반환 경로는 클라우드 및 온프레미스 네트워크 모두에서 포드 IP의 적절한 라우팅에 따라 달라집니다. ### CNI NAT 사용 이 흐름은 *CNI NAT가 없는* 흐름과 매우 유사하지만 한 가지 주요 차이점이 있습니다. CNI는 패킷을 노드의 네트워크 스택으로 전송하기 전에 패킷에 소스 NAT(SNAT)를 적용한다는 점입니다. 이렇게 하면 패킷의 소스 IP가 노드의 IP로 변경되므로 추가 라우팅 구성 없이 패킷을 노드로 다시 라우팅할 수 있습니다. ### 요청 **1: 포드에서 요청 시작** 포드는 임의의 소스 포트에서 EKS Kubernetes API 서버 포트(443)의 `kubernetes` 서비스 IP(`172.16.0.1`)로 요청을 전송합니다. 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` **2. CNI 처리** CNI는 대상 IP가 관리하는 어떤 포드 CIDR에도 속하지 않음을 감지합니다. **발신 NAT가 활성화**되었으므로 CNI는 패킷에 SNAT를 적용하여 소스 IP를 노드의 네트워크 스택에 전달하기 전에 노드의 IP로 변경합니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 172.16.0.1 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` 참고: 예에서는 명확성을 위해 CNI와 `iptables`를 별도의 블록으로 표시했지만 실제로는 일부 CNI가 `iptables`를 사용하여 NAT를 적용할 수 있습니다. **3. 노드 네트워크 처리** 여기서 `kube-proxy` 설정한 `iptables` 규칙은 이전 예제에서와 동일하게 동작하여 패킷을 EKS 컨트롤 플레인 ENI 중 하나로 로드 밸런싱합니다. 패킷은 이제 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.80.0.2 | Src: 67493 (random) | | | Dst: 10.0.0.132 | Dst: 443 | | +-----------------+---------------------+-----------------+ ``` 대상 IP가 로컬 네트워크에 없기 때문에 노드는 패킷을 기본 게이트웨이로 전달합니다. **4. 로컬 라우터 라우팅** 로컬 라우터는 대상 IP(`10.0.0.132`)가 VPC CIDR(`10.0.0.0/16`)에 속한다고 판단하고 이를 AWS에 연결하는 게이트웨이로 전달합니다. **5. 교차 경계 전송** 패킷은 설정된 연결(예: Direct Connect 또는 VPN)을 통해 클라우드 경계를 넘어 VPC로 이동합니다. **6. VPC 네트워크 전송** VPC 네트워킹 계층은 EKS 컨트롤 플레인 ENI(`10.0.0.132`)가 위치한 올바른 서브넷으로 패킷을 라우팅합니다. **7. ENI 수신** 패킷은 Kubernetes API 서버에 연결된 EKS 컨트롤 플레인 ENI에 도달합니다. ### 응답 EKS 컨트롤 플레인이 요청을 처리한 후 포드에 응답을 다시 전송합니다. **7. API 서버 전송 응답** EKS Kubernetes API 서버는 원본 소스 IP를 대상으로 하는 응답 패킷을 생성합니다. 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` 대상 IP는 구성된 원격 노드 CIDR(`10.80.0.0/16`)에 속하므로 서브넷의 라우터를 다음 홉으로 사용하여 VPC의 ENI를 통해 전송합니다. **6. VPC 라우팅** VPC 라우팅 테이블에는 원격 노드 CIDR(`10.80.0.0/16`)에 대한 항목이 포함되어 이 트래픽을 VPC-온프레미스 게이트웨이로 전달합니다. **5. 교차 경계 전송** 게이트웨이는 설정된 연결(예: Direct Connect 또는 VPN)을 통해 클라우드 경계를 넘어 온프레미스 네트워크로 패킷을 전송합니다. **4. 온프레미스 네트워크 수신** 패킷이 로컬 온프레미스 라우터에 도착합니다. **3. 노드로 전송** 로컬 라우터는 대상 IP(`10.80.0.2`) 주소가 직접 연결된 네트워크에 속하는 것을 식별하고 패킷을 대상 하이브리드 노드로 직접 전달합니다. **2. 노드 네트워크 처리** 패킷이 노드의 네트워크 스택에서 처리될 때 `conntrack`(`netfilter`의 일부)은 패킷을 포드가 처음에 설정한 연결과 일치시키고 DNAT가 원래 적용되었기 때문에 EKS 컨트롤 플레인 ENI의 IP에서 `kubernetes` 서비스 IP로 소스 IP를 다시 작성하여 이를 반대로 수행합니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.80.0.2 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` **1: CNI 처리** CNI는 이 패킷이 이전에 SNAT를 적용한 연결에 속함을 식별합니다. SNAT를 반대로 실행하여 대상 IP를 포드의 IP로 다시 변경합니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 172.16.0.1 | Src: 443 | | | Dst: 10.85.1.56 | Dst: 67493 | | +-----------------+---------------------+-----------------+ ``` CNI는 대상 IP가 네트워크의 포드에 속함을 감지하고 패킷을 올바른 포드 네트워크 네임스페이스로 전송합니다. 이 흐름은 CNI NAT-ing이 Pod CIDR에 대한 추가 라우팅을 요구하지 않고도 패킷을 노드로 다시 라우팅할 수 있도록 하여 구성을 간소화하는 방법을 보여줍니다. ## 하이브리드 노드에서 실행되는 포드에 대한 EKS 컨트롤 플레인(웹후크) ![\[하이브리드 노드에서 실행되는 포드에 대한 EKS 컨트롤 플레인\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-cp-to-pod.png) 이 트래픽 패턴은 EKS 컨트롤 플레인이 하이브리드 노드의 포드에서 실행되는 웹후크 서버에 대한 연결을 직접 시작해야 하는 웹후크에서 가장 일반적으로 볼 수 있습니다. 리소스 검증 또는 변형 프로세스 중 API 서버에서 직접적으로 호출하는 승인 웹후크의 검증 및 변형을 예로 들 수 있습니다. ### 요청 **1: EKS Kubernetes API 서버가 요청 시작** 클러스터에 웹후크가 구성되고 관련 API 작업이 이를 트리거하면 EKS Kubernetes API 서버는 웹후크 서버 포드에 직접 연결해야 합니다. API 서버는 먼저 웹후크와 연결된 서비스 또는 엔드포인트 리소스에서 포드의 IP 주소를 조회합니다. IP가 `10.85.1.23`인 하이브리드 노드에서 웹후크 포드가 실행 중이라는 가정하에 EKS Kubernetes API 서버는 웹후크 엔드포인트에 HTTPS 요청을 생성합니다. 대상 IP `10.85.1.23`이 구성된 원격 포드 CIDR(`10.85.0.0/16`)에 속하기 때문에 초기 패킷은 VPC의 EKS 컨트롤 플레인 ENI를 통해 전송됩니다. 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.132 | Src: 41892 (random) | | | Dst: 10.85.1.23 | Dst: 8443 | | +-----------------+---------------------+-----------------+ ``` **2. VPC 네트워크 처리** 패킷은 EKS 컨트롤 플레인 ENI를 떠나 서브넷의 라우터를 다음 홉으로 하여 VPC 네트워킹 계층으로 들어갑니다. **3. VPC 라우팅 테이블 조회** EKS 컨트롤 플레인 ENI가 포함된 서브넷의 VPC 라우팅 테이블에는 원격 포드 CIDR에 대한 특정 경로(`10.85.0.0/16`)가 포함되어 있습니다. 이 라우팅 규칙은 패킷을 VPC-온프레미스 게이트웨이(예: Direct Connect 또는 VPN 연결을 위한 가상 프라이빗 게이트웨이)로 전달합니다. ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` **4. 교차 경계 전송** 게이트웨이는 설정된 연결(예: Direct Connect 또는 VPN)을 통해 클라우드 경계를 넘어 온프레미스 네트워크로 패킷을 전송합니다. 패킷은 이 연결을 통과할 때 원본 소스 및 대상 IP 주소를 유지합니다. **5. 온프레미스 네트워크 수신** 패킷이 로컬 온프레미스 라우터에 도착합니다. 라우터는 라우팅 테이블을 참조하여 10.85.1.23 주소에 도달하는 방법을 결정합니다. 이를 위해서는 온프레미스 네트워크에 트래픽을 적절한 하이브리드 노드로 전달하는 포드 CIDR에 대한 경로가 있어야 합니다. 이 경우 라우터의 라우팅 테이블에는 IP가 `10.80.0.2`인 하이브리드 노드를 통해 `10.85.1.0/24` 서브넷에 도달할 수 있음을 나타내는 항목이 포함되어 있습니다. ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **6. 노드로 전송** 라우팅 테이블 항목을 기반으로 라우터는 패킷을 하이브리드 노드(`10.80.0.2`)로 전달합니다. 패킷이 노드에 도착하면 대상 IP가 여전히 포드의 IP인 것을 제외하면 EKS Kubernetes API 서버가 패킷을 전송했을 때와 동일하게 보입니다. **7. CNI 처리** 노드의 네트워크 스택은 패킷을 수신하고 대상 IP가 노드의 자체 IP가 아님을 확인한 후 처리를 위해 CNI에 전달합니다. CNI는 대상 IP가 이 노드에서 로컬로 실행되는 포드에 속함을 식별하고 적절한 가상 인터페이스를 통해 패킷을 올바른 포드로 전달합니다. ``` Original packet -> node routing -> CNI -> Pod's network namespace ``` 포드의 웹후크 서버는 요청을 수신하고 처리합니다. ### 응답 웹후크 포드가 이 요청을 처리한 후, 동일한 경로를 역으로 응답을 다시 전송합니다. **7. 포드에서 응답 전송** 웹후크 포드는 자체 IP를 소스로, 원래 요청자(EKS 컨트롤 플레인 ENI)를 대상으로 응답 패킷을 생성합니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.23 | Src: 8443 | | | Dst: 10.0.0.132 | Dst: 41892 | | +-----------------+---------------------+-----------------+ ``` CNI는 이 패킷이 로컬 포드가 아닌 외부 네트워크로 이동함을 식별하고 원본 소스 IP가 보존된 노드의 네트워크 스택으로 패킷을 전달합니다. **6. 노드 네트워크 처리** 노드는 대상 IP(`10.0.0.132`)가 로컬 네트워크에 없다고 판단하고 패킷을 기본 게이트웨이(로컬 라우터)로 전달합니다. **5. 로컬 라우터 라우팅** 로컬 라우터는 라우팅 테이블을 참조하여 대상 IP(`10.0.0.132`)가 VPC CIDR(`10.0.0.0/16`)에 속한다고 판단하고 패킷을 AWS에 연결하는 게이트웨이로 전달합니다. **4. 교차 경계 전송** 패킷은 동일한 온프레미스를 통해 VPC 연결로 다시 이동하며 반대 방향으로 클라우드 경계를 통과합니다. **3. VPC 라우팅** 패킷이 VPC에 도착하면 라우팅 테이블은 대상 IP가 VPC 내의 서브넷에 속함을 식별합니다. 패킷은 VPC 내에서 그에 따라 라우팅됩니다. **2. 및 1. EKS 컨트롤 플레인 ENI 수신** 패킷이 EKS Kubernetes API 서버에 연결된 ENI에 도달하여 왕복을 완료합니다. API 서버는 웹후크 응답을 수신하고 이 응답을 기반으로 원래 API 요청을 계속 처리합니다. 이 트래픽 흐름은 원격 포드 CIDR을 올바르게 구성하고 라우팅해야 하는 이유를 보여줍니다. + VPC에는 온프레미스 게이트웨이를 가리키는 원격 포드 CIDR에 대한 경로가 있어야 합니다. + 온프레미스 네트워크에는 해당 포드를 호스팅하는 특정 노드로 트래픽을 전달하는 포드 CIDR에 대한 경로가 있어야 합니다. + 이 라우팅 구성이 없으면 EKS 컨트롤 플레인이 하이브리드 노드의 포드에서 실행되는 웹후크와 기타 유사 서비스에 연결할 수 없습니다. ## 하이브리드 노드에서 실행되는 포드 간 ![\[하이브리드 노드에서 실행되는 포드 간\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-pod-to-pod.png) 이 섹션에서는 서로 다른 하이브리드 노드에서 실행되는 포드가 서로 통신하는 방법을 설명합니다. 이 예에서는 CNI가 캡슐화를 위해 VXLAN을 사용한다고 가정하며, 이는 Cilium 또는 Calico와 같은 CNI에 일반적입니다. 전체 프로세스는 Geneve 또는 IP-in-IP 등의 다른 캡슐화 프로토콜과 유사합니다. ### 요청 **1: 포드 A에서 통신 시작** 노드 1의 포드 A(`10.85.1.56`)가 노드 2의 포드 B(`10.85.2.67`)로 트래픽을 전송하려고 합니다. 초기 패킷은 다음과 같습니다. ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` **2. CNI에서 패킷을 가로채고 처리** 포드 A의 패킷이 네트워크 네임스페이스를 벗어나면 CNI가 이를 가로챕니다. CNI는 라우팅 테이블을 참조하여 다음을 확인합니다. - 대상 IP(`10.85.2.67`)는 포드 CIDR에 속합니다. - 이 IP는 로컬 노드에 없지만 노드 2(`10.80.0.3`)에 속합니다. - 패킷은 VXLAN으로 캡슐화되어야 합니다. 캡슐화 결정은 기본 물리적 네트워크가 포드 CIDR을 직접 라우팅하는 방법을 모르고 노드 IP 간의 트래픽을 라우팅하는 방법만 알기 때문에 중요합니다. CNI는 VXLAN 프레임 내에서 전체 원본 패킷을 캡슐화합니다. 이렇게 하면 새로운 헤더가 포함된 ‘패킷 내의 패킷’이 효과적으로 생성됩니다. ``` +-----------------+----------------+--------------+------------+---------------------------+ | Outer Ethernet | Outer IP | Outer UDP | VXLAN | Original Pod-to-Pod | | Src: Node1 MAC | Src: 10.80.0.2 | Src: Random | VNI: 42 | Packet (unchanged | | Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472 | | from above) | +-----------------+----------------+--------------+------------+---------------------------+ ``` 이 캡슐화의 핵심 사항: - 외부 패킷은 노드 1(`10.80.0.2`)에서 노드 2(`10.80.0.3`)로 주소가 지정됩니다. - UDP 포트 `8472`는 Cilium이 기본적으로 사용하는 VXLAN 포트입니다. - VXLAN 네트워크 식별자(VNI)는 이 패킷이 속하는 오버레이 네트워크를 식별합니다. - 전체 원본 패킷(포드 A의 IP를 소스로, 포드 B의 IP를 대상으로 함)은 내부에 그대로 보존됩니다. 캡슐화된 패킷은 이제 노드 1의 일반 네트워킹 스택에 들어가서 다른 패킷과 동일한 방식으로 처리됩니다. 1. **노드 네트워크 처리**: 노드 1의 네트워크 스택은 대상(`10.80.0.3`)을 기반으로 패킷을 라우팅합니다. 1. **로컬 네트워크 전송**: + 두 노드가 동일한 계층 2 네트워크에 있는 경우 패킷이 노드 2로 직접 전송됩니다. + 서로 다른 서브넷에 있는 경우 패킷이 먼저 로컬 라우터로 전달됩니다. 1. **라우터 처리**: 라우터가 라우팅 테이블을 기반으로 패킷을 전달하여 노드 2로 전송합니다. **3. 수신 노드 처리** 캡슐화된 패킷이 노드 2(`10.80.0.3`)에 도착하면 1. 노드의 네트워크 스택이 이를 수신하고 VXLAN 패킷(UDP 포트 `4789`)으로 식별합니다. 1. 패킷이 처리를 위해 CNI의 VXLAN 인터페이스로 전달됩니다. **4. VXLAN 캡슐화 해제** 노드 2의 CNI가 VXLAN 패킷을 처리합니다. 1. 외부 헤더(이더넷, IP, UDP 및 VXLAN)를 제거합니다. 1. 원래 내부 패킷을 추출합니다. 1. 이제 패킷이 원래 형식으로 돌아갑니다. ``` +------------------+-----------------+-------------+-----------------+ | Ethernet Header | IP Header | TCP/UDP | Payload | | Src: Pod A MAC | Src: 10.85.1.56 | Src: 43721 | | | Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080 | | +------------------+-----------------+-------------+-----------------+ ``` 노드 2의 CNI는 대상 IP(`10.85.2.67`)를 검사하고 다음을 수행합니다. 1. 이 IP가 로컬 포드에 속함을 식별합니다. 1. 적절한 가상 인터페이스를 통해 패킷을 라우팅합니다. 1. 포드 B의 네트워크 네임스페이스로 패킷을 전송합니다. ### 응답 포드 B가 포드 A에 응답하면 전체 프로세스가 반대로 수행됩니다. 1. 포드 B가 포드 A(`10.85.1.56`)로 패킷을 전송합니다. 1. 노드 2의 CNI는 노드 1(`10.80.0.2`)로 대상을 설정하여 VXLAN으로 캡슐화합니다. 1. 캡슐화된 패킷이 노드 1로 전달됩니다. 1. 노드 1의 CNI는 이를 캡슐화 해제하고 포드 A에 원래 응답을 전달합니다. ## 클라우드 노드의 포드에서 하이브리드 노드의 포드로(동서 트래픽) ![\[클라우드 노드의 포드에서 하이브리드 노드의 포드로\]](http://docs.aws.amazon.com/ko_kr/eks/latest/userguide/images/hybrid-nodes-east-west.png) ### 요청 **1: 포드 A에서 통신 시작** EC2 노드의 포드 A(`10.0.0.56`)가 하이브리드 노드의 포드 B(`10.85.1.56`)로 트래픽을 전송하려고 합니다. 초기 패킷은 다음과 같습니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.0.0.56 | Src: 52390 (random) | | | Dst: 10.85.1.56 | Dst: 8080 | | +-----------------+---------------------+-----------------+ ``` VPC CNI를 사용하면 포드 A는 VPC CIDR의 IP를 가지며 EC2 인스턴스의 ENI에 직접 연결됩니다. 포드의 네트워크 네임스페이스는 VPC 네트워크에 연결되므로 패킷은 VPC 라우팅 인프라에 직접 들어갑니다. **2. VPC 라우팅** VPC 라우팅 테이블에는 원격 포드 CIDR(`10.85.0.0/16`)에 대한 특정 경로가 포함되어 있으며, 이 트래픽을 VPC-온프레미스 게이트웨이로 전달합니다. ``` Destination Target 10.0.0.0/16 local 10.85.0.0/16 vgw-id (VPC-to-onprem gateway) ``` 이 라우팅 규칙에 따라 패킷은 온프레미스 네트워크에 연결하는 게이트웨이로 전달됩니다. **3. 교차 경계 전송** 게이트웨이는 설정된 연결(예: Direct Connect 또는 VPN)을 통해 클라우드 경계를 넘어 온프레미스 네트워크로 패킷을 전송합니다. 패킷은 이 전송 과정에서 원본 소스 및 대상 IP 주소를 유지합니다. **4. 온프레미스 네트워크 수신** 패킷이 로컬 온프레미스 라우터에 도착합니다. 라우터는 라우팅 테이블을 참조하여 10.85.1.56 주소에 도달하기 위한 다음 홉을 결정합니다. 온프레미스 라우터에 트래픽을 적절한 하이브리드 노드로 전달하는 포드 CIDR에 대한 경로가 있어야 합니다. 라우터의 테이블에는 IP가 `10.80.0.2`인 하이브리드 노드를 통해 `10.85.1.0/24` 서브넷에 연결할 수 있음을 나타내는 항목이 있습니다. ``` Destination Next Hop 10.85.1.0/24 10.80.0.2 ``` **5. 노드 네트워크 처리** 라우터는 패킷을 하이브리드 노드(`10.80.0.2`)로 전달합니다. 패킷이 노드에 도착해도 여전히 포드 A의 IP가 소스이고 포드 B의 IP가 대상입니다. **6. CNI 처리** 노드의 네트워크 스택은 패킷을 수신하고 대상 IP가 자체가 아님을 확인한 후 처리를 위해 CNI에 전달합니다. CNI는 대상 IP가 이 노드에서 로컬로 실행되는 포드에 속함을 식별하고 적절한 가상 인터페이스를 통해 패킷을 올바른 포드로 전달합니다. ``` Original packet -> node routing -> CNI -> Pod B's network namespace ``` 포드 B는 패킷을 수신하고 필요에 따라 처리합니다. ### 응답 **6. 포드 B에서 응답 전송** 포드 B는 자체 IP를 소스로, 포드 A의 IP를 대상으로 하는 응답 패킷을 생성합니다. ``` +-----------------+---------------------+-----------------+ | IP Header | TCP Header | Payload | | Src: 10.85.1.56 | Src: 8080 | | | Dst: 10.0.0.56 | Dst: 52390 | | +-----------------+---------------------+-----------------+ ``` CNI는 이 패킷이 외부 네트워크로 향하는 것을 식별하여 노드의 네트워크 스택으로 전달합니다. **5. 노드 네트워크 처리** 노드는 대상 IP(`10.0.0.56`)가 로컬 네트워크에 속하지 않는다고 판단하고 패킷을 기본 게이트웨이(로컬 라우터)로 전달합니다. **4. 로컬 라우터 라우팅** 로컬 라우터는 라우팅 테이블을 참조하여 대상 IP(`10.0.0.56`)가 VPC CIDR(`10.0.0.0/16`)에 속한다고 판단하고 패킷을 AWS에 연결하는 게이트웨이로 전달합니다. **3. 교차 경계 전송** 패킷은 동일한 온프레미스를 통해 VPC 연결로 다시 이동하며 반대 방향으로 클라우드 경계를 통과합니다. **2. VPC 라우팅** 패킷이 VPC에 도착하면 라우팅 시스템은 대상 IP가 VPC 내의 서브넷에 속함을 식별합니다. 패킷은 VPC 네트워크를 통해 포드 A를 호스팅하는 EC2 인스턴스로 라우팅됩니다. **1: 포드 A에서 응답 수신** 패킷은 EC2 인스턴스에 도착하고 연결된 ENI를 통해 포드 A로 직접 전달됩니다. VPC CNI는 VPC의 포드에 오버레이 네트워킹을 사용하지 않으므로 추가 캡슐화 해제가 필요하지 않습니다. 패킷은 원래 헤더가 그대로 유지된 상태로 도착합니다. 이 동서 트래픽 흐름은 원격 포드 CIDR을 올바르게 구성하고 양방향으로 라우팅해야 하는 이유를 보여줍니다. + VPC에는 온프레미스 게이트웨이를 가리키는 원격 포드 CIDR에 대한 경로가 있어야 합니다. + 온프레미스 네트워크에는 해당 포드를 호스팅하는 특정 노드로 트래픽을 전달하는 포드 CIDR에 대한 경로가 있어야 합니다.