Há tanta confusão quanto caos no mundo dos contêineres. Todos os dias parecem trazer algum novo recurso ou componente para o mundo dos ambientes de orquestração de contêineres. Isso é necessário porque ainda está amadurecendo à medida que o uso de contêineres se expande do experimental para o existencial.
Velocidade e escala estão entre os dois principais motivadores das implantações de contêineres. O primeiro tem tanto a ver com desenvolvimento quanto com entrega e, portanto, o foco é na escala. Mas não estamos falando apenas da escala do protocolo vanilla, estamos falando da escala da aplicação .
A distinção é importante. Os contêineres foram eleitos como os mais propensos a conter microsserviços, e uma das regras fundamentais dos microsserviços é a comunicação somente via API. Uma API baseada em HTTP – não TCP – e, portanto, requer uma solução mais inteligente para escala.
A maioria dos ambientes de orquestração de contêineres vem “prontos para uso” com proxies capazes de escalabilidade vanilla. Isso significa balanceamento de carga simples e antigo (POLB) na camada TCP. Endereços IP e portas são a língua franca desses proxies. Embora funcionem bem em um ambiente onde os serviços são diferenciados com base em uma combinação de endereço IP/porta, eles não funcionam tão bem para aplicativos (serviços) que são diferenciados por características da camada HTTP, como versão da API, URI ou nome do host. Essas são construções da camada de aplicativo (HTTP) e exigem proxies mais inteligentes para rotear e dimensionar com a velocidade desejada. Essas construções devem ser levadas em consideração ao receber uma solicitação de uma entidade do lado do cliente, algo que a maioria das soluções de escala padrão para contêineres não consegue fornecer.
Em resposta a essa necessidade surge a noção de controle Ingress*. O controle de entrada é basicamente roteamento de aplicativo ou HTTP ou comutação de camada 7 ou comutação de conteúdo ou qualquer outro dos cerca de uma dúzia de nomes pelos quais o recurso passou desde a virada do século. O controle de entrada pressupõe diferenciação de serviço na camada de aplicação (HTTP) e, consequentemente, atua sobre ela ao tomar decisões de roteamento e dimensionamento dentro do ambiente do contêiner.
Mas você não pode simplesmente colocar um F5 BIG-IP na frente de um ambiente de contêiner e chamá-lo de controle de entrada. Isso ocorre porque um controlador Ingress também precisa ser integrado ao ambiente de orquestração do contêiner para atingir a escala e a velocidade desejadas. Para fazer isso, você precisa de algo que viva dentro do ambiente de contêiner e que fale nativamente orquestração de contêineres e BIG-IP.
É isso que o BIG-IP Controller para Kubernetes faz. É um contêiner Docker que é executado em um Pod do Kubernetes e permite que você use um BIG-IP como um controlador de entrada do Kubernetes. Isso significa que ele pode ler o recurso Ingress do Kubernetes e configurar automaticamente o BIG-IP com os objetos apropriados para garantir que as solicitações sejam dimensionadas com base nas construções da camada de aplicativo desejadas.
Agora, antes da disponibilidade deste controlador, as pessoas tendiam a usar o BIG-IP para "dispersar" o tráfego por uma segunda camada de proxies em execução dentro do ambiente de orquestração de contêineres. Esses proxies forneciam controle de entrada. Há alguns bons motivos para parar de fazer isso, incluindo a dor de cabeça recursiva de executar seu serviço de disponibilidade dentro daquilo para o qual ele está fornecendo disponibilidade.
Outros bons motivos incluem:
Seja qual for o motivo, a realidade é que você pode usar um BIG-IP como um controlador de entrada para o Kubernetes. Você não precisa de dois níveis diferentes para escalar. Eliminar esse segundo nível de escala aumentará a velocidade (de entrega e implantação) e simplificará as implantações, ao mesmo tempo em que fornecerá uma plataforma na qual você poderá habilitar uma ampla variedade de serviços avançados para segurança, velocidade e escala.
Você pode ler mais sobre o BIG-IP Controller para Kubernetes aqui , ou obtê-lo no hub do Docker, aqui ou simplesmente baixá-lo diretamente:
docker puxar f5networks/k8s-bigip-ctlr
Aumentar a escala.
* Sim, o “I” maiúsculo é importante, pois o distingue do termo de rede tradicional “ingress”, que simplesmente se refere ao “acesso ao ambiente”, enquanto “Ingress” é usado para se referir ao “roteamento HTTP”. Sim, tendemos a tornar as coisas mais difíceis do que deveriam ser, mas esse é o mundo em que os desenvolvedores estão implementando construções de rede e redefinindo mais do que apenas como os aplicativos são entregues.