-
질문 & 답변
카테고리
-
세부 분야
데브옵스 · 인프라
-
해결 여부
해결됨
IP가 변경되는 것에 대해서 질문이 있습니다.
23.11.24 21:24 작성 조회수 258
0
질문 답변을 제공하지만, 강의 비용에는 Q&A는 포함되어 있지 않습니다. 다만 실습이 안되거나, 잘못된 내용의 경우는 알려주시면 가능한 빠르게 조치하겠습니다!
[질문 전 답변]
1. 강의에서 다룬 내용과 관련된 질문인가요? 예
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? 예
3. 질문 잘하기 법을 읽어보셨나요? 예
(https://www.inflearn.com/blogs/1719)
4. 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
5. vagrant up 에서 발생하는 문제는 주로 호스트 시스템(Windows, MacOS)과 연관된 다양한 조건에 의해 발생합니다. 따라서 이를 모두 제가 파악할 수 없어서 해결이 어렵습니다. vagrant up으로 진행이 어렵다면 제공해 드리는 가상 머신(VM) 이미지를 import해서 진행하시기 바랍니다.
(https://www.inflearn.com/questions/992407/comment/281901)
6. ARM 계열의 m1 , m2 계열은 VirtualBox를 통한 구성이 원할하지 않고, 실습 환경의 다변화는 추후 대처하기 어려워서 현재 과정에서는 지원하지 않습니다.
(https://www.inflearn.com/questions/915529)
[질문 하기]
안녕하세요! 명강의 잘 듣고있습니다 :)
4.4 로드밸런서 파드에서의 질문입니다.
로드밸런서는 사실 내부적으로 nodePort가 동작하므로 노드 포트로 접속하고자 하는 노드들 中 1택을 할 때 RR과 같은 트래픽 분산정책이 사용된다고 알고있습니다.
서비스 내부로 도착해서 파드에 트래픽이 분배될 때 또한 트래픽 분산정책이 발생하고요.
따라서 로드밸런서를 사용할 경우, <접속할 노드 중 1택>을 결정할 때 트래픽이 한번 분산되고, 내부의 서비스에 도착해서 파드에 접속할 때 트래픽이 분산되는, 총 2번의 트래픽 분산이 수행되는 것으로 알고있습니다.
[질문]
질문은 아래와 같습니다.
현재 실습에서 접속되는 파드의 IP가 "지속적으로 변경되는 것"은 직접적으로 보았을 때 서비스에서 파드에 접속할 때의 트래픽 분산에 의한 것인가요?
답변을 작성해보세요.
1
조훈(Hoon Jo)
지식공유자2023.11.25
안녕하세요
LoadBalancer는 구현 방법에 따라 NodePort와 유사할 수도 있고 아닐 수도 있습니다.
그리고 내부 라우팅을 구현하는 방법에 따라 역시 좀 다를 수도 있습니다.
서비스 내부에 도착해서 내부 트래픽 분배가 아니라...
노드포트 기준으로 도착한 시점에 파드 분배는 정책에 따라 다소 다르지만, 옆의 노드에 있는 파드로 트래픽이 옮겨질 수 있습니다. (엄밀히 따지면 RR은 아닙니다.)
이와 관련해서 알아야 하는건 Kube-proxy(주로 iptables, 요즘은 eBPF가...)를 기반으로 하는 기술들입니다.
이런 경우 다른 노드로 넘어가서 latency를 높이는 것을 방지하고자 하는 경우
externalTrafficPolicy를 local로 제한해서 사용합니다.
단점도 많이 있습니다. 클러스터를 클러스터 답게 못(안) 쓰게 되거든요.
질문이...
현재 실습에서 접속되는 파드의 IP가 "지속적으로 변경되는 것"은 직접적으로 보았을 때 서비스에서 파드에 접속할 때의 트래픽 분산에 의한 것인가요?
무슨 뜻인지 정확하게는 모르겠습니다...그래서 일단 이해하고 계시는 내용을 다시 정리했는데요
IP가 지속적으로 변경되는건 위의 kube-proxy를 구현하고 있는 기술에 의해서
여러 개의 Endpoints에 접속하는 돌아가면서 접속하는 것입니다.
아마 질문에 대한 답은 되는거 같긴 한데...
혹시 제가 잘 못 이해해서 다른 형태의 답변이 나간거면 다시 말씀 부탁드려요.
위의 내용과 관련해서 읽어보시면 좋을 내용 2개를 더 붙여 드립니다.
https://discuss.kubernetes.io/t/how-traffic-is-routed-to-pod-by-node-port/12890
cloud
질문자2023.11.25
먼저 주말에도 정말 상세하게 질 좋은 답변 해주셔서 너무나 감사합니다.
두 글 모두 너무나 잘 읽어보았습니다.
모르는 걸 GPT 돌려서 공부하다보니, 여기서 여러 잘못된 지식이 습득되었던 것 같습니다😂
제가 글을 보고 다시 생각을 정리해 보았는데, 혹시나 너무나 긴 질문글이 될까봐😂 단순하게 이해 한 바에 대해서 맞는지 틀린지만 검증해 주시면 감사하겠습니다. :)
해당 강의자료를 대한 이해를 바탕으로 한 질문이라, 강의자료를 들고왔습니다.
[질문]
지속적으로 IP가 변경되는(접속되는 파드가 달라지는) 이유는 kube-proxy의 iptables 또는 ebpf 기술에 의해서 접속되는 Endpoint가 변경되기 때문이다.
2. nodePort를 통해서 애플리케이션을 노출 시, externalTrafficPolicy는 default 값으로 Cluster를 가지고 있다. 따라서 <워커 노드 #1 IP>:<nodePort 포트번호> 로 접속하더라도, nodePort 서비스에서 워커 노드 #1, #2, #3 중 하나에게 트래픽이 분배되어 들어간다. (이러한 트래픽 분배는 kube-proxy의 iptables 또는 ebpf 기술에 의해 발생한다.)
3. externalTrafficPolicy가 Cluster 이고, 클러스터 내 <워커노드 # 1> 에만 파드가 배포되어 있다고 했을 때, <워커 노드 #1 IP>:<nodePort 포트번호>로 접속하더라도, 노드포트 서비스에서 워커노드 #1, #2, #3 트래픽이 분배되어 해당 파드에 접속하지 못할 수도 있다.(https://discuss.kubernetes.io/t/how-traffic-is-routed-to-pod-by-node-port/12890의 2번 질문)
4. local과 Cluster의 각 단점externalTrafficPolicy : local인 경우의 단점
✅ 한 노드로 트래픽이 고정되므로, 부하가 증가하고 가용성이 낮아진다.(말씀해주신 클러스터를 클러스터 답게 못쓴다)externalTrafficPolicy : Cluster(default)의 단점
✅ 노드간에 실제 물리적 거리가 멀 경우, 그만큼 네트워크 내 hop이 많아져서 latency(지연시간)가 증가할 수 있다.
✅ <워커 노드 #1 IP>:<nodePort 포트번호> 로 정확하게 파드가 있는 노드로 접속했음에도, 노드 포트 서비스에서 파드가 배포되지 않은 엉뚱한 노드로 트래픽이 옮겨질 수 있다.
질문이 많아서 죄송합니다..ㅠㅠ
공부하다가 추가 질문이 생겼는데..추가적으로 저희가 노드 포트 실습 때, <각 워커노드의 INTERNAL-IP>:30000과 같이 파드에 접속하였는데 , 로드밸런서의 역할은 이 <각 워커노드 INTERNAL-IP>를 어떤 워커노드 IP를 쓸 지 로드밸런싱 해주는 건가요?
조훈(Hoon Jo)
지식공유자2023.11.27
질문]
지속적으로 IP가 변경되는(접속되는 파드가 달라지는) 이유는 kube-proxy의 iptables 또는 ebpf 기술에 의해서 접속되는 Endpoint가 변경되기 때문이다.
네 간단하게 보면 Endpoints가 여러개라서 그렇게 동작하는 거가 맞습니다.
2. nodePort를 통해서 애플리케이션을 노출 시, externalTrafficPolicy는 default 값으로 Cluster를 가지고 있다. 따라서 <워커 노드 #1 IP>:<nodePort 포트번호> 로 접속하더라도, nodePort 서비스에서 워커 노드 #1, #2, #3 중 하나에게 트래픽이 분배되어 들어간다. (이러한 트래픽 분배는 kube-proxy의 iptables 또는 ebpf 기술에 의해 발생한다.)이건 좀 복합적인데요...
externalTrafficPolicy은 트래픽을 처리하는 옵션에 가깝습니다.
기본 값이 cluster 전체로 하는거고요. (배포 후 매니페스트 뽑아 보시면 확인 가능합니다.)
노드로 들어온 이후에 진행은 CNI에 따라 다릅니다. (주로 overlay network 이고, calico는 터널링을 통할겁니다. / 저도 뜯어서 다시 봐야 합니다. 구현하는 것에 따라 달라서요)
3. externalTrafficPolicy가 Cluster 이고, 클러스터 내 <워커노드 # 1> 에만 파드가 배포되어 있다고 했을 때, <워커 노드 #1 IP>:<nodePort 포트번호>로 접속하더라도, 노드포트 서비스에서 워커노드 #1, #2, #3 트래픽이 분배되어 해당 파드에 접속하지 못할 수도 있다.(https://discuss.kubernetes.io/t/how-traffic-is-routed-to-pod-by-node-port/12890의 2번 질문)
해보고 패킷의 흐름을 잡거나(wireshark) 아니면 테스트 후에 되고 안되는걸 보셨으면 아마 더 확실히 아실꺼 같은데....
Cluster 모드는 파드가 현재 접속한 노드에 없어도 클러스터에 속해 있는 어느 노드에도 전달해 주어 통신할 수 있게 해줍니다. 반대가 local 입니다. 위의 내용이 local을 쓰신거 같아요.
4. local과 Cluster의 각 단점externalTrafficPolicy : local인 경우의 단점
✅ 한 노드로 트래픽이 고정되므로, 부하가 증가하고 가용성이 낮아진다.(말씀해주신 클러스터를 클러스터 답게 못쓴다)externalTrafficPolicy : Cluster(default)의 단점
✅ 노드간에 실제 물리적 거리가 멀 경우, 그만큼 네트워크 내 hop이 많아져서 latency(지연시간)가 증가할 수 있다.
✅ <워커 노드 #1 IP>:<nodePort 포트번호> 로 정확하게 파드가 있는 노드로 접속했음에도, 노드 포트 서비스에서 파드가 배포되지 않은 엉뚱한 노드로 트래픽이 옮겨질 수 있다.
질문이 많아서 죄송합니다..ㅠㅠ
공부하다가 추가 질문이 생겼는데..추가적으로 저희가 노드 포트 실습 때, <각 워커노드의 INTERNAL-IP>:30000과 같이 파드에 접속하였는데 , 로드밸런서의 역할은 이 <각 워커노드 INTERNAL-IP>를 어떤 워커노드 IP를 쓸 지 로드밸런싱 해주는 건가요?
local의 단점은...노드에 고정되어 가용성이 낮아진다는거고 부하는...그렇게 생각할 수도 있긴 한데 보통 local을 쓰고 부하가 증가한다고 계산하지 않을꺼 같습니다. 애초에 local을 쓰는 목적이 latency나 hop을 거치는걸 선호하지 않는 서비스에 대한 우려로 구현 하는 부분이니까요.
엉뚱한 노드로 트래픽이라는 관점은 노드포트에 어울리지 않습니다. 애초에 접속한 노드에 파드가 있을꺼라는 것을 보증하지 않으니까요.
IT 세계에서 내가 가는 곳에 모두 다 있다고 보증하는 서비스는 존재하지 않습니다.
(아..SAN은 약간 보증하긴 하네요..)
없을 수도 있다는 가정은 IT 세상에서 항상 존재합니다. 하물며 ECC 메모리도 칩이 하나 깨질수도 있다고 가정하고 진행하니까요.
이건 노드포트가 아니라 LoadBalancer도 마찬가지 입니다. Best Effort이지 Gurantee하지 않습니다.
관점의 차이가 있긴 하지만요.
4번은 스터디 주제로 삼아서 많은 사람이 모여서 얘기하시는게 좋으실꺼 같아요.
--- 추가 ---
질문이 많은거야 🙂 괜찮은데...
제 생각에는 알아야 하는 이유가 명확하고 (아마도 보통 트러블슈팅 혹은 구현의 목적) 그걸 위해서 이것저것 뒤져보고 테스트한 이후에 하셔야 기억에 오래 남고, 나중에 필요할 때 사용하실 수도 있을꺼에요.
위의 내용들을 직접 구현해서 테스트해 보고 결과를 가지고 본인이 고민하는 시간이 있어야 아마 이해도 오래가고 활용도 가능하실꺼라는 의미입니다. (그래서 주로 실습 가능하도록 저는 랩을 구성하기도 합니다. 안 해보면 이해가 잘 안 가더라고요)
근데 이건 사람마다 공부법의 차이라서..이게 꼭 정답은 아닙니다. cloud님에게 가장 적합한 방법을 찾으셔서 오래 기억에 남고 잘 활용할 수 있는 방법으로 진행하시면 될 것 같아요!!!
(질문을 계속 하는 방법이 맞으시면 그걸로 하셔도 된다는 의미입니다 😉 )
답변 1