Compartilhar via

Principais conceitos do Kubernetes para AKS (Serviço de Kubernetes do Azure)

  • Artigo

Este artigo descreve os principais conceitos do AKS (Serviço de Kubernetes do Azure), um serviço de Kubernetes gerenciado que você pode usar para implantar e operar aplicativos conteinerizados em escala no Azure. Ele ajuda você a aprender sobre os componentes de infraestrutura do Kubernetes e obter uma compreensão mais ampla de como o Kubernetes funciona no AKS.

O que é Kubernetes?

O Kubernetes é uma plataforma em rápida evolução que gerencia aplicativos baseados em contêiner e seus componentes de rede e armazenamento associados. O Kubernetes foca nas cargas de trabalho de aplicativos e não nos componentes de infraestrutura subjacentes. O Kubernetes fornece uma abordagem declarativa para implementações, apoiada por um conjunto robusto de APIs para operações de gerenciamento.

Você pode criar e executar aplicativos modernos, portáteis e baseados em microsserviços usando o Kubernetes para orquestrar e gerenciar a disponibilidade dos componentes de aplicativo. O Kubernetes dá suporte a aplicativos sem estado e com estado.

Como uma plataforma aberta, o Kubernetes permite que você construa seus aplicativos com sua linguagem de programação, sistema operacional, bibliotecas ou barramento de mensagens preferido. As ferramentas existentes de integração contínua e entrega contínua (CI/CD) podem ser integradas ao Kubernetes para agendar e implantar versões.

O AKS oferece um serviço de Kubernetes gerenciado que reduz a complexidade das tarefas de implantação e de gerenciamento principais. A plataforma Azure gerencia o painel de controle do AKS, e você paga apenas pelos nós de AKS que executam seus aplicativos.

Arquitetura de cluster do Kubernetes

Um cluster Kubernetes é dividido em dois componentes:

  • O painel de controle fornece os serviços principais do Kubernetes e a orquestração de cargas de trabalho do aplicativo.
  • Nós que executam as cargas de trabalho do aplicativo.

Componentes de nó e painel de controle do Kubernetes

Painel de controle

Ao criar um cluster do AKS, a plataforma Azure automaticamente estabelece e configura o painel de controle associado. Esse painel de controle de locatário único é oferecido sem custo como um recurso gerenciado do Azure abstraído do usuário. Você paga apenas pelos nós anexados ao cluster do AKS. O painel de controle e os recursos dele ficam restritos à região onde você criou o cluster.

O painel de controle inclui os seguintes componentes principais do Kubernetes:

Componente Descrição
kube-apiserver O servidor de API expõe as APIs subjacentes do Kubernetes e fornece a interação para ferramentas de gerenciamento como o kubectl ou o painel do Kubernetes.
etcd O etcd é um repositório de chave-valor altamente disponível no Kubernetes que ajuda a manter o estado do cluster e da configuração do Kubernetes.
kube-scheduler Quando você cria ou dimensiona aplicativos, o Agendador determina quais nós podem executar a carga de trabalho e iniciar os nós identificados.
kube-controller-manager O gerenciador do controlador supervisiona um número de controladores de menores do que executar ações como replicar pods e lidar com operações de nó.

Tenha em mente que você não pode acessar diretamente o painel de controle. Os upgrades do painel de controle do Kubernetes e do nó são orquestrados por meio do CLI do Azure ou do portal do Azure. Para solucionar possíveis problemas, você pode examinar os logs do painel de controle usando o Azure Monitor.

Observação

Se quiser configurar ou acessar diretamente um painel de controle, você pode implantar um cluster do Kubernetes autogerenciado usando o Provedor de API de Cluster do Azure.

Nós

Para executar seus aplicativos e serviços de suporte, é necessário um Kubernetes nó. Cada cluster AKS tem pelo menos um nó, uma VM (máquina virtual) do Azure que executa os componentes do nó e o runtime do contêiner do Kubernetes.

Os nós incluem os seguintes componentes principais do Kubernetes:

Componente Descrição
kubelet O agente do Kubernetes que processa as solicitações de orquestração do painel de controle, bem como o agendamento e a execução dos contêineres solicitados.
kube-proxy O proxy identifica a rede virtual em cada nó, encaminhando o tráfego de rede e gerenciando o endereçamento IP para serviços e pods.
Tempo de execução de contêiner O runtime do contêiner permite que aplicativos conteinerizados sejam executados e interajam com outros recursos, como a rede virtual e o armazenamento. Para obter mais informações, confira a Configuração de runtime do contêiner.

Máquina virtual do Azure e recursos de suporte para um nó do Kubernetes

O tamanho da VM do Azure para seus nós define as CPUs, memória, tamanho e tipo de armazenamento disponíveis, como SSD de alto desempenho ou HDD comum. Ao planejar o tamanho do nó, considere se os seus aplicativos podem exigir grandes quantidades de CPU e memória ou armazenamento de alto desempenho. Escale horizontalmente o número de nós no seu cluster AKS para atender à demanda. Para obter mais informações sobre dimensionamento, consulte Opções de dimensionamento para aplicativos no AKS.

No AKS, a imagem da VM dos nós de cluster é baseada no Ubuntu Linux, no Azure Linux ou no Windows Server 2022. Quando você cria um cluster AKS ou escala horizontalmente o número de nós, a plataforma do Azure cria e configura automaticamente o número solicitado de VMs. Os nós de agente são cobrados como VMs padrão, portanto, qualquer desconto de tamanho de VM, inclusive reservas do Azure, é aplicado automaticamente.

Para discos gerenciados, o padrão de tamanho e desempenho do disco é atribuído de acordo com a contagem de SKU e vCPU da VM selecionada. Para obter mais informações, consulte o Dimensionamento padrão do disco do sistema operacional.

Observação

Se você precisar de configuração e controle avançados em seu runtime de contêiner do nó e sistema operacional do Kubernetes, poderá implantar um cluster autogerenciado usando o Provedor de API de Cluster do Azure.

Configuração do SO

O AKS dá suporte ao Ubuntu 22.04 e ao Azure Linux 2.0 como o SO (sistema operacional) de nó para clusters com Kubernetes 1.25 e superior. O Ubuntu 18.04 também pode ser especificado na criação do nodepool para as versões 1.24 e inferiores do Kubernetes.

O AKS dá suporte ao Windows Server 2022 como o SO padrão para pools de nós do Windows em clusters com Kubernetes 1.25 e superior. O Windows Server 2019 também pode ser especificado na criação do nodepool para as versões 1.32 e inferiores do Kubernetes. O Windows Server 2019 será desativado após a versão 1.32 do Kubernetes chegar ao fim da vida útil e não terá suporte em versões futuras. Para obter mais informações sobre essa desativação, veja as notas sobre a versão do AKS.

Configuração de runtime do contêiner

O runtime do contêiner é um software que executa contêineres e gerencia imagens de contêineres em um nó. O runtime ajuda a abstrair as chamadas sys ou a funcionalidade específica do SO para executar contêineres no Linux ou no Windows. Para pools de nós do Linux, containerd é usado para pools de nós usando o Kubernetes versão 1.19 e superior. Para pools de nós do Windows Server 2019 e 2022, containerd está em disponibilidade geral e é a única opção de runtime de contêiner no Kubernetes 1.23 e superior. A partir de maio de 2023, o Docker será desativado e não terá mais suporte. Para obter mais informações sobre essa desativação, veja as notas sobre a versão do AKS.

O Containerd é um runtime de contêiner de núcleo em conformidade com a OCI (Open Container Initiative) que fornece o conjunto mínimo de funcionalidades necessárias para executar contêineres e gerenciar imagens em um nó. Com nós baseados em containerd e pools de nós, o kubelet se comunica diretamente com o containerd pelo plug-in da CRI (interface de runtime do contêiner), removendo saltos extras no fluxo de dados em comparação com a implementação de CRI do Docker. Dessa maneira, a latência de inicialização do pod aumenta e o uso de recursos (CPU e memória) diminui.

O Containerd funciona em todas as versões em GA do Kubernetes no AKS, em todas as versões do Kubernetes a partir da 1.19, além de ser compatível com todos os recursos do Kubernetes e do AKS.

Importante

Clusters com pools de nós do Linux criados no Kubernetes v1.19 ou posterior têm containerd como padrão para o runtime de contêiner. Clusters com pools de nós em versões anteriores do Kubernetes com suporte recebem o Docker para seu runtime de contêiner. Os pools de nós do Linux serão atualizados para uma containerd vez que a versão Kubernetes do pool de nós for atualizada para uma versão compatível com o containerd.

O containerd geralmente está disponível para clusters com pools de nós do Windows Server 2019 e 2022 e é a única opção de runtime de contêiner para Kubernetes v1.23 e posterior. Você pode continuar usando pools de nós e clusters do Docker em versões inferiores à 1.23, mas o Docker não terá mais suporte a partir de maio de 2023. Para obter mais informações, consulte Adicionar um pool de nós do Windows Server com containerd.

É altamente recomendável testar suas cargas de trabalho em pools de nós AKS com containerd antes de usar clusters com uma versão Kubernetes que dê suporte a containerd para seus pools de nós.

Limitações/diferenças do containerd

  • Para containerd, recomendamos usar crictl como substituição da CLI do Docker para solucionar problemas de pods, contêineres e imagens de contêineres nos nós do Kubernetes. Para obter mais informações sobre crictl, confira Uso geral e Opções de configuração do cliente.

    • O Containerd não oferece a funcionalidade completa da CLI do Docker. Ele está disponível apenas para solução de problemas.
    • crictl oferece uma exibição mais amigável do Kubernetes de contêineres, com conceitos como pods, etc. presentes.

  • O Containerd configura o registro em log usando o formato de log padronizado cri. Sua solução de registro precisa ser compatível com o formato de registro cri, como o Azure Monitor para Contêineres.

  • Não é mais possível acessar o mecanismo do Docker, /var/run/docker.sock, nem usar o DinD (Docker-in-Docker).

    • Se você atualmente extrai os logs de aplicativo ou monitora dados do mecanismo do Docker, use os Insights de Contêiner. Além disso, o AKS não dá suporte à execução de comandos fora de banda nos nós do agente que possam causar instabilidade.
    • Não recomendamos criar imagens ou usar diretamente o mecanismo do Docker. O Kubernetes não está totalmente ciente desses recursos consumidos, e esses métodos apresentam diversos problemas, conforme descrito aqui e aqui.

  • Ao compilar imagens, é possível continuar usando o fluxo de trabalho de build atual do Docker normalmente, a menos que você esteja compilando imagens no cluster do AKS. Nesse caso, considere a possibilidade de mudar para a abordagem recomendada de compilação de imagens usando as Tarefas do ACR ou uma opção mais segura no cluster, como o Docker Buildx.

Reservas de recursos

O AKS usa recursos de nó para ajudar a função de nó como parte do cluster. Esse uso pode criar uma discrepância entre os recursos totais do seu nó e os recursos alocados no AKS. Lembre-se disso ao definir solicitações e limites para pods implantados pelo usuário.

Para localizar o recurso alocável de um nó, você pode usar o comando kubectl describe node:

kubectl describe node [NODE_NAME]

Para manter o desempenho e a funcionalidade do nó, o AKS reserva dois tipos de recursos, CPU e memória, em cada nó. À medida que um nó aumenta em recursos, a reserva de recursos cresce devido a uma necessidade maior de gerenciamento de pods implantados pelo usuário. Tenha em mente que as reservas de recursos não podem ser alteradas.

Observação

O uso de complementos do AKS, como o Container Insights (OMS), consome recursos de nó adicionais.

CPU

A CPU reservada depende do tipo de nó e da configuração de cluster, o que pode reduzir a CPU alocável devido à execução de recursos adicionais. A tabela a seguir mostra a reserva de CPU em mililitros:

Núcleos de CPU no host 1 2 4 8 16 32 64
Reservado para o Kube (multicores) 60 100 140 180 260 420 740

Memória

A memória reservada no AKS inclui a soma de dois valores:

Importante

O AKS 1.29 entra em versão prévia em janeiro de 2024 e inclui determinadas alterações nas reservas de memória. Essas alterações serão detalhadas na seção a seguir.

AKS 1.29 e versões posteriores

  1. Por padrão, o daemon kubelet tem a regra de remoção memory.available<100Mi. Essa regra garante que um nó tenha pelo menos 100Mi passíveis de alocação em todos os momentos. Quando um host está abaixo do limite de memória disponível, o kubelet dispara o encerramento de um dos pods em execução e libera a memória no computador host.

  2. Uma taxa de reservas de memória definida de acordo com o valor inferior de: 20 MB * número máximo de pods com suporte no nó + 50 MB ou 25% do total de recursos de memória do sistema.

    Exemplos:

    • Se a VM fornecer 8 GB de memória e o nó der suporte a até 30 pods, o AKS reservará 20 MB * 30 pods no máximo + 50 MB = 650 MB para kube-reserved. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
    • Se a VM fornecer 4 GB de memória e o nó der suporte a até 70 pods, o AKS reservará 25% * 4 GB = 1.000 MB para kube-reserved, pois isso é inferior a 20 MB * 70 pods no máximo + 50 MB = 1.450 MB.

    Para obter mais informações, confira Configurar o número máximo de pods por nó em um cluster do AKS.

Versões do AKS anteriores à 1.29

  1. Por padrão, o daemon kubelet tem a regra de remoção memory.available<750Mi. Essa regra garante que um nó tenha pelo menos 750Mi passíveis de alocação em todos os momentos. Quando um host está abaixo do limite de memória disponível, o kubelet dispara o encerramento de um dos pods em execução e libera a memória no computador host.
  2. Uma taxa regressiva de reservas de memória para o daemon kubelet funcionar adequadamente (kube-reserved).
    • 25% dos primeiros 4 GB de memória
    • 20% dos próximos 4 GB de memória (até 8 GB)
    • 10% dos próximos 8 GB de memória (até 16 GB)
    • 6% dos próximos 112 GB de memória (até 128 GB)
    • 2% de qualquer memória com mais de 128 GB

Observação

O AKS reserva mais 2 GB para o processo do sistema em nós do Windows que não fazem parte da memória calculada.

As regras de alocação de memória e CPU foram projetadas para:

  • Mantenha a integridade dos nós de agente, incluindo alguns pods de sistema de hospedagem críticos para a integridade do cluster.
  • Faz com que o nó relate menos memória alocável e CPU do que relataria se ele não fosse parte de um cluster Kubernetes.

Por exemplo, se um nó oferecer 7 GB, ele relatará 34% de memória não alocável, incluindo o limite de remoção rígido de 750Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Além das reservas para o Kubernetes em si, o sistema operacional do nó subjacente também reserva uma quantidade de recursos de CPU e memória para manter o funcionamento das funções do SO.

Para ver as melhores práticas associadas, confira Melhores práticas para recursos básicos do agendador no AKS.

Pools de nós

Observação

O pool de nós do Linux do Azure agora está disponível em geral (GA). Para saber mais sobre os benefícios e as etapas de implantação, consulte a Introdução ao Host de Contêiner Linux do Azure para AKS.

Os nós da mesma configuração são agrupados em conjuntos de nós. Cada cluster do Kubernetes contém pelo menos um pool de nós. Você define o número inicial de nós e os tamanhos ao criar um cluster do AKS, que cria um conjunto de nós padrão. Esse pool de nó padrão no AKS contém as VMs subjacentes que executam o agente de nós.

Observação

Para verificar se o seu cluster opera de maneira confiável, execute pelo menos dois nós no pool de nós padrão.

Você escala ou faz upgrade de um cluster do AKS em relação ao pool de nós padrão. Você pode optar por escalar ou fazer upgrade de um pool de nós específico. Para operações de atualização, os contêineres em execução são planejados em outros nós no conjunto de nós até que todos os nós sejam atualizados com êxito.

Para obter mais informações, confira Criar pools de nós e Gerenciar pools de nós.

Dimensionamento padrão do disco do sistema operacional

Quando você cria um cluster ou quando um novo pool de nós é adicionado a um cluster existente, o número de VCPUs por padrão determina o tamanho de disco do sistema operacional. O número de vCPUs é baseado na SKU da VM. A tabela a seguir lista o tamanho do disco do sistema operacional padrão para cada SKU de VM:

Núcleos da SKU da VM (vCPUs) Camada Padrão do Disco do Sistema Operacional IOPS provisionado Taxa de Transferência Provisionada (Mpbs)
1 – 7 P10/128 G 500 100
8 – 15 P15/256 G 1100 125
16 – 63 P20/512 G 2300 150
64+ P30/1024 G 5.000 200

Importante

O dimensionamento padrão do disco do sistema operacional só é usado em novos clusters ou pools de nós quando não há suporte para discos de SO Efêmero e um tamanho padrão do disco do sistema operacional não foi especificado. O tamanho do disco do sistema operacional padrão pode afetar o desempenho ou o custo do cluster. Não é possível alterar o tamanho do disco do sistema operacional após a criação do pool de nós ou cluster. Esse dimensionamento padrão do disco afeta os clusters ou os pools de nós criados em julho de 2022 ou após essa data.

Seletores de nó

Em um cluster do AKS com vários pools de nó, talvez seja necessário informar ao Agendador do Kubernetes qual pool de nós deve ser usado para um determinado recurso. Por exemplo, controladores de entrada não devem ser executados em nós do Windows Server. Você usará seletores de nó para definir vários parâmetros, como o sistema operacional do nó, para controlar onde um pod deve ser agendado.

O exemplo básico a seguir agenda uma instância do NGINX em um nó do Linux usando o seletor de nó "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Para obter mais informações, confira Práticas recomendadas para recursos avançados do agendador no AKS.

Grupo de recursos do nó

Ao criar um cluster do AKS, você especifica um grupo de recursos do Azure para criar os recursos do cluster. Além desse grupo de recursos, o provedor de recursos do AKS cria e gerencia um grupo de recursos separado chamado grupo de recursos do nó. O grupo de recursos donó contém os seguintes recursos de infraestrutura:

  • Os conjuntos de dimensionamento de máquinas virtuais e as VMs em cada nó nos pools de nós
  • A rede virtual do cluster
  • O armazenamento do cluster

O grupo de recursos do nó recebe um nome por padrão com o seguinte formato: MC_resourceGroupName_clusterName_location. Durante a criação do cluster, você pode especificar o nome atribuído ao grupo de recursos do nó. Ao usar um modelo do ARM, você pode definir o nome usando a propriedade nodeResourceGroup. Ao usar a CLI do Azure, use o parâmetro --node-resource-group com o comando az aks create, conforme mostrado no exemplo a seguir:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

Quando você exclui seu cluster do AKS, o provedor de recursos do AKS exclui automaticamente o grupo de recursos do nó.

O grupo de recursos do nó tem as seguintes limitações:

  • Você não pode especificar um grupo de recursos existente para o grupo de recursos do nó.
  • Você não pode especificar uma assinatura diferente para o grupo de recursos do nó.
  • Você não pode alterar o nome do grupo de recursos do nó após a criação do cluster.
  • Você não pode especificar nomes para os recursos gerenciados dentro do grupo de recursos do nó.
  • Você não pode modificar ou excluir as marcas de recursos gerenciados criadas pelo Azure dentro do grupo de recursos do nó.

A modificação quaisquer Marcas criadas pelo Azure nos recursos do grupo de recursos do nó no cluster do AKS é uma ação não suportada, que quebra o objetivo do nível de serviço (SLO). Se você modificar ou excluir as marcas criadas pelo Azure ou outras propriedades de recursos no grupo de recursos do nó, poderá obter resultados inesperados, como erros de dimensionamento e atualização. O AKS gerencia o ciclo de vida da infraestrutura no grupo de recursos do nó. Portanto, fazer alterações coloca o cluster em um estado sem suporte. Para obter mais informações, confira O AKS oferece um SLA?

O AKS permite criar e modificar marcas que são propagadas para os recursos no grupo de recursos do nó, e você pode adicionar essas marcas ao criar ou atualizar o cluster. O ideal é criar ou modificar marcas personalizadas para atribuir uma unidade de negócios ou um centro de custo, por exemplo. Também é possível é criar políticas do Azure com um escopo no grupo de recursos gerenciados.

Para reduzir a chance de alterações no grupo de recursos do nó que afetam seus clusters, você pode habilitar o bloqueio do grupo de recursos do nó para aplicar uma atribuição de negação aos seus recursos do AKS. para obter mais informações, confira Grupo de recursos totalmente gerenciados (versão prévia).

Aviso

Se você não tiver o bloqueio do grupo de recursos do nó habilitado, poderá modificar diretamente qualquer recurso no grupo de recursos do nó. Modificar diretamente os recursos no grupo de recursos do nó pode fazer com que seu cluster fique instável ou não responda.

Pods

O Kubernetes usa pods para executar instâncias do seu aplicativo. Um único pod representa uma única instância do seu aplicativo.

Os pods normalmente têm um mapeamento de 1:1 com um contêiner. Em cenários avançados, um pod pode conter vários contêineres. Os pods de vários contêineres são agendados juntos no mesmo nó e permitem que os contêineres compartilhem recursos relacionados.

Quando você cria um pod, você pode definir solicitações de recursos para determinada quantidade de CPU ou memória. O Agendador do Kubernetes tenta atender à solicitação ao agendar os pods para serem executados em um nó com recursos disponíveis. Você também pode especificar limites máximos de recursos para impedir que um determinado pod consuma muito recurso de computação do nó subjacente. Nossa melhor prática é incluir limites de recurso para todos os pods para ajudar o Agendador do Kubernetes a identificar recursos necessários e permitidos.

Para obter mais informações, consulte pods Kubernetes e ciclo de vida de pod Kubernetes.

Um pod é um recurso lógico, mas as cargas de trabalho do aplicativo são executadas em contêineres. Pods são normalmente recursos efêmeros e descartáveis. Os pods agendados individualmente perdem alguns dos recursos de alta disponibilidade e redundância do Kubernetes. Em vez disso, os Controladores do Kubernetes, como o Controlador de Implantação, implantam e gerenciam os pods.

Manifestos de implantações e YAML

Uma implantação representa um ou mais pods idênticos gerenciados pelo Controlador de Implantação do Kubernetes. Uma implantação define o número de réplicas de pod a criar. O Agendador do Kubernetes garante que os pods adicionais sejam agendados em nós íntegros se os pods ou nós encontrarem problemas. Você pode atualizar as implantações para alterar a configuração de pods, a imagem do contêiner ou o armazenamento anexado.

O Controlador de Implantação gerencia o ciclo de vida de implantação e executa as seguintes ações:

  • Esvazia e encerra um determinado número de réplicas.
  • Cria réplicas a partir da nova definição de implantação.
  • Continua o processo até que todas as réplicas na implantação sejam atualizadas.

A maioria dos aplicativos sem monitoração de estado no AKS devem usar o modelo de implantação em vez de agendamento pods individuais. O Kubernetes pode monitorar a integridade da implantação e o status para garantir que o número necessário de réplicas seja executado dentro do cluster. Quando você agenda individualmente, os pods não são reiniciados se encontrarem um problema e não são reprogramados em nós saudáveis se o nó atual encontrar um problema.

Recomendamos não interromper as decisões de gerenciamento com um processo de atualização se seu aplicativo exigir um número mínimo de instâncias disponíveis. Orçamentos de interrupção de pod definem quantas réplicas em uma implantação podem ser desativadas durante uma atualização ou upgrade de nó. Por exemplo, se você tiver cinco réplicas em sua implantação, você pode definir uma interrupção de quatro para permitir que apenas uma réplica seja excluída ou reprogramada por vez. Assim como os limites de recursos do pod, nossa melhor prática é definir orçamentos de interrupção de pod em aplicativos que exigem que um número mínimo de réplicas esteja sempre presente.

Implantações geralmente são criadas e gerenciadas com o kubectl create ou kubectl apply. É possível criar uma implantação definindo um arquivo de manifesto no formato YAML. O exemplo a seguir mostra um arquivo de manifesto de implantação básico para um servidor Web NGINX:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Um detalhamento das especificações de implantação no arquivo de manifesto YAML é o seguinte:

Especificação Descrição
.apiVersion Especifica o grupo de API e o recurso de API que você deseja usar ao criar o recurso.
.kind Especifica o tipo de recurso que você deseja proteger.
.metadata.name Especifica o nome da implantação. Este arquivo YAML de exemplo executa a imagem nginx do Docker Hub.
.spec.replicas Especifica quantos pods criar. Este arquivo YAML de exemplo cria três pods duplicados.
.spec.selector Especifica quais pods serão afetados por essa implantação.
.spec.selector.matchLabels Contém um mapa de pares de {chave, valor} que permite que a implantação localize e gerencie os pods criados.
.spec.selector.matchLabels.app Tem que corresponder a .spec.template.metadata.labels.
.spec.template.labels Especifica os pares {key, value} anexados ao objeto.
.spec.template.app Tem que corresponder a .spec.selector.matchLabels.
.spec.spec.containers Especifica a lista de contêineres que pertencem ao pod.
.spec.spec.containers.name Especifica o nome do contêiner especificado como um rótulo DNS.
.spec.spec.containers.image Especifica o nome da imagem de contêiner.
.spec.spec.containers.ports Especifica a lista de portas a serem expostas do contêiner.
.spec.spec.containers.ports.containerPort Especifica o número de porta a ser exposto no endereço IP do pod.
.spec.spec.resources Especifica os recursos de computação exigidos pelo contêiner.
.spec.spec.resources.requests Especifica a quantidade mínima de recursos de computação necessários.
.spec.spec.resources.requests.cpu Especifica a quantidade mínima de CPU necessária.
.spec.spec.resources.requests.memory Especifica a quantidade mínima de memória necessária.
.spec.spec.resources.limits Especifica a quantidade máxima de recursos de computação permitida. O kubelet impõe esse limite.
.spec.spec.resources.limits.cpu Especifica a quantidade máxima de CPU permitida. O kubelet impõe esse limite.
.spec.spec.resources.limits.memory Especifica a quantidade máxima de memória permitida. O kubelet impõe esse limite.

Aplicativos mais complexos podem ser criados incluindo serviços como balanceadores de carga no manifesto YAML.

Para obter mais informações, consulte implantações de Kubernetes.

Gerenciamento de pacotes com Helm

Helm é normalmente usado para gerenciar aplicativos no Kubernetes. Você pode implantar recursos se criar e usar gráficos do Helm público existente, que contêm uma versão empacotada do código do aplicativo e manifestos do YAML do Kubernetes. Você pode armazenar gráficos do Helm localmente ou em um repositório remoto, como um repositório de gráficos do Helm do Registro de Contêiner do Azure.

Para usar o Helm, instale o cliente do Helm no computador ou use o cliente Helm no Azure Cloud Shell. Procure ou crie gráficos de Helm e depois instale-os no seu cluster do Kubernetes. Para obter mais informações, confira Instalar aplicativos existentes com o Helm no AKS.

StatefulSets e DaemonSets

O Controlador de Implantação usa o Agendador do Kubernetes e executa réplicas nos nós disponíveis com os recursos disponíveis. Embora essa abordagem possa ser suficiente para aplicativos sem estado, o controlador de implantação não é ideal para aplicativos que exigem as seguintes especificações:

  • Uma convenção de nomenclatura ou armazenamento persistente.
  • Uma réplica a existir em cada nó escolhido dentro de um cluster.

Dois recursos do Kubernetes, no entanto, permitem gerenciar esses tipos de aplicativos: StatefulSets e DaemonSets.

StatefulSets mantém o estado de aplicativos além do ciclo de vida um pod individual, como o armazenamento. DaemonSets assegura uma instância em execução em cada nó, no início do processo de bootstrap do Kubernetes.

StatefulSets

O desenvolvimento de aplicativos modernos geralmente visa aplicativos sem estado. Para aplicativos com estado, como aqueles que incluem componentes de banco de dados, você pode usar StatefulSets. Como as implantações, um StatefulSet cria e gerencia pelo menos um pod idêntico. As réplicas em um StatefulSet seguem uma abordagem detalhada e sequencial para operações de implantação, dimensionamento, upgrade e terminação. A convenção de nomenclatura, os nomes de rede e o armazenamento persistem à medida que as réplicas são reprogramadas com StatefulSet.

É possível definir o aplicativo no formato YAML usando kind: StatefulSet. A partir daí, o controlador StatefulSet lida com a implantação e o gerenciamento das réplicas necessárias. Gravações de dados no armazenamento persistente, fornecido pelos Discos Gerenciados do Azure ou pelos Arquivos do Azure. Com StatefulSets, o armazenamento persistente subjacente permanece mesmo quando o StatefulSet é excluído.

Para obter mais informações, consulte Kubernetes StatefulSets.

Importante

Réplicas de um StatefulSet sejam agendadas e executadas em qualquer nó disponível em um cluster do AKS. Para garantir que pelo menos um pod no seu conjunto seja executado em um nó, você deve usar um DaemonSet.

DaemonSets

Para coleta ou monitoramento de logs específicos, talvez seja necessário executar um pod em todos os nós ou um conjunto selecionado de nós. Você pode usar DaemonSets para implantar em um ou mais pods idênticos. O Controlador DaemonSet garante que cada nó especificado execute uma instância do pod.

O DaemonSet do controlador pode agendar os pods em nós no início do processo de inicialização do cluster, antes do início do agendador do Kubernetes padrão. Essa capacidade garante que os pods em um estado DaemonSet, antes dos pods tradicionais em uma Implantação ou StatefulSet, sejam agendados.

Como StatefulSets, é possível definir um DaemonSet como parte de uma definição YAML usando kind: DaemonSet.

Para obter mais informações, consulte Kubernetes DaemonSets.

Observação

Se você estiver usando o complemento de nós virtuais, o DaemonSets não criará pods no nó virtual.

Namespaces

Os recursos do Kubernetes, como pods e implantações, são agrupados logicamente no namespace para dividir um cluster do AKS e criar, exibir ou gerenciar o acesso aos recursos. Por exemplo, você pode criar namespaces para separar grupos de negócios. Os usuários podem interagir apenas com recursos dentro de seus namespaces atribuídos.

Espaços de nomes do Kubernetes para dividir logicamente recursos e aplicativos

Os namespaces a seguir estão disponíveis quando você cria um cluster do AKS:

Namespace Descrição
default Onde os pods e as implantações são criadas por padrão quando nenhum seja fornecido. Em ambientes menores, você pode implantar aplicativos diretamente no namespace padrão sem criar separações lógicas adicionais. Quando você interage com a API do Kubernetes, como com kubectl get pods, o namespace padrão é usado quando nenhum é especificado.
kube-system Onde os recursos principais existem, como recursos de rede como DNS e proxy, ou o painel do Kubernetes. Normalmente, você não implantar seus próprios aplicativos para esse namespace.
kube-public Normalmente não é usado, mas você pode usá-lo para que os recursos fiquem visíveis em todo o cluster e possam ser visualizados por todos os usuários.

Para obter mais informações, consulte Kubernetes namespaces.

Próximas etapas

Para obter mais informações sobre os principais conceitos do Kubernetes e do AKS, confira os seguintes artigos: