4월 26일 쿠버네티스 온라인 세미나 Q&A _ (2) Network, Service
‘네이버 클라우드 플랫폼의 개발자들은 컨테이너를 어떻게 사용할까?’
지난 4월 26일 진행하였던 쿠버네티스 웨비나에서 많은 분들이 궁금해하신 질문들과 그에 대한 답변입니다. 컨테이너와 도커, 쿠버네티스 활용에 도움이 되셨으면 합니다.
□ Network
Q1.
Pod으로만 네트워크를 구성했을 때의 pod끼리는 어떻게 통신을 하나요?
A1.
Kubernetes Service는 현재 flannel CNI를 사용 중이라서 이 CNI로 설명드리겠습니다.
Pod끼리 통신은 2가지로 구분할 수 있습니다. 동일 Worker Node의 Pod 통신인지 다른 Worker Node의 Pod 통신인지
- 동일 Worker Node인 경우: docker0 interface 내에서 통신
- 다른 Worker Node인 경우: A Worker Node의 flanneld 프로세스에서 목적지 OuterIP와 InnerIP정보를 패킷에 담아서 B 워커 노드로 보내고 B의 flanneld에서 InnerIP를 통해 Target Pod로 통신
참고: https://docker-k8s-lab.readthedocs.io/en/latest/docker/docker-flannel.html
Q2.
k8s의 네트워크 플러그인 종류가 굉장히 많은데 (flannel 등등) 그중에 대표적으로 많이 쓰는 것과 어떤 차이가 있을까요? 관리하는 네트워크 환경에 따라 어떤 걸 선택해야 좋은 선택일지 궁금합니다.
A2.
Kubernetes Service는 각 CNI에 대한 내부 성능 테스트를 진행했습니다. 그중 flannel의 성능 및 호환성이 Kubernetes Service와 잘 맞아서 현재 이 CNI로 서비스를 제공하고 있습니다.
네트워크 환경에 따른 CNI 선택은 아래 링크를 참고해주세요.
Q3.
네이버 클라우드 플랫폼 Kubernetes Service에서는 외부로 서비스를 노출 시 도메인 말고 TCP/UDP port 노출도 가능할까요?
A3.
도메인 외에 TCP/UDP Port를 노출하려면 Worker Node에 직접 Public IP를 부여 후 해당 서버에 NodePort로 Service를 구동하면 됩니다.
Q4.
k8s 에서 사용 가능한 nw plugin으로 flannel calico weave를 표현하였는데 이를 선택적으로 사용 가능하다는 얘기인가요? 어떤 경우 어떤 plugin을 사용해야 하는지 알 수 있을까요?
A4.
Kubernetes Service는 flannel만 지원하고 있습니다.
네트워크 환경에 따른 CNI 선택은 아래 링크를 참고해주세요.
□ Service
Q1.
네이버 클라우드 플랫폼에 올라가는 서비스들이 무수히 많을 것 같은데요. 쿠버네티스에서 service를 생성하여 pod로 들어오는 Traffic을 처리한다고 알고 있습니다. service를 생성할 때 제약(iptables 정책 개수로 인한 성능 저하)이 있을 것 같은데요. 관련된 부분을 네이버 클라우드 플랫폼에서는 어떻게 지원을 하고 있나요? Kubernetes Service를 사용할 때 생성 가능한 서비스의 제약이 있나요?
A1.
클러스터에서 이용하시는 서비스에 대한 제약은 없습니다.
다만 서비스 개수가 많은 경우 ubuntu 커널 버전에 따라 iptable 성능 저하가 발생할 수 있는데요.
Kubernetes Service는 해당 이슈가 있는 커널 버전에 대해 테스트 중이며, 문제가 있는 경우 최적화된 커널 버전으로 업데이트하는 것을 준비 중입니다.
Ubuntu Iptables Service 테스트: https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c#summary
Q2.
VIP 관련 헷갈리는 게 ingress를 사용하게 되면 ingress controller가 특정 worker node에 띄워지고 별도의 VIP를 설정하라는 의미인지, 아니면 ingress controller가 내부에서 자동으로 이중화돼서 VIP만 노출해준다는 의미인가요?
A2.
ingress도 쿠버네티스에서 구동하는 앱의 일종입니다. ingress용 deployment와 service가 있으며, service의 descriptor에 externalIPs를 통해 VIP를 명시하는 방식입니다. ingress용 pod가 특정 워커에 있어서 동작하는 방식이 아닙니다. 해당 VIP를 kube-proxy가 listen하여 트래픽을 ingress pod로 라우팅 하여 동작합니다. ingress pod는 사용자가 각 네임스페이스에 등록된 ingress설정을 참조하여 다시 트래픽을 라우팅 합니다. 참고로 VIP는 온 프레미스 등과 같은 환경에서 L4 Switch에서 오는 VIP를 사용하는 예를 팁으로 드린 것입니다. 클라우드 환경에서와는 활용 사례가 다릅니다.
Q3.
로드밸런싱과 pod 간의 관계가 궁금하네요. 개별 pod 자체가 프로세스이고 쉽게 없어지고 올라오기 때문에 endpoint를 service에 external type으로 지정을 한다고 하셨는데요. 그러면 유저가 접근하는 최종 endpoint가 service에서 끝나는 거 아닌가 해서요.
pod가 도커 이미지를 품은 대략의 was 개념으로 볼 때 pod까지 load balancing이 되어야 하지 않나요? LB 웹서버 (WAS), LB service POD (다수 존재 가능)으로 이해가 돼서 잘못 이해하고 있는 건가 궁금하네요.
A3.
컴포넌트 간 참조를 개별 pod 별 ip로 하는 것은 pod는 생성되고 없어질 수 있는 대상이므로, 직접적인 참조를 지양하시는 것을 권장 드립니다. 쿠버네티스의 Service가 제공하는 ClusterIP 혹은 DNS A레코드를 이용하여 참조하면 pod들에게로 라우팅을 하므로 pod가 사라져서 발생할 수 있는 문제를 최소화할 수 있습니다.
외부 노출을 위해 사용하는 Service의 LoadBalancer는 CSP의 ExternalLB와 NodePort설정의 조합입니다.
Service를 LoadBalancer로 설정하는 경우, NodePort 옵션으로 30000과 같은 포트를 각 워커 노드의 kube-proxy라는 컴포넌트가 Listen하여 pod로 트래픽을 밸런싱 하며, 해당 포트로 클러스터 외부에서 내부의 Service로 접근할 수 있습니다.
CSP사에서 LB의 80포트를 통해 서비스하는 경우, LB는 보통 src80=>dst30000과 같은 포트포워딩 설정이 되어 있으며, 80번 포트를 통해 NodePort로 선언된 포트로 서비스로 접근합니다.
다시 말씀드리면 각 워커 간 로드밸런싱은 외부 LB이며, 워커에 도착한 트래픽은 Service에서 다시 밸런싱 됩니다.
