O livro “Mastering Kubernetes. Orquestração de arquiteturas de contêiner "

Oi, habrozhiteli! Publicamos recentemente um livro sobre o Kubernetes versão 1.10. O post revisou a passagem "Soluções de Rede para Kubernetes"

Networking é um tópico extenso. Existem várias maneiras de configurar uma rede com dispositivos, lareiras e contêineres. O Kubernetes não o limita a isso. Tudo o que esta plataforma prescreve é ​​um modelo de rede de alto nível com um espaço de endereço plano para lareiras. Nesse espaço, você pode implementar muitas boas soluções com diferentes recursos e para diferentes ambientes. Nesta seção, examinaremos alguns deles e tentaremos entender como eles se encaixam no modelo de rede Kubernetes.

Criando pontes em clusters de hardware

O ambiente mais simples é um cluster bare metal, que é uma rede física regular no nível L2. Para conectar contêineres a essa rede, você pode usar a ponte padrão do Linux. Esse é um procedimento minucioso que requer experiência com comandos de rede Linux de baixo nível, como brctl, endereço IP, rota IP, link IP, nsenter etc. Você pode começar a implementar essa solução lendo o seguinte guia: blog.oddbit.com/
11/08/2014 / quatro maneiras de conectar-se a um docker / (procure a seção Com dispositivos Linux Bridge).

Contiv

O Contiv é um complemento de rede de uso geral. Ele foi projetado para conectar contêineres via CNI e pode ser usado com Docker (diretamente), Mesos, Docker Swarm e, naturalmente, Kubernetes. O Contiv lida com políticas de rede e duplica parcialmente um objeto semelhante no Kubernetes. A seguir, estão alguns dos recursos desse complemento de rede:

• suporte para CNM na libnetwork e a especificação CNI;
• Um mecanismo de política rico em recursos que fornece segurança e implantação previsível de aplicativos.
• o melhor desempenho de contêineres da categoria;
• sub-redes de multilocação, isolamento e sobreposição;
• Integração IPAM e descoberta de serviços;
• ampla seleção de topologias físicas:
  
  a) protocolos da camada 2 (VLAN);
  b) protocolos da camada 3 (BGP);
  c) redes de sobreposição;
  d) Cisco SDN (ACI);
• Suporte IPv6;
• política escalável e alocação de rotas;
• Integração com modelos de aplicativos, incluindo o seguinte:
  
  a) Docker-compor;
  b) gerente de implantação do Kubernetes;
  c) balanceamento de carga nos serviços, integrado ao balanceador de microsserviços do tipo "leste-oeste" (leste-oeste);
  d) isolamento do tráfego durante o armazenamento, controle de acesso (por exemplo, etcd / consul), transmissão e gerenciamento de rede.

O Contiv possui muitos recursos. Essa ferramenta implementa uma ampla gama de tarefas e suporta várias plataformas, portanto, não tenho certeza se será a melhor opção para o Kubernetes.

Abrir vswitch

O Open vSwitch é uma solução madura de switch virtual (software) suportada por muitos dos principais players do mercado. O sistema Open Virtualization Network (OVN) permite criar várias topologias de rede virtual. Ela tem um complemento especial para o Kubernetes, mas é muito difícil de configurar (consulte o manual github.com/openvswitch/ovn-kubernetes ). O complemento Linen CNI possui menos recursos, mas sua configuração é muito mais fácil: github.com/John-Lin/linen-cni . A estrutura Linen CNI é mostrada na Fig. 10.6


O vSwitch aberto pode integrar servidores físicos, VMs e pods / contêineres em uma única rede lógica. Este sistema suporta os modos overlay e físico.

Aqui estão algumas de suas principais características:

• VLAN 802.1Q padrão com tronco e portas públicas
• Ligação de NIC com ou sem LACP para um comutador de nível superior
• NetFlow, sFlow® e espelhamento para maior visibilidade;
• Configuração de QoS (Qualidade de Serviço) mais políticas;
• tunelamento através de Geneve, GRE, VXLAN, STT e LISP;
• controle de interrupção no 802.1ag;
• OpenFlow 1.0, além de vários complementos;
• banco de dados transacional para armazenar configuração com ligações para C e Python;
• redirecionamento de alto desempenho usando módulos do kernel Linux.

Nuage Networks VCS

O Virtualized Cloud Services (VCS) é um produto da Nuage, uma plataforma baseada em políticas bem escalonável para a construção de redes definidas por software (Networking Definido por Software, SDN). Esta é uma solução de nível corporativo, baseada no sistema aberto Open vSwitch (para redirecionamento de dados) e em um controlador SDN multifuncional baseado em padrões abertos.

A plataforma Nuage combina pods Kubernetes e ambientes de terceiros (virtual e hardware) em redes de sobreposição transparentes e permite descrever políticas detalhadas para diferentes aplicativos. Seu mecanismo de análise em tempo real permite monitorar a visibilidade e a segurança dos aplicativos Kubernetes.

Além disso, todos os componentes do VCS podem ser instalados como contêineres. Não há requisitos de hardware específicos.

Canal

Canal é uma mistura de dois projetos de código aberto: Calico e Flannel. Daí o nome. O projeto Flannel, desenvolvido pela equipe do CoreOS, lida com os recursos de rede dos contêineres, enquanto o Calico é responsável pelas políticas de rede. Inicialmente, eles foram desenvolvidos separadamente, mas os usuários queriam usá-los juntos. O projeto de código aberto do Canal agora é um modelo de implantação para instalar o Calico e o Flannel como complementos separados da CNI. Criada pelos fundadores da Calico, a Tigera deu suporte a ambos os projetos e até planejou uma integração mais estreita, mas desde o lançamento de sua própria solução para rede segura entre aplicativos no Kubernetes, a prioridade mudou para simplificar a configuração e a integração do Flannel e do Calico em vez de desenvolver uma solução unificada. Na fig. 10.7 mostra o status atual do sistema do Canal e como ele se relaciona com plataformas de orquestração como Kubernetes e Mesos.


Observe que, ao integrar-se ao Kubernetes, o Canal não acessa o etcd diretamente, mas o servidor da API do Kubernetes.

Flanela

Flannel é uma rede virtual que fornece a cada nó uma rede virtual para trabalhar com tempos de execução de contêiner. Em cada nó, o agente de flanela é iniciado, aumentando a sub-rede com base no espaço de endereço reservado armazenado no cluster etcd. Troca de pacotes entre contêineres e, em geral, o nó é feito por um dos vários servidores. Na maioria das vezes, o servidor usa UDP sobre o dispositivo TUN, que por padrão direciona o tráfego pela porta 8285 (não esqueça de abri-lo no firewall).

Na fig. 10.8 descreve em detalhes os vários componentes da rede Flannel, os dispositivos de rede virtual criados e como eles se comunicam com o host e a lareira por meio da ponte docker0. Aqui você também pode ver o processo de encapsular pacotes UDP e seu movimento entre os nós.


Outras tecnologias de rede são suportadas:

• vxlan - encapsula pacotes usando VXLAN dentro do kernel;
• host-gw - cria rotas IP para sub-redes através dos endereços IP do servidor remoto. Vale ressaltar que isso requer uma conexão direta na segunda camada de rede entre os servidores que executam Flannel;
• aws-vpc - Crie rotas IP na tabela de roteamento do Amazon VPC
• gce - cria rotas IP na rede do Google Compute Engine
• alocar - executa apenas a seleção da sub-rede, mas não o redirecionamento de pacotes;
• ali-vpc - Cria rotas IP na tabela de roteamento do Alicloud VPC.

Projeto Calico

O Calico é uma solução completa para a rede entre contêineres e segurança de rede. Ele pode ser integrado a todas as principais plataformas de orquestração e tempos de execução:

• Kubernetes (complemento para CNI);
• Mesos (complemento para CNI);
• Docker (complemento para libnework);
• OpenStack (complemento para Neutron).

O Calico também pode ser implantado localmente ou em uma nuvem pública, preservando todos os recursos. A aplicação de políticas de rede pode depender da carga, o que fornece um controle de tráfego claro e garante que os pacotes sempre atinjam os destinos desejados. O Calico pode importar automaticamente políticas de rede de plataformas de orquestração. De fato, ele é responsável pela implementação de políticas de rede no Kubernetes.

Romana

Romana é uma solução moderna para a rede entre contêineres. Ele foi originalmente projetado para uso na nuvem e opera na terceira camada de rede, utilizando métodos padrão para gerenciar endereços IP. O Romana permite isolar redes inteiras, criando gateways e rotas para eles usando servidores baseados em Linux. O trabalho na terceira camada de rede não requer encapsulamento. A diretiva de rede é aplicada a todos os terminais e serviços como um firewall distribuído. O Romana facilita implantações locais e híbridas entre diferentes plataformas em nuvem, pois você não precisa mais configurar redes de sobreposição virtual.

Recentemente, apareceu no Romana endereços IP virtuais, permitindo que os usuários locais abram o acesso a seus serviços em redes locais do segundo nível, usando endereços externos e especificações de serviços.

Os desenvolvedores da Romana afirmam que sua abordagem melhora significativamente o desempenho. Na fig. A Figura 10.9 mostra como, juntamente com a prevenção do encapsulamento VXLAN, você pode se livrar de muita sobrecarga.

Rede de tecer

As principais características do projeto Weave Net são a facilidade de uso e a falta de configuração. Ele usa o encapsulamento VXLAN e instala o micro-DNS em cada nó. Como desenvolvedor, você estará lidando com um alto nível de abstração. Depois de nomear seus contêineres, o Weave Net permitirá que você se conecte às portas padrão e habilite os serviços apropriados. Isso ajuda na migração de aplicativos existentes para plataformas de microsserviço e containerização. O Weave Net fornece um complemento da CNI para trabalhar com Kubernetes e Mesos. A partir do Kubernetes 1.4, a integração com o Weave Net pode ser realizada com um único comando que implanta o DaemonSet:

kubectl apply -f https://git.io/weave-kube 

Os pods do Weave Net hospedados em cada nó são responsáveis ​​por conectar outras instâncias do pod à rede do Weave. O Weave Net suporta APIs com políticas de rede, fornecendo uma solução completa e fácil de configurar.

Uso eficaz de políticas de rede

A política de rede do Kubernetes foi projetada para controlar o tráfego direcionado a pods e namespaces específicos. Ao gerenciar centenas de microsserviços implantados (como costuma ser o caso do Kubernetes), a rede entre os lares vem à tona. É importante entender que esse mecanismo está apenas indiretamente relacionado à segurança. Se um invasor conseguir penetrar na rede interna, provavelmente poderá criar sua própria instância da lareira que cumprirá a política de rede e permitirá a comunicação livre com outras lareira. Na seção anterior, vimos várias soluções de rede no Kubernetes, com foco em interfaces de rede. Aqui vamos nos concentrar na política de rede implementada sobre essas soluções, embora ambos os componentes estejam intimamente interconectados.

Arquitetura de diretiva de rede no Kubernetes

A política de rede determina como os subconjuntos de lares podem interagir entre si e com outros pontos de extremidade da rede. O recurso NetworkPolicy usa rótulos para selecionar lareiras e define uma lista de regras de permissão que permitem que o tráfego seja direcionado para instâncias de lareira selecionadas (além do que já é permitido pela política de isolamento no espaço de nome fornecido).

»Mais informações sobre o livro podem ser encontradas no site do editor
» Conteúdo
» Trecho

Cupom de 20% de desconto para Khabrozhitel - Kubernetes

Após o pagamento da versão em papel do livro, uma versão eletrônica do livro é enviada por e-mail.

PS: 7% do custo do livro será destinado à tradução de novos livros de informática; a lista de livros entregues à gráfica está aqui .