KubeIP v2: IPs públicos estáticos para nós Kubernetes em qualquer nuvem

Em alguns cenários, nós Kubernetes ganham bastante ao ter endereços IP públicos estáticos dedicados.

O KubeIP, um utilitário open source, resolve essa necessidade atribuindo IPs públicos estáticos a nós Kubernetes. A versão mais recente, KubeIP v2, amplia o suporte do GKE (Google Cloud) para o EKS (Amazon), com um design preparado para acomodar outros provedores de nuvem. Ele roda como um DaemonSet, o que traz mais confiabilidade, flexibilidade de configuração e facilidade de uso em comparação à abordagem anterior, baseada em controller do Kubernetes. O KubeIP v2 atribui endereços IPv4 e IPv6.

Neste post, vamos explorar casos de uso específicos do KubeIP, compará-lo com cloud NAT gateways e analisar sua arquitetura e configuração.

O KubeIP é útil em diversos cenários nos quais nós Kubernetes precisam de IPs públicos estáticos.

Veja alguns casos de uso comuns:

Aplicações de jogos

Em cenários de jogos, um console pode precisar estabelecer uma conexão direta com uma VM na nuvem para reduzir saltos de rede e latência. Atribuir um IP público dedicado ao nó que hospeda o servidor do jogo permite que o console se conecte diretamente. Isso melhora a experiência do jogador, reduzindo latência e perda de pacotes.

Whitelist de IPs de agentes

Se você tem vários agentes ou serviços rodando no Kubernetes que precisam se conectar diretamente a um servidor externo, e esse servidor exige que os IPs dos agentes estejam em uma whitelist, usar o KubeIP para atribuir IPs públicos estáveis aos nós facilita o gerenciamento e evita liberar faixas CIDR mais amplas. Isso é especialmente útil quando o servidor externo aplica controles de acesso por IP rigorosos.

Evitar SNAT em pods específicos

Por padrão, os pods recebem IPs privados da faixa CIDR da VPC. Quando se comunicam com endereços IPv4 externos, o plugin Amazon VPC CNI traduz o IP do pod para o IP privado primário da interface de rede do nó usando SNAT (source network address translation).

Em alguns casos, você pode querer evitar o SNAT em determinados pods para que serviços externos enxerguem o IP real do pod. Atribuir IPs públicos aos nós com o KubeIP e definir hostNetwork: true na spec do pod resolve isso. O pod passa a se comunicar diretamente com serviços externos pelo IP público do nó.

Conexões de entrada diretas e cenários de rede customizados

Atribuir IPs públicos aos nós com o KubeIP viabiliza diversos cenários de rede. Você pode, por exemplo, encaminhar tráfego diretamente para os pods em execução nesses nós, o que é útil para expor serviços do nó na internet sem precisar de um load balancer tradicional.

Um exemplo é executar um servidor web em um pod e encaminhar o tráfego até ele pelo IP público do nó.

Além disso, o KubeIP pode ser usado para implementar cenários de rede customizados que exigem IPs públicos nos nós. Você poderia, por exemplo, criar um load balancer customizado que encaminha tráfego para nós específicos com base no IP público. Essa flexibilidade transforma o KubeIP em uma ferramenta poderosa para testar ou implantar soluções de rede customizadas no Kubernetes.

O KubeIP vai além do IPv4 e também atribui endereços IPv6 públicos estáticos aos nós. Esse recurso fica cada vez mais importante à medida que a internet avança rumo ao IPv6, dado o esgotamento dos endereços IPv4.

Com o suporte a IPv6 do KubeIP, você atribui endereços IPv6 públicos estáticos aos seus nós Kubernetes, permitindo que se comuniquem diretamente com serviços externos por IPv6. Isso é especialmente vantajoso para aplicações que dependem de conectividade IPv6. Se você está desenvolvendo ou implantando uma aplicação que precisa suportar IPv6, dá para usar o KubeIP para fornecer essa conectividade aos pods que rodam a aplicação.

Além disso, o IPv6 oferece um espaço de endereçamento muito maior, formato de cabeçalho simplificado, melhor suporte a extensões e opções, roteamento multicast aprimorado e outros avanços em relação ao IPv4.

NAT gateways são serviços gerenciados de nuvem que oferecem acesso de saída à internet para recursos em sub-redes privadas, traduzindo seus IPs privados em IPs públicos. Eles permitem que recursos em uma rede privada iniciem conexões de saída para a internet sem comprometer a privacidade e a segurança.

No entanto, NAT gateways não suportam conexões de entrada nem atribuem IPs públicos diretamente aos recursos. Ou seja, embora sejam ótimos para fornecer acesso de saída seguro, não foram feitos para cenários que exigem conexões de entrada ou recursos com IP público próprio.

Já o KubeIP atribui IPs públicos estáticos diretamente aos nós Kubernetes. Isso permite que conexões de entrada cheguem aos pods que rodam nesses nós, encaminhando o tráfego do nó para o pod. Pode ser especialmente útil para aplicações que precisam estar acessíveis pela internet ou para cenários de rede customizados.

E mais: quando o hostNetwork está habilitado, os pods conseguem iniciar conexões de saída usando diretamente o IP do host. Isso pode melhorar o desempenho da rede e simplificar o troubleshooting, mas exige cuidado por questões de segurança.

Em resumo, embora os NAT gateways sejam uma excelente solução para acesso de saída seguro, o KubeIP entrega flexibilidade e controle adicionais sobre a conectividade de entrada e saída para pods e nós específicos.

Vários fatores entram em jogo ao avaliar o custo de usar o KubeIP em vez de cloud NAT gateways.

Custos dos cloud NAT gateways

Cloud NAT gateways são um serviço gerenciado e, portanto, têm custo. Esse valor costuma depender do volume de dados processados e do tempo em que o NAT gateway fica provisionado e disponível.

Na data deste artigo, por exemplo, a AWS cobra US$ 0,045 por hora por NAT gateway, além das taxas de processamento de dados. Você também paga as taxas padrão de transferência de dados da AWS para todo o tráfego que passa pelo NAT gateway.

O modelo de preços do Google Cloud NAT é parecido.

Custos do KubeIP

O KubeIP, por sua vez, é uma ferramenta open source, então não há custo direto pelo uso. Ainda assim, há alguns custos indiretos a considerar:

1. Endereços IP públicos estáticos: você paga pelos IPs públicos estáticos atribuídos aos seus nós. O valor varia conforme o provedor de nuvem. A AWS, por exemplo, cobra US$ 0,005 por hora por um Elastic IP, esteja ele em uso ou não. O Google Cloud cobra o mesmo valor por um IP estático.
2. Transferência de dados: as taxas padrão de transferência se aplicam ao tráfego que passa pelos IPs públicos estáticos atribuídos. Esses custos dependem da política de preços de transferência de dados do seu provedor.
3. Workload adicional no cluster: embora o KubeIP rode como DaemonSet e consuma pouco CPU e memória, ele continua sendo um workload extra no seu cluster Kubernetes. Isso pode afetar o desempenho de outros workloads, sobretudo em clusters com recursos limitados. Na maioria dos casos, porém, o impacto é mínimo.
4. Manutenção e suporte: por ser open source, o KubeIP não conta com suporte dedicado. Qualquer manutenção, troubleshooting ou atualização fica por conta da sua equipe. Não há custo direto, mas isso demanda tempo e esforço, o que se traduz em custo para a organização.

Em resumo, embora o KubeIP não tenha custo direto, há vários custos indiretos a considerar. Mesmo assim, em muitos casos, a flexibilidade e o controle que ele oferece compensam.

Considerações sobre custos

Ao avaliar o custo-benefício do KubeIP, vale considerar tanto os custos diretos quanto os indiretos. Isso inclui o custo dos IPs públicos estáticos, as taxas de transferência de dados, o impacto potencial de rodar um workload extra no cluster Kubernetes e o tempo e esforço de manutenção e suporte.

Mesmo sem custo direto, esses custos indiretos podem se acumular, principalmente em clusters maiores. Por outro lado, a flexibilidade e o controle do KubeIP agregam valor significativo, sobretudo em casos de uso que exigem conexões de entrada diretas ou cenários de rede customizados.

Já os cloud NAT gateways oferecem um serviço gerenciado que simplifica a conectividade de saída para recursos em sub-redes privadas. Apesar do custo do serviço, eles trazem benefícios como facilidade de uso, escalabilidade e confiabilidade.

Em conclusão, a escolha entre o KubeIP e um cloud NAT gateway depende do seu caso de uso, do tamanho e dos requisitos do seu cluster Kubernetes e do orçamento disponível. Recomendamos calcular os custos com base na transferência de dados esperada, no número de nós/IPs e nas necessidades de manutenção para tomar uma decisão bem-informada.

O KubeIP roda como DaemonSet nos nós escolhidos. Em cada nó, ele:

1. Descobre informações sobre o nó e o provedor de nuvem usando a Kubernetes Downward API.
2. Adquire um lock no cluster inteiro para garantir que só um nó atribua IP por vez, evitando race conditions e conflitos de IP.
3. Seleciona um IP estático disponível no pool configurado por meio de filtros e seletores.
4. Atribui o IP à interface de rede primária do nó pela API do provedor de nuvem.
5. Se a atribuição falhar por algum erro, como queda de rede ou erro de API, o KubeIP refaz a tentativa até o limite configurado.
6. Quando um nó é excluído, o KubeIP devolve o IP atribuído ao pool, deixando-o disponível para outros nós.

O KubeIP suporta endereços IPv4 e IPv6 e pode ser configurado para usar pools distintos para cada um. Também aceita pools de IPs customizados para nós ou grupos de nós diferentes, oferecendo flexibilidade no gerenciamento de IPs.

O KubeIP v2 foi projetado como um DaemonSet padrão do Kubernetes, ou seja, roda em cada nó do cluster.

Esse design eleva a confiabilidade e a facilidade de uso em comparação ao desenho anterior, baseado em controller. Ele também simplifica a implantação e garante que cada nó receba um IP público. Além disso, ao aproveitar recursos padrão do Kubernetes como node selectors e node affinity, você controla em quais nós o KubeIP é implantado. Com isso, você ganha controle granular sobre a atribuição de IPs e consegue direcioná-los para nós específicos conforme suas necessidades.

O design extensível do KubeIP v2 facilita a integração com outros provedores de nuvem além de GKE e EKS, tornando-o uma ferramenta versátil para gerenciar IPs públicos em ambientes multicloud.

O KubeIP precisa de uma service account do Kubernetes com permissões para obter nós e gerenciar leases.

Do lado da nuvem, ele exige uma role IAM ou service account com permissões para atribuir/desatribuir e listar IPs públicos e obter informações dos nós.

Veja um exemplo de policy IAM da AWS:

{
  "Version": "2012-10-17",
  "Statement": [\
    {\
      "Effect": "Allow",\
      "Action": [\
        "ec2:AssociateAddress",\
        "ec2:DisassociateAddress",\
        "ec2:DescribeInstances",\
        "ec2:DescribeAddresses"\
      ],\
      "Resource": "*"\
    }\
  ]
}

E uma role IAM do Google Cloud:

title: "KubeIP Role"
description: "KubeIP required permissions"
stage: "GA"
includedPermissions:
- compute.instances.addAccessConfig
- compute.instances.deleteAccessConfig
- compute.instances.get
- compute.addresses.get
- compute.addresses.list
- compute.addresses.use
- compute.zoneOperations.get
- compute.subnetworks.useExternalIp
- compute.projects.get

Para escolher quais IPs usar, defina filtros com a mesma sintaxe do CLI/API do provedor de nuvem para listar IPs. Por exemplo:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kubeip
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kubeip
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: kubeip
    spec:
      serviceAccountName: kubeip-service-account
      terminationGracePeriodSeconds: 30
      priorityClassName: system-node-critical
      nodeSelector:
        nodegroup: public
        kubeip: "use"
      tolerations:
        - operator: "Exists"
          effect: "NoSchedule"
        - operator: "Exists"
          effect: "NoExecute"
      containers:
      - name: kubeip
        image: doitintl/kubeip-agent
        imagePullPolicy: Always
        resources:
          requests:
            cpu: "10m"
            memory: "32Mi"
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: LEASE_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: FILTER
          value: "Name=tag:kubeip,Values=reserved;Name=tag:environment,Values=prod"
        - name: LOG_LEVEL
          value: "debug"
        - name: LOG_JSON
          value: "true"

Isso diz ao KubeIP, na AWS, para considerar apenas IPs com as tags kubeip=reserved e environment=prod.

O filtro do KubeIP para AWS usa a mesma sintaxe do comando describe-addresses da AWS. Para mais detalhes, consulte describe-addresses. Ao especificar vários filtros, eles são combinados com um AND, e a requisição retorna apenas resultados que atendam a todos os filtros. Vários filtros precisam ser separados por ponto e vírgula (;).

Já o filtro do KubeIP para Google Cloud usa a mesma sintaxe do comando gcloud compute addresses list. Para mais detalhes, consulte gcloud topic filter. Ao especificar vários filtros, eles são combinados com um AND, e a requisição retorna apenas resultados que atendam a todos os filtros. Vários filtros precisam ser separados por ponto e vírgula (;).

O diretório examples traz configurações Terraform para subir clusters GKE e EKS já com o KubeIP implantado.

Para rodar no EKS:

cd examples/aws

terraform init

terraform apply

E no GKE:

cd examples/gcp

terraform init

# sem suporte a IPv6
terraform apply -var="project_id=<your-project-id>"

# com suporte a IPv6
terraform apply -var="project_id=<your-project-id>" -var="ipv6_support=true"

Isso provisiona um cluster com node pools públicos e privados, reserva alguns IPs estáticos e implanta o DaemonSet do KubeIP configurado para usar esses IPs reservados.

Como projeto open source, contribuições são muito bem-vindas! Envie pull requests, abra issues, ajude na documentação ou divulgue o projeto.

Com o suporte ampliado a nuvens e o modelo simplificado de DaemonSet na v2, mal podemos esperar para ver mais casos de uso viabilizados pelo KubeIP. Experimente no seu ambiente e conte para a gente como foi!