쿠버네티스 네트워킹 헷갈리는 사항
1. 같은 노드의 서로 다른 파드
1-1. 클러스터IP로 통신하는 경우
송신 파드A 내의 프로세스가 특정 서비스(B)와 통신을 시도함 -> vethA1(파드 네임스페이스와 연결) -> vethA2(호스트 네임스페이스와 연결) -> kube-proxy (ClusterIP로 가는 흐름 인터셉트)가 파드 DNAT -> 호스트 브릿지 인터페이스 -> 브릿지 인터페이스에 추가된 상대 파드쪽 vethB2 -> vethB1
*참고사항
- 리눅스에서 브리지 인터페이스(cni0, br0 등)는 물리적인 네트워크 스위치와 유사하게 동작합니다.
- 스위치는 여러 개의 포트를 가지고 있으며, 각 포트에 연결된 장치들의 MAC 주소를 학습하여 효율적으로 트래픽을 전달합니다. 브릿지 인터페이스는 네트워크 인터페이스를 브리지의 포트로 추가합니다.
- 브리지 인터페이스에 네트워크 인터페이스(물리적 또는 가상)를 "포트로 추가"한다는 것은 해당 인터페이스를 브리지의 멤버로 만드는 것을 의미합니다.
- 이렇게 되면 브리지는 해당 인터페이스를 통해 들어오고 나가는 모든 네트워크 트래픽을 감시하고 처리할 수 있게 됩니다.
1-2. 다른 파드의 IP를 알고있는 경우
2. 다른 노드에 놓여진 각각의 파드
-> 2-1. 다른 노드에 있는 파드의 IP를 알고있는 경우
해당 경우는 CNI가 만들어놓은 경로를 통해 직접통신.
이때 DNS, kube-proxy 작동X
-> 이 전체 경로를 CNI가 자동으로 설정합니다 그럼 CNI는 노드간 네트워크 경로를 만들어주기만 하는거고, POD-POD가 IP통신을 한다고할때 통로를 타고 TCP/IP통신을 시작
-> 같은 클러스터의 다른 노드에 있는 파드로 가려면 다른 노드로 가야하는데, 노드-노드간 라우팅 정보는 CNI가 업데이트해준다
-> 2-2. 다른 노드에 있는 파드의 IP를 모르는 경우
다른 노드에 있는 클러스터IP로 통신
왜 클러스터IP로 하는가?
A 역할을 하는 파드들은 A라는 서비스(클러스터IP) 아래에 다 있고, B라는 역할을 하는 파드들은 B라는 서비스(클러스터IP)아래에 존재하고, 파드는 없어졌다가도 생길 수 있음. A의 파드는 B파드랑 직접 하는것보다 B의 서비스를 바라보게해놓으면 그 서비스가 아래의 파드로 알아서 이어줄 수 있음.
서비스는 spec.selector.[키:값] // Deployment는 spec.template.metadata.label.[키:값] 이 두개가 매칭되는것.
서비스는 같은 주황값 가진 파드로 트래픽을 보냄.
->다른 서비스IP를 어떻게 알수있는가? 이때 DNS개념이 등장
혼동금지
1. ClusterIP라는것이 '서비스'라는 용어를 사용하고있음. 앱도 서비스고 DB도 서비스고 클러스터IP도 서비스...
2. ClusterIP라는것은 하나의 단일한 진입점 역할을 한다는것은, 단일한 진입점 역할을 한다고해서 단일하게 존재하는게 아님. 클러스터IP는 여러개가 존재 가능함.