K8s 네트워크 상세 정보

우선 K8s 의 사용은 사실 용기에 대한 정리와 관리라는 것을 이해해야 한다. 가장 작은 구성 요소는 실제로 컨테이너가 아니라 곤돌라입니다. 물리적 시스템 또는 가상 시스템을 노드라고 하며 pod 는 기본 단위입니다. Pod 에는 여러 컨테이너가 있거나 하나의 컨테이너만 있을 수 있습니다. 동일한 pod 내의 컨테이너는 네트워크 및 호스트 구성을 서로 공유할 수 있습니다. 즉, 동일한 시스템에서 통신하는 것과 유사하게 localhost 에서 직접 서로 통신할 수 있으므로 격리와 격리가 없습니다. 그래서 첫 번째 질문은, 같은 pod 의 다른 컨테이너가 다른 노드에 있을 수 있는가 하는 것입니다. 물론 아닙니다. * * * 호스트와 네트워크를 즐기므로 동일한 노드에 있어야 합니다. Pod 하나에 여러 개의 컨테이너가 있다는 것을 어떻게 알 수 있습니까? Kubectl exec 가 실행해야 할 컨테이너를 지정할 수 있습니까? 물론 다음 지침을 참조하십시오.

따라서 컨테이너의 개념을 무시하고 pod 만 고려할 수 있습니다. 결국 pod 는 k8s 의 가장 작은 스케줄링 단위입니다. 그럼 pod 과 pod 은 어떻게 소통하나요?

포드 통신은 K8s 네트워크 모델과 분리 될 수 없습니다.

플란넬은 두 층의 평평한 네트워크를 형성하고, pod 의 IP 분배는 플란넬에 의해 균일하게 분배되며, 통신 과정도 플란넬의 다리이다.

노드 간 통신을 위해 각 노드에 flannel0 가상 네트워크 카드가 생성됩니다. 따라서 컨테이너는 pod id 와 직접 통신할 수 있습니다.

노드 간 통신이 이루어지면 발신자 데이터는 docker0 에서 flannel0 가상 NIC 로 라우팅되고 수신자 데이터는 flannel0 에서 docker0 으로 라우팅됩니다.

Pod 가 응용 프로그램 컨테이너의 집합이라면 서비스는 의미가 없습니다. 애플리케이션 서비스가 전체 수명주기 동안 로드, 추적 및 관리되어야 할 때 나타난다는 의미입니다. 따라서 서비스는 Pod 의 논리적 집합과 이러한 Pod 에 액세스하는 정책을 정의하는 추상적인 개념입니다.

어떤 이유로 Pod 가 작동을 멈추면 kubelet 은 배포 요구 사항에 따라 새로운 Pod 를 다시 시작하여 이전 Pod 기능을 제공하지만 플란넬은 이 새로운 Pod 에 새로운 IP 를 할당하여 많은 작업량을 초래하고 응용 서비스의 많은 구성 항목을 조정해야 합니다. 서비스가 있다면, 이것은 문제가 되지 않는다. 서비스의 작동 원리를 살펴 보겠습니다.

이 그림은 서비스의 운영 메커니즘을 보여줍니다. 서비스 A 가 만들어지면 서비스 컨트롤러와 엔드포인트 컨트롤러가 트리거되어 일부 리소스를 업데이트합니다. 예를 들어 서비스에 구성된 POD 선택기에 따라 각 POD 에 대한 엔드포인트 리소스가 만들어져 etcd 에 저장됩니다. 또한 Kube-proxy 는 IPtables 의 체인 규칙을 업데이트하여 서비스 기반 클러스터 IP 에서 해당 Pod 로 연결되는 링크 규칙을 생성합니다. 클러스터의 pod 중 하나가 서비스에 액세스하려고 하면 직접 클러스터 ip:port 가 iptables 링크를 기반으로 요청을 해당 Pod 로 보낼 수 있습니다. 이 레이어에서 pod 를 선택하는 두 가지 알고리즘, 즉 순환법과 세션 친연관성이 있습니다. 물론, 이 iptabels 모드 이외에, 또 다른 기본 방법은 사용자 모드 전달입니다. Kube-Proxy 는 각 서비스의 프록시 포트를 무작위로 수신하고 IPtables 규칙을 추가합니다. 클라이언트에서 클러스터 IP: 포트로의 메시지는 프록시 포트로 리디렉션됩니다. Kube-Proxy 가 메시지를 수신하면 루프 일정 또는 세션 친연 관계 (즉, 동일한 클라이언트 IP 가 동일한 Pod 서비스에 동일한 링크를 가져옴) 를 통해 해당 Pod 에 배포됩니다.

물론 k8s 의 새 버전은 ipvs 기반 iptables 를 대체하기 시작했지만 iptables 와 비슷한 형식입니다.

개념지도는 다음을 볼 수 있습니다.

이것이 가장 원시적인 방법입니다. 다음 그림을 참조하십시오.

IPVS 는 LVS 프로젝트의 일부이며 Linux 커널에서 실행되는 4 계층 로드 밸런서로 성능이 뛰어납니다. 최적화된 커널을 사용하여 초당 6 억 5 천 4 백 8 십만 회 이상의 전달 요청을 쉽게 처리할 수 있습니다. 현재, 중대형 인터넷 프로젝트에서는 IPVS 가 사이트 포털의 트래픽을 감당하는 데 널리 사용되고 있다.