Conceitos básicos do Kubernetes para o Serviço de Kubernetes do Azure

  • Artigo

O desenvolvimento de aplicativos prossegue na direção de uma abordagem baseada em contêineres, o que aumenta a necessidade de orquestrar e gerenciar recursos. Como a plataforma líder, o Kubernetes oferece um agendamento confiável de cargas de trabalho de aplicativos tolerantes a falhas. Azure Kubernetes Service (AKS), uma oferta de Kubernetes gerenciado que simplifica ainda mais a implantação e o gerenciamento de aplicativos baseados em contêiner.

Este artigo apresenta os principais conceitos:

  • Componentes de infraestrutura do Kubernetes:

    • painel de controle
    • nós
    • pools de nós

  • Recursos de carga de trabalho:

    • pods
    • implantações
    • conjuntos

  • Agrupar recursos usando namespaces.

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, 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 suporta aplicativos sem estado e com estado, à medida que as equipes progridem através da adoção de aplicativos baseados em micros serviços.

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, como a coordenação da upgrade. 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:

  • Painel de controle: fornece os serviços principais do Kubernetes e a orquestração de cargas de trabalho do aplicativo.
  • Nós: executam suas cargas de trabalho do aplicativo.

Kubernetes control plane and node components

Painel de controle

Quando você cria um cluster AKS, um painel de controle é criado e configurado automaticamente. Esse painel de controle é 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 residem apenas na região em que você criou o cluster.

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

Componente Descrição
kube-apiserver O servidor de API é como as APIs do Kubernetes subjacentes são expostas. Esse componente fornece a interação para ferramentas de gerenciamento, tais como kubectl ou o painel do Kubernetes.
etcd Para manter o estado do seu cluster e configuração do Kubernetes, o altamente disponível etcd é um armazenamento de valores chave dentro do Kubernetes.
kube-scheduler Quando você cria ou dimensiona aplicativos, o Agendador determina quais nós podem executar a carga de trabalho e iniciá-los.
kube-controller-manager O Gerenciador do controlador supervisiona um número de controladores menores que executam ações como replicar pods e lidar com operações de nó.

O AKS oferece um painel de controle de locatário único, com um servidor de API dedicado, um agendador, etc. Você define o número e o tamanho dos nós e a plataforma Azure configura a comunicação segura entre o painel de controle e os nós. A interação com o painel de controle ocorre por meio das APIs do Kubernetes, como kubectl ou o painel do Kubernetes.

Embora não seja necessário configurar componentes (como um armazenamento etcd altamente disponível) com esse painel controle gerenciado, não é possível acessá-lo diretamente. 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 por meio dos logs do Azure Monitor.

Para configurar ou acessar diretamente um plano de controle, implante um cluster do Kubernetes autogerenciado usando o Provedor de API de Cluster do Azure.

Para as melhores práticas associadas, confira Melhores práticas para segurança de cluster e atualizações no AKS.

Para gerenciamento de custos do AKS, consulte Noções básicas de custo do AKS e Preços para AKS.

Nós e pools de nós

Para executar seus aplicativos e serviços de suporte, é necessário um Kubernetes nó. Um cluster AKS tem pelo menos um nó, uma máquina virtual (VM) do Azure que executa os componentes do nó e o runtime do contêiner 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 Trata da rede virtual em cada nó. As rotas de proxy o tráfego de rede e gerencia o endereçamento IP para os serviços e os pods.
Tempo de execução de contêiner Permite que aplicativos conteinerizados sejam executados e interajam com recursos adicionais, como a rede virtual e o armazenamento. Os clusters do AKS que usam os pools de nós do Kubernetes versão 1.19 para Linux e superior usam containerd como runtime de contêiner. A partir do Kubernetes versão 1,20 para pools de nós do Windows, o containerd pode ser usado na visualização para o tempo de execução do contêiner, mas o Docker ainda é o tempo de execução de contêiner padrão. Os clusters AKS usando versões anteriores do Kubernetes para pools de nós usam o Docker como seu tempo de execução de contêiner.

Azure virtual machine and supporting resources for a Kubernetes node

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 do cluster é baseada no Ubuntu Linux, no Azure Linux ou no Windows Server 2019. 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 tamanho e o desempenho do disco padrão serão atribuídos 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.

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.

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 encontrar os recursos alocáveis de um nó, execute:

kubectl describe node [NODE_NAME]

Para manter o desempenho e a funcionalidade do nó, o AKS reserva recursos 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.

Observação

O uso de complementos do AKS, como o Insights do contêiner (OMS), consumirá mais recursos de nó.

Dois tipos de recursos são reservados:

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.

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 usada pelo 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. Isso garante que um nó sempre 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. O daemon kubelet é instalado em todos os nós de agente do Kubernetes para gerenciar a criação e o encerramento de contêiner. Por padrão, no AKS, o daemon kubelet tem a regra de remoção memory.available<750Mi, o que garante que um nó precisa ter pelo menos 750 Mi alocáveis o tempo todo. Quando um host estiver abaixo do limite de memória disponível, o kubelet será disparado para encerrar um dos pods em execução e liberar 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 acima de 128 GB

Observação

O AKS reserva 2 GB adicionais 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 fazer o seguinte:

  • 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.

As reservas do recurso acima não podem ser alteradas.

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. Um cluster do Kubernetes contém pelo menos um pool de nós. O número inicial de nós e o tamanho são definidos quando você cria um cluster 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 2 (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 sobre como usar diversos pools de nós no AKS, confira Criar vários pools de nós para um cluster no AKS.

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.

Seletores de nó permitem 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 sobre como controlar onde os pods são agendados, confira Melhores práticas para recursos avançados do agendador no AKS.

Grupo de recursos do nó

Quando você cria um cluster do AKS, precisa especificar um grupo de recursos para criar o recurso do cluster. Além desse grupo de recursos, o provedor de recursos do AKS também 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, como MC_myResourceGroup_myAKSCluster_eastus. Durante a criação do cluster, você também tem a opção de especificar o nome atribuído ao grupo de recursos do nó. 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ó.

Se você modificar ou excluir as marcas criadas pelo Azure e outras propriedades de recursos no grupo de recursos do nó, poderá obter resultados inesperados, como erros de dimensionamento e atualização. Como o AKS gerencia o ciclo de vida da infraestrutura no Grupo de Recursos do Nó, qualquer alteração moverá seu cluster para um estado não suportado.

Um cenário comum em que os clientes desejam modificar recursos é através de marcas. 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, por exemplo, para atribuir uma unidade de negócios ou um centro de custo. Isso também pode ser obtido com a criação de políticas do Azure com um escopo no grupo de recursos gerenciado.

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). Para obter mais informações, confira O AKS oferece um SLA?

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. Mais informações podem ser encontradas na Configuração do Cluster no AKS.

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 uma instância do seu aplicativo. Um 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 solicitar uma determinada quantidade de recursos 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. A 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 pods são implementados e gerenciados pelos Controladores do Kubernetes, como o Controlador de Implantação.

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 usada ou o armazenamento anexado. O Controlador de Implantação:

  • 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 (5) réplicas em sua implantação, você pode definir uma interrupção de quatro (4) para permitir que apenas uma réplica seja excluída ou reprogramada por vez. Assim como os limites de recursos do pod, uma 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. Crie uma implantação definindo um arquivo de manifesto no formato YAML.

O exemplo a seguir cria uma implementação básica do servidor da Web NGINX. A implantação especifica três (3) réplicas a serem criadas e que a porta 80 esteja aberta no contêiner. Solicitações de recursos e limites também são definidos para CPU e memória.

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. Esse arquivo executará a imagem nginx do Docker Hub.
.spec.replicas Especifica quantos pods criar. Esse arquivo criará 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. Esse limite é imposto pelo kubelet.
.spec.spec.resources.limits.cpu Especifica a quantidade máxima de CPU permitida. Esse limite é imposto pelo kubelet.
.spec.spec.resources.limits.memory Especifica a quantidade máxima de memória permitida. Esse limite é imposto pelo kubelet.

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

Usando o Agendador do Kubernetes, o controlador de implantação executa réplicas em qualquer nó disponível com 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:

  • 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 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 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.

Defina 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. Os dados são gravados 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.

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ó, use 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 padrão Agendador Kubernetes foi iniciada. Essa capacidade garante que os pods em um DaemonSet sejam iniciados antes de pods tradicionais em uma implantação ou StatefulSet estão agendados.

Como StatefulSets, um DaemonSet é definido 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 em um 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.

Kubernetes namespaces to logically divide resources and applications

Quando você cria um cluster do AKS, os namespaces a seguir estão disponíveis:

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 pode ser usado para que os recursos sejam 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

Este artigo aborda alguns dos componentes principais do Kubernetes e como elas se aplicam aos clusters AKS. Para obter mais informações sobre os principais conceitos do Kubernetes e do AKS, confira os seguintes artigos: