[번역] 쿠버네티스 네트워킹 이해하기#2: Services | 커피고래의 노트

[utterances-bot]

[번역] 쿠버네티스 네트워킹 이해하기#2: Services | 커피고래의 노트

쿠버네티스 네트워킹 이해하기 시리즈 중 첫번째 포스트에서는 쿠버네티스가 가상 네트워크 device와 라우팅 규칙을 이용하여 한 Pod가 다른 Pod와 어떻게 통신하는지 알아봤습니다. 이번 글에서는 Service라는 리소스에 대해 알아보고 한 Pod가 어떻게 Service와 통신을

https://coffeewhale.com/k8s/network/2019/05/11/k8s-network-02/

[hongkunyoo]

Comment written by 오리뎅이 on 05/25/2019

=========================================================== IP대역이 Pod들과는 조금 다르다는 것을 알 수 있습니다. 종류 IP Network pod1 10.0.1.2 10.0.0.0/14 pod2 10.0.2.2 10.0.0.0/14 service 10.3.241.152 10.3.240.0/20 =========================================================== 본문에서 10.3.241.151은 10.0.0.0/14 subnet의 range에 속하는 IP 인데요. 왜 저자는 다른 network로 설명을 하는 것일까요? 10.0.0.0/14 range : 10.0.0.0 ~ 10.3.255.255

Comment written by HongKun Yoo on 05/26/2019 02:22:22

날카로운 포인트 짚어 주셔서 감사합니다. 저도 오리뎅이 님의 코멘트를 보고 생각해보니 정말 같은 네트워크 range 안에 든다는 것을 발견했습니다. 오타인지 아니면 저자의 의도가 있는지 원본 블로그를 살펴 보던 중 비슷한 코멘트가 달린 것을 확인했습니다.

저자가 답변하길, 자신의 표현에 서투름이 있었는 것을 인정하며 service 네트워크는 로컬 device에 연결되지 않고 netfilter를 통해서만 패킷이 전달되기 때문에 다른 네트워크라고 얘기한 것 같습니다.

https://medium.com/@betz.mark/hi-constantin-d02849ab76b5

저도 질문을 받고 더 깊이 공부하는 시간이 되었습니다. 감사합니다.

[hongkunyoo]

Comment written by JunYoung Park on 07/07/2019 02:22:22

안녕하세요 또 왔습니다 ㅎㅎ 좋은글 여전히 감사합니다

제가 이해한 부분으로는 "서비스는 사실상 실체가 없다. 그냥 ClusterIP : pod ip들 형태의 iptables를 말한다" 라고 봐도 될까요?

만약 제대로 이해한게 맞다면,

• Pod 간의 로드밸런싱은 iptables를 이용해서 구현했다(iptables 에서 이것도 되나요? 잘 몰라서..)
• kube-proxy가 계속해서 이 iptables를 관리해준다
• 기존에는 kube-proxy 에서 로드밸런싱을 해줬었다

로 이해되는게 이게 맞을까요?

올려주신 글이 정말 많이 도움이 되었습니다. 혹시나 잘못 이해한점 있으면 알려주시면 감사하겠습니다

Comment written by HongKun Yoo on 07/09/2019

안녕하세요, JunYoung Park 님. 저의 글을 지속적으로 읽어주시고 관심 가져주셔서 감사합니다. 덕분에 블로깅하는 보람을 느낍니다.

네, 말씀하신 부분이 전부 맞는 것 같습니다. 처음에는 kube-proxy에서 로드밸런싱을 담당했던 것에서 (userspace mode) kube-proxy는 iptables만 관리하고 iptables에서 로드밸런싱 역할을 하는 것으로 바뀌었고 (iptables mode) 마지막으로 iptables은 기본적으로 로드밸런싱을 위해 존재하는 녀석이 아니기 > 때문에 Pod의 개수가 많아지게되면 느려지는 문제의 한계 때문에 추후에는 ipvs가 그 역할을 대체할 예정 (ipvs mode)로 볼 수 있을 것 같습니다.

그리고 iptables에서 로드밸런싱 기능 자체가 있는 것은 아니고 iptables에 있는 기능 (패킷을 forwarding 해주는 기능)을 잘 조합하여 마치 로드밸런싱이 되는 것처럼 kube-proxy가 조작하는 것 같습니다. 그렇기 때문에 추후에는 로드밸런싱의 역할을 제대로 해줄 수 있는 ipvs를 적용하는 것이 아닌가 생각됩니다.

Comment written by JunYoung Park on 07/14/2019 02:22:22

그렇군요. 상세한 답변 감사합니다!

[hongkunyoo]

Comment written by Cheol on 08/07/2020

좋은글 감사합니다. 제가 이해한걸로는 node 에서 나가는 요청을 iptable 을 이용해서 프록시하는걸로 이해되는데 그렇다면 pod 이나 service 의 업데이트가 잇을 때는 kubenetes 가 iptable 을 지속적으로 업데이트 해야 할 것 같은데 그걸 kube-proxy 가 하는건가요?

Comment written by HongKun Yoo on 08/07/2020

안녕하세요, 관심 가져주셔서 감사합니다. 네, 맞습니다. 다만 service만 해당됩니다. pod는 라우팅 테이블에 의해 결정되는데 네트워크 프로바이더가 담당합니다.

아래 링크를 참고하시면 더 자세히 확인하실 수 있습니다. https://kubernetes.io/docs/concepts/services-networking/service/#ips-and-vips

[hongkunyoo]

Comment written by J W on 10/07/2020

좋은 글 고맙습니다. 많은 도움이 되었어요

Comment written by HongKun Yoo on 10/07/2020

관심 가져주셔서 감사합니다!

[JeongJin984]

좋은 글 너무 감사합니다!

[hongkunyoo]

@JeongJin984 감사합니다ㅎㅎ

[kingbj940429]

매우 흥미로운 글이네요 감사합니다 :)

[whoo3474]

안녕하세요! 항상 글 자주 여러번 잘 읽고있습니다! :)

사실 serivce를 하나 등록하게 되면 쿠버네티스의 어려 컴포넌트들에 영향을 미치게 되는데 오늘 여기에서는 위의 예시를 가능하게 만들었던 kube-proxy에 대해서만 살펴보도록 하겠습니다.

중에서 어려 -> 여러 가 아닐까 하여 댓글 달아봅니다..!ㅎ 좋은글 써주셔서 감사합니다!

[gomgomshrimp]

좋은 글 감사합니다. 그림에서 문의드릴게 있는데요. kube-proxy 와 netfilter 동작에 관한 설명 그림에서,

client process -> pod veth0 10.0.2.3 으로 되어있는데, 이전 그림 예시를 참고했을 때 제가 이해한 것이 올바르다면, client Pod는 veth1 그리고 10.0.1.3이 되어야할 것 같다는 생각이 들었습니다.

혹시 그림의 오류일지, 제가 놓치는 부분이 있을지 문의드려봅니다.

[hongkunyoo]

안녕하세요, @gomgomshrimp 님, 좋은 질문 감사합니다. 제가 생각했을 때에는 원저자가 또 하나의 다른 예시를 든 것 같이 보입니다만 이전 그림과 연결해서 봤을 때에는 말씀하신대로 다음과 같이 표현되는게 맞는 것 같습니다. client process -> pod veth1 10.0.1.3

사람들이 헷갈려할 수 있을 것 같았는데 중요한 포인트 짚어주셔서 감사합니다.

[gmjeong86]

중간에 서비스 생성하는 부분이 누락된건가요 생략된건가요!? 갑자기 중간에 붕뜬 느낌입니다

[hongkunyoo]

안녕하세요. @gmjeong86 님. 이 글은 번역글로 최대한 원작자 글을 그대로 번역하려고 노력하였습니다. 다만 원작자가 일부 생략하고 설명한 부분이 있는 것 같습니다.