Aprimore a arquitetura de rede 5G da Telco com o Service Proxy para Kubernetes

No início de 2018, continuei tendo conversas semelhantes com meus amigos e colegas que eram especialistas em redes e padrões 5G emergentes. Todos nós tínhamos um vago desconforto por estarmos correndo em direção a uma transição com MUITAS incógnitas. Todos nós entendíamos que o 5G impulsionaria uma transição para contêineres e arquitetura nativa da nuvem, mas também sabíamos que o Kubernetes e outras ferramentas nativas da nuvem foram originalmente criadas com um conjunto totalmente diferente de casos de uso em mente. O que todos nós vimos (e provavelmente muitos que leram este post também observaram) foi que nosso setor estava em rota de colisão com a azia.

Desde aqueles dias apreensivos, os Provedores de Serviços de Comunicação (CSPs) começaram o verdadeiro trabalho de migração para uma infraestrutura nativa da nuvem. Os pioneiros dessas implantações estão de fato descobrindo barreiras inesperadas, onde áreas críticas na rede do Kubernetes, conforme projetadas originalmente, não conseguem atender às demandas dos casos de uso do provedor de serviços. Seja que o objetivo da empresa de telecomunicações seja avançar em direção a uma implantação de núcleo autônomo (SA) 5G ou parte de uma iniciativa de modernização com uma arquitetura de nuvem distribuída, adaptar o Kubernetes para dar suporte à interoperabilidade de rede, escala de nível de operadora e políticas de segurança de operadora são recursos essenciais necessários em toda a infraestrutura nativa da nuvem.

Como o Kubernetes evoluiu principalmente para focar em casos de uso da Web e de TI em execução na nuvem pública ou em ambientes corporativos, é compreensível que o conjunto exclusivo de requisitos e protocolos para implantar casos de uso do provedor de serviços nunca tenha sido planejado. Felizmente, no entanto, os arquitetos do Kubernetes implementaram um conjunto sólido de padrões de design que tornam o Kubernetes extensível, criando um caminho para casos de uso fundamentais de telecomunicações: para gerenciamento de tráfego de rede, visibilidade e controle, e suporte estendido a protocolos como HTTP/2, GTP, SIP e Diameter.

Antes de descrever quais melhorias são necessárias para tornar o Kubernetes adequado aos casos de uso de provedores de serviços atuais, vamos primeiro identificar os requisitos exclusivos que uma rede de provedores de serviços traz.

O Kubernetes deve se encaixar em um ecossistema maior

Primeiro, um cluster Kubernetes precisa se integrar à rede e às operações mais amplas do provedor de serviços. Decisões arquitetônicas podem ter ramificações de longo prazo, em termos de aumento de custo operacional e complexidade. Os arquitetos de rede devem levar em consideração vários casos de uso de telecomunicações, suporte para protocolos legados e como mudanças dinâmicas no Kubernetes podem impactar a topologia de rede existente, o que pode levar a uma maior 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 de provedores de serviços e suas funções de rede utilizam mais do que apenas HTTP/HTTPS ou TCP padrão. Será fundamental que as operadoras de telefonia móvel tenham suporte de rede para protocolos 3G/4G legados, como SIP, GTP, SCTP, etc., e 5G HTTP2. As cargas de trabalho de telecomunicações também têm uma camada adicional de padrões que se sobrepõem às camadas de rede tradicionais em comparação às cargas de trabalho de TI.

Por último, e 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 implantada em todas as camadas e trabalhar 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 ter controle de segurança consistente. Além disso, políticas de segurança mais amplas da rede precisam ser atualizadas e adaptáveis ao longo do tempo.

Duas abordagens atuais para lidar com essas lacunas funcionais

Contornar padrões do Kubernetes

Contornar padrões nativos da nuvem é um indicador de que os arquitetos são necessariamente levados a criar hacks, porque o Kubernetes não vem nativamente com as ferramentas para lidar com cargas de trabalho de telecomunicações. Observamos diversas maneiras preocupantes pelas quais as empresas de telecomunicações estão quebrando os padrões:

• Contornando a rede do Kubernetes – A grande maioria dos CNFs está colocando uma ou mais interfaces fora do controle do Kubernetes. Esses CNFs exigem acesso direto à rede (frequentemente apresentado como uma solicitação de “multus”, para permitir uma interface extra direta para o exterior). Sem um ponto central de controle de rede, isso expõe a complexidade interna do Kubernetes à rede do provedor de serviços externo, o que levará ao aumento da complexidade operacional e do custo, bem como a uma maior superfície de ataque à segurança. Isso também coloca uma demanda maior sobre qualquer desenvolvedor de aplicativo/função de rede e operador de rede para gerenciar endereços IP, bem como lidar com a natureza dinâmica dos contêineres no Kubernetes, que agora está exposta ao mundo externo.
• Clusters separados para cada função de rede – a rede Kubernetes não fornece nativamente um ponto central para entrada/saída de tráfego de rede. O Kubernetes fornece algum controle de entrada, mas ignora quase totalmente o tráfego de saída, e não há uma maneira integrada de vincular redes de entrada e saída. Vimos diversas implantações em que cada função de rede é executada em seu próprio cluster, para permitir a correlação entre endereços IP de servidores e endereços IP de funções de rede. Isso leva a uma sobrecarga adicional de recursos e ao aumento dos gastos com CapEx, além de adicionar complexidade operacional, resultando em aumento dos gastos com OpEx.

Alinhar com os padrões do Kubernetes

Uma abordagem alternativa é alinhar-se aos padrões de design do Kubernetes e introduzir um proxy de serviço que fornecerá um “painel único” para rede de entrada/saída e segurança do cluster do Kubernetes para o mundo externo. O objetivo de um proxy de serviço é preencher as lacunas funcionais que o Kubernetes apresenta quando usado em um ambiente de provedor de serviços. Um proxy de serviço deve:

• Use padrões nativos do Kubernetes para estender a rede do Kubernetes (definições de recursos personalizados, loop de controle do K8s)
• Interface com rede mais ampla (roteamento BGP, atribuições de IP SNAT de saída, tradução IPv4/v6)
• Vincular entrada e saída individualmente para cada CNF
• Fornece amplo suporte L4/L7 (tcp, udp, sctp, NGAP, HTTP/2, Diameter, GTP, SIP)
• Fornecer uma camada de segurança (terminação TLS, firewall, DDoS, firewall de aplicativo da web)
• Apresentar CNF consistente , ocultando eventos Kubernetes altamente dinâmicos

Abordagem da F5 — Apresentando o proxy de serviço

A F5 escolheu o segundo cenário descrito acima para estender o Kubernetes e criar este proxy de serviço para fornecer essa funcionalidade ausente. Com base em nossas décadas de experiência em gerenciamento de tráfego e segurança, acreditamos que essa é uma função essencial necessária para dar suporte à migração nativa da nuvem em larga escala. Pronto para produção e disponível agora, desenvolvemos o produto de infraestrutura nativa em nuvem BIG-IP Next Service Proxy for Kubernetes (SPK), para abordar diretamente as deficiências do Kubernetes e permitir que os provedores de serviços criem recursos que o Kubernetes "normal" não possui. O SPK simplifica e protege a arquitetura, com uma estrutura que automatiza e se integra perfeitamente com políticas de rede e segurança mais amplas. Essa abordagem do Kubernetes para empresas de telecomunicações continuará resultando em menor complexidade e custos operacionais, além de uma infraestrutura mais resiliente e segura. Como hoje estamos testemunhando uma desaceleração na transição para o 5G SA ( Operadoras de telecomunicações falham no 5G SA, descobre a GlobalData ), é seguro assumir que a transição fracassará ainda mais sem a introdução de um proxy de serviço adequado. Clientes de telecomunicações em produção, em meio à modernização digital em larga escala, estão descobrindo que o SPK está se mostrando a solução do Kubernetes para o problema de arquitetura de rede 5G que eles nem sabiam que tinham.

O SPK da F5 agora está disponível para venda e atualmente está em produção com grandes empresas de telecomunicações. Aguarde os próximos eventos onde demonstraremos os recursos do SPK em comparação com outras abordagens e como certificar CNFs em nossa plataforma. Para mais informações, visite esta página e, se quiser falar diretamente com um membro da equipe F5, entre em contato conosco .