Pods, implantações e conjuntos de réplicas: explicações sobre os recursos do Kubernetes

O Kubernetes não é conhecido por ser acessível. Para dominar o Kubernetes, você precisa entender como suas abstrações se encaixam. O Kubernetes vem com dezenas de tipos de recursos que você pode usar em seus aplicativos. Vejamos as funções dos recursos usados ​​com mais frequência.

Pods

Se houver um termo do Kubernetes para aprender, é “ Pod. ” Os pods são a unidade de computação fundamental usada pelo Kubernetes. Eles hospedam seus contêineres em execução. Por esse motivo, é comum comparar um pod a uma instância de um contêiner do Docker.

Essa semelhança não é exata, pois um único pod do Kubernetes pode ter vários contêineres em execução. Os pods são melhor vistos como um “ grupo ” de contêineres que possuem um contexto de execução compartilhado. O ambiente do pod está isolado; os ambientes de contêineres individuais são sub-isolados.

Os contêineres em um pod são sempre programados no mesmo nó do Kubernetes. Eles serão executados na mesma máquina física e podem compartilhar recursos de armazenamento e rede.

apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-container image: my-image: latest

O manifesto acima criaria manualmente um único pod. O pod executaria um contêiner usando minha imagem: imagem mais recente.

Normalmente, você não gerencia pods diretamente no Kubernetes. Os pods são criados como consequência da adição de outros recursos, como uma implantação (veja abaixo). Você deve tratar seus Pods como unidades efêmeras. O Kubernetes tem controle sobre o pod e pode reagendá-lo para outro nó se os recursos do cluster forem limitados.

Conjuntos de réplicas

Conjuntos de réplicas (geralmente escritos como ReplicaSets, sem espaço) são outra camada de abstração sobre os pods. Os ReplicaSets garantem que haverá um número específico de pods idênticos em execução a qualquer momento.

Ao usar ReplicaSets, você aplica um número mínimo de pods para seu aplicativo. Você especifica o número de pods que devem ser executados simultaneamente. O Kubernetes agenda pods suficientes para atender à disponibilidade mínima definida por você. Lembre-se de que cada pod pode consistir em vários contêineres em execução, dependendo de como seu aplicativo está configurado.

Quando um pod é criado por um ReplicaSet, o Kubernetes atualiza o campo metadata. ownerReferences do pod para incluir a identidade do ReplicaSet. O ReplicaSet pode então estabelecer os pods que controla, para saber se a meta de disponibilidade mínima foi atingida.

ReplicaSets tem um campo de réplicas que define o número de pods a serem executados. Altere esse valor e aplique o manifesto ReplicaSet atualizado ao seu cluster para que o Kubernetes reprograme seus pods para corresponder à nova contagem de réplicas.

Este detalhe destaca um ponto importante sobre ReplicaSets: o Kubernetes apenas garante que o número de pods em execução corresponderá à contagem de réplicas que você especificou. Se você alterar a contagem de réplicas, haverá um período em que mais ou menos pods estarão em execução do que o indicado pelo seu manifesto. O ReplicaSet criará ou excluirá pods até que o número desejado esteja operacional.

apiVersion: apps / v1 kind: ReplicaSet metadata: name: my-replicaset labels: my-label: my-value spec: replicas: 3 selector: matchLabels: my-label: my-value template: metadata: labels: my -label: especificação do meu valor: contêineres: - nome: imagem do contêiner do aplicativo: minha imagem: mais recente

O manifesto acima executaria três réplicas da minha imagem: imagem de contêiner mais recente usando um ReplicaSet. Você pode alterar o número de réplicas atualizando o valor no manifesto e reaplicando-o (kubectl apply -f my-manifest. yml).

Implantações

Embora os ReplicaSets facilitem o trabalho com pods, eles também raramente são usados ​​diretamente. As implantações são uma abstração sobre ReplicaSets. Normalmente, você cria uma implantação ao adicionar uma nova carga de trabalho a um cluster.

Os recursos de implantação permitem atualizações declarativas de pods e ReplicaSets. Eles permitem que você execute atualizações contínuas de ReplicaSets, onde os pods são reprogramados sem qualquer tempo de inatividade do serviço. Os pods e ReplicaSets são substituídos individualmente, permitindo que versões novas e antigas coexistam brevemente.

A necessidade de implantações surgiu do Kubernetes &’ abordagem histórica das réplicas. ReplicaSets evoluiu a partir de controladores de replicação. Os controladores de replicação ofereciam funcionalidade semelhante a ReplicaSets, mas com suporte de escalonamento integrado.

No entanto, os controladores de replicação não oferecem escalonamento declarativo. Você teve que usar manualmente kubectl rolling-update para dimensionar as réplicas sem tempo de inatividade. Isso estava em desacordo com a abordagem baseada em manifesto declarativo de outros recursos do Kubernetes.

Em comparação com ReplicaSets, a principal vantagem das implantações é o suporte para atualizações contínuas. Alterar o número de réplicas em um ReplicaSet não garante que qualquer número de pods permanecerá em qualquer estado durante a implementação. Com uma implantação, você pode ter certeza de que seu aplicativo continuará gerindo tráfego, mesmo que a implantação ainda não tenha sido concluída.

Hoje, o Kubernetes aconselha o uso de implantações para representar suas cargas de trabalho. Suas implantações serão executadas e escalonadas ReplicaSets automaticamente; ReplicaSets, por sua vez, gerenciará seus pods. Você pode realizar uma atualização contínua de uma implantação, atualizando o campo de réplicas em seu manifesto. O Kubernetes irá garantir que seu aplicativo permaneça disponível durante toda a mudança, permitindo que pods novos e antigos coexistam temporariamente.

apiVersion: apps / v1 kind: Metadados de implantação: nome: my-deployment labels: my-label: my-value spec: replicas: 3 selector: matchLabels: my-label: my-value template: metadata: labels: my -label: especificação do meu valor: contêineres: - nome: imagem do contêiner do aplicativo: minha imagem: mais recente

O manifesto acima criaria uma implantação que consiste em três réplicas, cada uma executando a imagem de contêiner my-image: latest. Alterar o valor das réplicas acionaria uma atualização contínua dos ReplicaSets e pods subjacentes.

Outros tipos de recursos

Os três tipos de recursos que examinamos são os objetos mais comuns que você encontrará ao trabalhar com o Kubernetes. Eles são usados ​​para configurar as cargas de trabalho de seu aplicativo e gerenciar seus contêineres.

Você precisará usar outros tipos de recurso à medida que trabalhar mais com o Kubernetes. ConfigMaps e segredos permitem injetar configuração em seus pods, permitindo que eles acessem valores externos. Volumes e Volumes persistentes fornecem pods com um sistema de arquivos gravável compartilhado que pode ser usado para armazenar dados, em vez do armazenamento temporário padrão que é perdido quando o pod é encerrado.

Um outro conjunto de recursos ajuda a gerenciar as opções de rede da sua carga de trabalho. Os serviços permitem que você exponha um conjunto de pods como um único serviço de rede com um endereço IP. Ingressos permitem expor serviços externamente. Eles encaminham o tráfego para o cluster para um serviço de destino com base em atributos como nome do host, porta e caminho de URL.

Finalmente, existem meta-recursos que descrevem o seu cluster. Os namespaces são usados ​​para isolar cargas de trabalho individuais, evitando colisões de nomes. Normalmente, você deve criar um novo namespace para cada uma de suas cargas de trabalho independentes. Os nós são um tipo de recurso que representa as máquinas físicas que executam seus pods. Cada nó geralmente hospeda vários pods. O Kubernetes descobre como agendar cargas de trabalho com base na disponibilidade de cada nó e nas restrições que você aplica.

Você pode ver a lista completa de recursos do seu cluster executando kubectl api-resources. Além dos recursos integrados, as cargas de trabalho podem adicionar suas próprias definições de recursos personalizados (CRDs), que permitem criar novos tipos de objeto. O Kubernetes fornece pontos de extremidade de API automaticamente para definições de recursos personalizados.

Conclusão

Aprender Kubernetes significa se familiarizar com novas abstrações e terminologias. Embora isso crie uma ampla área de superfície da API, cada objeto Kubernetes tem uma finalidade relativamente estreita.

Freqüentemente, você será capaz de se limitar a abstrações de alto nível, como implantações. Não deve ser necessário microgerenciar tipos de recursos fundamentais, como pods, a menos que tenha requisitos complexos que não podem ser resolvidos apenas com implantações e ReplicaSets.