Compartilhar via

Usar IPs públicos no nível da instância no Serviço de Kubernetes do Azure (AKS)

  • Artigo

Os nós do AKS não exigem seus próprios endereços IP públicos para comunicação. No entanto, os cenários podem exigir que os nós em um pool de nós recebam seus próprios endereços IP públicos dedicados. Um cenário comum é para cargas de trabalho de jogos, em que um console precisa fazer uma conexão direta com uma máquina virtual de nuvem para minimizar os saltos. Esse cenário pode ocorrer no AKS usando o IP público do nó.

Primeiro, crie um novo grupo de recursos.

az group create --name <resourceGroup> --location <region>

Crie um novo cluster do AKS e anexe um IP público para os nós. Cada um dos nós no pool de nós recebe um IP público exclusivo. Você pode verificar isso examinando as instâncias do conjunto de dimensionamento de máquinas virtuais.

az aks create \
    --resource-group <resourceGroup> \
    --name <aksClusterName> \
    --location <region> \
    --enable-node-public-ip \
    --generate-ssh-keys

Para os clusters do AKS existentes, você também pode adicionar um novo pool de nós e anexar um IP público para os nós.

az aks nodepool add --resource-group <resourceGroup> --cluster-name <aksClusterName> --name <newNodePool> --enable-node-public-ip

Adicionar um prefixo IP público

Há vários benefícios para o uso de um prefixo IP público. O AKS dá suporte ao uso de endereços de um prefixo IP público existente para os nós, passando a ID do recurso com o sinalizador --node-public-ip-prefix-id ao criar um novo cluster ou adicionar um pool de nós.

Primeiro, crie um prefixo IP público usando az network public-ip prefix create:

az network public-ip prefix create --length 28 --location <region> --name <publicIPPrefixName> --resource-group <resourceGroup>

Exiba a saída e anote o id para o prefixo:

{
  ...
  "id": "/subscriptions/<subscription-id>/resourceGroups/<resourceGroup>/providers/Microsoft.Network/publicIPPrefixes/<publicIPPrefixName>",
  ...
}

Por fim, ao criar um novo cluster ou adicionar um novo pool de nós, use o sinalizador --node-public-ip-prefix-id e passe a ID do recurso do prefixo:

az aks create \
    --resource-group <resourceGroup> \
    --name <aksClusterName> \
    --location <region> \
    --enable-node-public-ip \
    --node-public-ip-prefix-id /subscriptions/<subscription-id>/resourceGroups/<resourceGroup>/providers/Microsoft.Network/publicIPPrefixes/<publicIPPrefixName> \
    --generate-ssh-keys

Localizar IPs públicos para os nós

Você pode localizar os IPs públicos para os nós de várias maneiras:

Importante

O grupo de recursos do nó contém os nós e os IPs públicos. Use o grupo de recursos do nó ao executar os comandos para localizar os IPs públicos para os nós.

az vmss list-instance-public-ips --resource-group <MC_region_aksClusterName_region> --name <virtualMachineScaleSetName>

Usar marcas de IP públicas nos IPs públicos de nó

As marcas de IP público podem ser utilizadas em IPs públicos de nó para utilizar o recurso Preferência de Roteamento do Azure.

Requisitos

  • O AKS versão 1.29 ou superior é necessário.

Criar um novo cluster usando a Internet de preferência de roteamento

az aks create \
    --name <aksClusterName> \
    --location <region> \
    --resource-group <resourceGroup> \
    --enable-node-public-ip \
    --node-public-ip-tags RoutingPreference=Internet \
    --generate-ssh-keys

Adicionar um pool de nós com a Internet de preferência de roteamento

az aks nodepool add --cluster-name <aksClusterName> \
  --name <nodePoolName> \
  --location <region> \
  --resource-group <resourceGroup> \
  --enable-node-public-ip \
  --node-public-ip-tags RoutingPreference=Internet

Permitir conexões de porta de host e adicionar pools de nós a grupos de segurança de aplicativos

Os nós do AKS que utilizam IPs públicos de nó que hospedam serviços em seu endereço de host precisam ter uma regra NSG adicionada para permitir o tráfego. Adicionar as portas desejadas na configuração do pool de nós criará as regras de permissão apropriadas no grupo de segurança de rede do cluster.

Se um grupo de segurança de rede estiver em vigor na sub-rede com um cluster usando a rede virtual bring-your-own, uma regra de permissão deverá ser adicionada a esse grupo de segurança de rede. Isso pode ser limitado aos nós em um determinado pool de nós adicionando o pool de nós a um ASG ( grupo de segurança de aplicativo ). Um ASG gerenciado será criado por padrão no grupo de recursos gerenciados se as portas de host permitidas forem especificadas. Nós também podem ser adicionados a um ou mais ASGs personalizados especificando a ID do recurso dos NSGs nos parâmetros do pool de nós.

Formato de especificação da porta do host

Ao especificar a lista de portas a serem permitidas, use uma lista separada por vírgulas com entradas no formato de port/protocol ou startPort-endPort/protocol.

Exemplos:

  • 80/tcp
  • 80/tcp,443/tcp
  • 53/udp,80/tcp
  • 50000-60000/tcp

Requisitos

  • O AKS versão 1.29 ou superior é necessário.

Criar um novo cluster com portas permitidas e grupos de segurança de aplicativos

az aks create \
    --resource-group <resourceGroup> \
    --name <aksClusterName> \
    --nodepool-name <nodePoolName> \
    --nodepool-allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp\
    --nodepool-asg-ids "<asgId>,<asgId>" \
    --generate-ssh-keys

Adicionar um novo pool de nós com portas permitidas e grupos de segurança de aplicativos

az aks nodepool add \
  --resource-group <resourceGroup> \
  --cluster-name <aksClusterName> \
  --name <nodePoolName> \
  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
  --asg-ids "<asgId>,<asgId>"

Atualizar as portas permitidas e os grupos de segurança de aplicativos para um pool de nós

az aks nodepool update \
  --resource-group <resourceGroup> \
  --cluster-name <aksClusterName> \
  --name <nodePoolName> \
  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
  --asg-ids "<asgId>,<asgId>"

Atribuir portas de host automaticamente para cargas de trabalho de pod (VERSÃO PRÉVIA)

Quando os IPs públicos são configurados em nós, as portas de host podem ser utilizadas para permitir que os pods recebam tráfego diretamente sem precisar configurar um serviço de balanceador de carga. Isso é especialmente útil em cenários como jogos, em que a natureza efêmera do IP e da porta do nó não é um problema porque um serviço de correspondência em um nome de host conhecido pode fornecer o host e a porta corretos a serem usados no momento da conexão. No entanto, como apenas um processo em um host pode estar escutando na mesma porta, o uso de aplicativos com portas de host pode levar a problemas com o agendamento. Para evitar esse problema, o AKS fornece a capacidade de fazer com que o sistema atribua dinamicamente uma porta disponível no horário de agendamento, evitando conflitos.

Aviso

O tráfego da porta de host do pod será bloqueado pelas regras de NSG padrão em vigor no cluster. Esse recurso deve ser combinado com a permissão de portas de host no pool de nós para permitir que o tráfego flua.

Importante

As versões prévias do recurso AKS estão disponíveis em uma base de autoatendimento e aceitação. As visualizações são fornecidas "como estão" e "conforme disponíveis" e estão excluídas dos acordos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

Requisitos

  • O AKS versão 1.29 ou superior é necessário.

Registrar o sinalizador do recurso "PodHostPortAutoAssignPreview"

Registre o sinalizador de recursos PodHostPortAutoAssignPreview usando o comando az feature register, conforme mostrado no seguinte exemplo:

az feature register --namespace "Microsoft.ContainerService" --name "PodHostPortAutoAssignPreview"

Demora alguns minutos para o status exibir Registrado. Verifique o status do registro usando o comando az feature show:

az feature show --namespace "Microsoft.ContainerService" --name "PodHostPortAutoAssignPreview"

Quando o status reflete Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o comando az provider register:

az provider register --namespace Microsoft.ContainerService

Atribuir automaticamente uma porta de host a um pod

O disparo da atribuição automática da porta do host é feito implantando uma carga de trabalho sem portas de host e aplicando a anotação kubernetes.azure.com/assign-hostports-for-containerports com a lista de portas que precisam de atribuições de porta de host. O valor da anotação deve ser especificado como uma lista separada por vírgulas de entradas como port/protocol, em que a porta é um número de porta individual definido na especificação pod e o protocolo é tcp ou udp.

As portas serão atribuídas a partir do intervalo 40000-59999 e serão exclusivas em todo o cluster. As portas atribuídas também serão adicionadas às variáveis de ambiente dentro do pod para que o aplicativo possa determinar quais portas foram atribuídas. O nome da variável de ambiente estará no seguinte formato (exemplo abaixo): <deployment name>_PORT_<port number>_<protocol>_HOSTPORT, portanto, um exemplo seria mydeployment_PORT_8080_TCP_HOSTPORT: 41932.

Aqui está um exemplo echoserver de implantação, mostrando o mapeamento de portas de host para as portas 8080 e 8443:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver-hostport
  labels:
    app: echoserver-hostport
spec:
  replicas: 3
  selector:
    matchLabels:
      app: echoserver-hostport
  template:
    metadata:
      annotations:
        kubernetes.azure.com/assign-hostports-for-containerports: 8080/tcp,8443/tcp
      labels:
        app: echoserver-hostport
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: echoserver-hostport
          image: k8s.gcr.io/echoserver:1.10
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
            - name: https
              containerPort: 8443
              protocol: TCP

Quando a implantação for aplicada, as entradas hostPort estarão no YAML dos pods individuais:

$ kubectl describe pod echoserver-hostport-75dc8d8855-4gjfc
<cut for brevity>
Containers:
  echoserver-hostport:
    Container ID:   containerd://d0b75198afe0612091f412ee7cf7473f26c80660143a96b459b3e699ebaee54c
    Image:          k8s.gcr.io/echoserver:1.10
    Image ID:       k8s.gcr.io/echoserver@sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229                                                                                                      Ports:          8080/TCP, 8443/TCP
    Host Ports:     46645/TCP, 49482/TCP
    State:          Running
      Started:      Thu, 12 Jan 2023 18:02:50 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      echoserver-hostport_PORT_8443_TCP_HOSTPORT:  49482
      echoserver-hostport_PORT_8080_TCP_HOSTPORT:  46645

Próximas etapas