No início de 2018, eu me via repetidamente tendo conversas semelhantes com amigos e colegas especialistas em redes e nos padrões emergentes de 5G — todos sentíamos um vago desconforto por estarmos avançando às pressas rumo a uma transição repleta de incógnitas. Todos entendíamos que o 5G impulsionaria uma migração para contêineres e uma arquitetura nativa da nuvem, mas também sabíamos que o Kubernetes e outras ferramentas nativas da nuvem haviam sido originalmente criados para um conjunto de casos de uso totalmente diferente. O que todos percebíamos (e que provavelmente muitos dos leitores deste post também observaram) era que o nosso setor estava em rota de colisão com uma grande dor de cabeça.
Desde aqueles dias de apreensão, os provedores de serviços de comunicação (CSPs) começaram o trabalho efetivo de migração para uma infraestrutura nativa da nuvem. Os pioneiros nessas implantações estão, de fato, descobrindo obstáculos inesperados em áreas críticas da rede do Kubernetes que, conforme originalmente projetadas, não conseguem atender às demandas dos casos de uso dos provedores de serviços. Seja o objetivo da operadora avançar para uma implantação de núcleo 5G autônomo (SA) ou participar de uma iniciativa de modernização com uma arquitetura de nuvem distribuída, adaptar o Kubernetes para oferecer suporte à interoperabilidade de rede, à escalabilidade de nível de operadora e às políticas de segurança de operadora é essencial em toda a infraestrutura nativa da nuvem.
Como o Kubernetes evoluiu desde então com foco principalmente em casos de uso de web e TI executados em nuvens públicas ou ambientes empresariais, é compreensível que o conjunto específico de requisitos e protocolos necessários para implantar casos de uso de provedores de serviços nunca tenha sido previsto. Felizmente, porém, os arquitetos do Kubernetes implementaram um conjunto sólido de padrões de projeto que torna o Kubernetes extensível, abrindo caminho para casos de uso essenciais de telecomunicações, como gerenciamento, visibilidade e controle do tráfego de rede, além de suporte ampliado a protocolos como HTTP/2, GTP, SIP e Diameter.
Antes de descrever quais melhorias são necessárias para adequar o Kubernetes aos atuais casos de uso dos provedores de serviços, vamos primeiro identificar os requisitos específicos de uma rede de provedor de serviços.
O Kubernetes deve se integrar a um ecossistema mais amplo
Em primeiro lugar, um cluster Kubernetes precisa se integrar à rede e às operações mais amplas do provedor de serviços. As decisões arquiteturais podem ter consequências de longo prazo, como o aumento dos custos e da complexidade operacional. Os arquitetos de rede devem levar em conta diversos casos de uso de telecomunicações, o suporte a protocolos legados e como as mudanças dinâmicas no Kubernetes podem afetar a topologia de rede existente, o que pode aumentar ainda mais a complexidade.
Em segundo lugar, as cargas de trabalho de telecomunicações (funções de rede) são diferentes das cargas de trabalho de TI. As redes das operadoras e suas funções de rede utilizam mais do que apenas os protocolos padrão HTTP/HTTPS ou TCP. Será fundamental que as operadoras móveis tenham suporte de rede tanto para protocolos legados de 3G/4G, como SIP, GTP, SCTP etc., quanto para HTTP/2 no 5G. Em comparação com as cargas de trabalho de TI, as cargas de trabalho de telecomunicações também contam com uma camada adicional de padrões sobre as camadas de rede tradicionais.
Por fim, mas certamente não menos importante, a segurança é fundamental para todos os novos pontos de exposição, que exigem novas funções de automação, visibilidade e gerenciamento. A segurança deve ser implementada em todas as camadas e funcionar em conjunto com os novos clusters ao introduzir novas tecnologias. As equipes de SecOps dos provedores de serviços estão sempre buscando maneiras de reduzir a superfície de ataque e manter um controle de segurança consistente. Além disso, as políticas de segurança mais abrangentes da rede precisam ser atualizadas e adaptáveis ao longo do tempo.
Duas abordagens atuais para lidar com essas lacunas funcionais
Contornar os padrões do Kubernetes
Contornar os padrões nativos da nuvem é um indício de que os arquitetos são obrigados a criar soluções improvisadas, pois o Kubernetes não oferece nativamente as ferramentas necessárias para lidar com cargas de trabalho de telecomunicações. Observamos várias maneiras preocupantes pelas quais as operadoras de telecomunicações estão desrespeitando esses padrões:
- Contornando a rede do Kubernetes – A grande maioria das CNFs está colocando uma ou mais interfaces fora do controle do Kubernetes. Essas CNFs exigem acesso direto à rede (muitas vezes solicitado como “multus”, para permitir uma interface adicional com conexão direta ao ambiente externo). Sem um ponto central de controle da rede, isso expõe a complexidade interna do Kubernetes à rede externa da operadora, o que resultará em maior complexidade e custo operacional, além de ampliar a superfície de ataque. Isso também exige mais dos desenvolvedores de aplicativos/funções de rede e dos operadores de rede para gerenciar endereços IP e lidar com a natureza dinâmica dos contêineres no Kubernetes, que agora fica exposta ao mundo externo.
- Clusters separados para cada função de rede – A rede do Kubernetes não oferece nativamente um ponto central para o tráfego de entrada e saída da rede. O Kubernetes oferece algum controle de entrada, mas ignora quase totalmente o tráfego de saída, e não há uma forma integrada de vincular as redes de entrada e saída. Vimos várias implantações em que cada função de rede é executada em seu próprio cluster, permitindo correlacionar os endereços IP dos servidores com os endereços IP das funções de rede. Isso gera uma sobrecarga adicional de recursos e aumenta os gastos de CapEx, além de elevar a complexidade operacional, resultando em maiores gastos de OpEx.
Alinhe-se aos padrões do Kubernetes
Uma abordagem alternativa é seguir os padrões de design do Kubernetes e introduzir um proxy de serviços que forneça uma “visão unificada” da rede de entrada/saída e da segurança do cluster Kubernetes em relação ao mundo externo. O objetivo de um proxy de serviços é preencher as lacunas funcionais apresentadas pelo Kubernetes quando usado em um ambiente de provedor de serviços. Um proxy de serviços deve:
- Usar padrões nativos do Kubernetes para ampliar os recursos de rede do Kubernetes (Definições de Recursos Personalizados, loop de controle do K8s)
- Integração com a rede mais ampla (roteamento BGP, atribuições de endereços IP SNAT de saída, tradução IPv4/v6)
- Vincular a entrada e a saída individualmente para cada CNF
- Ofereça amplo suporte a L4/L7 (tcp, udp, sctp, NGAP, HTTP/2, Diameter, GTP, SIP)
- Fornecer uma camada de segurança (terminação TLS, firewall, proteção contra DDoS, firewall de aplicações web)
- Apresentar uma CNF consistente, ocultando eventos altamente dinâmicos do Kubernetes
A abordagem da F5 — Apresentando o proxy de serviço
A F5 escolheu o segundo cenário descrito acima para ampliar o Kubernetes e criar esse proxy de serviço, fornecendo a funcionalidade que faltava. Com base em nossas décadas de experiência em gerenciamento e segurança de tráfego, acreditamos que essa seja uma função essencial para viabilizar a migração em larga escala para ambientes nativos da nuvem. Pronto para produção e já disponível, desenvolvemos o BIG-IP Next Service Proxy for Kubernetes (SPK), um produto de infraestrutura nativa da nuvem que aborda diretamente as limitações do Kubernetes e permite que os provedores de serviços criem recursos que não existem no Kubernetes “padrão”. O SPK simplifica e protege a arquitetura por meio de uma estrutura que automatiza processos e se integra perfeitamente a políticas mais amplas de rede e segurança. Essa abordagem ao Kubernetes para empresas de telecomunicações continuará reduzindo a complexidade e os custos operacionais, além de proporcionar uma infraestrutura mais resiliente e segura. Como atualmente estamos observando uma desaceleração na transição para o 5G SA (Operadoras de telecomunicações não conseguem implementar o 5G SA, segundo a GlobalData), é razoável supor que essa transição perderá ainda mais força sem a introdução de um proxy de serviço adequado. Clientes do setor de telecomunicações com ambientes em produção e em meio a uma modernização digital de grande escala estão constatando que o SPK está se mostrando a solução Kubernetes para um problema da arquitetura de rede 5G que eles nem sequer sabiam que tinham.
O SPK da F5 já está disponível para o público em geral (GA) e atualmente está em produção em operadoras de telecomunicações de grande porte. Fique de olho nos próximos eventos, nos quais demonstraremos os recursos do SPK em comparação com outras abordagens e explicaremos como certificar CNFs em nossa plataforma. Para mais informações, acesse esta página e, se quiser falar diretamente com um membro da equipe da F5, entre em contato conosco.
Sobre o autor
Publicaçõ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...