Referência de Configuração do Cluster AKS

Para obter o ID da assinatura, clique em Todos os Serviços na barra de navegação à esquerda. Em seguida, clique em Assinaturas. Vá até o nome da assinatura que você deseja associar ao seu cluster Kubernetes e copie o ID da Assinatura.

Para obter o ID do cliente, vá para o Portal do Azure, clique em Azure Active Directory, depois clique em Registros de aplicativos, e clique no nome do principal de serviço. O ID do cliente está listado na página de detalhes do registro do aplicativo como ID do Aplicativo (cliente).

Você não pode recuperar o valor do segredo do cliente após ele ser criado, então, se você ainda não tiver um valor de segredo do cliente, precisará criar um novo segredo do cliente.

Para obter um novo segredo do cliente, vá para o Portal do Azure, clique em Azure Active Directory, depois clique em Registros de aplicativos, e clique no nome do principal de serviço.

Em seguida, clique em Certificados e segredos e clique em Novo segredo do cliente. Clique em Adicionar. Então copie o Valor do novo segredo do cliente.

A Microsoft fornece múltiplas nuvens para conformidade com leis regionais, que estão disponíveis para seu uso:

As versões disponíveis do Kubernetes são buscadas dinamicamente na API do Azure.

Um grupo de recursos é um contêiner que abriga recursos relacionados para uma solução do Azure. O grupo de recursos pode incluir todos os recursos da solução ou apenas aqueles que você deseja gerenciar como um grupo. Você decide como deseja alocar recursos para grupos de recursos com base no que faz mais sentido para sua organização. Geralmente, adicione recursos que compartilham o mesmo ciclo de vida ao mesmo grupo de recursos para que você possa implantá-los, atualizá-los e excluí-los facilmente como um grupo.

Use um grupo de recursos existente ou insira um nome de grupo de recursos e um será criado para você.

Usar um grupo de recursos contendo um cluster AKS existente criará um novo grupo de recursos. O Azure AKS permite apenas um cluster AKS por grupo de recursos.

Para informações sobre como gerenciar grupos de recursos, consulte a documentação do Azure.

O nome de usuário usado para criar uma conexão SSH com os nós Linux.

O nome de usuário padrão para os nós AKS é azureuser.

A chave usada para criar uma conexão SSH com os nós Linux.

As tags do cluster podem ser úteis se sua organização usar tags como uma forma de organizar recursos em vários serviços do Azure. Essas tags não se aplicam a recursos dentro do cluster.

Os balanceadores de carga do Azure suportam tanto SKUs padrão quanto básicos (unidades de manutenção de estoque).

Para uma comparação entre balanceadores de carga padrão e básicos, consulte a documentação oficial do Azure. A Microsoft recomenda o balanceador de carga padrão.

O balanceador de carga padrão é necessário se você selecionou uma ou mais zonas de disponibilidade, ou se você tem mais de um pool de nós.

Todos os pods em um cluster AKS podem enviar e receber tráfego sem limitações, por padrão. Para melhorar a segurança, você pode definir regras que controlam o fluxo de tráfego. O recurso de política de rede no Kubernetes permite que você defina regras para tráfego de entrada e saída entre pods em um cluster.

O Azure fornece duas maneiras de implementar a política de rede. Você escolhe uma opção de política de rede ao criar um cluster AKS. A opção de política não pode ser alterada após a criação do cluster:

Você também pode optar por não ter política de rede.

Para mais informações sobre as diferenças entre as políticas de rede do Azure e Calico e suas capacidades, consulte a documentação do AKS.

Insira um prefixo DNS exclusivo para o FQDN do servidor API Kubernetes do seu cluster.

Existem dois plugins de rede: kubenet e Azure CNI.

O plugin Kubernetes kubenet é a configuração padrão para a criação de clusters AKS. Quando o kubenet é utilizado, cada nó no cluster recebe um endereço IP roteável. Os pods usam NAT para se comunicar com outros recursos fora do cluster AKS. Essa abordagem reduz o número de endereços IP que você precisa reservar no seu espaço de rede para os pods usarem.

Com o plugin de rede Azure CNI (avançado), os pods obtêm conectividade total à rede virtual e podem ser acessados diretamente pelo seu endereço IP privado a partir de redes conectadas. Esse plugin requer mais espaço de endereços IP.

Para mais informações sobre as diferenças entre kubenet e Azure CNI, consulte a documentação do AKS.

Quando habilitado, o complemento de roteamento de aplicativos HTTP facilita o acesso a aplicativos implantados no cluster AKS. Ele implanta dois componentes: um controlador de Ingress do Kubernetes e um controlador External-DNS.

Para mais informações, consulte a documentação do AKS.

Você pode proteger o acesso ao servidor de API do Kubernetes usando faixas de endereços IP autorizadas.

O servidor de API do Kubernetes expõe a API do Kubernetes. Esse componente fornece a interação para ferramentas de gerenciamento, como kubectl. O AKS fornece um plano de controle de cluster de inquilino único com um servidor de API dedicado. Por padrão, o servidor de API é atribuído um endereço IP público, e você deve controlar o acesso a ele usando RBAC baseado em Kubernetes ou Azure.

Para proteger o acesso ao plano de controle do AKS e ao servidor de API, que são publicamente acessíveis, você pode habilitar e usar faixas de IP autorizadas. Essas faixas de IP autorizadas permitem apenas que faixas de endereços IP definidas se comuniquem com o servidor de API.

No entanto, mesmo que você use faixas de endereços IP autorizadas, ainda deve usar o RBAC do Kubernetes ou o RBAC do Azure para autorizar os usuários e as ações que eles solicitam.

O monitoramento de contêineres fornece visibilidade de desempenho ao coletar métricas de memória e processador de controladores, nós e contêineres que estão disponíveis no Kubernetes através da API de Métricas. Os logs de contêiner também são coletados. Após habilitar o monitoramento, métricas e logs são coletados automaticamente para você através de uma versão conteinerizada do agente de Log Analytics para Linux. As métricas são escritas no armazenamento de métricas e os dados de log são escritos no armazenamento de logs associado ao seu workspace de Log Analytics.

O grupo de recursos que contém o Workspace de Log Analytics. Você deve criar pelo menos um workspace para usar os Logs do Azure Monitor.

Os dados coletados pelos Logs do Azure Monitor são armazenados em um ou mais workspaces de Log Analytics. O workspace define a localização geográfica dos dados, os direitos de acesso que definem quais usuários podem acessar os dados e as configurações, como o nível de preços e a retenção de dados.

Você deve criar pelo menos um workspace para usar os Logs do Azure Monitor. Um único workspace pode ser suficiente para todos os seus dados de monitoramento, ou você pode optar por criar vários workspaces dependendo de suas necessidades. Por exemplo, você pode ter um workspace para seus dados de produção e outro para testes.

Para mais informações sobre os Logs do Azure Monitor, consulte a documentação do Azure.

Normalmente, os nós de trabalho do AKS não recebem IPs públicos, independentemente de o cluster ser privado. Em um cluster privado, o plano de controle não possui um endpoint público.

O Rancher pode se conectar a um cluster AKS privado de duas maneiras.

A primeira maneira é garantir que o Rancher esteja rodando na mesma NAT que os nós do AKS.

A segunda maneira é executar um comando para registrar o cluster no Rancher. Uma vez que o cluster esteja provisionado, você pode executar o comando exibido em qualquer lugar que você consiga se conectar à API do Kubernetes do cluster. Esse comando é exibido em um pop-up quando você provisiona um cluster AKS com um endpoint de API privado habilitado.

Para mais informações sobre como se conectar a um cluster privado do AKS, consulte a documentação do AKS.

A interface do Azure permite que os usuários especifiquem se um Pool de Nós Primário depende de system (normalmente usado para planos de controle) ou user (o que é mais tipicamente necessário para o Rancher).

Para pools de nós primários, você pode especificar Modo, SO, Contagem e Tamanho.

Pools de nós do sistema sempre requerem nós em execução, portanto, não podem ser escalonados abaixo de um nó. Pelo menos um pool de nós do sistema é necessário.

Para pools de nós subsequentes, a interface do Rancher força o padrão de Usuário. Pools de nós de Usuário permitem que você escale para zero nós. Pools de nós de Usuário não executam nenhuma parte do plano de controle do Kubernetes.

O AKS não expõe os nós que executam os componentes do plano de controle do Kubernetes.

Zonas de Disponibilidade são locais físicos únicos dentro de uma região. Cada zona é composta por um ou mais data centers equipados com energia, refrigeração e rede independentes.

Nem todas as regiões têm suporte para zonas de disponibilidade. Para uma lista de regiões do Azure com zonas de disponibilidade, consulte a documentação do Azure.

Escolha um tamanho para cada VM no pool de nós. Para detalhes sobre cada tamanho de VM, consulte esta página.

Os nós no pool de nós podem ter discos gerenciados ou efêmeros.

Discos de SO efêmeros são criados no armazenamento local da máquina virtual e não são salvos no Armazenamento do Azure remoto. Discos de SO efêmeros funcionam bem para cargas de trabalho sem estado, onde os aplicativos são tolerantes a falhas individuais de VM, mas são mais afetados pelo tempo de implantação da VM ou pela reimagem das instâncias individuais de VM. Com o disco de SO efêmero, você obtém menor latência de leitura/gravação para o disco do SO e uma reimagem de VM mais rápida.

Discos gerenciados do Azure são volumes de armazenamento em nível de bloco que são gerenciados pelo Azure e usados com Máquinas Virtuais do Azure. Discos gerenciados são projetados para 99,999% de disponibilidade. Discos gerenciados alcançam isso fornecendo três réplicas dos seus dados, permitindo alta durabilidade.

O tamanho em GB para o disco de cada nó.

O número de nós no pool de nós. O número máximo de nós pode ser limitado pela sua assinatura do Azure.

O número máximo de pods por nó é 110, com um máximo de 250.

Quando o escalonamento automático está habilitado, você precisará inserir uma contagem mínima e máxima de nós.

Quando o Escalonamento Automático está habilitado, você não pode escalar manualmente o pool de nós. A escala é controlada pelo escalonador automático do AKS.