0

Kurbernerts com azure cloud

A
Alfredo Neto

Conceitos de Kubernetes para o serviço de Kubernetes do Azure (AKS)

  • 05/03/2020
  • 16 minutos para o fim da leitura

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:

  • Principais componentes da infraestrutura do Kubernetes:
  • painel de controle
  • nós
  • pools de nós
  • Recursos de carga de trabalho:
  • pods
  • implantações
  • conjuntos
  • Como agrupar recursos em 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. O AKS é criado sobre o mecanismo open-source do Serviço de Kubernetes do Azure: aks-engine.

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.

Componentes de nó e painel de controle do Kubernetes

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:

PAINEL DE CONTROLE

ComponenteDescriçãokube-apiserverO 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.etcdPara 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-schedulerQuando você cria ou dimensiona aplicativos, o Agendador determina quais nós podem executar a carga de trabalho e iniciá-los.kube-controller-managerO 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ó.

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 painel de controle, implante seu próprio cluster do Kubernetes com o aks-engine.

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

Nós e pools de nós

Para executar seus aplicativos e serviços de suporte, é necessário um Kubernetes . 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.

NÓS E POOLS DE NÓS

ComponenteDescriçãokubeletO agente do Kubernetes que processa as solicitações de orquestração do painel de controle e o agendamento da execução dos contêineres solicitados.kube-proxyTrata 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êinerPermite 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.

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

O tamanho de VM do Azure para seus nós define as CPUs, memória, tamanho e tipo disponíveis (como SSD de alto desempenho ou HD 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.

No AKS, a imagem da VM dos nós do cluster é baseada no Ubuntu 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.

Implante seu próprio cluster Kubernetes com o aks-engine se estiver usando um sistema operacional de host diferente, runtime de contêiner ou incluindo pacotes personalizados diferentes. O aks-engine upstream libera recursos e oferece opções de configuração antes do suporte em clusters do AKS. Portanto, se quiser usar um runtime de contêiner diferente de containerd ou Docker, você poderá executaraks-engine para configurar e implantar um cluster Kubernetes que atenda às suas necessidades atuais.

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

Copiar

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.
  • TABELA 3
  • Núcleos de CPU no host1248163264Reservado para o Kube (multicores)60100140180260420740
  • Memória
  • A memória usada pelo AKS inclui a soma de dois valores.
  1. daemon kubelet
  2. O daemon kubelet é instalado em todos os nós de agente do Kubernetes para gerenciar a criação e o encerramento do contêiner.
  3. Como 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.
  4. 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 primeiros 4 GB de memória (até 8 GB)
  • 10% dos primeiros 8 GB de memória (até 16 GB)
  • 6% dos primeiros 112 GB de memória (até 128 GB)
  • 2% de qualquer memória acima de 128 GB

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

  • 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 haveria se 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

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 vários pools de nós no AKS, confira Criar e gerenciar 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ó "beta.kubernetes.Io/os": linux:

YAML

Copiar

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "beta.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.

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.

YAML

Copiar

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

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 escolhidos. Você pode usar DaemonSet para implantar um ou mais pods idênticos, mas o controlador DaemonSet assegura 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 restringir a criação, a exibição ou o gerenciamento de acesso para os 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

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

NAMESPACES

NamespaceDescriçãodefaultOnde 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-systemOnde 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-publicNormalmente 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.

0
0

Comentários (1)

0
Vagner Bellacosa

Vagner Bellacosa

20/08/2021 16:46

Alfredo, muito bacana seu artigo, sucesso

alfredo gelk neto

Brasil