K8s의 ExternalTrafficPolicy

  • Post author:
  • Post category:칼럼
  • Post comments:0 Comments
  • Post last modified:February 21, 2020

Network Load Balancer Support in Kubernetes 1.9는 NLB를 다루면서 ExternalTrafficPolicy 별 차이점과 주의할 사항을 비교적 잘 설명하기에 기록으로 남긴다. 누가 물어볼 때 투척해주기에 좋을 듯 하다.

Nodes are added to an NLB by instance ID, but, to explain a little bit of Kubernetes networking, the traffic from the NLB doesn’t go straight to the pod. Client traffic first hits the kube-proxy on a cluster-assigned nodePort and is passed on to all the matching pods in the cluster. When the spec.externalTrafficPolicy is set to the default value of Cluster, the incoming LoadBalancer traffic may be sent by the kube-proxy to pods on the node, or to pods on other nodes. With this configuration the client IP is sent to the kube-proxy, but when the packet arrives at the end pod, the client IP shows up as the local IP of the kube-proxy.

ExternalTrafficPolicy: Cluster 에 대한 설명

By changing the spec.externalTrafficPolicy to Local, the kube-proxy will correctly forward the source IP to the end pods, but will only send traffic to pods on the node that the kube-proxy itself is running on. Kube-proxy also opens another port for the NLB health check, so traffic is only directed to nodes that have pods matching the service selector. This could easily result in uneven distribution of traffic, so use a DaemonSet or specify pod anti-affinity to ensure that only one pod for a given service is on a node.

ExternalTrafficPolicy: Local 의 장점과 주의할 점

참고

Author Details
Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.
0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments