Rede de contêiner de tecnologia de contêiner Docker

índice

A tendência de desenvolvimento da rede de contêineres

CNI

CNI (Container Network Interface) é um padrão de rede de contêiner liderado pelo Google e CoreOS, desenvolvido com base na proposta de rede RKT, levando em consideração fatores como flexibilidade, escalabilidade, alocação de IP e múltiplas placas de rede. .

O objetivo do CNI é fornecer padronização de rede para plataformas de contêiner. Diferentes plataformas de contêiner (por exemplo, Kubernetes, Mesos e RKT) podem chamar diferentes componentes de rede por meio da mesma interface. Este protocolo conecta dois componentes:

1. Sistema de gerenciamento de contêineres
2. Plugin de rede

Coisas específicas são implementadas por plug-ins, incluindo: criar um espaço de rede de contêiner (namespace de rede), colocar uma interface de rede (interface) no espaço de rede correspondente e atribuir IP à interface de rede.

Atualmente, as soluções fornecidas pela CNI geralmente são divididas em dois tipos

1. Plano do túnel
2. Esquema de roteamento

Especificamente: Soluções de rede Flannel, Callico, Weave e macvlan. Em termos de dificuldade, Callico é a mais simples, seguida de Flanela, e Weave é a mais complicada. Do ponto de vista da tecnologia de rede, Weave e Flannel são tecnologias de encapsulamento de rede. A diferença está na localização do encapsulamento no dispositivo de rede ou no host.

Flanela

Flannel é uma solução de rede proposta pela CoreOS para resolver a comunicação entre hosts em clusters de contêineres. Flannel é essencialmente uma rede Overlay, ou seja, os dados TCP são empacotados em outro pacote de rede para roteamento, encaminhamento e comunicação. Atualmente, ela suporta UDP, VXLAN, AWS VPC, roteamento GCE e outros métodos de encaminhamento de dados, entre os quais a tecnologia VXLAN é a mais Populares, muitos data centers consideram a mudança para a rede VXLAN da Flannel ao considerar a introdução de contêineres.

Flannel atribui uma sub-rede a cada host e o contêiner atribui o IP dessa sub-rede. Esses IPs podem ser roteados entre os hosts e os contêineres podem se comunicar entre os hosts sem NAT e mapeamento de porta. A flanela permite que diferentes hosts de nós no cluster tenham um endereço IP virtual exclusivo em todo o cluster ao criar contêineres e se conectem à rede de nós do host. Flannel pode replanejar as regras de uso de endereço IP para todos os nós do cluster, de modo que os contêineres em nós diferentes possam obter endereços IP "iguais" e "não duplicados", permitindo que contêineres em nós diferentes passem diretamente pela intranet Para comunicação IP, a parte do encapsulamento da rede é invisível para o contêiner. O serviço de host de origem encapsula o conteúdo de dados original em UDP e os entrega ao nó de destino de acordo com sua própria tabela de roteamento. Depois que os dados chegam, eles são descompactados e, em seguida, entram diretamente na placa de rede virtual do nó de destino e, em seguida, chega diretamente à placa de rede virtual do contêiner do host de destino para atingir o propósito de comunicação de rede.

Embora o Flannel tenha altos requisitos na rede, a tecnologia de encapsulamento é introduzida e a eficiência de encaminhamento também é afetada, mas pode fazer uma transição suave para a rede SDN. A tecnologia VXLAN pode ser bem integrada com SDN e é digna de implantação automática e operação e manutenção inteligentes de toda a rede. E gerenciamento, mais adequado para implantação de nova rede de data center.

Callico

A maior diferença entre a rede de contêiner Callico e outras redes virtuais é que ela não usa uma rede de sobreposição para o encaminhamento de pacotes e fornece um modelo de rede de três camadas puro. O modelo de comunicação de três camadas significa que cada contêiner se comunica diretamente por IP. Para que o roteamento funcione corretamente, o nó do host onde cada contêiner está localizado deve ter alguma forma de saber as informações de roteamento de todo o cluster. Callico usa o protocolo de roteamento BGP para tornar toda a rede O Nó e o equipamento de rede da rede registram a rota para toda a rede.

No entanto, este método produzirá muitas rotas inválidas, o que requer muitas especificações de roteamento de equipamentos de rede, e a rede inteira não pode ter equipamentos com especificações de roteamento baixas. Além disso, Callico realiza o roteamento do contêiner de origem para o host de origem, através do data center, depois para o host de destino e, finalmente, para o contêiner de destino. Todo o processo é sempre roteado e encaminhado de acordo com o protocolo BGP, sem empacotamento ou desempacotamento. Processo, para que a eficiência do encaminhamento seja muito mais rápida, que é a vantagem técnica da rede de contêineres Callico.

Tecer

O Weave é essencialmente uma rede Overlay. O Weave pode virtualizar a rede conectando contêineres em diferentes hosts em uma rede semelhante a uma rede local. Diferentes hosts usam seus próprios endereços IP privados. Quando os contêineres são distribuídos em vários hosts diferentes Na ocasião, a comunicação entre esses containers pode ser simplificada através do Weave.

Os contêineres na rede Weave usam portas padrão para fornecer serviços (por exemplo, o MySQL usa 3306 por padrão) e o gerenciamento de microsserviços é muito direto e simples. Cada contêiner pode se comunicar com outros contêineres por meio de um nome de domínio ou se comunicar diretamente sem usar NAT e sem mapeamento de porta ou conexões complicadas.

A maior vantagem de implantar a rede de contêineres Weave é que você não precisa modificar o código do aplicativo. O Weave inicia um roteador virtual em cada host no cluster de contêiner e usa o host como um roteador para formar uma topologia de rede interconectada. Com base nisso, ele realiza a comunicação entre hosts do contêiner.

Para implantar o Weave, você precisa garantir que a versão do kernel Linux do host seja superior a 3.8, Docker 1.10 ou superior. Se houver um firewall para acesso entre os hosts, os firewalls devem permitir um ao outro números de porta, como TCP 6783 e UDP 6783/6784. Essas são as portas de controle e de dados do Weave. Os nomes não podem ser iguais, o Weave precisa identificar a sub-rede pelo nome do host.

A rede Weave é semelhante à tecnologia de sobreposição de host, que encapsula diretamente o tráfego de pacotes no host, de modo a realizar o acesso mútuo entre o host e o host através da rede de três camadas Underlay. Esta é a maior diferença da rede de flanela. A flanela é uma solução de sobreposição de rede. .

Macvlan

Macvlan é um recurso relativamente novo do Linux Kernel. Ele permite que várias interfaces de rede virtual sejam configuradas em uma interface de rede do host. Essas interfaces de rede têm seus próprios endereços MAC independentes e também podem ser configuradas com endereços IP para comunicação. A máquina virtual ou rede de contêiner em macvlan e o host estão no mesmo segmento de rede e compartilham o mesmo domínio de transmissão. Macvlan e bridge são semelhantes, mas como elimina a existência de bridge, a configuração e a depuração são relativamente simples e a eficiência é relativamente alta. Além disso, o próprio macvlan também oferece suporte perfeito para VLAN.

ServiceMesh + CNI

ServiceMesh e CNI são uma relação combinada. ServiceMesh não substitui CNI. Eles funcionam em diferentes níveis SDN. CNI funciona mais no nível L2-4 e ServiceMesh funciona no nível L5-7 Application SDN. O ServiceMesh não pode ser implantado independentemente do CNI e, junto com o CNI, fornece os serviços de rede exigidos por aplicativos de microsserviço hierárquicos. De acordo com um relatório do Gartner, em 2020, quase 100% das nuvens de contêiner terão a tecnologia ServiceMesh integrada. O Istio de código aberto atual só oferece governança de microsserviços em um único cluster do Kubernetes e carece de nuvem de contêiner heterogênea e recursos de nuvem cruzada.

O CNI precisa ser entregue a cada contêiner POD dentro do microsserviço na camada L2-4 da nuvem de contêiner. A entrega do terminal de aplicativo requer conexão de rede L2, roteamento L3, isolamento de segurança de camada L2-4, segurança geral de contêiner em nuvem, balanceamento de carga, etc.

A ServiceMesh está mais comprometida com a governança de serviço no nível do aplicativo de microsserviço e com os serviços de rede da camada L5-7. A malha de serviço implanta um proxy de aplicativo Sidecar Envoy na frente de cada contêiner de aplicativo para fornecer roteamento inteligente entre microsserviços e cargas distribuídas. Equilíbrio, gerenciamento de tráfego, azul-verde, liberação canário, elasticidade de microsserviço, disjuntor de limite de corrente, nova tentativa de tempo limite, visualização entre microsserviços, segurança, etc.
·

Rede de contêiner Docker

O Docker fornece vários tipos de redes, que determinam a forma de comunicação entre os contêineres e entre eles e o mundo externo.

• Tipo de rede básico
  

• Ver todos os tipos de rede de contêiner:

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
c79756cf9cde        bridge              bridge              local
204025a5abbc        host                host                local
9b9024f5ac40        macvlan             macvlan             local
6478888548d8        none                null                local
p2e02u1zhn8x        overlay             overlay             swarm

Modo Ponte

A rede Docker em modo bridge é implementada com base na tecnologia de rede virtual do Linux. As interfaces de rede do Container Docker são interfaces virtuais por padrão, o que pode proporcionar a eficiência do encaminhamento de dados entre diferentes contêineres ou entre contêineres em hosts. Isso ocorre porque a tecnologia de rede virtual Linux realiza o encaminhamento de dados entre interfaces virtuais, copiando dados no kernel, ou seja: os pacotes de dados no buffer de envio da interface de envio serão copiados diretamente para o buffer de recebimento da interface de recebimento sem passar Equipamento externo de rede física é trocado.

Quando o Docker Daemon é iniciado, uma ponte Linux chamada docker0 será criada no host e os contêineres Docker iniciados neste host serão conectados a esta ponte virtual. O Docker Daemon atribuirá um IP da sub-rede docker0 (uma rede L2 virtual) ao Container para uso e definirá o endereço IP de docker0 como o gateway padrão do Container. Ao mesmo tempo, crie um par de dispositivos de cabo de rede virtual de par veth no host. O Docker Daemon insere uma extremidade do dispositivo de par de veth no contêiner recém-criado e denomina-o de eth0 (a placa de rede do contêiner) e insere a outra extremidade no docker0 Linux Bridge em formato vethxxx nome.

Os contêineres nesta rede podem se comunicar entre si.Se o mundo externo quiser acessar os contêineres nesta rede, eles também precisam acessar a rede de ponte e implementar regras DNAT através de iptables para obter a conversão de endereços internos e externos.

$ ip a
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever

$ docker run -itd --name box1 busybox

$ docker exec -it box1 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever

/ # ip r
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2

$ brctl show
bridge name	bridge id		STP enabled	interfaces
docker0		8000.024246c300eb	no		vethd4ae072

modo host

Se o modo de host for usado ao iniciar o container, o container não obterá um namespace de rede independente, mas compartilhará um namespace de rede com o host. Em outras palavras, o Container não virtualizará sua própria placa de rede, configurará seu próprio IP, etc., mas usará diretamente o IP e a porta do host.

Claro, outros aspectos do Container, como o sistema de arquivos, lista de processos, etc., ainda estão isolados do host. Os contêineres que usam apenas este tipo de rede usarão a rede do host. Esse tipo de rede é totalmente aberta ao mundo externo. Se você puder acessar o host, poderá acessar o contêiner.

$ docker run -itd --network host --name box2 busybox

$ docker exec -it box2 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:94:84:10 brd ff:ff:ff:ff:ff:ff
    inet 172.18.22.204/24 brd 172.18.22.255 scope global dynamic eth0
       valid_lft 48054sec preferred_lft 48054sec
    inet6 fe80::f816:3eff:fe94:8410/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever
7: vethd4ae072@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master docker0
    link/ether ce:95:19:64:d0:d4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::cc95:19ff:fe64:d0d4/64 scope link
       valid_lft forever preferred_lft forever

modo macvlan

Para algumas aplicações, como a necessidade de monitorar o tráfego da rede e esperar conectar-se diretamente à rede física, neste caso, você pode usar o modo de rede macvlan. O driver macvlan não apenas atribui o endereço IP ao contêiner, mas também atribui o endereço MAC físico ao recipiente. Por meio do macvlan, a comunicação antes do contêiner de host cruzado também pode ser realizada.

1. Crie uma rede macvlan:

docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=eth0 macvlan1

2. Defina a placa de rede para o modo promíscuo:

ip link set eth0 promisc on

3. Crie um contêiner usando a rede macvlan:

docker run -it --network macvlan1  --ip=172.16.86.2 busybox /bash

Modo container

O modo de contêiner, também conhecido como links Docker, é um mecanismo de comunicação entre contêineres Docker. Se um novo container estiver vinculado a um container existente, o novo container obterá as informações de link do container existente por meio de variáveis ​​de ambiente. A comunicação entre contêineres é realizada fornecendo informações de link sobre contêineres existentes para contêineres confiáveis.

O modo de contêiner é semelhante ao modo de host, exceto que o contêiner criado no modo de contêiner compartilha o IP e a porta de outros contêineres em vez da máquina física. Nesse modo, o próprio contêiner não configura a rede e a porta. Depois de criar este modo, você o encontrará dentro dele. O IP é o IP do contêiner que você especificou e a porta também é compartilhada. Claro, outros são isolados uns dos outros, como processos.

docker run -it --network container:<container ID>

modo nenhum

No modo nenhum, o contêiner terá seu próprio espaço de nomes de rede, mas não realiza nenhuma configuração de rede para o contêiner. Em outras palavras, este Container não terá informações como placa de rede, IP, roteamento, etc. Você precisa adicionar placas de rede manualmente e configurar o IP para o contêiner. Os contêineres que usam este tipo de rede ficarão completamente isolados.

Após usar o modo nenhum, o contêiner é fechado e não participa da comunicação da rede, para que a segurança do contêiner seja garantida.

$ docker run -itd --network none --name box3 busybox

$ docker exec -it box3 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

Modo de sobreposição

O modo de sobreposição é usado em clusters Swarm para conectar contêineres Docker de host cruzado, permitindo que contêineres em hosts diferentes se comuniquem uns com os outros. O modo de sobreposição adiciona uma camada de rede virtual entre os nós do cluster Docker. Ele tem um segmento de rede virtual independente. Portanto, o conteúdo enviado pelo contêiner será enviado primeiro para a sub-rede virtual e, em seguida, a sub-rede virtual será empacotada como o URL real do host para entrega. .

# 初始化 manager node。
$ docker swarm init

# 添加 worker node 到 manager。
$ docker swarm join --token <token> <manager_host>:2377

# 新建一个 Overlay 网络
$ docker network create --driver=overlay --attachable overlay

# 分别在不同的 worker node 上启动一个 busybox 容器，并连接到 Overlay 网络
$ docker run -it --network overlay --name box4 sh

Dessa forma, os contêineres de host cruzado na mesma rede de sobreposição podem se comunicar uns com os outros.

Com base no Swarm, também podemos gerenciar serviços de cluster de contêineres. Por exemplo, crie um cluster Nginx com cinco cópias conectadas à rede Overlay e a porta exposta é 80:

$ docker service create --name my-nginx --publish target=80,published=80 --replicas=5 --network overlay nginx

Neste cluster Nginx, se algum nó terminar uma cópia, o serviço de cluster reiniciará uma nova cópia para manter o número de cópias Nginx em todos os nós de trabalho para cinco.

Mapeamento de porta de contêiner

Opções principais:

• -p Porta do host: Mapeia a porta de escuta do aplicativo no contêiner para uma porta específica no host físico.

Exemplo:

• Mapeamento personalizado:

docker run -d -p 8888:80  nginx:latest 

• Mapeamento aleatório

# 需要镜像支持
docker run -P