Há tanta confusão quanto caos no universo dos contêineres. A cada dia, parece surgir um novo recurso ou componente no mundo dos ambientes de orquestração de contêineres. Isso é necessário, pois esse ecossistema ainda está amadurecendo à medida que o uso de contêineres deixa de ser experimental e passa a ser essencial.
Velocidade e escala estão entre os dois principais fatores que impulsionam as implantações de contêineres. A primeira diz respeito tanto ao desenvolvimento quanto à entrega, daí o foco na escala. Mas não apenas na escala básica de protocolos; estamos falando de escala de aplicações .
A distinção é importante. Os contêineres foram considerados os candidatos mais prováveis a abrigar microsserviços, e uma das regras fundamentais dos microsserviços é que a comunicação ocorra exclusivamente por meio de APIs. Uma API baseada em HTTP — e não em TCP — exige, portanto, uma solução mais inteligente para escalabilidade.
A maioria dos ambientes de orquestração de contêineres já vem com proxies capazes de oferecer escalabilidade básica. Isso significa balanceamento de carga convencional (POLB) na camada TCP. Endereços IP e portas são a língua franca desses proxies. Embora funcionem bem em um ambiente no qual os serviços são diferenciados com base em uma combinação de endereço IP e porta, eles não se saem tão bem com aplicações (serviços) diferenciadas por características da camada HTTP, como versão da API, URI ou nome do host. Esses são elementos da camada de aplicação (HTTP) e exigem proxies mais inteligentes para realizar o roteamento e o dimensionamento na velocidade desejada. Esses elementos precisam ser considerados assim que uma solicitação é recebida de uma entidade do lado do cliente, algo que a maioria das soluções básicas de escalabilidade para contêineres não consegue oferecer.
Em resposta a essa necessidade, surge o conceito de controle de Ingress*. O controle de Ingress consiste basicamente no roteamento de aplicações ou HTTP ou na comutação de camada 7, comutação de conteúdo ou qualquer uma das cerca de uma dúzia de denominações que esse recurso recebeu desde a virada do século. O controle de Ingress pressupõe a diferenciação de serviços na camada de aplicação (HTTP) e age de acordo com ela ao tomar decisões de roteamento e escalabilidade dentro do ambiente de contêineres.
Mas não basta simplesmente colocar um F5 BIG-IP na frente de um ambiente de contêineres e chamá-lo de controle de Ingress. Isso porque um controlador de Ingress também precisa estar integrado ao ambiente de orquestração de contêineres para alcançar a escala e a velocidade desejadas. Para isso, é necessário algo que opere dentro do ambiente de contêineres e seja nativamente compatível com a orquestração de contêineres e o BIG-IP.
É isso que o Controlador BIG-IP para Kubernetes faz. Ele é um contêiner Docker executado em um Pod do Kubernetes e permite usar um BIG-IP como controlador de Ingress 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 estruturas da camada de aplicação desejadas.
Antes da disponibilização desse controlador, era comum usar o BIG-IP para “distribuir” 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 Ingress. Há alguns bons motivos para deixar de fazer isso, incluindo a dor de cabeça recursiva de executar seu serviço de disponibilidade dentro daquilo cuja disponibilidade ele deve garantir.
Outros bons motivos incluem:
- Habilitar a mitigação de DDoS
- Use um firewall de aplicações web para proteger APIs e aplicativos
- Ofereça suporte a clientes IPv6 para que usem aplicativos em contêineres IPv4
- Descarregue o TLS no BIG-IP e criptografe novamente com certificados autoassinados
- Use opções de aceleração de aplicativos para melhorar o desempenho
Seja qual for o motivo, a realidade é que você pode usar um BIG-IP como controlador de Ingress para Kubernetes. Não é necessário ter duas camadas diferentes para escalar. Eliminar essa segunda camada de escalabilidade aumentará a velocidade (de entrega e implantação) e simplificará as implantações, além de fornecer uma plataforma na qual você pode habilitar uma ampla variedade de serviços avançados de segurança, velocidade e escalabilidade.
Você pode saber mais sobre o BIG-IP Controller for Kubernetes aqui, obtê-lo no Docker Hub aqui ou simplesmente baixá-lo diretamente:
docker pull f5networks/k8s-bigip-ctlr
Continue escalando.
* Sim, o “I” maiúsculo é importante, pois diferencia o termo tradicional de redes “ingress”, que se refere simplesmente ao “acesso ao ambiente”, de “Ingress”, usado para se referir ao “roteamento HTTP”. Sim, temos a tendência de tornar as coisas mais difíceis do que precisam ser, mas esse é o mundo em que os desenvolvedores estão implementando estruturas de rede e redefinindo muito mais do que apenas a forma como os aplicativos são entregues.
Sobre o autor
Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog
Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...