Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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 <resourceGroup> --location <region>
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 <resourceGroup> \
--name <aksClusterName> \
--location <region> \
--enable-node-public-ip \
--generate-ssh-keys
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 <resourceGroup> --cluster-name <aksClusterName> --name <newNodePool> --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-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>
Veja a saída e tome nota do prefixo id :
{
...
"id": "/subscriptions/<subscription-id>/resourceGroups/<resourceGroup>/providers/Microsoft.Network/publicIPPrefixes/<publicIPPrefixName>",
...
}
Finalmente, ao criar um novo cluster ou adicionar um novo pool de nós, use o sinalizador --node-public-ip-prefix-id e passe o ID de 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
Use um prefixo de IP público dual-stack (pré-visualização)
Pode atribuir endereços IP públicos IPv4 e IPv6 a cada nó de um pool de nós usando prefixos de IP públicos num cluster de pilha dupla. Esta funcionalidade é útil para cargas de trabalho que requerem conectividade direta de entrada ou saída tanto em IPv4 como em IPv6, ou para aplicações que operam em ambientes que exigem conformidade com IPv6.
Existem duas configurações suportadas:
- Traga os seus próprios prefixos IPv4 e IPv6. Cada nó recebe um endereço IPv4 do seu prefixo IPv4 e um endereço IPv6 do seu prefixo IPv6. Use esta configuração quando ambos os endereços precisam de vir de intervalos de endereços que o utilizador controla, como quando um firewall ou serviço parceiro permite tráfego apenas dos seus prefixos.
- Traga apenas o seu próprio prefixo IPv6. Cada nó recebe um endereço IPv6 do seu prefixo IPv6, e o Azure atribui automaticamente o endereço IPv4. Use esta configuração quando apenas o endereço IPv6 precisa de vir de um intervalo que o utilizador controla. Como o pool de nós não consome endereços de um prefixo IPv4, o tamanho de um prefixo IPv4 não limita a quantidade de nós a que o pool de nós pode escalar.
Importante
Os recursos de pré-visualização do AKS estão disponíveis numa base de autosserviço e adesão voluntária. 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 versões de teste do AKS são parcialmente cobertas pelo suporte ao cliente numa base de melhor esforço. Assim sendo, estas funcionalidades não se destinam ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:
Requisitos
Para usar prefixos IP públicos de dupla pilha com endereços IP públicos dos nós, certifique-se de que os seguintes pré-requisitos estão reunidos:
- O seu cluster está configurado como um cluster dual-stack com famílias IP IPv4 e IPv6. É necessário um cluster dual-stack para ambas as configurações, incluindo a configuração de prefixo apenas IPv6.
- O teu cluster usa Azure CNI com rede sobreposta.
- Criaste os prefixos de IP públicos que planeias usar na mesma subscrição e região do teu cluster AKS. Dependendo da configuração que escolheres, precisas de um prefixo IPv4 e um prefixo IPv6, ou de um único prefixo IPv6.
- Cada prefixo IP público usa o SKU Standard e não está ligado a um balanceador de carga.
- A identidade do cluster AKS tem permissão para gerir os prefixos IP públicos. Se os prefixos estiverem num grupo de recursos diferente, atribui o papel de Network Contributor nesse grupo de recursos à identidade do cluster.
Registe as funcionalidades de pré-visualização
O suporte para prefixos IP públicos dual-stack (IPv4 e IPv6) para os IPs públicos dos nós está atualmente disponível em pré-visualização. Antes de poder utilizar esta funcionalidade, tem de instalar ou atualizar a extensão da CLI do Azure e registar os sinalizadores de funcionalidade NodePublicIPv6PrefixPreview na sua subscrição.
Instale ou atualize a extensão aks-preview:
az extension add --name aks-preview --upgrade
Registe as funcionalidades de pré-visualização obrigatórias:
az feature register --namespace Microsoft.ContainerService --name NodePublicIPv6PrefixPreview
Pode demorar vários minutos até que os registos de funcionalidades sejam concluídos. Para verificar o estado do registo, execute:
az feature show --namespace Microsoft.ContainerService --name NodePublicIPv6PrefixPreview --query "properties.state"
Espere até que a funcionalidade reporte um estado de Registered antes de avançar.
Depois de registadas as feature flags, atualize o fornecedor de recursos para garantir que as alterações são aplicadas:
az provider register --namespace Microsoft.ContainerService
Depois de concluído o registo, pode criar ou atualizar um cluster para utilizar prefixos de IP públicos de pilha dupla para os endereços IP públicos dos nós.
Criar prefixos IP públicos
Crie um prefixo IP público para IPv4 e IPv6 usando a CLI do Azure. Se planeia usar a configuração apenas com prefixo IPv6, crie apenas o prefixo IPv6.
Para IPv4:
az network public-ip prefix create \
--resource-group <resourceGroup> \
--name <ipv4PrefixName> \
--location <region> \
--length 28 \
--sku Standard \
--version IPv4
Para IPv6:
az network public-ip prefix create \
--resource-group <resourceGroup> \
--name <ipv6PrefixName> \
--location <region> \
--length 124 \
--sku Standard \
--version IPv6
Depois de criar os prefixos, note o ID de recurso de cada prefixo.
Crie um novo cluster com prefixos IP públicos de nós de pilha dupla
Ao criar um novo cluster AKS, use o --node-public-ip-prefix-ids parâmetro para especificar tanto os prefixos IPv4 como IPv6 de IP público.
az aks create \
--resource-group <resourceGroup> \
--name <aksClusterName> \
--location <region> \
--enable-node-public-ip \
--ip-families IPv4,IPv6 \
--network-plugin azure \
--network-plugin-mode overlay \
--node-public-ip-prefix-ids "<ipv4PrefixResourceId>,<ipv6PrefixResourceId>" \
--generate-ssh-keys
O --node-public-ip-prefix-ids parâmetro aceita uma lista separada por vírgulas de IDs de recursos com prefixos de IP públicos. A lista pode conter, no máximo, um prefixo IPv4 e um prefixo IPv6. A ordem não importa, porque o AKS determina a versão IP a partir de cada prefixo referenciado.
Adicionar um pool de nós com prefixos públicos de IP de nós de pilha dupla
Também pode adicionar um pool de nós com prefixos IP públicos de nós dual-stack a um cluster dual-stack existente.
az aks nodepool add \
--resource-group <resourceGroup> \
--cluster-name <aksClusterName> \
--name <nodePoolName> \
--enable-node-public-ip \
--node-public-ip-prefix-ids "<ipv4PrefixResourceId>,<ipv6PrefixResourceId>"
Utilize um prefixo IP público exclusivo para IPv6
Se só precisares que o endereço IPv6 venha de um prefixo que controlas, especifica um único prefixo IPv6. Cada nó recebe um endereço IPv6 do seu prefixo, e o Azure atribui automaticamente o endereço IPv4. O pool de nós ainda requer um cluster dual-stack.
Use esta configuração quando o tamanho de um prefixo IPv4 de outro modo limitaria até onde o pool de nós pode escalar. Como o pool de nós não extrai endereços IPv4 de um prefixo, apenas a capacidade do prefixo IPv6 limita o número de nós.
Crie um novo cluster com um prefixo de IP público apenas para IPv6:
az aks create \
--resource-group <resourceGroup> \
--name <aksClusterName> \
--location <region> \
--enable-node-public-ip \
--ip-families IPv4,IPv6 \
--network-plugin azure \
--network-plugin-mode overlay \
--node-public-ip-prefix-ids "<ipv6PrefixResourceId>" \
--generate-ssh-keys
Adicione um pool de nós com um prefixo IP público de nó apenas IPv6 a um cluster de pilha dupla existente:
az aks nodepool add \
--resource-group <resourceGroup> \
--cluster-name <aksClusterName> \
--name <nodePoolName> \
--enable-node-public-ip \
--node-public-ip-prefix-ids "<ipv6PrefixResourceId>"
Como o Azure atribui automaticamente o endereço IPv4, o endereço IPv4 de cada nó não é previsível e não o pode adicionar a uma lista de permissões antecipadamente. Como resultado, não pode usar um prefixo IP público apenas IPv6 num cluster que utilize intervalos de IP autorizados do servidor API. Utilize API Server VNet Integration ou um cluster privado, ou inclua um prefixo IPv4 na lista.
Verifique a configuração do prefixo IP público do nó
Confirme quais os prefixos que um pool de nós usa com o comando az aks nodepool show:
az aks nodepool show \
--resource-group <resourceGroup> \
--cluster-name <aksClusterName> \
--name <nodePoolName> \
--query "networkProfile.nodePublicIPPrefixIDs"
Liste os endereços IP públicos que os nós receberam com o comando az vmss list-instance-public-ips . Utilize o grupo de recursos do nó:
az vmss list-instance-public-ips \
--resource-group <MC_resourceGroup_aksClusterName_region> \
--name <virtualMachineScaleSetName> \
--query "[].{name:name, ipAddress:ipAddress, version:publicIPAddressVersion}" \
--output table
Para um prefixo apenas IPv6, cada nó tem um endereço IPv6 do seu prefixo e um endereço IPv4 do conjunto de endereços gerido pelo Azure.
Limitações
As seguintes limitações aplicam-se aos prefixos de IP públicos para IPs públicos de nós.
Lista de prefixos:
- A lista de prefixos pode conter, no máximo, um prefixo IPv4 e um prefixo IPv6. Dois prefixos da mesma versão de IP são rejeitados.
- Deve ativar IPs públicos de nós no pool de nós quando especificar prefixos.
- Não podes usar os parâmetros
--node-public-ip-prefix-idse--node-public-ip-prefix-idno mesmo comando. - A configuração do IP público do nó é imutável. Para alterar os prefixos de IP público, é necessário criar um novo pool de nós e migrar cargas de trabalho.
Recursos com prefixo:
- Cada prefixo deve usar o SKU padrão. Os prefixos V2 Basic e Standard não são suportados.
- Cada prefixo deve estar na mesma assinatura e na mesma região do seu cluster AKS.
- Não podes usar um prefixo que já esteja ligado a um balanceador de carga.
- Se o seu pool de nós usar zonas de disponibilidade, as zonas de cada prefixo devem cobrir as zonas do pool de nós. Um prefixo redundante de zona, que não tem zonas atribuídas, funciona com qualquer pool de nós.
Capacidade e escala:
- Cada prefixo deve ter endereços suficientes para a contagem de nós do pool de nós, porque cada nó consome um endereço de cada prefixo que fornece.
- O Cluster Autoscaler é suportado, mas certifique-se de que o número máximo de nós configurado não ultrapassa o número de endereços IP disponíveis em cada prefixo de rede que fornecer. Se usares um prefixo apenas IPv6, só o prefixo IPv6 limita o número de nós, porque o Azure atribui automaticamente os endereços IPv4.
Compatibilidade de funcionalidades:
- Não podes usar um prefixo IP público apenas IPv6 num cluster que usa intervalos de IP autorizados do servidor da API, porque o Azure atribui automaticamente o endereço IPv4 do nó e não podes adicioná-lo a uma lista de autorizações antecipadamente. Utilize a API Server VNet Integration ou um cluster privado, ou inclua um prefixo IPv4 na lista.
- Cada nó recebe um único endereço IP público IPv6.
- Esta funcionalidade não é suportada no AKS Automatic nem no auto-provisionamento de nós.
- Os conjuntos de nós multi-NIC não são suportados.
Localizar IPs públicos para nódulos
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 nodo ao executar comandos para localizar os IPs públicos para os seus nodos.
az vmss list-instance-public-ips --resource-group <MC_region_aksClusterName_region> --name <virtualMachineScaleSetName>
Usar etiquetas IP públicas nos IPs públicos dos nós
As etiquetas IP públicas podem ser utilizadas em IPs públicos de nós para utilizar a funcionalidade Azure Routing Preference , que está disponível em regiões específicas.
Requisitos
- AKS versão 1.29 ou superior é necessária.
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 preferência de roteamento internet
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 na porta do host e adicionar pools de nós a grupos de segurança de aplicações
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 houver um grupo de segurança de rede configurado na sub-rede com um cluster que utilize uma rede virtual própria, deverá ser adicionada uma regra de autorização 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 ao especificar a ID de 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.
Examples:
- 80/tcp
- 80/tcp,443/tcp
- 53/udp,80/tcp
- 50000-60000/tcp
Requisitos
- AKS versão 1.29 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 <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 aplicações 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 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 de matchmaking num 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 num host pode estar a ouvir na mesma porta, o uso de aplicações que utilizam portas do host pode levar a problemas no processo de 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 pré-visualização do AKS estão disponíveis numa base de autosserviço e adesão voluntária. 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 versões de teste do AKS são parcialmente cobertas pelo suporte ao cliente numa base de melhor esforço. Assim sendo, estas funcionalidades não se destinam ao uso em produção. Para obter mais informações, consulte os seguintes artigos de suporte:
Requisitos
- AKS versão 1.29 ou superior é necessária.
Registre o sinalizador de recurso 'PodHostPortAutoAssignPreview'
Registe o PodHostPortAutoAssignPreview sinalizador de recurso, utilizando 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 estado refletir Registrado, atualize o registo do provedor de recursos Microsoft.ContainerService utilizando o comando az provider register:
az provider register --namespace Microsoft.ContainerService
Atribuir automaticamente uma porta de host a um pod
A ativação da atribuição automática de portas de host é feita ao implementar uma tarefa sem portas de host e aplicar a anotação kubernetes.azure.com/assign-hostports-for-containerports com a lista de portas que precisam de atribuições de portas 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
Saiba mais sobre como usar vários pools de nós no AKS.
Saiba mais sobre como usar balanceadores de carga padrão no AKS