clusterIP가 없을 때 POD끼리의 통신가능 여부

Question

[질문 하기] 안녕하세요 4.6 강의를 듣다가 궁금증이 생겨 질문드려요 CluterIP는 내부에서 POD끼리 통신을 위해 존재하는 서비스라고 이해를 했습니다. 그렇다면 ClusterIP가 없다면 POD끼리 통신이 불가능하지 않을까 생각이 들어 아래와 같은 yaml파일을 배포해봤습니다 apiVersion: apps/v1 kind: Deployment metadata: name: deploy-nginx labels: app: deploy-nginx spec: replicas: 3 selector: matchLabels: app: deploy-nginx template: metadata: labels: app: deploy-nginx spec: containers: - name: chkip image: sysnet4admin/net-tools-ifn #--- #apiVersion: v1 #kind: Service #metadata: # name: cl-nginx #spec: # selector: # app: deploy-nginx # ports: # - name: http # port: 80 # targetPort: 80 # type: ClusterIP 처음에는 아래에 있는 주석을 풀어 ClusterIP를 생성하고 각 POD에 접속하여 pod끼리 ping을 날렸을 때는 당연히 ClusterIP 덕분에 통신이 된다고 생각했습니다 그리고, 주석을 추가해 ClusterIP없이 배포를 했습니다 [root@m-k8s 4.6]# k get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES deploy-nginx-bc5885484-snsgf 1/1 Running 0 33s 172.16.221.160 w1-k8s deploy-nginx-bc5885484-tqcp2 1/1 Running 0 33s 172.16.132.51 w3-k8s deploy-nginx-bc5885484-x269c 1/1 Running 0 33s 172.16.103.178 w2-k8s net 1/1 Running 0 76m 172.16.132.43 w3-k8s [root@m-k8s 4.6]# k get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 10d 그런데 생각과는 달리 ClusterIP가 없어도 pod끼리 통신이 가능하더라고요 [root@m-k8s 4.6]# k exec deploy-nginx-bc5885484-snsgf -it -- /bin/bash [root@deploy-nginx-bc5885484-snsgf /]# ping 172.16.132.51 PING 172.16.132.51 (172.16.132.51): 56 data bytes 64 bytes from 172.16.132.51: seq=0 ttl=62 time=0.806 ms 64 bytes from 172.16.132.51: seq=1 ttl=62 time=0.497 ms ClusterIP가 없어도 통신이 가능한 이유가 어떻게 될까요??

조훈(Hoon Jo) · Answer

안녕하세요 현재 구성 환경은 (한 개의 호스트에 가상으로 구성하기 위해서) 노드 간에 IP 및 서로 터널링(calico - tunneling)으로 통신이 모두 가능하도록 구성되어 있습니다. 따라서 현재의 환경에서는 파드 간의 통신이 터널링 구간을 통해서 가능합니다. 그전에 NAT (eth0)를 통해서 넘어갑니다. 해당 내용은 traceroute 로 다음과 같이 확인하실 수 있습니다. [ 온프레미스 / 현재 환경 ] root@cp-k8s:~# k get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES net-775d7d6b6-cxh5h 1/1 Running 0 46s 172.16.132.41 w3-k8s net-775d7d6b6-rh568 1/1 Running 0 53s 172.16.221.163 w1-k8s net-775d7d6b6-xlftb 1/1 Running 0 46s 172.16.103.163 w2-k8s [root@net-775d7d6b6-cxh5h /]# traceroute 172.16.221.163 1 10.0.2.15 (10.0.2.15) 0.012 ms 0.014 ms 0.007 ms 2 172.16.221.128 (172.16.221.128) 1.133 ms 0.508 ms 0.628 ms 3 172.16.221.163 (172.16.221.163) 1.285 ms 1.401 ms 27.686 ms 이는 클라우드 (공급사에 따라 다름)에서도 마찬가지입니다. 크게 보면 내부 IDC 이기 때문에 통신 가능하다면 응답 받을 수 있습니다. 아마 왜 clusterIP를 사용하는지는 헤드리스 서비스(도메인으로만 통신)와 연관 지으면 좀 더 이해가 되실 것 같습니다. IP 로(계속 변화하는 값) 통신하고 설정되는 것은 애플리케이션에서 사용하기 어렵습니다. 또한 엔드포인트까지 보신다면 단일 파드 접근은 큰의미 없다는 것을 알게 되실 것 같습니다. [ 클라우드 환경 / GKE ] [(☸️ |hj-gke:default)]$ k get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES net-775d7d6b6-58khn 1/1 Running 0 69s 10.116.2.19 gke-keycloak-default-pool-05b3d298-mpdt net-775d7d6b6-rqjnv 1/1 Running 0 69s 10.116.1.9 gke-keycloak-default-pool-05b3d298-855c net-775d7d6b6-vqdxv 1/1 Running 0 69s 10.116.0.7 gke-keycloak-default-pool-05b3d298-9p4p [root@net-775d7d6b6-58khn /]# traceroute 10.116.1.9 traceroute to 10.116.1.9 (10.116.1.9), 30 hops max, 46 byte packets 1 10.116.2.1 (10.116.2.1) 0.010 ms 0.008 ms 0.004 ms 2 gke.prjname.internal (10.128.0.37) 1.331 ms 0.228 ms 0.402 ms 3 10.116.1.9 (10.116.1.9) 0.836 ms 0.316 ms 0.230 ms