[Editor– Este post é um trecho do nosso eBook completo, Gerenciamento de tráfego do Kubernetes com o F5 NGINX: um guia prático. Baixe-o gratuitamente hoje mesmo.]
À medida que as organizações crescem, os fluxos de trabalho de desenvolvimento e operações no Kubernetes se tornam mais complexos. Em geral, é mais econômico — e pode ser mais seguro — que as equipes compartilhem clusters e recursos do Kubernetes, em vez de cada equipe ter seu próprio cluster. No entanto, suas implantações podem sofrer danos graves se as equipes não compartilharem esses recursos de forma segura ou se hackers explorarem suas configurações.
As práticas de multilocação e o isolamento de namespaces nos níveis de rede e de recursos ajudam as equipes a compartilhar recursos do Kubernetes com segurança. Também é possível reduzir significativamente o impacto das violações isolando os aplicativos por locatário. Esse método ajuda a aumentar a resiliência, pois apenas partes dos aplicativos pertencentes a equipes específicas podem ser comprometidas, enquanto os sistemas que fornecem outras funcionalidades permanecem intactos.
O NGINX Ingress Controller oferece suporte a vários modelos de multilocação, mas observamos dois padrões principais. O padrão de provedor de serviços de infraestrutura normalmente inclui várias implantações do NGINX Ingress Controller com isolamento físico, enquanto o padrão empresarial normalmente usa uma implantação compartilhada do NGINX Ingress Controller com isolamento de namespace. Nesta seção, exploramos o padrão empresarial em detalhes. Para obter informações sobre como executar vários NGINX Ingress Controllers, consulte nossa documentação.
Delegação com o NGINX Ingress Controller
O NGINX Ingress Controller oferece suporte tanto ao recurso Ingress padrão do Kubernetes quanto aos recursos personalizados do NGINX Ingress, que permitem um gerenciamento de tráfego mais sofisticado e a delegação do controle sobre a configuração a várias equipes. Os recursos personalizados são VirtualServer, VirtualServerRoute, GlobalConfiguration, TransportServer e Policy.
Com o NGINX Ingress Controller, os administradores de cluster usam recursos VirtualServer para provisionar regras de domínio (nome do host) do Ingress que encaminham o tráfego externo para aplicações de backend e recursos VirtualServerRoute para delegar o gerenciamento de URLs específicas aos proprietários das aplicações e às equipes de DevOps.
Há dois modelos que você pode escolher ao implementar a multilocação no seu cluster do Kubernetes: autoatendimento completo e autoatendimento restrito.
Implementando o autoatendimento completo
Em um modelo totalmente self-service, os administradores não participam das alterações cotidianas na configuração do NGINX Ingress Controller. Eles são responsáveis apenas por implantar o NGINX Ingress Controller e o Serviço do Kubernetes que expõe a implantação externamente. Em seguida, os desenvolvedores implantam aplicações em um namespace atribuído sem envolver o administrador. Os desenvolvedores são responsáveis por gerenciar segredos TLS, definir a configuração de balanceamento de carga para nomes de domínio e expor suas aplicações criando recursos VirtualServer ou Ingress padrão.
Para ilustrar esse modelo, replicamos o aplicativo de exemplo bookinfo (originalmente criado pelo Istio) com dois subdomínios, a.bookinfo.com e b.bookinfo.com, conforme mostrado no diagrama a seguir. Depois que o administrador instala e implanta o NGINX Ingress Controller no namespace nginx-ingress (destacado em verde), as equipes DevA (rosa) e DevB (roxo) criam seus próprios recursos VirtualServer e implantam aplicativos isolados em seus respectivos namespaces (A e B).
As equipes DevA e DevB definem regras de Ingress para seus domínios a fim de encaminhar conexões externas para suas aplicações.
A equipe DevA aplica o seguinte objeto de recurso VirtualServer para expor aplicações para o domínio a.bookinfo.com no namespace A.
Carregando exemplo de código…
Da mesma forma, a equipe DevB aplica o seguinte recurso VirtualServer para expor aplicações para o domínio b.bookinfo.com no namespace B.
Carregando exemplo de código…
Implementando o autoatendimento restrito
Em um modelo de autoatendimento restrito, os administradores configuram recursos VirtualServer para encaminhar o tráfego que entra no cluster para o namespace apropriado, mas delegam a configuração dos aplicativos nos namespaces às equipes de desenvolvimento responsáveis. Cada equipe é responsável apenas pela sub-rota de seu aplicativo, conforme instanciada no recurso VirtualServer, e usa recursos VirtualServerRoute para definir regras de tráfego e expor sub-rotas de aplicativos em seu namespace.
Conforme ilustrado no diagrama, o administrador do cluster instala e implanta o NGINX Ingress Controller no namespace nginx-ingress (destacado em verde) e define um recurso VirtualServer que estabelece regras baseadas em caminho que fazem referência às definições de recursos VirtualServerRoute.
Essa definição de recurso VirtualServer estabelece duas regras baseadas em caminho que fazem referência a definições de recursos VirtualServerRoute para duas sub-rotas, /productpage-A e /productpage-B.
Carregando exemplo de código…
As equipes de desenvolvimento responsáveis pelos aplicativos nos namespaces A e B definem então recursos VirtualServerRoute para expor sub-rotas de aplicativos em seus namespaces. As equipes são isoladas por namespace e limitadas à implantação das sub-rotas de aplicativos definidas pelos recursos VirtualServer provisionados pelo administrador:
- A equipe DevA (em rosa no diagrama) aplica o seguinte recurso VirtualServerRoute para expor a regra de sub-rota do aplicativo definida pelo administrador para
/productpage-A.Carregando exemplo de código…
- A equipe DevB (roxo) aplica o seguinte recurso VirtualServerRoute para expor a regra de sub-rota do aplicativo definida pelo administrador para
/productpage-B.Carregando exemplo de código…
Para obter mais informações sobre os recursos que você pode configurar nos recursos VirtualServer e VirtualServerRoute, consulte a documentação do NGINX Ingress Controller.
Observação: Você pode usar tipos de Ingress mescláveis para configurar o roteamento entre namespaces, mas, em um modelo restrito de delegação de autoatendimento, essa abordagem apresenta três desvantagens em comparação com os recursos VirtualServer e VirtualServerRoute:
- É menos seguro.
- À medida que sua implantação do Kubernetes cresce e se torna maior e mais complexa, ela fica cada vez mais sujeita a modificações acidentais, pois os tipos de Ingress mescláveis não impedem que os desenvolvedores definam regras de Ingress para nomes de host dentro de seus namespaces.
- Ao contrário dos recursos VirtualServer e VirtualServerRoute, os tipos de Ingress mescláveis não permitem que o recurso de Ingress principal (“mestre”) controle os caminhos dos recursos de Ingress “subordinados”.
Aproveitando o RBAC do Kubernetes em um modelo restrito de autoatendimento
Você pode usar o controle de acesso baseado em funções (RBAC) do Kubernetes para regular o acesso de um usuário a namespaces e recursos do NGINX Ingress com base nas funções atribuídas a ele.
Por exemplo, em um modelo de autoatendimento restrito, somente administradores com privilégios especiais podem receber acesso seguro aos recursos VirtualServer, pois esses recursos definem o ponto de entrada do cluster do Kubernetes e seu uso indevido pode causar interrupções em todo o sistema.
Os desenvolvedores usam recursos VirtualServerRoute para configurar regras de Ingress para as rotas de aplicações sob sua responsabilidade. Por isso, os administradores definem políticas de RBAC que permitem aos desenvolvedores criar apenas esses recursos. Eles podem até restringir essa permissão a namespaces específicos caso precisem controlar ainda mais o acesso dos desenvolvedores.
Em um modelo totalmente de autoatendimento, os desenvolvedores podem receber acesso com segurança aos recursos VirtualServer, mas, ainda assim, o administrador pode restringir essa permissão a namespaces específicos.
Para obter mais informações sobre a autorização RBAC, consulte a documentação do Kubernetes.
Adicionando políticas
Os recursos Policy do NGINX são outra ferramenta que permite que equipes distribuídas configurem o Kubernetes em implantações multilocatário. Os recursos Policy oferecem funcionalidades como autenticação usando OAuth e OpenID Connect (OIDC), limitação de taxa e firewall de aplicações Web (WAF). Os recursos Policy são referenciados nos recursos VirtualServer e VirtualServerRoute para serem aplicados à configuração do Ingress.
Por exemplo, uma equipe responsável pelo gerenciamento de identidades em um cluster pode definir políticas de JSON Web Token (JWT) ou OIDC, como a política a seguir, que usa o Okta como provedor de identidade (IdP) OIDC.
Carregando exemplo de código…
As equipes de NetOps e DevOps podem usar recursos VirtualServer ou VirtualServerRoute para referenciar essas políticas, como neste exemplo.
Carregando exemplo de código…
Em conjunto, os recursos Policy, VirtualServer e VirtualServerRoute do NGINX viabilizam arquiteturas de configuração distribuída, nas quais os administradores podem delegar facilmente a configuração a outras equipes. As equipes podem combinar módulos entre namespaces e configurar o NGINX Ingress Controller para casos de uso sofisticados de forma segura, escalável e gerenciável.
Para obter mais informações sobre os recursos de Policy, consulte a documentação do NGINX Ingress Controller.
Este post é um trecho do nosso eBook completo, Como gerenciar o tráfego do Kubernetes com o NGINX: um guia prático. Baixe-o gratuitamente hoje mesmo.
Experimente o NGINX Ingress Controller baseado no NGINX Plus com uma avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para conversar sobre seus casos de uso.
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.