Conceitos principais do Kubernetes para Azure Kubernetes Service (AKS)

  • Artigo
  • 17 minutos para ler

O desenvolvimento de aplicações continua a avançar para uma abordagem baseada em contentores, aumentando a nossa necessidade de orquestrar e gerir recursos. Como plataforma líder, o Kubernetes fornece um agendamento fiável de cargas de trabalho de aplicações tolerantes a falhas. Azure Kubernetes Service (AKS), uma oferta do Kubernetes gerida, simplifica ainda mais a implementação e a gestão de aplicações baseadas em contentores.

Este artigo apresenta:

  • Componentes principais da infraestrutura do Kubernetes:
    • plano de controlo
    • nós
    • conjuntos de nós
  • Recursos da carga de trabalho:
    • pods
    • implementações
    • conjuntos
  • Como agrupar recursos em espaços de nomes.

O que é o Kubernetes?

O Kubernetes é uma plataforma em rápida evolução que gere aplicações baseadas em contentores e os componentes de rede e armazenamento associados. O Kubernetes concentra-se nas cargas de trabalho da aplicação e não nos componentes de infraestrutura subjacentes. O Kubernetes fornece uma abordagem declarativa às implementações, apoiada por um conjunto robusto de APIs para operações de gestão.

Pode criar e executar aplicações modernas, portáteis e baseadas em microsserviços, com o Kubernetes para orquestrar e gerir a disponibilidade dos componentes da aplicação. O Kubernetes suporta aplicações sem estado e com monitorização de estado à medida que as equipas progridem através da adoção de aplicações baseadas em microsserviços.

Como plataforma aberta, o Kubernetes permite-lhe criar as suas aplicações com a sua linguagem de programação preferida, SO, bibliotecas ou barramento de mensagens. As ferramentas de integração contínua e entrega contínua (CI/CD) existentes podem ser integradas no Kubernetes para agendar e implementar lançamentos.

O AKS fornece um serviço do Kubernetes gerido que reduz a complexidade das tarefas de implementação e gestão principal, como a coordenação de atualizações. A plataforma do Azure gere o plano de controlo do AKS e paga apenas os nós do AKS que executam as suas aplicações.

Arquitetura do cluster do Kubernetes

Um cluster do Kubernetes está dividido em dois componentes:

  • Plano de controlo: fornece os principais serviços do Kubernetes e orquestração de cargas de trabalho de aplicações.
  • Nós: execute as cargas de trabalho da aplicação.

Componentes do plano de controlo e do nó do Kubernetes

Plano de controlo

Quando cria um cluster do AKS, é criado e configurado automaticamente um plano de controlo. Este plano de controlo é proporcionado sem custos como um recurso do Azure gerido abstraído do utilizador. Só paga pelos nós anexados ao cluster do AKS. O plano de controlo e os recursos associados residem apenas na região onde criou o cluster.

O plano de controlo 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. Este componente fornece a interação para ferramentas de gestão, como kubectl ou o dashboard do Kubernetes.
etcd Para manter o estado do cluster e da configuração do Kubernetes, o etcd de elevada disponibilidade é um arquivo de valores chave no Kubernetes.
kube-scheduler Quando cria ou dimensiona aplicações, o Scheduler determina que nós podem executar a carga de trabalho e inicia-as.
kube-controller-manager O Gestor de Controladores supervisiona vários Controladores mais pequenos que executam ações como replicar pods e processar operações de nós.

O AKS fornece um plano de controlo de inquilino único, com um servidor de API dedicado, agendador, etc. Define o número e o tamanho dos nós e a plataforma do Azure configura a comunicação segura entre o plano de controlo e os nós. A interação com o plano de controlo ocorre através das APIs do Kubernetes, como kubectl ou do dashboard do Kubernetes.

Embora não precise de configurar componentes (como um arquivo etc. de elevada disponibilidade) com este plano de controlo gerido, não pode aceder diretamente ao plano de controlo. As atualizações do plano de controlo e do nó do Kubernetes são orquestradas através da CLI do Azure ou portal do Azure. Para resolver possíveis problemas, pode rever os registos do plano de controlo através dos registos do Azure Monitor.

Para configurar ou aceder diretamente a um plano de controlo, implemente um cluster do Kubernetes autogerido com o Fornecedor de API de Clusters do Azure.

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

Para obter informações sobre a gestão de custos do AKS, veja Noções básicas de custos do AKS e Preços do AKS.

Nós e conjuntos de nós

Para executar as suas aplicações e serviços de suporte, precisa de um nó do Kubernetes. Um cluster do AKS tem, pelo menos, um nó, uma máquina virtual (VM) do Azure que executa os componentes do nó do Kubernetes e o runtime de contentor.

Componente Descrição
kubelet O agente do Kubernetes que processa os pedidos de orquestração do plano de controlo, juntamente com o agendamento e execução dos contentores pedidos.
kube-proxy Processa as redes virtuais em cada nó. O proxy encaminha o tráfego de rede e gere o endereçamento IP para serviços e pods.
runtime do contentor Permite que as aplicações em contentores executem e interajam com recursos adicionais, como a rede virtual e o armazenamento. Os clusters do AKS que utilizam o Kubernetes versão 1.19 e superior para conjuntos de nós do Linux utilizam containerd como o respetivo runtime de contentor. A partir do Kubernetes versão 1.20 para conjuntos de nós do Windows, containerd pode ser utilizado na pré-visualização do runtime do contentor, mas o Docker continua a ser o runtime de contentor predefinido. Os clusters do AKS que utilizam versões anteriores do Kubernetes para conjuntos de nós utilizam o Docker como o respetivo runtime de contentor.

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

O tamanho da VM do Azure para os nós define CPUs, memória, tamanho e o tipo de armazenamento disponível (como SSD de alto desempenho ou HDD normal). Planeie o tamanho do nó em torno de se as aplicações podem exigir grandes quantidades de CPU e memória ou armazenamento de alto desempenho. Aumente horizontalmente o número de nós no cluster do AKS para satisfazer a procura. Para obter mais informações sobre o dimensionamento, veja Opções de dimensionamento para aplicações no AKS.

No AKS, a imagem da VM para os nós do cluster baseia-se no Ubuntu Linux, Mariner Linux ou Windows Server 2019. Quando cria um cluster do AKS ou aumenta horizontalmente o número de nós, a plataforma do Azure cria e configura automaticamente o número pedido de VMs. Os nós de agente são faturados como VMs padrão, pelo que todos os descontos de tamanho de VM (incluindo reservas do Azure) são aplicados automaticamente.

Para os discos geridos, o tamanho e o desempenho do disco predefinidos serão atribuídos de acordo com o SKU da VM selecionado e a contagem de vCPUs. Para obter mais informações, veja Dimensionamento do disco do SO predefinido.

Se precisar de configuração e controlo avançados no runtime de contentor do nó do Kubernetes e no SO, pode implementar um cluster autogerido com o Fornecedor de API de Cluster do Azure.

Reservas de recursos

O AKS utiliza recursos de nós para ajudar a função do nó como parte do cluster. Esta utilização pode criar uma discrepância entre o total de recursos do nó e os recursos alocáveis no AKS. Lembre-se destas informações ao definir pedidos e limites para pods implementados pelo utilizador.

Para localizar os recursos alocáveis de um nó, execute:

kubectl describe node [NODE_NAME]

Para manter o desempenho e a funcionalidade dos nós, o AKS reserva recursos em cada nó. À medida que um nó aumenta em recursos, a reserva de recursos aumenta devido a uma maior necessidade de gestão de pods implementados pelo utilizador.

Nota

A utilização de suplementos do AKS, como o Container Insights (OMS), irá consumir recursos de nós adicionais.

Estão reservados dois tipos de recursos:

  • CPU
    A CPU reservada depende do tipo de nó e da configuração do cluster, o que pode causar uma CPU menos alocável devido à execução de funcionalidades adicionais.

    Núcleos de CPU no anfitrião 1 2 4 8 16 32 64
    Kube-reserved (millicores) 60 100 140 180 260 420 740

  • Memória
    A memória utilizada pelo AKS inclui a soma de dois valores.

    1. kubelet daemon
      O kubelet daemon está instalado em todos os nós de agente do Kubernetes para gerir a criação e terminação de contentores.

      Por predefinição no AKS, kubelet o daemon tem a <regra de expulsão 750Mi 750Mi disponível, garantindo que um nó tem sempre de ter sempre, pelo menos, 750 Mi alocáveis. Quando um anfitrião estiver abaixo desse limiar de memória disponível, o acionará kubelet para terminar um dos pods em execução e libertar memória no computador anfitrião.

    2. Uma taxa regressiva de reservas de memória para o daemon do kubelet funcionar corretamente (kube-reserved).

      • 25% dos primeiros 4 GB de memória
      • 20% dos próximos 4 GB de memória (até 8 GB)
      • 10% dos 8 GB seguintes 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

Nota

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

Regras de alocação de memória e CPU:

  • Mantenha os nós do agente em bom estado de funcionamento, incluindo alguns pods de sistema de alojamento críticos para o estado de funcionamento do cluster.
  • Faça com que o nó comunique menos memória e CPU alocáveis do que se não fizesse parte de um cluster do Kubernetes.

As reservas de recursos acima não podem ser alteradas.

Por exemplo, se um nó oferecer 7 GB, reportará 34% da memória não alocável, incluindo o limiar de expulsão 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 próprio Kubernetes, o SO do nó subjacente também reserva uma quantidade de recursos de CPU e memória para manter as funções do SO.

Para obter as melhores práticas associadas, veja Melhores práticas para funcionalidades básicas do agendador no AKS.

Conjuntos de nós

Os nós da mesma configuração são agrupados em conjuntos de nós. Um cluster do Kubernetes contém, pelo menos, um conjunto de nós. O número inicial de nós e tamanho é definido quando cria um cluster do AKS, que cria um conjunto de nós predefinido. Este conjunto de nós predefinido no AKS contém as VMs subjacentes que executam os nós do agente.

Nota

Para garantir que o cluster funciona de forma fiável, deve executar pelo menos dois (2) nós no conjunto de nós predefinido.

Dimensiona ou atualiza um cluster do AKS no conjunto de nós predefinido. Pode optar por dimensionar ou atualizar um conjunto de nós específico. Para operações de atualização, os contentores em execução são agendados noutros nós no conjunto de nós até que todos os nós sejam atualizados com êxito.

Para obter mais informações sobre como utilizar múltiplos conjuntos de nós no AKS, veja Criar e gerir múltiplos conjuntos de nós para um cluster no AKS.

Seletores de nós

Num cluster do AKS com múltiplos conjuntos de nós, poderá ter de indicar ao Kubernetes Scheduler qual o conjunto de nós a utilizar para um determinado recurso. Por exemplo, os controladores de entrada não devem ser executados em nós do Windows Server.

Os seletores de nós permitem-lhe definir vários parâmetros, como o SO do nó, para controlar onde um pod deve ser agendado.

O exemplo básico seguinte agenda uma instância NGINX num nó Linux com o seletor de nós "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 estão agendados, veja Melhores práticas para funcionalidades avançadas do agendador no AKS.

Pods

O Kubernetes utiliza pods para executar uma instância da sua aplicação. Um pod representa uma única instância da sua aplicação.

Normalmente, os pods têm um mapeamento 1:1 com um contentor. Em cenários avançados, um pod pode conter vários contentores. Os pods de vários contentores são agendados em conjunto no mesmo nó e permitem que os contentores partilhem recursos relacionados.

Quando cria um pod, pode definir pedidos de recursos para pedir uma determinada quantidade de recursos de CPU ou memória. O Kubernetes Scheduler tenta cumprir o pedido ao agendar os pods para serem executados num nó com recursos disponíveis. Também pode especificar limites máximos de recursos para impedir que um pod consuma demasiado recurso de computação do nó subjacente. A melhor prática é incluir limites de recursos para todos os pods para ajudar o Kubernetes Scheduler a identificar os recursos necessários e permitidos.

Para obter mais informações, veja O ciclo de vida dos pods do Kubernetes e do Kubernetes.

Um pod é um recurso lógico, mas as cargas de trabalho da aplicação são executadas nos contentores. Os pods são normalmente recursos descartáveis e efémeros. Os pods agendados individualmente não têm algumas das funcionalidades do Kubernetes de elevada disponibilidade e redundância. Em vez disso, os pods são implementados e geridos pelos Controladores do Kubernetes, como o Controlador de Implementação.

Implementações e manifestos YAML

Uma implementação representa pods idênticos geridos pelo Controlador de Implementação do Kubernetes. Uma implementação define o número de réplicas de pods a criar. O Kubernetes Scheduler garante que estão agendados pods adicionais em nós em bom estado de funcionamento se os pods ou os nós encontrarem problemas.

Pode atualizar implementações para alterar a configuração de pods, imagem de contentor utilizada ou armazenamento anexado. O Controlador de Implementação:

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

A maioria das aplicações sem estado no AKS deve utilizar o modelo de implementação em vez de agendar pods individuais. O Kubernetes pode monitorizar o estado e o estado de implementação para garantir que o número necessário de réplicas é executado no cluster. Quando agendados individualmente, os pods não são reiniciados se encontrarem um problema e não serão reagendados em nós em bom estado de funcionamento se o nó atual encontrar um problema.

Não quer interromper as decisões de gestão com um processo de atualização se a sua aplicação exigir um número mínimo de instâncias disponíveis. Os Orçamentos de Interrupção do Pod definem quantas réplicas numa implementação podem ser desativadas durante uma atualização de atualização ou de nó. Por exemplo, se tiver cinco (5) réplicas na sua implementação, pode definir uma interrupção do pod de 4 (quatro) para permitir que apenas uma réplica seja eliminada ou reagendada de cada vez. Tal como acontece com os limites de recursos do pod, a melhor prática é definir orçamentos de interrupção do pod em aplicações que exijam um número mínimo de réplicas para estarem sempre presentes.

Normalmente, as implementações são criadas e geridas com kubectl create ou kubectl apply. Crie uma implementação ao definir um ficheiro de manifesto no formato YAML.

O exemplo seguinte cria uma implementação básica do servidor Web NGINX. A implementação especifica três (3) réplicas a serem criadas e requer que a porta 80 esteja aberta no contentor. Os pedidos de recursos e os 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

Uma discriminação das especificações de implementação no ficheiro de manifesto YAML é a seguinte:

Especificação Description
.apiVersion Especifica o grupo de API e o recurso de API que pretende utilizar ao criar o recurso.
.kind Especifica o tipo de recurso que pretende criar.
.metadata.name Especifica o nome da implementação. Este ficheiro irá executar a imagem nginx a partir de Docker Hub.
.spec.replicas Especifica o número de pods a criar. Este ficheiro irá criar três pods desplicados.
.spec.selector Especifica os pods que serão afetados por esta implementação.
.spec.selector.matchLabels Contém um mapa de pares {key, value} que permite à implementação localizar e gerir os pods criados.
.spec.selector.matchLabels.app Tem de corresponder .spec.template.metadata.labelsa .
.spec.template.labels Especifica os pares {key, value} anexados ao objeto.
.spec.template.app Tem de corresponder .spec.selector.matchLabelsa .
.spec.spec.containers Especifica a lista de contentores pertencentes ao pod.
.spec.spec.containers.name Especifica o nome do contentor especificado como uma etiqueta DNS.
.spec.spec.containers.image Especifica o nome da imagem de contentor.
.spec.spec.containers.ports Especifica a lista de portas a expor a partir do contentor.
.spec.spec.containers.ports.containerPort Especifica o número de porta a expor no endereço IP do pod.
.spec.spec.resources Especifica os recursos de computação necessários para o contentor.
.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 permitidos. Este limite é imposto pelo kubelet.
.spec.spec.resources.limits.cpu Especifica a quantidade máxima de CPU permitida. Este limite é imposto pelo kubelet.
.spec.spec.resources.limits.memory Especifica a quantidade máxima de memória permitida. Este limite é imposto pelo kubelet.

As aplicações mais complexas podem ser criadas ao incluir serviços (como balanceadores de carga) no manifesto YAML.

Para obter mais informações, veja Implementações do Kubernetes.

Gestão de pacotes com o Helm

O Helm é normalmente utilizado para gerir aplicações no Kubernetes. Pode implementar recursos ao criar e utilizar gráficos Helm públicos existentes que contenham uma versão em pacote do código da aplicação e manifestos YAML do Kubernetes. Pode armazenar gráficos Helm localmente ou num repositório remoto, como um Azure Container Registry repositório de gráficos Helm.

Para utilizar o Helm, instale o cliente Helm no seu computador ou utilize o cliente Helm no Azure Cloud Shell. Procure ou crie gráficos Helm e, em seguida, instale-os no cluster do Kubernetes. Para obter mais informações, veja Instalar aplicações existentes com o Helm no AKS.

StatefulSets e DaemonSets

Com o Kubernetes Scheduler, o Controlador de Implementação executa réplicas em qualquer nó disponível com recursos disponíveis. Embora esta abordagem possa ser suficiente para aplicações sem estado, o Controlador de Implementação não é ideal para aplicações que exijam:

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

No entanto, dois recursos do Kubernetes permitem-lhe gerir estes tipos de aplicações:

  • Os StatefulSets mantêm o estado das aplicações para além do ciclo de vida de um pod individual, como o armazenamento.
  • Os DaemonSets garantem uma instância em execução em cada nó, no início do processo de bootstrap do Kubernetes.

StatefulSets

O desenvolvimento de aplicações modernas visa frequentemente aplicações sem estado. Para aplicações com monitorização de estado, como as que incluem componentes de base de dados, pode utilizar StatefulSets. Tal como as implementações, um StatefulSet cria e gere pelo menos um pod idêntico. As réplicas num StatefulSet seguem uma abordagem correta e sequencial à implementação, dimensionamento, atualização e terminação. A convenção de nomenclatura, os nomes de rede e o armazenamento persistem à medida que as réplicas são reagendadas com um StatefulSet.

Defina a aplicação no formato YAML com kind: StatefulSet. A partir daí, o Controlador StatefulSet processa a implementação e a gestão das réplicas necessárias. Os dados são escritos no armazenamento persistente, fornecido pelo Azure Managed Disks ou Ficheiros do Azure. Com StatefulSets, o armazenamento persistente subjacente permanece, mesmo quando o StatefulSet é eliminado.

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

As réplicas num StatefulSet são agendadas e executadas em qualquer nó disponível num cluster do AKS. Para garantir que, pelo menos, um pod no seu conjunto é executado num nó, utilize antes um DaemonSet.

DaemonSets

Para uma recolha ou monitorização de registos específica, poderá ter de executar um pod em todos os nós ou selecionados. Pode utilizar a implementação da DaemonSet num ou mais pods idênticos, mas o Controlador DaemonSet garante que cada nó especificado executa uma instância do pod.

O Controlador DaemonSet pode agendar pods em nós no início do processo de arranque do cluster, antes do agendador do Kubernetes predefinido ter sido iniciado. Esta capacidade garante que os pods num DaemonSet são iniciados antes de os pods tradicionais numa Implementação ou StatefulSet serem agendados.

Tal como StatefulSets, um DaemonSet é definido como parte de uma definição YAML com kind: DaemonSet.

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

Nota

Se utilizar o suplemento Nós Virtuais, o DaemonSets não criará pods no nó virtual.

Espaços de nomes

Os recursos do Kubernetes, como pods e implementações, são agrupados logicamente num espaço de nomes para dividir um cluster do AKS e restringir a criação, vista ou gestão do acesso aos recursos. Por exemplo, pode criar espaços de nomes para separar grupos de negócios. Os utilizadores só podem interagir com recursos dentro dos espaços de nomes atribuídos.

Espaços de nomes do Kubernetes para dividir logicamente recursos e aplicações

Quando cria um cluster do AKS, os seguintes espaços de nomes estão disponíveis:

Espaço de Nomes Description
predefinição Onde os pods e as implementações são criados por predefinição quando não é fornecido nenhum. Em ambientes mais pequenos, pode implementar aplicações diretamente no espaço de nomes predefinido sem criar separações lógicas adicionais. Quando interage com a API do Kubernetes, como com kubectl get pods, o espaço de nomes predefinido é utilizado quando nenhum é especificado.
kube-system Onde existem recursos principais, como funcionalidades de rede, como DNS e proxy, ou o dashboard do Kubernetes. Normalmente, não implementa as suas próprias aplicações neste espaço de nomes.
kube-public Normalmente, não é utilizado, mas pode ser utilizado para que os recursos sejam visíveis em todo o cluster e podem ser visualizados por qualquer utilizador.

Para obter mais informações, veja Kubernetes namespaces (Espaços de nomes do Kubernetes).

Passos seguintes

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