부두 마스터 스위치

Docker 를 설치하면 docker 데몬이 다음과 같은 세 개의 네트워크를 자동으로 만듭니다.

실제로 docker 에는 다리, 호스트, 없음, 컨테이너 등 네 가지 네트워크 통신 모드가 있습니다.

기본 네트워크 모델은 브리지이며 우리 생산에도 사용됩니다.

다음으로, docker 컨테이너 상호 운용의 원리를 여러분과 공유하겠습니다. 그 당시 브리지 네트워크 모델도 사용되었습니다.

또한 docker 를 설치한 후 docker 는 docker0 이라는 네트워크 장치를 만들어 줍니다.

Ifconfig 명령을 통해 볼 수 있습니다. 마치 네트워크 카드처럼 eth0 네트워크 상태와 같습니다. 그러나 docker0 은 실제로 리눅스 다리입니다.

왜 봤지? 다음 명령을 사용하여 운영 체제에서 브리지 정보를 볼 수 있습니다.

그렇다면 리눅스 브리지의 개념을 어떻게 이해할 수 있을까요?

실제로, 당신은 가상 스위치로 docker0 를 이해할 수 있다! 그런 다음 이런 식으로 다음과 같이 이해하면 갑자기 밝아질 것이다.

1, 대학이 기계실에 있을 때 선생님 옆에 있는 큰 스위치 장치처럼요.

2. 기계실의 모든 컴퓨터를 스위치에 연결하고, docker 컨테이너와 비교하며, docker 컨테이너는 호스트의 docker0 에 장치로 연결됩니다.

3. 스위치의 IP 와 기계실의 기계를 같은 네트워크 세그먼트에 놓고, docker0 과 비교한다. 네가 시작한 docker 컨테이너의 IP 도 172 네트워크 세그먼트에 속한다.

비유는 이렇습니다.

우리는 방금 docker0 을 이해할 때 이렇게 말했습니다. "기계실의 모든 컴퓨터를 스위치에 연결하고, 이를 docker container 에 비하고, 호스트에서 docker0 에 연결된 장치로 비유했습니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 컴퓨터명언) 그럼 어떤 기술로 착지를 실현할 수 있을까요?

대답은: veth pair 입니다.

Veth pair 의 전체 이름은 가상 이더넷이며 가상 이더넷 카드입니다.

이더넷 카드에 대해 말하자면, 모두들 낯설지 않다. 일반적인 네트워크 장치는 eth0 또는 ens 라고 하지 않나요?

그럼 베스는 어떻게 놀았을까요? 무슨 소용이 있습니까? 다음 그림을 볼 수 있습니다.

Veth-pair 장치는 서로 다른 두 개의 네트워크 네임스페이스를 연결하기 위해 항상 쌍으로 나타납니다.

위 그림과 같이 network-namespace 1 의 veth0 에서 보낸 데이터는 network-namespace2 의 veth 1 디바이스에 나타납니다.

이 특성은 좋지만 컨테이너가 여러 개 있으면 조직 구조가 점점 더 복잡해지고 혼란스러울 수 있습니다.

다행히도 Linux bridge (docker0) 와 veth-pair 장치에 대해 점점 더 잘 알고 있으므로 전체 아키텍처를 다음과 같이 다시 그릴 수 있습니다.

서로 다른 컨테이너에는 자체 격리된 네트워크 네임스페이스가 있기 때문에 모두 자체 네트워크 스택이 있습니다.

그럼 컨테이너와 물리기 중 어느 카드가 한 쌍의 네트워크 vethpair 장치인지 알 수 있을까요?

다음과 같습니다.

마스터 컴퓨터로 돌아가기

즉, 컨테이너 545ed62d3abf 의 eth0 NIC 와 호스트가 IP addr 명령을 통해 본 네트워크 디바이스 번호 55 의 디바이스는 vethpair 디바이스 한 쌍으로 구성되며, 트래픽은 서로 상호 운용됩니다!

동일한 LAN 에서 서로 다른 호스트 A 와 B 간에 데이터를 쉽게 교환할 수 있는 방법을 살펴보겠습니다. 다음 그림

네, 같은 LAN 에 있는 이상 A 와 B 의 IP 주소가 같은 네트워크 세그먼트에 있다는 뜻입니다. 위 그림과 같이 둘 다192.168.1.0 네트워크 세그먼트에 있다고 가정합니다.

아래의 OSI 7 계층 네트워크 모델을 봐야 합니다.

호스트 a 가 호스트 b 로 데이터를 보냅니다. 호스트 a 의 경우 데이터는 최상위 애플리케이션 계층에서 하위 계층으로 전송됩니다. 예를 들어 응용 프로그램 계층을 사용할 때 어떤 일이 발생합니까?

위의 지식 예비로? 오늘 우리가 논의할 문제를 보는 것은 어렵지 않다.

빨간색 부분은 다음과 같습니다. 같은 호스트의 다른 컨테이너는 어떻게 서로 통신합니까?

그런 다음 컨테이너에 각각 로그인하여 IP 를 기록합니다.

실험 결과를 먼저 보세요: 900 1 의 curl9002.

실험 결과는 인터넷 상호 운용성이다!

위 그림을 개선하고 docker0 과 두 컨테이너의 IP 를 다음 그림과 같이 추가해 보겠습니다.

두 시스템은 통신하기 전에 OSI 네트워크 모델과 이더넷 프로토콜을 따라야 합니다.

우리는 172 438+07.0.2 컨테이너 2 라고 부릅니다.

우리는 172 438+07.0.3 컨테이너 3 이라고 부른다.

예를 들어 컨테이너 2 에서 컨테이너 3 을 꺼내면 컨테이너 2 도 아래와 같이 이더넷 프로토콜에 따라 패킷을 캡슐화해야 합니다.

그래서 지금 문제는 3 번 컨테이너의 MAC 주소가 뭔가요?

컨테이너 2 는 먼저 로컬 캐시를 확인합니다. 이전에 액세스되지 않은 경우 캐시에 레코드가 없습니다!

하지만 괜찮습니다. ARP 메커니즘이 하나 더 있습니다. 그래서 컨테이너 2 는 ARP 요청 패키지를 대략 다음과 같이 보냅니다.

컨테이너 2 는 자체 라우팅 테이블을 쿼리하고 자체 게이트웨이에서 이 ARP 요청을 발행합니다.

컨테이너 2 의 게이트웨이에 해당하는 네트워크 디바이스의 IP 는 docker0 의 IP 주소이며 eth0 을 통해 전송되었습니다!

이봐? Eth0 은 우리가 앞서 말한 veth-pair 장치가 아닌가요?

다음 명령을 통해 다른 쪽 끝이 호스트의 어떤 네트워크 디바이스에 해당하는지 알 수 있습니다.

그리고 우리는 위의 관점이 정확한지 확인하기 위해 다음과 같은 작은 실험을 할 수 있다.

따라서 컨테이너 2 의 eth0 에서 ARP 요청 메시지가 호스트의 53 번째 네트워크 장치에 동시에 나타납니다.

아래 그림에서 볼 수 있듯이 53 번째 네트워크 장치는 실제로 아래 그림의 veth0- 1 입니다.

따라서 이 ARP 요청 패키지는 docker0 으로 전송됩니다. Docker0 이 이 ARP 메시지를 받았을 때, 대상 IP 가 자신이 아니라 172. 17.0.3 이라는 것을 알게 되자, docker0 은 이 ARP 요청 메시지,/KLOC 를 더 방송할 것이다. 3 번 컨테이너 포함!

이 ARP 메시지를 받으면 컨테이너 3 이 판단됩니다, 오! 대상 IP 는 자체 IP 이므로 자신의 MAC 주소를 ARP 메시지로 채우고 docker0 으로 반환합니다!

마찬가지로 호스트에서 패킷을 캡처하여 확인할 수 있습니다.

그래서 컨테이너 2 는 컨테이너 3 의 MAC 주소를 받았고, 이더넷 패킷에 필요한 정보가 완성되었습니다! 다음과 같습니다.

컨테이너 2 는 컨테이너 3 과 정상적으로 상호 연결됩니다!

용기 3 은 많은 가방을 받을 수 있는데, 어떤 가방이 자신에게 보내졌는지, 어떤 가방이 그렇지 않은지 어떻게 알 수 있을까요? 다음과 같은 판단 논리를 참고할 수 있다.