Cni 호스트

이 문서에서는 다음을 포함하여 현재 컨테이너 네트워크 유형의 세분화를 중점적으로 설명합니다.

-응? 아무도 없다

-응? 커버

-응? 패딩

컨테이너 기술의 발전과 발전에 따라 이전의 컨테이너 네트워크. 다음 두 모드의 네트워크 솔루션이 사라졌습니다.

링크 및 대사

Swarm 을 사용하여 다중 호스트 네트워크를 지원하고 구성하기 전에 Docker 는 단일 호스트 네트워크로 시작하여 링크를 통해 네트워크 접속을 촉진하며, 컨테이너가 환경 변수 또는 /etc/hosts 파일 항목을 통해 서로를 찾아 컨테이너 간에 정보를 전송할 수 있도록 하는 메커니즘입니다. 링크 기능은 일반적으로 대사 모드와 결합되어 호스트 간 컨테이너 연결을 용이하게 하고 링크가 기록되는 취약점을 줄입니다. 이 방법의 가장 큰 문제는 너무 정적이라는 것이다. 컨테이너가 만들어지고 환경 변수가 정의되면 관련 컨테이너 또는 서비스가 새 IP 주소로 이동되면 이러한 변수의 값을 업데이트할 수 없습니다.

컨테이너 매핑 네트워크

이 네트워크 모드에서는 한 컨테이너가 다른 컨테이너의 네트워크 이름 공간을 재사용 (매핑) 합니다. 이 네트워킹 모드는-net: container: some _ container _ name _ or _ id 로만 사용할 수 있습니다.

이 run 명령 플래그는 Docker 에게 이 컨테이너의 프로세스를 이미 다른 컨테이너에서 만든 네트워크 스택에 배치하라고 지시합니다. 첫 번째 컨테이너와 동일한 IP 및 MAC 주소 및 포트 번호를 공유하더라도 새 컨테이너의 프로세스는 여전히 자체 파일 시스템, 프로세스 목록 및 자원 제약으로 제한됩니다. 두 컨테이너의 프로세스는 루프백 인터페이스를 통해 서로 연결될 수 있습니다.

이러한 네트워킹 방식은 실행 중인 컨테이너에서 진단을 수행하는 데 유용하며 컨테이너에는 필요한 진단 도구 (예: curl 또는 dig) 가 부족합니다. 필요한 진단 도구가 있는 임시 컨테이너를 만들어 첫 번째 컨테이너의 네트워크에 연결할 수 있습니다.

컨테이너 맵 네트워크는 여러 컨테이너가 동일한 네트워크 네임 스페이스를 공유하는 pod 네트워킹을 시뮬레이션하는 데 사용할 수 있습니다. * * * 로컬 호스트 통신 공유, * * 동일한 IP 주소 공유 등의 장점은 컨테이너가 동일한 pod 에서 실행되는 개념에 내재되어 있다는 것입니다. 이는 rkt 컨테이너의 동작입니다.

현재 컨테이너 네트워크 없음

None 은 네트워크 스택을 수신하지만 외부 네트워크 인터페이스가 없는 비교적 직접적인 컨테이너입니다. 그러나 루프백 인터페이스를 받게 됩니다. Rkt 및 Docker 컨테이너 항목은 네트워크를 사용하지 않거나 빈 네트워크를 사용할 때 유사한 동작을 제공합니다. 이 컨테이너 네트워크 모델은 컨테이너 테스트, 향후 네트워크 연결에 컨테이너 할당, 외부 통신이 필요하지 않은 컨테이너 할당 등 다양한 용도로 사용됩니다.

다리

Linux bridge 는 동일한 호스트의 컨테이너는 통신할 수 있지만 각 컨테이너에 할당된 IP 주소는 호스트 외부에서 액세스할 수 없는 호스트 내부 네트워크를 제공합니다. 브리지 네트워크는 NAT 및 포트 매핑에 iptables 를 사용하여 단일 호스트 네트워크를 제공합니다. 브리지 네트워크는 가상 네트워크 인터페이스 쌍의 한쪽 끝이 브리지와 컨테이너 사이에 연결된 기본 Docker 네트워크 유형 (docker0) 입니다.

다음은 작성 프로세스의 예입니다.

1. 호스트에 다리를 만듭니다.

2. 각 컨테이너의 네임스페이스가 이 다리에서 제공됩니다.

컨테이너의 ethX 는 개인 브리지 인터페이스에 매핑됩니다.

4. NAT 가 있는 iptables 를 사용하여 각 개인 컨테이너 및 호스트에 대한 공용 인터페이스를 맵핑합니다.

NAT 는 호스트 외부의 통신을 제공하는 데 사용됩니다. 브리징 네트워크는 포트 충돌 문제를 해결하고 호스트에서 실행되는 컨테이너에 대한 네트워크 격리를 제공하지만 NAT 관련 성능 비용이 발생합니다.

주재하다

이 방법에서는 새로 생성된 컨테이너가 호스트와 네트워크 네임스페이스를 공유하고, 더 높은 성능 (베어 메탈 근처) 을 제공하며, NAT 에 대한 필요성을 없앴습니다. 그러나 포트 충돌이 있습니다. 컨테이너는 모든 호스트의 네트워크 인터페이스에 액세스할 수 있지만 권한 모드로 배포되지 않는 한 호스트의 네트워크 스택을 재구성하지 못할 수 있습니다.

호스트 네트워크는 Mesos 에서 사용되는 기본 유형입니다. 즉, 프레임워크에 네트워크 유형이 지정되지 않은 경우 새 네트워크 네임스페이스가 컨테이너와 연결되지 않고 호스트 네트워크와 연결됩니다. 로컬 네트워크라고도 하는 호스트 네트워크는 개념이 간단하고 이해, 문제 해결 및 사용이 용이합니다.

커버

덮어쓰기 네트워크 터널을 사용하여 호스트 간에 통신을 전달합니다. 이렇게 하면 컨테이너가 터널 네트워크 서브넷을 통해 한 호스트에서 다음 호스트로 마치 같은 시스템에 있는 것처럼 작동할 수 있습니다. 실제로 하나의 네트워크가 여러 호스트에 걸쳐 있습니다. 현재 가상 확장 가능 LAN VXLAN 과 같은 많은 터널 기술이 있습니다.

VXLAN 은 Docker libnetwork 가 선호하는 터널링 기술이며 다중 호스트 네트워크는 1.9 버전의 기본 기능입니다. 이 기능이 도입되면서 Docker 는 HashiCorp 의 Serf 를 gossip 프로토콜로 선택하고 이웃 테이블 교환 및 수렴 시간 효율성을 선택했습니다.

플란넬은 다른 터널 기술을 지원해야 하는 사람들의 선택일 수 있다. Udp, vxlan, host-gw, aws-vpc 또는 GCE 를 지원합니다. 각 클라우드 공급자 터널 유형은 공급자의 라우팅 테이블에 계정 또는 VPC 에 대한 경로를 만듭니다. 공용 * * * 클라우드에 대한 지원은 overlay 드라이버에 특히 중요합니다. overlay 는 혼합 클라우드 시나리오를 더 잘 해결하고 공용 * * * 포트를 열지 않고 확장 및 중복성을 제공하기 때문입니다.

다중 호스트 네트워크는 Docker 데몬을 시작하고 키 값을 저장할 때 추가 매개변수가 필요합니다. 일부 재정의는 분산 키 값 저장소에 따라 달라집니다. 컨테이너 구성을 진행 중인 경우 이미 분산 키 값 저장소가 있습니다.

커버리지는 호스트 간 통신 과제에 초점을 맞추고 있습니다. 동일한 호스트에서 서로 다른 두 개의 오버레이 네트워크에 연결된 컨테이너는 로컬 브리지를 통해 서로 통신할 수 없습니다. 즉, 서로 세그먼트화됩니다.

...... 의 기초가 되다

기본 네트워크 드라이버는 호스트에서 실행 중인 컨테이너 또는 가상 시스템에 호스트 인터페이스 (즉, eth0 의 물리적 네트워크 인터페이스) 를 직접 노출시킵니다. 이러한 두 드라이버는 MACVLAN 과 IPVLAN 입니다. 네트워크 엔지니어는 MACVLAN 및 IPVLAN 드라이버의 운영 및 기능에 대해 잘 알고 있습니다. 이 두 네트워크 드라이버는 브리지 네트워크보다 개념적으로 간단하며 포트 매핑이 필요하지 않으며 효율성이 높습니다. 또한 IPVLAN 에는 많은 네트워크 엔지니어가 선호하는 L3 모드가 있습니다. 대부분의 공용 클라우드의 제한 (또는 용량 부족) 을 고려하면 기본 계층은 로컬 워크로드, 보안 문제, 트래픽 우선 순위 또는 규정 준수 요구 사항이 있을 때 특히 유용합니다. VLAN 당 브리지 1 개와 달리 기본 네트워크는 하위 인터페이스당 VLAN 1 개를 허용합니다.

맥플랜지

MACVLAN 을 사용하면 호스트의 단일 물리적 인터페이스 뒤에 여러 가상 네트워크 인터페이스를 만들 수 있습니다. 각 가상 인터페이스에는 고유한 MAC 및 IP 주소 할당이 있지만 IP 주소가 물리적 인터페이스와 동일한 브로드캐스트 도메인에 있어야 한다는 제한이 있습니다. 많은 네트워크 엔지니어가 하위 인터페이스라는 용어를 더 잘 알고 있을 수 있지만 (보조 인터페이스와 혼동하지 마십시오), MACVLAN 가상 인터페이스를 설명하는 데 사용되는 용어는 일반적으로 상위 또는 하위 인터페이스입니다. MACVLAN 네트워크는 LINUX 브리지, NAT 및 포트 매핑의 필요성을 제거하여 물리적 인터페이스에 직접 연결할 수 있도록 하는 방법입니다.

MACVLAN 의 각 컨테이너는 고유한 MAC 주소를 사용하므로 MAC 스푸핑을 방지하기 위해 이 보안 정책을 사용하는 네트워크 스위치에 문제가 발생할 수 있습니다 (물리적 스위치 인터페이스당 하나의 MAC 주소만 허용됨).

컨테이너 트래픽이 필터링되고 기본 호스트와 통신할 수 없으므로 호스트가 실행되는 컨테이너와 완전히 격리됩니다. 호스트가 컨테이너에 도달할 수 없습니다. 컨테이너가 호스트와 격리됩니다. 이 기능은 서비스 공급자 또는 멀티 테넌시 시나리오에 유용하며 브리지 모델보다 격리가 더 좋습니다.

MACVLAN 에는 하이브리드 모드가 필요합니다. MACVLAN 에는 네 가지 작동 모드가 있으며 Docker 1. 12 는 브리지 모드만 지원합니다. MACvlan 브리징 모드와 IPvlan L2 모드는 기능적으로 동일합니다. 두 모드 모두 브로드캐스트 및 멀티 캐스트 트래픽 입력을 허용합니다. 이러한 기본 프로토콜은 설계 시 내부 사용 사례를 고려합니다. 공용 클라우드 마일리지는 대부분의 가상 시스템 인터페이스가 혼합 모드를 지원하지 않기 때문에 다를 수 있습니다.

참고: MACVLAN 브리징 모드는 각 컨테이너에 고유한 MAC 주소를 할당하여 네트워크 트래픽과 엔드 투 엔드 가시성을 추적하는 데 도움이 될 수 있습니다. 그러나 BR OADCOM 과 같이 5 12 개의 고유한 MAC 주소 상한선이 있는 일반적인 NIC (네트워크 인터페이스 카드) 의 경우 이 상한선을 고려해야 합니다.

IPVLAN

MACVLAN 과 유사한 IPVLAN 은 새로운 가상 네트워크 인터페이스를 만들고 각 IP 주소에 고유한 IP 주소를 할당합니다. 차이점은 호스트의 모든 pod 및 컨테이너 물리적 인터페이스의 MAC 주소가 동일하다는 것입니다. 이 동작은 많은 스위치가 일반적으로 구성된 보안 상태가 여러 MAC 주소의 트래픽을 차단하는 스위치 포트이기 때문에 필요합니다.

가장 잘 실행되는 커널은 버전 4.2 이상이며 IPVLAN 은 L2 또는 L3 모드에서 실행할 수 있습니다. MACVLAN 과 마찬가지로 IPVLAN L2 모드에서는 하위 인터페이스에 할당된 IP 주소가 물리적 인터페이스와 동일한 서브넷에 있어야 합니다. 그러나 IPvlan L3 모드에서는 컨테이너 네트워크와 IP 주소가 상위 물리적 인터페이스와 다른 서브넷에 있어야 합니다.

Linux 호스트의 802. 1q 구성 (IP 링크를 사용하여 만들 때) 은 짧기 때문에 대부분의 운영자는 네트워크 시작 스크립트를 사용하여 구성을 저장합니다. 자동화는 기본 드라이버를 실행하는 컨테이너 엔진을 개선하고 프로그래밍 방식으로 VLAN 을 구성하는 API 를 공개합니다. 예를 들어 랙 스위치에 새 VLAN 을 만들 때 노출된 컨테이너 엔진 API.ico 를 통해 Linux 호스트에 VLAN 을 푸시할 수 있습니다.

MACVLAN 및 IPVLAN

두 가지 기본 유형 중에서 선택할 때 단일 컨테이너의 MAC 주소를 볼 네트워크가 필요한지 여부를 고려합니다.

ARP (address resolution protocol) 및 브로드캐스트 통신의 경우 기본 구동 L2 모드에 관계없이 스위치를 연결하는 서버와 마찬가지로 많은 802. 1D 그룹을 통해 작업을 배웁니다. 그러나 IPVLAN L3 모드에서는 네트워크 스택이 컨테이너에서 처리되며 멀티캐스트 또는 브로드캐스트 트래픽을 허용하지 않습니다. 이러한 의미에서 IPVLAN L3 모드는 L3 라우터의 동작에 따라 작동합니다.

업스트림 L3 라우터는 IPvlan 을 사용하여 만든 네트워크를 알아야 합니다. 온라인 광고와 인터넷의 재분배는 여전히 완성해야 한다. 현재 Docker 는 BGP (boundary gateway protocol) 를 시도하고 있습니다. GoBGP 프로젝트가 피어-투-피어 이웃 및 라우팅 스위칭 기능을 제공하기 위해 컨테이너 생태 친화적인 방식으로 급속히 발전해 온 것처럼 정적 라우팅은 랙 스위치 맨 위에 만들 수 있습니다.

지정된 호스트가 여러 네트워크 모드를 지원하지만 MACVLAN 과 IPVLAN 은 동일한 물리적 인터페이스에서 동시에 사용할 수 없습니다. 간단히 말해 호스트에서 트렁킹을 실행하는 데 익숙한 경우 L2 모드를 사용할 수 있습니다. 규모에 관심이 있다면, L3 는 규모의 잠재력을 가지고 있습니다.

직접 라우팅

같은 이유로 IPVLAN L3 모델은 네트워크 엔지니어에게 인기가 있으며 계층 3 의 네트워크 복잡성 해결에 집중할 수 있습니다. 이 방법은 기존 네트워크 인프라를 사용하여 컨테이너 네트워크를 관리하는 데 도움이 됩니다. L3 에 집중된 컨테이너 네트워크 솔루션은 라우팅 프로토콜을 사용하여 연결을 제공하므로 기존 데이터 센터 인프라, 연결 컨테이너, 가상 시스템 및 베어 메탈 서버와 상호 운용하기가 더 쉽다고 할 수 있습니다. 또한 L3 네트워크는 네트워크 트래픽 필터링 및 격리를 확장하고 세밀한 제어를 제공합니다.

CALICO 는 BGP 를 사용하여 각 네트워크에 라우팅, 특히 /32 를 사용하는 워크로드를 할당하는 프로젝트입니다. 이를 통해 기존 데이터 센터 인프라와 원활하게 통합되며 덮어쓸 필요가 없습니다. 덮어쓰거나 캡슐화하는 오버헤드가 없어 네트워크의 성능과 규모가 우수합니다. 컨테이너의 라우팅 가능한 IP 주소는 IP 주소와 포트를 외부에 노출시킵니다. 교육을 받고 라우팅 프로토콜을 사용하여 네트워크를 배포, 진단 및 운영하는 데 익숙한 네트워크 엔지니어는 직접 라우팅을 더 쉽게 이해할 수 있습니다. 그러나 CALICO 는 겹치는 IP 주소를 지원하지 않습니다.

팬카페

팬 네트워크는 할당된 IP 주소에서 250 개의 IP 주소로 확장되는 추가 IP 주소에 액세스하는 방법입니다. 이는 네트워크를 겹치지 않고 더 많은 IP 를 얻을 수 있는 효과적인 방법입니다. 이러한 유형의 네트워크는 공용 클라우드에서 컨테이너를 실행할 때 특히 유용합니다. 공용 클라우드에서는 단일 IP 주소가 호스트에 할당되고 추가 네트워크 시작을 금지하거나 다른 로드 밸런싱 인스턴스를 실행하는 것이 비용이 많이 듭니다.

점대점

포인트 투 포인트 (point-to-point) 는 코어 OS rkt 에서 사용하는 가장 간단한 네트워크 유형과 기본 네트워크일 수 있습니다. 기본적으로 NAT 또는 IPMASQ 를 사용하면 가상 이더넷 쌍이 만들어지고 하나는 호스트에, 다른 하나는 컨테이너 pod 에 배치됩니다. 지점 간 네트워크는 인바운드 트래픽에 대한 포트 포워딩뿐만 아니라 루프백 인터페이스를 통해 pod 의 다른 컨테이너 간 내부 통신에 대한 포트 포워딩을 제공합니다.

접속성뿐만 아니라 기능은 다른 네트워크 기능 및 서비스에 대한 지원도 고려해야 합니다. 많은 모드의 컨테이너 네트워크는 NAT 및 포트를 사용하여 전달되거나 의도적으로 사용하지 않습니다. 네트워크를 선택할 때 IP 주소 관리 IPAM, 멀티캐스트, 브로드캐스트, IPv6, 로드 밸런싱, 서비스 검색, 정책, 서비스 품질, 고급 필터링 및 성능을 추가로 고려해야 합니다.

문제는 이러한 기능이 지원되는지 여부입니다. 런타임, 오케스트레이션 엔진 또는 플러그인이 컨테이너 네트워크를 지원하더라도 인프라에서 이를 지원하지 않을 수 있습니다. 일부 2 차 공용 클라우드 공급업체는 IPv6 지원을 제공하지만, 최상위 공용 클라우드에서는 IPv6 에 대한 지원이 부족하여 오버레이 네트워크 및 팬 네트워크와 같은 다른 네트워크 유형에 대한 사용자의 수요가 증가합니다.

IPAM 의 경우 가용성을 높이기 위해 대부분의 컨테이너 런타임 엔진은 네트워크에 연결되어 있기 때문에 기본적으로 host-local 을 사용하여 컨테이너에 주소를 할당합니다. 호스트 로컬 IPAM 에는 선택할 고정 IP 주소 블록 정의가 포함되어 있습니다. 컨테이너 간 네트워크 프로젝트는 일반적으로 DHCP (dynamic host configuration protocol) 를 지원합니다. 컨테이너 네트워크 모델 (CNM) 과 컨테이너 네트워크 인터페이스 (CNI) 에는 IPAM 시스템과의 통합을 위한 IPAM 내장 및 플러그인 프레임워크가 있습니다. 이는 많은 기존 환경에서 사용되는 핵심 기능입니다.

컨테이너 네트워크 모델 (CNM) 및 컨테이너 네트워크 인터페이스 (CNI) 에 대한 자세한 기술적 세부 사항은 잊혀진 문장: 컨테이너 네트워크 초점: CNM 및 CNI 를 참조하십시오.

문말복지:' Wise2C' 위챗 공식 계정에주의를 기울여 그룹에 응답하십시오. 서운 조수는 가능한 한 빨리 너를 Docker 기업 착지 실천군으로 끌어들일 것이다. 우리가 공유하는 다양한 기업 사례 프로젝트의 기술 전문가와 사용자 대표가 당신의 왕림을 기다리고 있습니다. 우리는 당신이 팀의 황소와 프로젝트의 더 많은 세부 사항과 문제에 대해 상담하고 토론하기를 기대합니다.

서운호지 고객 프로젝트에 대한 자세한 내용은 Wise2C 위챗 공식 계정의 모범 사례 메뉴를 참조하십시오.

건화물 배송 시리즈 (a): 푸드 생명 컨테이너 기술 응용 사례

건화물 유통 시리즈 (2): 중국 핑안 컨테이너 기술 적용 사례

건화물 배송 시리즈 (3): 민생 생활 컨테이너 기술 응용 실제 사례

건화물 전달 시리즈 (4): 중형 생명 보험 회사 시스템 구조 개조 계획 컨설팅 실제 사례

연간 실사 시리즈: 연간 실사 | 20 16 금융업계 컨테이너 기술 애플리케이션-보험

연간 실사 시리즈: 연간 실사 | 20 16 금융업계 컨테이너 기술 애플리케이션-은행편

Wise PaaS 제품에 대한 자세한 내용은 마케팅 팀에 문의하십시오.

Contact@wise2c.com