Este documento pode estar desatualizado

Este documento possui uma data de atualização mais antiga que o documento original. Portanto, este conteúdo pode estar desatualizado. Se você lê inglês, veja a versão em inglês para acessar a versão mais atualizada: Proxies in Kubernetes

Proxies no Kubernetes

Esta página descreve o uso de proxies com Kubernetes.

Proxies

Existem vários tipos diferentes de proxies que você pode encontrar usando Kubernetes:

  1. O kubectl proxy:

Quando o kubectl proxy é utilizado ocorre o seguinte: - executa na máquina do usuário ou em um pod - redireciona/encapsula conexões direcionadas ao localhost para o servidor de API - a comunicação entre o cliente e o o proxy usa HTTP - a comunicação entre o proxy e o servidor de API usa HTTPS - o proxy localiza o servidor de API do cluster - o proxy adiciona os cabeçalhos de comunicação.

  1. O apiserver proxy:

    • é um bastion server, construído no servidor de API
    • conecta um usuário fora do cluster com os IPs do cluster que não podem ser acessados de outra forma
    • executa dentro do processo do servidor de API
    • cliente para proxy usa HTTPS (ou HTTP se o servidor de API for configurado)
    • proxy para o destino pode usar HTTP ou HTTPS conforme escolhido pelo proxy usando as informações disponíveis
    • pode ser usado para acessar um Nó, Pod ou serviço
    • faz balanceamento de carga quando usado para acessar um Service.
  2. O kube proxy:

    • executa em todos os Nós
    • atua como proxy para UDP, TCP e SCTP
    • não aceita HTTP
    • provém balanceamento de carga
    • apenas é usado para acessar serviços.
  3. Um Proxy/Balanceador de carga na frente de servidores de API(s):

    • a existência e a implementação de tal elemento varia de cluster para cluster, por exemplo nginx
    • fica entre todos os clientes e um ou mais serviços
    • atua como balanceador de carga se existe mais de um servidor de API.
  4. Balanceadores de carga da nuvem em serviços externos:

    • são fornecidos por algum provedor de nuvem (e.x AWS ELB, Google Cloud Load Balancer)
    • são criados automaticamente quando o serviço de Kubernetes tem o tipo LoadBalancer
    • geralmente suportam apenas UDP/TCP
    • O suporte ao SCTP fica por conta da implementação do balanceador de carga da provedora de nuvem
    • a implementação varia de acordo com o provedor de cloud.

Os usuários de Kubernetes geralmente não precisam se preocupar com outras coisas além dos dois primeiros tipos. O administrador do cluster tipicamente garante que os últimos tipos serão configurados corretamente.

Redirecionamento de requisições

Os proxies substituíram as capacidades de redirecionamento. O redirecionamento foi depreciado.

Última modificação January 24, 2022 at 8:54 PM PST: add requested changes (5123dfe252)