223. Service Networking

쿠버에서 Pod이 다른 Pod와 자유롭게 통신할 수 있도록 되어 있다고 해도, 이걸 직접 통신하는 데 사용하는 일은 잘 없다
보통은 Service를 사용하는 게 일반적

예를 들어 같은 노드에 있는 Pod A (10.244.1.2)와 Pod B(10.244.1.3)이 있다고 하자
Pod A에서 Pod B에 접속할 때, 10.244.1.3으로 그냥 IP 입력해서 접속하는 것도 가능은 하다.

• 하지만 보통은, B 접속용 서비스를 생성하고 그 서비스의 이름이나 IP로 접속을 한다
  • 서비스는, Pod이 어떤 노드에 있던간에, 클러스터의 모든 노드에서 접속이 가능하다

• (ClusterIP): 클러스터 내부에서만 접속이 가능하다

  • 클러스터 내부에서만 접속 가능하면 되는 시나리오 (DB 서버라든가)에 적합

• (NodePort): ClusterIP의 기능을 모두 하는 동시에, 모든 노드의 포트를 열고 앱을 연결해줌

  • 그러니까, 어떤 노드로든 NordPort에서 연 포트로 inbound 패킷이 들어오면, NodePort에 연결된 Pod로 리다이렉트됨

어떻게 작동하는가

모든 쿠버 노드에서는 Kubelet이 돌아간다
Kubelet은 kube-apiserver를 통해 노드에 대한 변경사항을 감지하고, 새로운 Pod이 생성되어야 할 때 Pod 생성을 진행한다.

• Pod를 생성하였으면, 해당 Pod에 대한 네트워크를 구성하기 위해 CNI 플러그인을 인보크한다

또, 모든 쿠버 노드에서는 kube-proxy가 돌아간다
kube-proxy는 kube-apiserver를 통해 클러스터의 변경사항을 감지하고, 새로운 서비스가 생성되어야 할 때 서비스 생성을 진행한다.

• Pod랑은 달리 서비스는 각 노드"에" 생성되거나, 노드"에" 할당되는 것이 아니다
  • 서비스는 클러스터 단위로 돌아감 - 클러스터의 모든 노드에 공존함
    • (사실 "존재"하는 것조차 아님, 해당 서비스에 대해 listen을 하는 서버, 프로세스, 네임스페이스 따위는 존재하지 않음!)
      • 예를 들어 서비스가 iptables을 사용한다고 가정하면, 그냥 모든 노드에 있는 kube-proxy가 똑같은 iptables DNAT rule을 추가하는 것뿐임

쿠버에서 서비스 오브젝트를 생성할 때, 기 지정된 범위의 IP 주소가 할당됨

• 각 노드에서 구동되는 kube-proxy가 해당 IP 주소를 받아, 클러스터의 각 노드에 forwarding rule을 생성
  • "이 IP:port 구성으로 들어오는 inbound 트래픽은 전부 이 Pod의 IP로 갈 것"
    • 이것을 구현하기 위해 방법이 여러 가지 있다
      • userspace
      • iptables (기본값)
      • ipvs

예시

node-1에 db Pod (IP: 10.244.1.2)이 있다고 하자.
이것을 위해 db-service ClusterIP Service를 생성하였으며, 서비스에 대한 IP는 10.103.132.104가 할당되었다.

• kube-apiserver의 파라미터 service-cluster-ip-range 에서 변경가능

주의사항: Service의 IP Range와 Pod의 IP Range가 겹쳐서는 안됨

iptables -L -t nat | grep db-service를 하면, kube-proxy가 만든 rule들을 db-service라는 주석과 함께 확인할 수 있다

• tcp anywhere 10.103.132.104 tcp dpt:3306 은, IP 10.103.132.104:3306 (서비스의 IP)으로 가는 모든 트래픽을 매칭
• DNAT tcp -- anywhere anywhere tcp to:10.244.1.2:3306은, 위에서 매칭된 트래픽을 전부 10.244.1.2:3306으로 보내버림

/var/log/kube-proxy.log 로그에서, 서비스 추가에 따라 iptables 엔트리를 추가하는 것을 볼 수 있다.

• 경로는 환경에 따라 다를 수 있음 / 로그 레벨 설정에 따라 안나올 수도 있음