Contêineres. Eles não são uma moda passageira nem apenas uma fase. Na verdade, sua taxa de adoção é bastante acelerada em comparação com a de sua antecessora, a virtualização. Em menos de dois anos, já estamos observando o interesse na implantação de serviços de aplicativos em contêineres, o que geralmente indica que já existem aplicativos em produção que precisam de escalabilidade, segurança e velocidade para atender às altas expectativas atuais em relação à experiência com aplicativos.
Curiosamente, os contêineres estão amadurecendo junto com seus frameworks de gerenciamento e orquestração. Isso não aconteceu com a virtualização, mas, por outro lado, ela surgiu antes da nuvem, que impulsionou outras tecnologias ágeis a adotar as APIs e os modelos que permitiram aplicar à infraestrutura virtual a automação e a orquestração da nuvem. Hoje, tanto os contêineres quanto a virtualização (que poderiam ser considerados tecnologias irmãs) geralmente são implantados com um framework de orquestração que coordena o provisionamento, o dimensionamento e até mesmo o roteamento do tráfego de e para outros aplicativos e serviços (tráfego leste-oeste).
Embora, dentro dos limites dos domínios dessas estruturas, esses mecanismos funcionem muito bem para oferecer escalabilidade e roteamento localizados, a realidade é que esses aplicativos e serviços fazem parte de um contexto mais amplo, que inclui um “aplicativo” mais abrangente e exige interação com os usuários (tráfego norte-sul). Uma pesquisa realizada pela Portworx no final de 2016 constatou que a segunda carga de trabalho mais popular prevista para conteinerização eram os “front-ends da Web”, citados por 48% dos entrevistados.
Isso praticamente garante a existência de um serviço upstream (ou dispositivo, se preferir) que oferece escalabilidade, segurança e velocidade entre os usuários e o “aplicativo” composto por serviços implantados em um ambiente conteinerizado.
Invariavelmente, isso significa que deve haver coordenação entre a plataforma de orquestração de contêineres e esse dispositivo/serviço upstream.
Conheça os F5 Container Connectors. Quando anunciamos os Container Connectors pela primeira vez, estávamos dando os retoques finais no suporte ao Mesos. Hoje, temos o prazer de lançar também o suporte ao Kubernetes.
F5 Container Connector
O F5 Container Connector fornece a integração necessária para cobrir o último trecho interno entre o ponto em que o tráfego norte-sul se transforma em tráfego leste-oeste. É nesse ponto que o BIG-IP upstream (em relação à posição do Kubernetes) encaminha as solicitações ao proxy local apropriado (que pode ser o nosso próprio Application Services Proxy ou, no caso do Kubernetes, Kube-Proxy, por exemplo) ou ao pod para processamento.
Em seguida, ele aguarda uma resposta, executa as tarefas que lhe foram atribuídas, como a limpeza de dados (para evitar vazamentos de dados) e a otimização de imagens (para melhorar o desempenho), e envia a resposta de volta ao usuário.
O principal componente é o Container Connector, que reside em um cluster do Kubernetes e se inscreve em eventos como os demais componentes. Ao detectar um evento relevante, ele configura dinamicamente ou modifica uma configuração existente no sistema upstream (BIG-IP), incluindo os detalhes apropriados. Isso pode significar aumentar a escala adicionando novos membros a um cluster/pool ou reduzi-la, removendo-os novamente.
O aspecto mais importante é que tudo é integrado e ocorre de forma automática, o que garante a aplicação consistente de políticas de segurança no tráfego de entrada e saída norte-sul, sem aumentar a complexidade do ambiente conteinerizado. Isso também incentiva o uso de SSL/TLS para proteger o tráfego de aplicativos (e APIs) com os usuários, oferecendo um ponto único para gerenciar e manter certificados. Além disso, mantém o ambiente conteinerizado livre de complexidade operacional adicional, uma reclamação comum quando contêineres e as arquiteturas de aplicativos associadas a eles são introduzidos.
O que os F5 Container Connectors oferecem é a capacidade de provisionar e gerenciar automaticamente os serviços de aplicação necessários para aplicações em contêineres em um ambiente de produção, sem exigir grandes reformulações no ambiente que já existia nas etapas de desenvolvimento e teste (você testou, certo?). Isso viabiliza implantações sem atrito e preserva a portabilidade, tão importante para as aplicações em contêineres atuais.
A F5 tem o compromisso de garantir que os serviços de entrega e segurança necessários aos aplicativos estejam disponíveis em todos os tipos de ambiente, sejam contêineres ou máquinas virtuais, em qualquer nuvem ou em um ambiente tradicional. Também temos o compromisso de tornar o provisionamento e o gerenciamento desses serviços o mais simples e descomplicado possível, o que significa oferecer soluções compatíveis com todos os tipos de arquitetura.
Para oferecer suporte às cadeias de ferramentas de DevOps, disponibilizamos gratuitamente os Container Connectors e nossa versão do kube-proxy em https://hub.docker.com/r/f5networks/e uma versão de código aberto do nosso controlador do Kubernetes pode ser obtida em nosso repositório Git em https://github.com/F5Networks/k8s-bigip-ctlr
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...