Share via

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

  • Artigo

Os nós AKS não requerem 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, onde um console precisa fazer uma conexão direta com uma máquina virtual em nuvem para minimizar saltos. Este cenário pode ser alcançado no AKS usando o Node Public IP.

Primeiro, crie um novo grupo de recursos.

az group create --name myResourceGroup2 --location eastus

Crie um novo cluster AKS e anexe um IP público para os seus 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áquina Virtual.

az aks create --resource-group MyResourceGroup2 --name MyManagedCluster --location eastus  --enable-node-public-ip

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

az aks nodepool add --resource-group MyResourceGroup2 --cluster-name MyManagedCluster --name nodepool2 --enable-node-public-ip

Usar um prefixo IP público

Há uma série de benefícios em usar um prefixo IP público. O AKS suporta o uso de endereços de um prefixo IP público existente para seus nós, passando o ID do recurso com o sinalizador node-public-ip-prefix 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 eastus --name MyPublicIPPrefix --resource-group MyResourceGroup3

Veja a saída e tome nota do prefixo id :

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

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

az aks create --resource-group MyResourceGroup3 --name MyManagedCluster --location eastus --enable-node-public-ip --node-public-ip-prefix /subscriptions/<subscription-id>/resourcegroups/MyResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix

Localizar IPs públicos para nós

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

  • Use o comando az vmss list-instance-public-ipsCLI do Azure .
  • Use comandos PowerShell ou Bash.
  • Você também pode exibir os IPs públicos no portal do Azure exibindo as instâncias no Conjunto de Dimensionamento de Máquina Virtual.

Importante

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

az vmss list-instance-public-ips --resource-group MC_MyResourceGroup2_MyManagedCluster_eastus --name YourVirtualMachineScaleSetName

Usar tags IP públicas em IPs públicos de nó

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

Requisitos

  • AKS versão 1.24 ou superior é necessária.

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

az aks create --name <clusterName> --location <location> --resource-group <resourceGroup> \
  --enable-node-public-ip \
  --node-public-ip-tags RoutingPreference=Internet

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

az aks nodepool add --cluster-name <clusterName> --name <nodepoolName> --location <location> --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 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 de cluster.

Se um grupo de segurança de rede estiver em vigor na sub-rede com um cluster usando traga sua própria rede virtual, 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 grupo de segurança de aplicativo (ASG). Um ASG gerenciado será criado por padrão no grupo de recursos gerenciado se as portas de host permitidas forem especificadas. Os nós também podem ser adicionados a um ou mais ASGs personalizados especificando a ID do recurso do(s) NSG(s) nos parâmetros do pool de nós.

Formato de especificação da porta do host

Ao especificar a lista de portas a permitir, 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

  • AKS versão 1.24 ou superior é necessária.

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

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

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

  --resource-group <resourceGroup> \
  --cluster-name <clusterName> \
  --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

  --resource-group <resourceGroup> \
  --cluster-name <clusterName> \
  --name <nodepoolName> \
  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
  --asg-ids "<asgId>,<asgId>"

Atribuir automaticamente portas de host para cargas de trabalho de pod (PREVIEW)

Quando 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 a necessidade de configurar um serviço de balanceador de carga. Isso é especialmente útil em cenários como jogos, onde a natureza efêmera do IP e da porta do nó não é um problema porque um serviço matchmaker em um nome de host bem conhecido pode fornecer o host e a porta corretos para usar 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 momento do agendamento, evitando conflitos.

Aviso

O tráfego da porta do host do pod será bloqueado pelas regras padrão do NSG 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

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

Requisitos

  • AKS versão 1.24 ou superior é necessária.

Registre o sinalizador de recurso 'PodHostPortAutoAssignPreview'

Registre o PodHostPortAutoAssignPreview sinalizador de recurso usando o comando az feature register , conforme mostrado no exemplo a seguir:

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

Leva alguns minutos para que o status mostre Registrado. Verifique o status do registro usando o comando az feature show :

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

Quando o status refletir 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 acionamento da atribuição automática de porta de host é feito implantando uma carga de trabalho sem portas de host e aplicando a kubernetes.azure.com/assign-hostports-for-containerports anotação 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, onde a porta é um número de porta individual definido na especificação do 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 hostPort entradas 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óximos passos