search

hongkunyoo / blog-comments

blog comments for utteranc.es
1 stars 0 forks source link

[번역]쿠버네티스 패킷의 삶 - #2 | 커피고래의 노트 #42

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

[번역]쿠버네티스 패킷의 삶 - #2 | 커피고래의 노트

쿠버네티스 패킷의 삶 #1에서 살펴 봤듯이, CNI plugin은 쿠버네티스 네트워킹에서 중요한 역할을 차지합니다. 현재 많은 CNI plugin 구현체들이 존재합니다. 그 중 Calico를 소개합니다. 많은 엔지니어들은 Calico를 선호합니다. 그 이유는 Calico는 네트워크 구성을 간단하게 만들어 주기 때문입니다. 쿠버네티스 패킷의 삶 시리즈 컨테이너 네트워킹과 CNI: 리눅스 네트워크 namespace와 CNI 기초 Calico CNI: CNI 구현체 중 하나인, Calico CNI 네트워킹 (원글) Pod 네트워킹: Pod간, 클러스터 내/외부 네

https://coffeewhale.com/packet-network2

MinkuEvanChoi commented 2 years ago

홍건님 안녕하세요. 채널톡에서 채용을 담당하고 있는 최민구라고 합니다.

블로그를 보고 너무 관심이 가네요 :) 짧게 15분정도 통화 어떠세요??

링크드인으로 1촌신청 드렸는데 이쪽으로 DM 또는 010-6613-1269 로 문자 한번 주시면 감사하겠습니다.

squareBird commented 2 years ago

안녕하세요, 항상 도움을 많이 받고 있습니다.

이번 글과 관련하여 질문 드리고 싶은 내용이 있습니다!

  1. 쿠버네티스는 kubenet을 기본 cni로 사용한다.
  2. Calico의 Felix 컴포넌트가 kube-proxy의 동작 모드에 따라서 iptables와 ipvs를 조작한다.

이 두가지와 관련된 질문입니다.

  1. Felix 컴포넌트가 kube-proxy이 동작 모드에 따라 다르게 동작한다는 것이 Felix 컴포넌트가 iptables와 ipvs를 조작할 때 kube-proxy를 이용해서 조작을 하는 것인가요?

  2. 만약 그렇지 않고 Felix가 직접 수행한다면 kube-proxy pod를 제거해도 정상적으로 pod간 통신이 수행되나요?

  3. calico에서는 bird를 이용해 노드간 라우팅 정보를 공유하는데 kubenet과 kube-proxy로 동작하는 환경에서는 어떻게 라우팅 정보를 공유하나요?

  4. cni의 역할 중 동료 노드들에게 IP 라우팅 정보 전달한다는 내용이 다른 worker node들에 iptables, netfilter 등을 이용해 어떤 pod으로 가는 패킷은 어떤 node로 전달하라는 내용을 전달하는 걸까요?

감사합니다!

hongkunyoo commented 2 years ago

@squareBird

안녕하세요, 좋은 질문 주셔서 감사합니다.

1, 2번 답변을 드리자면 상황에 따라서 다를 것 같습니다.

Felix는 라우팅 테이블을 조작하여 Pod 패킷을 전달합니다. 그리고 iptables을 이용하여 Network Policy(어떤 패킷이 지나갈 수 있고 없고)를 설정합니다. (iptables 모드인 경우) kube-proxy는 Service IP를 Pod IP로 치환하는 역할을 담당합니다.

다만 CNI 설정(eBPF 설정)에 따라서 CNI 컴포넌트(Felix)가 kube-proxy의 역할을 대신하는 경우도 있습니다. 이 경우에는 kube-proxy 없이 Felix만 있어도 Pod 패킷 전달과 Service - Pod IP 매핑이 가능합니다.

  1. kube-proxy는 Pod 레벨 네트워킹과 관계 없이 Service 레벨의 네트워킹을 담당하는 컴포넌트입니다. Service object 생성 시, 각 노드에 존재하는 kube-proxy가 해당 정보를 확인하여 iptables을 조작합니다.

  2. 결과적으로 해당 패킷 정보(혹은 MAC 정보)를 가진 Pod가 어느 노드에 존재하는지 알려주는 정보를 전달합니다.

[참고자료]

https://projectcalico.docs.tigera.io/reference/architecture/overview https://projectcalico.docs.tigera.io/reference/architecture/data-path https://projectcalico.docs.tigera.io/reference/felix/configuration#ebpf-dataplane-configuration

squareBird commented 2 years ago

답변 감사드립니다!

친절히 잘 설명해 주신 것 같은데 제가 아직 부족해서인지 개념이 잘 잡히지 않은 것 같습니다.

이전에 작성해주신 쿠버네티스 네트워킹 이해하기 글을 통해서 이해한 바로는 kube-proxy는 클러스터에 service가 생성되었을 때 iptables 또는 ipvs 룰을 설정해주는 역할을 하는것으로 이해하였습니다.

번거롭게 해드려서 죄송하지만, 관련하여 추가적으로 질문 드립니다.

  1. Pod레벨 네트워킹과 Service 레벨의 네트워킹이 어떤 개념일까요?

  2. NodePort Service를 정의할 때 kube-proxy가 동작하는 방식이 아래 방식과 동일할까요? 1) . Cluster IP의 특정 Port(port)를 목적지로 하는 패킷이 어떤 Node의 어떤 Port(NodePort)로 가야하는지 iptables rule정의 2). Node의 IP에 따라 어떤 Pod(컨테이너)의 어떤 Port(targetPort)로 가야하는지 iptables rule 정의 +). Userspace Mode에서는 kube-proxy가 직접 목적지를 변경했지만 iptables, ipvs 모드에서는 직접 변경하지 않고 iptables 또는 ipvs 룰만 변경 +). iptables rule 정의시 netfilter에도 정책 정의됨

  3. kube-proxy와 cni의 차이가 잘 와닿지 않습니다. 개념적으로 어떤 차이가 있는걸까요?

  4. kube-proxy는 Service IP를 Pod IP로 치환하는 역할을 담당한다고 말씀해 주셨는데, userspace mode가 아니라면 직접 치환하는 형태가 아닌 iptables나 ipvs 룰에 설정만 해주고 실제 치환은 해당 룰에 의해 정의된 netfilter 룰에 의해 수행되는게 아닌가요?

  5. eBPF 모드 설정시 kube-proxy를 disable하는 부분이 있고, pod에서 패킷을 캡쳐할 때 source ip가 docker0와 같은 브릿지 IP가 아닌 실제로 접근한 사용자의 IP로 잡히는 것을 확인했습니다. eBPF 모드를 제외한 ipvs, iptables mode에서는 felix가 kube-proxy를 이용해 iptables 룰을 설정하는걸까요?

다시한번 번거롭게 해드려 죄송합니다!

hongkunyoo commented 2 years ago
  1. Pod레벨 네트워킹과 Service 레벨의 네트워킹이 어떤 개념일까요?

Pod는 쿠버네티스의 가장 기본적인 실행 단위로 독립적인 네트워크 대역을 가지고 있습니다. (CNI 설정에 따라 호스트와 동일하게 설정도 가능) 한 Pod에서 다른 Pod로 어떻게 패킷이 라우팅될 것인가를 고민하는 것이 Pod 레벨 네트워킹입니다.

Service에 주어지는 Cluster IP는 실체하지 않고 각 호스트의 iptables에 존재하며 사용자가 Cluster IP로 패킷을 전송할 때 그것을 Pod IP로 치환해 줍니다.

  1. NodePort Service를 정의할 때 kube-proxy가 동작하는 방식이 아래 방식과 동일할까요?

2)번에 가깝다고 생각합니다. Node의 특정 Port가 Service로 연결이 됩니다.

  1. kube-proxy와 cni의 차이가 잘 와닿지 않습니다. 개념적으로 어떤 차이가 있는걸까요?

CNI는 Pod 네트워크에 관한 규약과 그 구현체들(Calico, flannel 등)을 말합니다. 쿠버네티스에서는 CNI라는 인터페이스를 통해 CNI 구현체와 상호작용합니다. CNI 구현체를 통해 Pod 네트워킹이 가능하게 됩니다.

kube-proxy는 쿠버네티스 리소스인 Service의 구현체입니다. 사용자가 Service를 생성하게 되면 그에 맞는 rule이 kube-proxy를 통해 iptables에 적용됩니다.

  1. kube-proxy는 Service IP를 Pod IP로 치환하는 역할을 담당한다고 말씀해 주셨는데, userspace mode가 아니라면 직접 치환하는 형태가 아닌 iptables나 ipvs 룰에 설정만 해주고 실제 치환은 해당 룰에 의해 정의된 netfilter 룰에 의해 수행되는게 아닌가요?

네, 맞습니다. 추상적으로 그렇게 설명했는데 말씀하신 내용이 정확합니다.

  1. eBPF 모드 설정시 kube-proxy를 disable하는 부분이 있고, pod에서 패킷을 캡쳐할 때 source ip가 docker0와 같은 브릿지 IP가 아닌 실제로 접근한 사용자의 IP로 잡히는 것을 확인했습니다. eBPF 모드를 제외한 ipvs, iptables mode에서는 felix가 kube-proxy를 이용해 iptables 룰을 설정하는걸까요?

felix가 kube-proxy를 이용하여 iptables을 조작하진 않고 직접 iptables을 조작하는 것으로 알고 있습니다.

minhohongpro commented 1 year ago

안녕하세요, 포스팅 잘 보았습니다. 궁금한 점이 있습니다.

master $ ip route
# default via 172.17.0.1 dev ens3
# 172.17.0.0/16 dev ens3 proto kernel scope link src 172.17.0.32
# 172.18.0.0/24 dev docker0 proto kernel scope link src 172.18.0.1 linkdown
# blackhole 192.168.49.64/26 proto bird
# 192.168.49.65 dev calic22dbe57533 scope link
# 192.168.49.66 dev cali9861acf9f07 scope link
# 192.168.196.128/26 via 172.17.0.40 dev tunl0 proto bird onlink

위 route rule에서 docker0 device는 사용하지 않는 것으로 보이는데 calico 를 통해 네트워킹을 하기 때문에 docker0 브리지는 disable한 것으로 보면 될까요?

hongkunyoo commented 1 year ago

@minhohongpro 님. 안녕하세요. 네, 맞습니다. 이 예제에서는 calico가 bridge 대신에 proxy ARP를 이용하여 중간의 패킷을 가로채서 대신 패킷을 보내기 때문에 bridge를 사용하지 않습니다. 하지만 설정에 따라서 calico도 bridge를 이용하게 만들 수도 있습니다.