Em nossa série anterior de posts, Implantação de serviços de aplicativos no Kubernetes, discutimos um padrão que observamos em muitos clientes durante suas jornadas de transformação digital. A maioria dessas jornadas começa com o modelo tradicional de criação e implantação de aplicativos (geralmente monolíticos), no qual a responsabilidade por essas duas funções é dividida entre equipes isoladas de Desenvolvimento e Operações. À medida que as organizações adotam um modelo mais moderno, elas criam aplicativos baseados em microsserviços e os implantam usando práticas de DevOps, que tornam menos nítida a divisão entre os silos tradicionais.
Embora as equipes de DevOps e os responsáveis pelos aplicativos estejam assumindo um controle mais direto sobre como seus aplicativos são implantados, gerenciados e disponibilizados, muitas vezes não é viável eliminar de uma só vez as barreiras entre os silos — e tampouco consideramos isso necessário. Em vez disso, observamos que ainda se aplica uma divisão lógica de responsabilidades:
- As equipes de rede e segurança continuam concentradas na segurança, no desempenho e na disponibilidade gerais da infraestrutura corporativa. Sua principal preocupação são os serviços globais, que geralmente são implantados na “porta de entrada” dessa infraestrutura. Essas equipes utilizam o F5 BIG-IP para casos de uso como balanceamento de carga global de servidores (GSLB), resolução e balanceamento de carga de DNS, além de gerenciamento sofisticado de tráfego. O BIG‑IQ e o NGINX Controller [agora F5 NGINX Management Suite] fornecem métricas e alertas no formato mais adequado às equipes de NetOps e, para as equipes de SecOps, oferecem a visibilidade e o controle sobre a segurança de que elas precisam para proteger os ativos da organização e cumprir as regulamentações do setor.
- As equipes de operações (DevOps com ênfase em Ops) criam e gerenciam aplicações individuais conforme as necessidades das respectivas linhas de negócios. Elas se concentram principalmente em serviços como automação e pipelines de CI/CD, que ajudam a implementar atualizações de recursos com mais rapidez; esses serviços geralmente são implantados mais “próximos” da aplicação, por exemplo, dentro de um ambiente Kubernetes. Essas equipes utilizam produtos NGINX como NGINX Plus, NGINX App Protect, NGINX Ingress Controller e NGINX Service Mesh para balanceamento de carga e gerenciamento de tráfego de aplicações distribuídas baseadas em microsserviços e hospedadas em vários ambientes, incluindo clusters Kubernetes. Os casos de uso incluem terminação TLS, roteamento baseado em host, reescrita de URI, autenticação JWT, persistência de sessão, limitação de taxa, verificação de integridade, segurança (com o NGINX App Protect como WAF integrado) e muito mais.
NetOps e DevOps em ambientes Kubernetes
As diferentes preocupações das equipes de NetOps e DevOps se refletem nas funções que desempenham em ambientes Kubernetes e nas ferramentas que utilizam para cumpri-las. Correndo o risco de simplificar demais, podemos dizer que as equipes de NetOps se preocupam principalmente com a infraestrutura e as funcionalidades de rede fora do cluster Kubernetes, enquanto as equipes de DevOps se concentram nessas funcionalidades dentro do cluster.
Para direcionar o tráfego para os clusters do Kubernetes, as equipes de NetOps podem usar o BIG‑IP como um balanceador de carga externo compatível com os recursos e a variedade de tecnologias de rede de sobreposição com os quais já estão familiarizadas. No entanto, por si só, o BIG‑IP não consegue acompanhar as alterações no conjunto de pods dentro do cluster do Kubernetes (por exemplo, alterações no número de pods ou em seus endereços IP). Para contornar essa limitação, F5 Container Ingress Services (CIS) é implantado como um operador dentro do cluster. O CIS monitora as alterações no conjunto de pods e modifica automaticamente os endereços no pool de balanceamento de carga do sistema BIG‑IP conforme necessário. Ele também detecta a criação de novos recursos Ingress, Route e personalizados e atualiza a configuração do BIG‑IP de acordo.
Embora seja possível usar a combinação do BIG‑IP com o CIS para balancear a carga do tráfego diretamente para os pods de aplicativos, na prática, o NGINX Ingress Controller é a solução ideal para detectar e acompanhar alterações dinâmicas nos pods e nas cargas de trabalho dos aplicativos que representam um grande número de serviços — por exemplo, durante o dimensionamento horizontal dos pods de aplicativos para atender a diferentes níveis de demanda.
Outra vantagem da implantação do NGINX Ingress Controller é que ela transfere o controle do balanceamento de carga das aplicações para as equipes de DevOps responsáveis pelas próprias aplicações. Seu plano de controle de alto desempenho e seu design centrado em DevOps o tornam especialmente eficaz no suporte a casos de uso de DevOps que mudam rapidamente, como reconfigurações no local e atualizações graduais, em serviços do Kubernetes distribuídos por vários namespaces. O NGINX Ingress Controller usa a API nativa do Kubernetes para detectar os pods à medida que são escalados.
Como o BIG-IP e o NGINX Ingress Controller trabalham juntos
Como você deve saber, o BIG‑IP e o NGINX Ingress Controller foram originalmente desenvolvidos por duas empresas distintas (F5 e NGINX, respectivamente). Desde que a F5 adquiriu a NGINX, os clientes têm nos dito que melhorar a interoperabilidade entre as duas ferramentas simplificaria o gerenciamento de sua infraestrutura. Em resposta, desenvolvemos um novo recurso do Kubernetes chamado IngressLink.
O recurso IngressLink é um aprimoramento simples que usa uma CustomResourceDefinition (CRD) do Kubernetes para “vincular” o NGINX Ingress Controller ao BIG‑IP. Em termos simples, ele permite que o CIS “informe” ao BIG‑IP sempre que o conjunto de pods do NGINX Ingress Controller for alterado. Com essas informações, o BIG‑IP pode ajustar rapidamente as políticas de balanceamento de carga correspondentes.
Com o BIG‑IP implantado para realizar o balanceamento de carga nos clusters do Kubernetes e o NGINX Ingress Controller gerenciando o tráfego de entrada e saída, o fluxo de tráfego é o seguinte:
- O BIG‑IP direciona o tráfego externo para as instâncias do NGINX Ingress Controller.
- O NGINX Ingress Controller distribui o tráfego para os serviços apropriados dentro do cluster.
- Como o NGINX Ingress Controller é excepcionalmente eficiente, um conjunto estável de instâncias pode lidar com alterações frequentes e significativas no conjunto de pods da aplicação. No entanto, quando o NGINX Ingress Controller precisa aumentar ou reduzir a escala horizontalmente (para lidar com picos e quedas de tráfego), o CIS informa o BIG‑IP sobre as alterações (por meio do recurso IngressLink), permitindo que o BIG‑IP se adapte rapidamente a elas.
Primeiros passos
Para obter mais detalhes sobre como o recurso IngressLink funciona, incluindo um guia de implantação, acesse a F5 CloudDocs.
Comece solicitando sua avaliação gratuita de 30 dias do NGINX Ingress Controller com NGINX App Protect WAF e DoS. Se você ainda não usa o BIG‑IP, selecione a avaliação no F5.com mais adequada para sua equipe.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.