Alibaba Cloud 컨테이너 네트워크 데이터 링크의 파노라마 분석(7): Terway DataPath V2(Terway≥1.8.0)

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

작가 : 유카이

머리말

최근 몇 년 동안 클라우드 네이티브 엔터프라이즈 인프라의 추세는 초기 IaaS부터 현재 마이크로서비스까지 점점 더 강력해지고 있으며, 세분화된 개선 및 관찰 가능성에 대한 고객의 요구는 더욱 강력해졌습니다. 고객의 더 높은 성능과 더 높은 밀도를 충족하기 위해 컨테이너 네트워크는 빠른 속도로 개발 및 진화해 왔으며, 이로 인해 고객의 클라우드 네이티브 네트워크 관찰 가능성에 대한 매우 높은 임계값과 과제가 필연적으로 발생합니다. 클라우드 네이티브 네트워크의 가시성을 향상시키고 고객과 일선 학생이 비즈니스 링크의 가독성을 더 쉽게 높일 수 있도록 ACK Industrial Research와 AES는 고객과 학생을 돕기 위해 일련의 클라우드 네이티브 네트워크 데이터 플레인 관측성을 공동으로 구축했습니다. 프론트 및 백라인에서는 클라우드 네이티브 네트워크 아키텍처 시스템을 이해하고, 클라우드 네이티브 네트워크의 관찰 가능성 임계값을 단순화하고, 어려운 문제를 처리하는 고객 운영 및 유지 관리 및 애프터 서비스 학생들의 경험을 최적화하고, 링크의 안정성을 향상시킵니다. 클라우드 네이티브 네트워크.

컨테이너 네트워크를 조감도로 보면 전체 컨테이너 네트워크는 포드 네트워크 세그먼트, 서비스 네트워크 세그먼트, 노드 네트워크 세그먼트의 세 부분으로 나눌 수 있습니다. 이 세 가지 네트워크는 상호 연결 및 액세스 제어를 달성해야 합니다. 그렇다면 구현을 위한 기술 원칙은 무엇입니까? 전체 링크는 무엇이며 제한 사항은 무엇입니까? 플란넬과 Terway의 차이점은 무엇입니까? 다양한 모드의 네트워크 성능은 어떻습니까? 이를 위해서는 고객이 컨테이너를 구축하기 전에 자신의 비즈니스 시나리오에 따라 선택해야 하며, 구축이 완료된 후에는 해당 아키텍처를 변경할 수 없으므로 고객은 각 아키텍처의 특성을 완전히 이해해야 합니다. 예를 들어 다음 그림은 단순화된 다이어그램입니다. Pod 네트워크는 동일한 ECS에 있는 Pod 간의 네트워크 상호 운용성과 제어를 실현해야 하며, SVC에 액세스하는 Pod의 백엔드도 동일한 ECS에 있을 수 있습니다. 다른 ECS, 이러한 다양한 모드에서는 데이터 링크 전달 모드가 다르며 비즈니스 측면의 성능 결과도 다릅니다.

이 글은 [컨테이너 네트워크 데이터 링크의 파노라마 분석]의 일곱 번째 부분으로, 주로 Kubernetes Terway DataPath V2 모드의 데이터 플레인 링크 전달 링크를 소개합니다. 먼저 다양한 시나리오의 데이터 플레인 전달 링크를 식별할 수 있습니다. 고객은 다양한 시나리오에서 액세스 링크의 데이터 표면 성능을 통해 고객이 컨테이너 네트워크 불안, 고객 운영 및 유지 관리 및 Alibaba Cloud에 직면할 때 전달 링크에 대한 심층적인 이해를 통해 비즈니스 아키텍처를 더욱 최적화할 수 있습니다. 학생들은 무슨 일이 일어나고 있는지 알 수 있으며 어떤 링크 포인트가 배포되었는지 수동으로 관찰하여 문제의 방향과 원인을 더 자세히 파악할 수 있습니다.

시리즈 1: Alibaba Cloud 컨테이너 네트워크 데이터 링크의 파노라마 분석(1) - Flannel

시리즈 2: Alibaba Cloud 컨테이너 네트워크 데이터 링크의 파노라마 분석(2) - Terway ENI

시리즈 3: Alibaba Cloud 컨테이너 네트워크 데이터 링크의 파노라마 분석(3) - Terway ENIIP

시리즈 4: Alibaba Cloud 컨테이너 네트워크 데이터 링크의 파노라마 분석(4) - Terway IPVLAN+EBPF

시리즈 5: Alibaba Cloud 컨테이너 네트워크 데이터 링크의 파노라마 분석(5) - Terway ENI-Trunking

시리즈 6: Alibaba Cloud 컨테이너 네트워크 데이터 링크의 파노라마 분석(6) - ASM Istio

Terway DataPath V2 패턴 아키텍처 설계

탄력적 네트워크 인터페이스(ENI)는 인스턴스 사양에 따라 단일 ENI(탄력적 네트워크 인터페이스)에 6~20개의 보조 IP를 할당할 수 있는 기능을 지원합니다. 컨테이너에 추가하여 Pod 배포의 크기와 밀도를 크게 향상시킵니다. 네트워크 연결 측면에서 Terway는 현재 veth pair 정책 라우팅과 IPVLAN의 두 가지 솔루션을 지원합니다. 그러나 커뮤니티는 cilium v1.12 [ 1] 이후 IPVLAN 지원을 포기했습니다 . ACK 진화는 클라우드 네이티브 기능의 통합을 촉진하고 차별화를 줄이는 커뮤니티와 일치합니다. v1.8.0부터 Terway는 더 이상 IPvlan 터널 가속을 지원하지 않지만 DataPath V2를 사용하여 데이터 평면을 통합합니다.

포드에서 사용하는 CIDR 네트워크 세그먼트는 노드의 CIDR과 동일한 네트워크 세그먼트입니다.

Pod 내부에 네트워크 카드 eth0이 있고, eth0의 IP는 Pod의 IP입니다. 이 네트워크 카드의 MAC 주소는 콘솔에 있는 ENI의 MAC 주소와 일치하지 않습니다. ECS의 네트워크 카드. 이는 ENI 연결된 네트워크 카드가 포드의 네트워크 네임스페이스에 직접 로드되지 않음을 의미합니다.

포드에는 eth0을 가리키는 기본 경로만 있습니다. 이는 포드가 주소 세그먼트에 액세스할 때 eth0이 통합된 입구와 출구임을 의미합니다.

동시에 ECS에는 여러 개의 ethx 네트워크 카드가 있습니다. 이는 ENI 연결된 네트워크 카드가 포드의 네트워크 네임스페이스에 직접 마운트되지 않음을 의미합니다.

OS Linux 라우팅을 통해 포드 IP로 향하는 모든 트래픽이 포드에 해당하는 calixx 가상 카드로 전달된다는 사실을 얻을 수 있습니다. 따라서 ECS OS 및 Pod의 네트워크 네임스페이스는 완전한 인바운드 및 아웃바운드 링크 구성을 설정했습니다.

ENI 다중 IP 구현의 경우 이는 ACK 컨테이너 네트워크 데이터 링크(Terway ENIIP) [ 2] 의 원리와 유사합니다 . Terway Pod는 Daemonset을 통해 각 노드에 배포됩니다. terway-cli 매핑 명령을 사용하여 노드에 연결된 ENI 수, MAC 주소 및 각 ENI의 IP를 가져올 수 있습니다.

Pod가 SVC에 액세스하기 위해 컨테이너는 다양한 방법을 사용하여 Pod가 있는 ECS 계층으로 요청을 전달하고 ECS의 netfilter 모듈은 SVC IP의 확인을 구현합니다. 하지만 데이터 링크는 Pod의 네트워크 네임스페이스에서 ECS의 OS의 네트워크 네임스페이스로 전환되어야 하기 때문에 중간에 커널 프로토콜 스택을 거치게 되기 때문에 이를 위한 메커니즘이 있다면 필연적으로 성능 저하가 발생하게 됩니다. 높은 동시성과 고성능을 추구하지만 고객의 요구를 완전히 충족시키지 못할 수도 있습니다. SVC 주소 변환을 위해 Pod 내부에 eBPF를 배포하는 IPVLAN 모드와 비교할 때 DataPath V2 모드의 eBPF는 각 Pod의 calixxx 네트워크 카드를 수신하여 Pod 및 Pod 액세스를 가속화하고 Pod 액세스 주소를 Pod로 전송합니다. SVC IP. 링크 가속의 경우 Terway 네트워크 플러그인 [ 3] 을 사용하여 모델 비교를 참조할 수 있습니다 .

BPF 라우팅

5.10 커널 이후 Cilium은 eBPF 호스트 라우팅 기능과 두 가지 새로운 리디렉션 방법인 bpf_redirect_peer 및 bpf_redirect_neigh를 추가했습니다.

bpf_redirect_peer

데이터 패킷은 호스트의 lxc 인터페이스를 거치지 않고 veth 쌍 Pod의 인터페이스 eth0으로 직접 전송되므로 데이터 패킷이 CPU 백로그 큐에 들어가는 횟수가 줄어들고 더 나은 전달 성능을 얻을 수 있습니다.
bpf_redirect_neigh

포드 송신 트래픽의 src 및 dst mac 주소를 채우는 데 사용됩니다. 트래픽은 커널의 경로 프로토콜 스택 처리를 거칠 필요가 없습니다.

따라서 전체 Terway DataPath V2 모델은 다음과 같이 요약될 수 있습니다.

현재 낮은 버전의 커널(4.2 미만)은 eBPF 가속을 지원하지 않습니다. Aliyun2는 부분 가속 기능을 얻을 수 있고 Aliyun3은 완전한 가속 기능을 얻을 수 있습니다.
노드는 Pod에 액세스하기 위해 호스트의 프로토콜 스택을 통과해야 합니다. Pod 간 액세스 및 SVC에 대한 Pod 액세스는 호스트의 프로토콜 스택을 통과하지 않습니다.
DataPath V2 모드에서 포드가 SVC IP에 액세스하면 SVC IP는 포드의 veth 쌍 calixxx 네트워크 카드의 eBPF에 의해 SVC 백엔드 포드의 IP로 변환된 다음 데이터 링크가 호스트 프로토콜 스택을 우회합니다. 즉, SVC IP는 소스 포드의 veth 쌍에서만 캡처되지만 대상 포드나 대상 포드가 있는 ECS는 캡처되지 않습니다.

Terway DataPath V2 모드 컨테이너 네트워크 데이터 링크 분석

컨테이너 네트워크의 특성에 따라 Terway datapathv2 모드의 네트워크 링크는 Pod IP를 사용하여 외부 서비스 제공 및 SVC를 사용하여 외부 서비스 제공이라는 두 가지 큰 SOP 시나리오로 크게 나눌 수 있습니다. 이는 11개의 서로 다른 작은 SOP 시나리오로 더 세분화될 수 있습니다. .SOP 시나리오.

이러한 15개 시나리오의 데이터 링크를 결합하고 병합한 후 이러한 시나리오는 다음과 같은 8개의 일반적인 시나리오로 요약될 수 있습니다.

포드 IP에 액세스하고 동일한 노드에서 포드에 액세스합니다.
Pod IP 액세스, 동일한 노드에 있는 Pod 간 상호 액세스(Pod는 동일한 ENI에 속함)
Pod IP 액세스, 동일한 노드에 있는 Pod 간 상호 액세스(Pod는 서로 다른 ENI에 속함)
Pod IP 액세스, 서로 다른 노드 간 Pod 간 상호 액세스
클러스터의 포드가 액세스하는 SVC 클러스터 IP/외부 IP, SVC 백엔드 포드 및 클라이언트 포드는 동일한 ECS 및 ENI에 속합니다.
클러스터의 포드가 액세스하는 SVC 클러스터 IP/외부 IP, SVC 백엔드 포드 및 클라이언트 포드는 동일한 ECS에 속하지만 ENI는 다릅니다.
클러스터의 포드, SVC 백엔드 포드 및 클라이언트 포드에서 액세스하는 SVC 클러스터 IP/외부 IP는 서로 다른 ECS에 속합니다.
클러스터 외부에서 SVC 외부 IP에 액세스

시나리오 1: 포드 IP에 액세스, 동일한 노드에서 포드에 액세스(동일한 노드의 노드 액세스 백엔드 SVC ClusterIP 포함)

환경

nginx2-7ff4679659-xkpmm은 IP 주소가 10.0.0.2인 노드 xxx.10.0.1.219에 존재합니다.

커널 라우팅

nginx2-7ff4679659-xkpmm, IP 주소 10.0.0.2, 호스트에 있는 컨테이너의 PID는 5630이고, 컨테이너 네트워크 네임스페이스에는 컨테이너 eth0을 가리키는 기본 경로가 있습니다.

ECS OS의 컨테이너 eth0에 해당하는 veth 쌍은 cali10e985649a0입니다. ECS OS에는 Pod IP를 가리키는 경로가 있고 다음 홉은 calixxx입니다. 이전 기사에서 calixxx 네트워크 카드가 다음과 같은 쌍임을 알 수 있습니다. 각 포드의 veth1.

다음 명령을 통해 nginx2-7ff4679659-xkpmm을 얻을 수 있습니다. IP 주소 10.0.0.2는 terway에 의해 eth2 액세서리 네트워크 카드에 할당됩니다.

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- terway-cli 매핑

요약

ECS의 eth0은 nginx2-7ff4679659-xkpmm에서 반환된 데이터를 캡처했지만 전송된 데이터는 캡처하지 않았습니다.

ECS의 eth1은 nginx2-7ff4679659-xkpmm에서 반환된 데이터도 캡처했지만 전송된 데이터는 캡처하지 않았습니다.

cali10e985649a0은 전송 및 수신된 패킷을 캡처할 수 있습니다.

후속 요약에는 더 이상 데이터 패킷 관찰이 표시되지 않습니다.

데이터 링크 전달 다이어그램(Aliyun2&Aliyun3):

전체 링크는 ECS와 Pod의 네트워크 프로토콜 스택을 통과합니다.
전체 요청 링크는 ECS OS -> calixxx -> ECS Pod eth0입니다.

시나리오 2: 포드 IP 액세스, 동일한 노드에 있는 포드 간 상호 액세스(포드는 동일한 ENI에 속함)

환경

nginx2-7ff4679659-xkpmm, IP 주소 10.0.0.2 및 centos-5bf8644bcf-jqxpk, IP 주소 10.0.0.13이 xxx.10.0.1.219 노드에 존재합니다.

커널 라우팅

centos-5bf8644bcf-jqxpk, IP 주소 10.0.0.13, 호스트에 있는 컨테이너의 PID는 126938이고, 컨테이너 네트워크 네임스페이스에는 컨테이너 eth0을 가리키는 기본 경로가 있습니다.

ECS OS에서 이 컨테이너 eth0의 해당 veth 쌍은 calia7003b8c36c입니다. ECS OS에는 Pod IP를 가리키는 경로가 있고 다음 홉은 calixxx입니다. 이전 기사에서 calixxx 네트워크 카드가 쌍임을 알 수 있습니다. 각 Pod에 veth1을 사용합니다.

다음 명령을 통해 nginx2-7ff4679659-xkpmm 및 centos-5bf8644bcf-jqxpk가 terway에 의해 동일한 eth2 액세서리 네트워크 카드에 할당되었음을 확인할 수 있습니다.

kubectl --kubeconfig kubeconfig -n kube-system exec -it terway-eniip-v5v2p -c terway -- terway-cli 매핑

요약

알리윤2：

Pod에 할당된 보조 네트워크 카드를 통과하지 않습니다.
전체 링크는 Pod의 네트워크 프로토콜 스택을 통과합니다. 링크가 Pod의 네트워크 네임스페이스를 통해 피어로 전달되면 eBPF에 의해 가속화되고 OS 프로토콜 스택을 우회합니다.
전체 요청 링크는 ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2입니다.

알리윤3：

Pod에 할당된 보조 네트워크 카드를 통과하지 않습니다.
전체 링크는 eBPF 수신을 통해 대상 포드로 직접 가속되며 대상 포드의 calixxx 네트워크 카드를 통과하지 않습니다.
전체 요청 링크는 다음과 같습니다.

방향: ECS Pod1 -> Pod1 calixxx -> ECS Pod2.
반환 방향: ECS Pod2 -> Pod2 calixxx -> ECS Pod1.

시나리오 3: 포드 IP 액세스, 동일한 노드에 있는 포드 간 상호 액세스(포드는 서로 다른 ENI에 속함)

환경

xxx.10.0.1.219 노드에는 IP 주소가 각각 10.0.0.251 및 10.0.0.13인 ngxin3-55f5c67988-p4qnb 및 centos-5bf8644bcf-jqxpk라는 두 개의 포드가 있습니다.

이 노드의 terway 포드의 경우 terway-cli 매핑 명령을 사용하여 두 IP(10.0.0.251 및 10.0.0.13)가 서로 다른 ENI 네트워크 카드에 속하고 OS 수준에서 eth1 및 eth2로 간주되는지 확인합니다.

커널 라우팅

ngxin3-55f5c67988-p4qnb, IP 주소 10.0.0.251, 호스트에 있는 컨테이너의 PID는 5630이고, 컨테이너 네트워크 네임스페이스에는 컨테이너 eth0을 가리키는 기본 경로가 있습니다.

ECS OS에서 이 컨테이너 eth0의 해당 veth 쌍은 cali08203025d22입니다. ECS OS에는 Pod IP를 가리키는 경로가 있고 다음 홉은 calixxx입니다. 이전 기사에서 calixxx 네트워크 카드가 쌍임을 알 수 있습니다. 각 Pod에 veth1을 사용합니다.

요약

알리윤2：

Pod에 할당된 보조 네트워크 카드를 통과하지 않습니다.
전체 링크는 Pod의 네트워크 프로토콜 스택을 통과합니다. 링크가 Pod의 네트워크 네임스페이스를 통해 피어로 전달되면 eBPF에 의해 가속화되고 OS 프로토콜 스택을 우회합니다.
전체 요청 링크는 ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2입니다.

알리윤3：

Pod에 할당된 보조 네트워크 카드를 통과하지 않습니다.
전체 링크는 eBPF 수신을 통해 대상 포드로 직접 가속되며 대상 포드의 calixxx 네트워크 카드를 통과하지 않습니다.
전체 요청 링크는 다음과 같습니다:
- 방향: ECS Pod1 -> Pod1 calixxx -> ECS Pod2.
- 반환 방향: ECS Pod2 -> Pod2 calixxx -> ECS Pod1.

시나리오 4: 포드 IP 액세스, 서로 다른 노드 간 포드 간 상호 액세스

환경

centos-5bf8644bcf-jqxpk는 xxx.10.0.1.219 노드에 존재하며 IP 주소는 10.0.0.13입니다.

nginx1-7bcf4ffdb4-6rsqz는 xxx.10.0.5.27 노드에 존재하며 IP 주소는 10.0.4.121입니다.

terway-cli show Factory 명령을 사용하여 IP 10.0.0.13이 centos-5bf8644bcf-jqxpk에 속하고 MAC 주소가 xxx.10.0.1.219에서 00:16:3e:0d:74:23인 ENI 네트워크 카드를 얻을 수 있습니다. .

마찬가지로 nginx1-7bcf4ffdb4-6rsqz의 IP 10.0.4.121은 xxx.10.0.5.27에서 MAC 주소 00:16:3e:0c:ef:6c를 사용하는 ENI 네트워크 카드에 속합니다.

커널 라우팅

nginx1-7bcf4ffdb4-6rsqz, IP 주소 10.0.4.121, 호스트에 있는 컨테이너의 PID는 7745이고, 컨테이너 네트워크 네임스페이스에는 컨테이너 eth0을 가리키는 기본 경로가 있습니다.

ECS OS에서 이 컨테이너 eth0의 해당 veth 쌍은 cali06cd16bb25f입니다. ECS OS에는 Pod IP를 가리키는 경로가 있고 다음 홉은 calixxx입니다. 이전 기사에서 calixxx 네트워크 카드가 쌍임을 알 수 있습니다. 각 Pod에 veth1을 사용합니다.

요약

알리윤2：

호스트 OS의 네트워크 네임스페이스를 통과하지만 프로토콜 스택 링크는 eBPF에 의해 가속화됩니다.
전체 링크는 클라이언트 포드가 속한 ENI 네트워크 카드의 ECS에서 나가고 대상 포드가 속한 ENI 네트워크 카드에서 ECS로 들어가야 합니다.
전체 요청 링크는 ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2 calixxx -> ECS2 Pod2입니다.

알리윤3：

전체 링크는 클라이언트 포드가 속한 ENI 네트워크 카드에서 시작한 다음 ECS를 통과하고 대상 포드가 속한 ENI 네트워크 카드에서 ECS로 들어가야 합니다.
전체 요청 링크는 다음과 같습니다:
- 방향: ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2.
- 회전 방향: ECS2 Pod2 -> ECS2 Pod2 calixxx -> ECS2 ENI ethx -> VPC -> ECS1 ENI ethx -> ECS1 Pod1.

시나리오 5: 클러스터의 포드에서 액세스하는 SVC 클러스터 IP/외부 IP, SVC 백엔드 포드 및 클라이언트 포드는 동일한 ECS 및 동일한 ENI에 속합니다.

환경

nginx2-7ff4679659-xkpmm, IP 주소 10.0.0.2 및 centos-5bf8644bcf-jqxpk, IP 주소 10.0.0.13이 xxx.10.0.1.219 노드에 존재합니다.

그 중 nginx2-7ff4679659-xkpmm Pod는 SVC nginx2의 엔드포인트입니다.

커널 라우팅

커널 라우팅은 시나리오 2와 유사하므로 여기서는 설명하지 않습니다.

eBPF와 관련하여 datapathv2에서 eBPF는 Pod 내부가 아닌 OS 수준에서 calixxx 네트워크 카드를 수신합니다. cilium의 eBPF 호출 기능을 사용하면 그래픽 명령을 통해 centos-5bf8644bcf-jqxpk 및 nginx2-7ff4679659-xkpmm ID ID를 각각 693 및 2702로 얻을 수 있습니다.

Pod가 terway-eniip-v5v2p로 위치한 ECS의 Terway Pod를 찾습니다. Terway Pod에서 cilium bpf lb list | grep -A5 192.168.152.119 명령을 실행하여 클러스터 IP 192.168.152.119에 대해 eBPF에 기록된 백엔드를 가져옵니다. :80은 10.0 .0.2:80입니다.

요약

클라이언트 포드 centos-5bf8644bcf-jqxpk에서 SVC에 액세스합니다.

클라이언트의 centos-6c48766848-znkl8 calia7003b8c36c 네트워크 카드 관찰을 통해 SVC IP 및 클라이언트의 Pod IP를 캡처할 수 있습니다.

Pod centos-6c48766848-znkl8이 속한 연결된 네트워크 카드의 ENI에서 관찰된 바에 따르면 관련 트래픽 패킷이 캡처되지 않았습니다. 이는 트래픽이 클라이언트의 calixx 네트워크 카드에서 ENI로 eBPF 변환되었음을 나타냅니다.

Pod nginx2-7ff4679659-xkpmmI의 cali10e985649a0 관찰에서는 centos 및 nginx의 Pod IP만 캡처할 수 있습니다.

Cilium은 모니터 기능을 제공합니다. cilium monitor --관련-to <endpoint ID>를 사용하면 소스 Pod IP가 SVC IP 192.168.152.119에 액세스한 다음 SVC 백엔드 Pod IP 10.0.0.2로 확인됩니다. SVC IP는 tc 계층에서 직접 전달됩니다.

알리윤2：

전체 링크는 Pod의 네트워크 프로토콜 스택을 통과합니다. 링크가 Pod의 네트워크 네임스페이스를 통해 피어로 전달되면 eBPF에 의해 가속화되고 OS 프로토콜 스택을 우회합니다.
전체 링크 요청은 포드에서 할당한 ENI를 통과하지 않습니다.
SVC IP는 클라이언트 포드의 calixxx 네트워크 카드에서 eBPF를 통해 SVC 백엔드 포드의 IP로 변환되며, 후속 노드는 SVC IP를 캡처할 수 없습니다.
전체 요청 링크는 ECS Pod1 -> Pod1 calixxx -> Pod2 calixxx -> ECS Pod2입니다.

알리윤3：

전체 링크는 Pod의 네트워크 프로토콜 스택을 통과합니다. 링크가 Pod의 네트워크 네임스페이스를 통해 피어로 전달되면 eBPF에 의해 가속화되고 OS 프로토콜 스택을 우회합니다.
전체 링크 요청은 포드에서 할당한 ENI를 통과하지 않습니다.
SVC IP는 클라이언트 포드의 calixxx 네트워크 카드에서 eBPF를 통해 SVC 백엔드 포드의 IP로 변환되며, 후속 노드는 SVC IP를 캡처할 수 없습니다.
전체 링크는 eBPF 수신을 통해 대상 포드로 직접 가속되며 대상 포드의 calixxx 네트워크 카드를 통과하지 않습니다.
전체 요청 링크는 다음과 같습니다.
- 방향: ECS Pod1 -> Pod1 calixxx -> ECS Pod2.
- 반환 방향: ECS Pod2 -> Pod2 calixxx -> ECS Pod1.

시나리오 6: 클러스터의 포드에서 액세스하는 SVC 클러스터 IP/외부 IP, SVC 백엔드 포드 및 클라이언트 포드는 동일한 ECS에 속하지만 ENI는 다릅니다.

환경

xxx.10.0.1.219 노드에는 ngxin3-55f5c67988-p4qnb, IP 주소 10.0.0.251 및 centos-5bf8644bcf-jqxpk, IP 주소 10.0.0.13이 있습니다.

그 중 ngxin3-55f5c67988-p4qnb Pod는 SVC nginx3의 엔드포인트입니다.

커널 라우팅

커널 라우팅은 시나리오 3과 유사하므로 여기서는 설명하지 않습니다.

eBPF와 관련하여 datapathv2에서 eBPF는 Pod 내부가 아닌 OS 수준에서 calixxx 네트워크 카드를 수신합니다. cilium의 eBPF 호출 기능을 사용하면 그래픽 명령을 통해 centos-5bf8644bcf-jqxpk 및 ngxin3-55f5c67988-p4qnb ID ID를 각각 693 및 94로 얻을 수 있습니다.

Pod가 terway-eniip-v5v2p로 위치한 ECS의 Terway Pod를 찾습니다. Terway Pod에서 cilium bpf lb list | grep -A5 192.168.239.183 명령을 실행하면 클러스터 IP에 대해 eBPF에 기록된 백엔드를 확인할 수 있습니다. 192.168.239.183:80은 10.0입니다.

요약

클라이언트 포드 centos-5bf8644bcf-jqxpk에서 SVC에 액세스합니다.

클라이언트의 centos-6c48766848-znkl8 calia7003b8c36c 네트워크 카드 관찰을 통해 SVC IP 및 클라이언트의 Pod IP를 캡처할 수 있습니다.

Pod centos-6c48766848-znkl8의 연결된 네트워크 카드 ENI와 ngxin3-55f5c67988-p4qnb의 연결된 네트워크 카드 ENI에서 관찰된 바에 따르면 관련 트래픽이 캡처되지 않았으며 이는 트래픽이 클라이언트의 calixx 네트워크 카드에서 SVC 관련 트래픽으로 변환되었음을 나타냅니다. by eBPF 엔드포인트 이후 대상 calixxx 네트워크 카드로 직접 단락됩니다.

Pod ngxin3-55f5c67988-p4qnb가 속한 cali08203025d22를 관찰하면 centos 및 nginx의 Pod IP만 캡처할 수 있습니다.

Cilium은 모니터 기능을 제공합니다. cilium monitor --관련-to <endpoint ID>를 사용하면 소스 Pod IP가 SVC IP 192.168.239.183에 액세스한 다음 SVC 백엔드 Pod IP 110.0.0.251로 확인됩니다. SVC IP는 tc 계층에서 직접 전달됩니다.

후속 섹션에 SVC IP 액세스가 포함되는 경우 유사성이 있으면 자세한 설명은 제공되지 않습니다.

알리윤2：

호스트 OS의 네트워크 네임스페이스를 통과하지만 프로토콜 스택 링크는 eBPF에 의해 가속화됩니다.
전체 링크 요청은 포드에서 할당한 ENI를 통과하지 않습니다.
SVC IP는 클라이언트 포드의 calixxx 네트워크 카드에서 eBPF를 통해 SVC 백엔드 포드의 IP로 변환되며, 후속 노드는 SVC IP를 캡처할 수 없습니다.
전체 요청 링크는 ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS2 Pod2 calixxx -> ECS2 Pod2입니다.

알리윤3：

Pod에 할당된 보조 네트워크 카드를 통과하지 않습니다.
전체 링크는 eBPF 수신을 통해 대상 포드로 직접 가속되며 대상 포드의 calixxx 네트워크 카드를 통과하지 않습니다.
SVC IP는 클라이언트 포드의 calixxx 네트워크 카드에서 eBPF를 통해 SVC 백엔드 포드의 IP로 변환되며, 후속 노드는 SVC IP를 캡처할 수 없습니다.
전체 요청 링크는 다음과 같습니다.

방향: ECS Pod1 -> Pod1 calixxx -> ECS Pod2.
반환 방향: ECS Pod2 -> Pod2 calixxx -> ECS Pod1.

시나리오 7: 클러스터의 포드에서 액세스하는 SVC 클러스터 IP/외부 IP, SVC 백엔드 포드 및 클라이언트 포드는 서로 다른 ECS에 속합니다.

환경

centos-5bf8644bcf-jqxpk는 xxx.10.0.1.219 노드에 존재하며 IP 주소는 10.0.0.13입니다.

nginx1-7bcf4ffdb4-6rsqz는 xxx.10.0.5.27 노드에 존재하며 IP 주소는 10.0.4.121입니다.

그 중 nginx1-7bcf4ffdb4-6rsqz Pod는 SVC nginx1의 엔드포인트입니다.

커널 라우팅

Pod는 SVC의 클러스터 IP에 액세스 하고 SVC의 백엔드 Pod와 클라이언트 Pod는 서로 다른 ECS에 배포됩니다. 이 아키텍처는 이 시나리오가 SVC의 클러스터 IP라는 점을 제외하면 시나리오 4: 서로 다른 노드 간 Pod 간 상호 액세스와 유사 합니다 . . 클러스터 IP의 eBPF 전달에 대한 자세한 내용은 시나리오 5 및 시나리오 6을 참조하세요.

요약

알리윤2：

호스트 OS의 네트워크 네임스페이스를 통과하지만 프로토콜 스택 링크는 eBPF에 의해 가속화됩니다.
전체 링크는 클라이언트 포드가 속한 ENI 네트워크 카드의 ECS에서 나가고 대상 포드가 속한 ENI 네트워크 카드에서 ECS로 들어가야 합니다.
전체 요청 링크는 ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2 calixxx -> ECS2 Pod2입니다.

알리윤3：

전체 링크는 클라이언트 포드가 속한 ENI 네트워크 카드에서 시작한 다음 ECS를 통과하고 대상 포드가 속한 ENI 네트워크 카드에서 ECS로 들어가야 합니다.
전체 요청 링크는 다음과 같습니다.
- 방향: ECS1 Pod1 -> ECS1 Pod1 calixxx -> ECS1 ENI ethx -> VPC -> ECS2 ENI ethx -> ECS2 Pod2.
- 회전 방향: ECS2 Pod2 -> ECS2 Pod2 calixxx -> ECS2 ENI ethx -> VPC -> ECS1 ENI ethx -> ECS1 Pod1.

시나리오 8: 클러스터 외부에서 SVC 외부 IP에 액세스

환경

nginx1-7bcf4ffdb4-6rsqz는 xxx.10.0.5.27 노드에 존재하며 IP 주소는 10.0.4.121입니다.

SVC를 설명하면 SVC nginx의 백엔드에 nginx Pod가 추가되었음을 알 수 있습니다. SVC의 클러스터 IP는 192.168.190.78입니다.

커널 라우팅

SLB 콘솔에서는 두 백엔드 nginx Pod의 ENI eni-j6cgs979ky3evxxx인 lb-3nsj50u4gyz623nitxxx 가상 서버 그룹의 백엔드 서버 그룹을 가져올 수 있습니다.

클러스터 외부에서 보면 SLB의 백엔드 가상 서버 그룹은 SVC의 백엔드 Pod가 속한 ENI 네트워크 카드이고, 인트라넷의 IP 주소는 Pod의 주소입니다.

요약

알리윤2：

외부 트래픽 정책(ExternalTrafficPolicy)이 로컬 또는 클러스터 모드인 경우 SLB는 포드에서 할당한 ENI만 SLB 가상 서버 그룹에 마운트합니다.
데이터 링크는 포드 Veth의 calixxx 네트워크 카드를 통과합니다.
데이터 링크: 클라이언트 -> SLB -> Pod ENI + Pod 포트 -> ECS1 Pod1 calixxx -> ECS1 Pod1 eth0.

알리윤3：

외부 트래픽 정책(ExternalTrafficPolicy)이 로컬 또는 클러스터 모드인 경우 SLB는 포드에서 할당한 ENI만 SLB 가상 서버 그룹에 마운트합니다.
데이터 링크는 ECS에 연결된 네트워크 카드의 eBPF에 의해 가속화되어 포드 Veth의 calixxx 네트워크 카드를 우회하고 포드의 네트워크 네임스페이스에 직접 들어갑니다.
데이터 링크: 클라이언트 -> SLB -> Pod ENI + Pod 포트 -> ECS1 Pod1 eth0.

관련된 링크들:

[1] 더 이상 사용되지 않는 IPVLAN 지원

https://docs.cilium.io/en/v1.12/Operations/upgrade/#deprecated-options

[2] ACK 컨테이너 네트워크 데이터 링크(Terway ENIIP)

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/ack-network-fabric-terway-eniip

[3] Terway 네트워크 플러그인 사용하기

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/work-with-terway

[4] 서로 다른 노드 간 Pod 간 상호 액세스 https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/ack-network-fabric-terway-eni-trunking # RS9Nc