[k8s] 서비스를 통한 트래픽 전달 과정

서비스는 여러 파드들에 트래픽을 로드밸런싱해주는 역할을 한다. 부족하지만 이 과정에 대해 이해한 것들을 정리해 보려 한다

서비스의 IP,Port로 보낸 트래픽이 Pod의 Ip,Port 로 로드밸런싱 되는 상세 과정

k8s에서 서비스를 생성하고 pod를 매핑시키게 되면 서비스의 IP,Port가 생성된다. 이렇게 생성된 서비스의 IP와 Port로 향하는 트래픽은 패킷이 노드를 떠날때 노드마다 설치된 kube-proxy 에 의해서 매핑된 파드중 하나의 IP,Port로 랜덤하게 전달된다. 정확하게는 패킷이 노드를 떠날때 커널에서 kube-proxy에 의해 설정된 iptables 규칙을 참고하여 도착지의 Ip,Port 가 서비스의 Ip,Port쌍중에 하나인지를 확인한 후, 맞다면 그에 매핑된 파드의 Ip,Port 쌍으로 교체하는 작업이 실행된다. 파드가 보통 여러개 매핑되어 있을 것인데, 이 파드의 Ip중에 하나가 랜덤으로 선택된다. 따라서 수치적으로 로드밸런싱이 맞지만 그것이 라운드로빈 방식과는 차이가 있다.

서비스 Dns Lookup 과정

파드 내부의 어플리케이션에서 서비스를 FQDN으로 참조하여 트래픽을 전송할때 발생하는 과정에 대해서도 정리를 해보면, 아래와 같다.

1. FQDN으로 서비스 주소를 작성하였다면 이것은 Ip로 기술된 것은 아니기 때문에 내부적으로 설정된 DNS Lookup을 통해 Ip로 변환되는 과정을 거친다.
2. UNIX 시스템에서 DNS Lookup과정에 앞서 /etc/resolve.conf 참고해 도메인 네임서버의 IP와 기본 Suffix를 참고하게 되는데, 아래와 같이 설정되어 있다.

   search jenkins.svc.cluster.local svc.cluster.local cluster.local ap-northeast-2.compute.internal
   nameserver 10.100.0.10

   여기서 nameserver로 적혀있는 IP는 k8s 클러스터 내에 설정된 dns서버의 service ip이다.
   search 이후에 적혀있는 목록들은 DNS 조회시 사용할 기본 도메인 접미사 목록 이다. 가장먼저 jenkins.svc.cluster.local 이 적혀 있는데, 맨앞의 jenkins는 namespace를 의미한다. 위 설정이 jenkins라는 namespace안의 container에서 가져온 것 인데, 해당 컨테이너 안에서 동일한 네임스페이스의 서비스명만 적어서 트래픽을 전송하더라도, 위 suffix가 붙어서 DNS lookup이 이루어지므로 결과적으로 조회에 문제가 없게되는 편리함이 있다.

외부 트래픽이 서비스를 통해 Pod에 로드밸런싱 되는 과정

서비스의 여러 모드 중 NodePort라는 모드에 해당하는 방식으로 예를 들어본다. 여기서도 서비스의 Ip,Port 쌍이 kube-proxy 의 iptables 규칙을 통해 매핑된 파드의 Ip,Port 쌍으로 변경되는 과정으로 인해 Pod로 트래픽이 전달되는것은 마찬가지이다. 하지만 이 과정을 거치기 위해 Node의 특정 Port를 생성하여, 해당 포트로 들어오는 트래픽을 특정서비스로 매핑시키는 처리를 통해 외부 트래픽이 서비스의 로드밸런싱 로직을 타게 된다.

참고

kubernetes in action(도서)