Conceitos do Kubernetes

Implantar aplicações em várias máquinas (usando contêineres implantados em pods)

Monitorar a integridade de contêineres e reiniciar contêineres que falharam

Aumentar ou reduzir a escala dos contêineres verticalmente dependendo da carga

Atualizar os contêineres com versões novas

Alocar recursos entre contêineres

Equilibrar o tráfego entre máquinas

Conteinerizado: o Kubernetes é uma ferramenta de orquestração de contêineres. Para usar o Kubernetes, suas aplicações deverão ser conteinerizadas primeiro. Dependendo do tipo de aplicação, isso pode ocorrer na forma de um conjunto de microsserviços, como trabalhos em lotes ou em outras formas. Então, suas aplicações podem utilizar um fluxo de trabalho do Kubernetes que engloba um enorme ecossistema de ferramentas e em que os contêineres podem ser armazenados como imagens em um registro de contêineres, implantados em um cluster do Kubernetes e executados em um nó disponível. É possível criar e testar contêineres individuais em seu computador local com o Docker ou outro runtime de contêiner antes de implantá-los em seu cluster do Kubernetes.

Escalável: se a demanda por suas aplicações exceder a capacidade das instâncias em execução dessas aplicações, o Kubernetes poderá aumentar a escala verticalmente. Conforme necessário, o Kubernetes pode dizer se as aplicações precisam de mais CPU ou memória e responder expandindo automaticamente a capacidade disponível ou usando mais da capacidade existente. O aumento da escala pode ser feito no nível do pod, se houver computação suficiente disponível para executar mais instâncias da aplicação (escalação automática horizontal do pod), ou no nível do nó, se mais nós precisarem ser criados para lidar com o aumento da capacidade (Cluster Autoscaler ou Karpenter). Como a capacidade não é mais necessária, esses serviços podem excluir pods desnecessários e desligar nós desnecessários.

Disponível: se uma aplicação ou um ou nó não estiver íntegro ou disponível, o Kubernetes poderá mover as workloads em execução para outro nó disponível. Você pode forçar o problema simplesmente excluindo uma instância em execução de uma workload ou um nó que esteja executando suas workloads. O ponto principal aqui é que as workloads poderão ser levadas para outros locais se não for mais possível executá-las onde estão.

Declarativo: o Kubernetes usa a reconciliação ativa para verificar constantemente se o estado que você declarou para o cluster corresponde ao estado real. Ao aplicar objetos do Kubernetes a um cluster, normalmente por meio de arquivos de configuração formatados em YAML, é possível, por exemplo, solicitar a inicialização das workloads que você deseja executar no cluster. Posteriormente, é possível alterar as configurações para fazer algo como usar uma versão posterior de um contêiner ou alocar mais memória. O Kubernetes fará o que for necessário para estabelecer o estado desejado. Isso pode incluir ativar ou desativar nós, interromper e reiniciar workloads ou obter contêineres atualizados.

Combinável: como uma aplicação geralmente consiste em vários componentes, você quer poder gerenciar um conjunto desses componentes (geralmente representado por vários contêineres) juntos. Embora o Docker Compose ofereça uma maneira de fazer isso diretamente com o Docker, o comando Kompose do Kubernetes pode ajudar você a fazer isso com o Kubernetes. Consulte Traduzir um arquivo do Docker Compose em recursos do Kubernetes para ver um exemplo de como fazer isso.

Extensível: ao contrário de software proprietário, o projeto de código aberto do Kubernetes foi desenvolvido para ser aberto para você, estendendo o Kubernetes da maneira que você quiser para atender às suas necessidades. As APIs e os arquivos de configuração são abertos para modificações diretas. Incentivamos todos a criar seus próprios controladores para ampliar a infraestrutura e os recursos do usuário final do Kubernetes. Os webhooks permitem que você configure regras de cluster para aplicar políticas e se adaptar às mudanças nas condições. Para obter mais ideias sobre como estender clusters do Kubernetes, consulte Estender o Kubernetes.

Portátil: muitas organizações padronizaram suas operações no Kubernetes porque isso permite que elas gerenciem todas as necessidades das respectivas aplicações da mesma forma. Os desenvolvedores podem usar os mesmos pipelines para criar e armazenar aplicações conteinerizadas. Essas aplicações podem então ser implantadas em clusters do Kubernetes executados on-premises, em nuvens, em terminais de ponto de venda em restaurantes ou em dispositivos de IoT distribuídos pelos locais remotos da empresa. Sua natureza de código aberto permite que as pessoas desenvolvam essas distribuições especiais do Kubernetes, junto com as ferramentas necessárias para gerenciá-las.

Hardware: se você não tiver hardware disponível para executar o Kubernetes de acordo com suas necessidades, um provedor de nuvem como o Amazon EKS da AWS pode ajudar a economizar nas despesas iniciais. Com o Amazon EKS, isso significa que é possível consumir os melhores recursos de nuvem oferecidos pela AWS, incluindo instâncias de computador (Amazon Elastic Compute Cloud), seu próprio ambiente privado (Amazon VPC), gerenciamento central de identidade e permissões (IAM) e armazenamento (Amazon EBS). A AWS gerencia os computadores, as redes, os data centers e todos os outros componentes físicos necessários para executar o Kubernetes. Da mesma forma, você não precisa planejar seu data center para lidar com a capacidade máxima nos dias de maior demanda. Para o Amazon EKS Anywhere ou outros clusters do Kubernetes on-premises, você é responsável por gerenciar a infraestrutura usada em suas implantações do Kubernetes, mas ainda pode contar com a AWS para manter o Kubernetes atualizado.

Ambiente de gerenciamento: o Amazon EKS gerencia a segurança e a disponibilidade do ambiente de gerenciamento do Kubernetes hospedado pela AWS, a qual é responsável por agendar contêineres, gerenciar a disponibilidade de aplicações e outras tarefas importantes para que você possa se concentrar em suas workloads de aplicações. Se seu cluster falhar, é esperado que a AWS tenha os meios necessários para restaurá-lo para um estado de execução. Para o Amazon EKS Anywhere, você mesmo gerenciaria o ambiente de gerenciamento.

Atualizações testadas: ao atualizar seus clusters, você pode confiar no Amazon EKS ou no Amazon EKS Anywhere para fornecer versões testadas de suas distribuições do Kubernetes.

Complementos: existem centenas de projetos criados para ampliar e trabalhar com o Kubernetes e que podem ser adicionados à infraestrutura do cluster ou usados para auxiliar na execução de workloads. Para que você não precise criar e gerenciar esses complementos por conta própria, o AWS fornece complementos do Amazon EKS que você pode usar com seus clusters. O Amazon EKS Anywhere fornece pacotes selecionados que incluem compilações de muitos projetos populares de código aberto. Assim, você não precisa criar o software sem ajuda ou gerenciar patches críticos de segurança, correções de bugs ou atualizações. Da mesma forma, se os padrões atenderem às suas necessidades, é normal que esses complementos exijam muito pouca configuração. Consulte Estender clusters para obter detalhes sobre como estender seu cluster com complementos.

Ambiente de gerenciamento gerenciado: o AWS garante que o cluster do Amazon EKS esteja disponível e seja escalável, pois ele gerencia o ambiente de gerenciamento para você e o disponibiliza em todas as zonas de disponibilidade da AWS.

Gerenciamento de nós: em vez de adicionar nós manualmente, você pode fazer com que o Amazon EKS crie nós automaticamente conforme necessário, seja usando grupos de nós gerenciados ou o Karpenter. Os grupos de nós gerenciados têm integrações com o escalonamento automático de clusters do Kubernetes. Usando ferramentas de gerenciamento de nós, você pode se beneficiar da economia de custos graças a recursos como instâncias spot, consolidação e disponibilidade de nós e utilização de recursos de programação para definir como as workloads são implantadas e os nós são selecionados.

Rede de clusters: usando modelos do CloudFormation, o eksctl configura a rede entre os componentes do ambiente de gerenciamento e do plano de dados (nó) no cluster do Kubernetes. Ele também configura endpoints por meio dos quais as comunicações internas e externas podem ocorrer. Consulte Desmistificar redes de cluster para nós de processamento do Amazon EKS para obter detalhes. A comunicação entre pods no Amazon EKS é feita via Identidades de pods do Amazon EKS, que fornecem um meio de permitir que os pods usem métodos de gerenciamento de credenciais e permissões na Nuvem AWS.

Complementos: o Amazon EKS evita que você precise criar e adicionar componentes de software que são comumente usados para oferecer suporte a clusters do Kubernetes. Por exemplo, quando você cria um cluster do Amazon EKS via Console de Gerenciamento da AWS, ele adiciona automaticamente o kube-proxy do Amazon EKS, o plug-in do Amazon VPC CNI para Kubernetes e os complementos do CoreDNS. Consulte Complementos do Amazon EKS para saber mais sobre esses complementos, incluindo uma lista de quais estão disponíveis.

Comunicação com os componentes do cluster (servidor de API): o servidor de API (kube-apiserver) expõe a API do Kubernetes para que as solicitações ao cluster possam ser feitas interna e externamente ao cluster. Em outras palavras, as solicitações para adicionar ou alterar os objetos de um cluster (pods, serviços, nós etc.) podem vir de comandos externos, como solicitações de kubectl para executar um pod. Da mesma forma, as solicitações podem ser feitas do servidor da API para componentes dentro do cluster, como uma consulta ao serviço kubelet para saber o status de um pod.

Armazenar dados sobre o cluster (armazenamento de valore de chave de etcd): o serviço etcdexerce a função crítica de acompanhar o estado atual do cluster. Se o serviço etcd se tornasse inacessível, você não conseguiria atualizar ou consultar o status do cluster, embora as workloads continuassem sendo executadas por algum tempo. Por esse motivo, os clusters críticos geralmente têm várias instâncias do serviço etcd com balanceamento de carga em execução ao mesmo tempo e fazem backups periódicos do armazenamento dos valores de chave do etcd para o caso de perda ou corrompimento de dados. Lembre-se de que, no Amazon EKS, tudo isso é gerenciado automaticamente para você por padrão. O Amazon EKS Anywhere fornece instruções sobre backup e restauração de etcd. Consulte o Modelo de dados do etcd para saber como o etcd gerencia dados.

Agendar pods em nós (agendador): as solicitações para iniciar ou interromper um pod no Kubernetes são direcionadas para o Agendador do Kubernetes (kube-scheduler). Como um cluster pode ter vários nós capazes de executar o pod, cabe ao agendador escolher em qual nó (ou nós, no caso de réplicas) o pod deve ser executado. Se não houver capacidade disponível suficiente para executar o pod solicitado em um nó existente, a solicitação falhará, a menos que você tenha feito outras provisões. Essas provisões podem incluir a habilitação de serviços, como grupos de nós gerenciados ou o Karpenter, que podem iniciar automaticamente novos nós para lidar com as workloads.

Manter os componentes no estado desejado (Controller Manager): o Kubernetes Controller Manager é executado como um processo daemon (kube-controller-manager) para observar o estado do cluster e fazer alterações no cluster para restabelecer os estados esperados. Em particular, existem vários controladores que vigiam objetos Kubernetes diferentes, incluindo um statefulset-controller, endpoint-controller, cronjob-controller, node-controller e outros.

Gerenciar recursos de nuvem (Cloud Controller Manager): as interações entre Kubernetes e o provedor de nuvem que realiza as solicitações dos recursos subjacentes do data center são gerenciadas pelo Cloud Controller Manager (cloud-controller-manager). Os controladores gerenciados pelo Cloud Controller Manager podem incluir um controlador de rota (para configurar rotas de rede na nuvem), controlador de serviço (para usar serviços de balanceamento de carga na nuvem) e controlador de ciclo de vida de nós (para manter os nós sincronizados com o Kubernetes durante os ciclos de vida).

Gerenciar cada nó (kubelet): o servidor da API se comunica com o serviço kubelet em execução em cada nó para garantir que o nó esteja registrado corretamente e que os pods solicitados pelo agendador estejam em execução. O kubelet pode ler os manifestos do Pod e configurar volumes de armazenamento ou outros recursos necessários aos Pods no sistema local. Ele também pode verificar a integridade dos contêineres executados localmente.

Executar contêineres em um nó (runtime de contêiner): o runtime de contêiner em cada nó gerencia os contêineres solicitados para cada pod atribuído ao nó. Isso significa que ele pode extrair imagens do contêiner do registro apropriado, executar o contêiner, interrompê-lo e responder às consultas sobre o contêiner. O runtime de contêiner padrão é containerd. A partir do Kubernetes versão 1.24, a integração especial do Docker (dockershim) que poderia ser usada como runtime de contêiner foi removida do Kubernetes. Embora ainda seja possível usar o Docker para testar e executar contêineres em seu sistema local, para usar o Docker com o Kubernetes, agora é necessário Instalar o mecanismo do Docker em cada nó para usá-lo com o Kubernetes.

Gerenciar a rede entre contêineres (kube-proxy): para que seja possível oferecer suporte à comunicação entre pods usando serviços, o Kubernetes precisava de uma forma de configurar redes de pods para rastrear endereços IP e portas associadas a esses pods. O serviço kube-proxy é executado em cada um dos nós para permitir que a comunicação entre os pods ocorra.

Uma imagem base: uma imagem base de contêiner é um contêiner que normalmente é construído usando uma versão mínima do sistema de arquivos de um sistema operacional (como Red Hat Enterprise Linux ou Ubuntu) ou de um sistema mínimo que é aprimorado para fornecer software para executar tipos específicos de aplicações (como aplicações nodejs ou python).

Software de aplicação: é possível adicionar o software de aplicação ao seu contêiner da mesma forma que adicionaria a um sistema Linux. Por exemplo, em seu Dockerfile, você pode executar npm e yarn para instalar um aplicativo Java ou yum e dnf para instalar pacotes RPM. Em outras palavras, com um comando RUN em um Dockerfile, é possível executar qualquer comando que esteja disponível no sistema de arquivos da sua imagem base para instalar ou configurar o software dentro da imagem de contêiner resultante.

Instruções: a Referência do Dockerfile descreve as instruções que podem ser adicionadas a um Dockerfile ao configurá-lo. Isso inclui instruções usadas para criar o que está no próprio contêiner (ADD ou COPY arquivos do sistema local), identificar comandos para executar quando o contêiner for executado (CMD ou ENTRYPOINT) e conectar o contêiner ao sistema em que ele é executado (identificando o USER de execução, um VOLUME local para montagem ou as portas para EXPOSE).

Armazenamento: quando um contêiner em execução for interrompido e excluído, o armazenamento de dados desse contêiner desaparecerá, a menos que você configure um armazenamento mais permanente. O Kubernetes oferece suporte a muitos tipos diferentes de armazenamento e os abstrai sob a égide de Volumes. Os tipos de armazenamento incluem CephFS, NFS, iSCSI e outros. Você pode até mesmo usar um dispositivo de blocos local conectado ao computador local. Com um desses tipos de armazenamento disponíveis no cluster, é possível montar o volume de armazenamento em um ponto de montagem selecionado no sistema de arquivos do contêiner. Um volume persistente é aquele que continua existindo depois que o pod é excluído, enquanto um volume efêmero é removido quando o pod é excluído. Se o administrador do cluster criou StorageClasses diferentes para seu cluster, talvez você tenha a opção de escolher os atributos do armazenamento que você usa, por exemplo, se o volume é excluído ou recuperado após o uso, se ele se expandirá se for necessário mais espaço e até mesmo se ele atende a determinados requisitos de performance.

Segredos: ao tornar os segredos disponíveis para contêineres nas especificações do Pod, você pode fornecer as permissões de que esses contêineres precisam para acessar sistemas de arquivos, bancos de dados ou outros ativos protegidos. Chaves, senhas e tokens estão entre os itens que podem ser armazenados como segredos. O uso de segredos faz com que você não precise armazenar essas informações em imagens de contêineres, mas apenas disponibilizá-los para contêineres em execução. ConfigMaps são semelhantes a segredos. Um ConfigMap tende a conter informações menos críticas, como pares de chave-valor para configurar um serviço.

Recursos de contêiner: os objetos para configuração adicional de contêineres podem assumir a forma de configuração de recursos. Para cada contêiner, é possível solicitar a quantidade de memória e CPU que ele pode usar, bem como impor limites para a quantidade total desses recursos que o contêiner pode usar. Consulte Gerenciamento de recursos para pods e contêineres para obter exemplos.

Interrupções: os pods podem ser interrompidos involuntariamente (um nó torna-se inativo) ou voluntariamente (uma atualização é necessária). Ao configurar um orçamento de interrupção do pod, é possível exercer algum controle sobre a disponibilidade da sua aplicação quando interrupções ocorrem. Consulte Especificação de um orçamento de interrupção para sua aplicação para obter exemplos.

Namespaces: o Kubernetes fornece maneiras diferentes de isolar componentes e workloads do Kubernetes uns dos outros. Executar todos os pods de uma aplicação específica no mesmo Namespace é uma forma comum de proteger e gerenciar esses pods juntos. Você pode criar seus próprios namespaces para usar ou optar por não indicar um namespace (o que faz com que o Kubernetes use o namespace default). Os componentes do ambiente de gerenciamento do Kubernetes normalmente são executados no namespace kube-system.

Aplicações sem estado: uma aplicação sem estado não salva os dados da sessão do cliente, portanto, outra sessão não precisa fazer referência ao que aconteceu em uma sessão anterior. Isso torna mais fácil simplesmente substituir os pods por novos caso eles percam a integridade ou movê-los sem salvar o estado. Se você estiver executando uma aplicação sem estado (como um servidor Web), poderá usar uma implantação para implantar pods e ReplicaSets. Um ReplicaSet define quantas instâncias de um pod você deseja executar simultaneamente. Embora seja possível executar um ReplicaSet diretamente, é comum executar réplicas diretamente em uma implantação para definir quantas réplicas de um pod devem ser executadas por vez.

Aplicações com estado: uma aplicação com estado é aquela em que a identidade do pod e a ordem na qual os pods são lançados são importantes. Essas aplicações precisam de armazenamento persistente que seja estável e que precise ser implantado e escalado de forma consistente. Para implantar uma aplicação com estado em Kubernetes, é possível usar StatefulSets. Um exemplo de aplicação que normalmente é executada como StatefulSet é um banco de dados. Em um StatefulSet, é possível definir réplicas, o pod e seus contêineres, volumes de armazenamento a serem montados e locais no contêiner em que os dados são armazenados. Consulte Executar uma aplicação com estado replicada para obter um exemplo de banco de dados sendo implantado como um ReplicaSet.

Aplicações por nó: há momentos em que você deseja executar uma aplicação em cada nó do seu cluster do Kubernetes. Por exemplo, seu data center pode exigir que cada computador execute uma aplicação de monitoramento ou um serviço de acesso remoto específico. Para o Kubernetes, é possível usar um DaemonSet para garantir que a aplicação selecionada seja executada em todos os nós do seu cluster.

Aplicações executadas até a conclusão: há algumas aplicações que você deseja executar para concluir uma tarefa específica. Isso pode incluir uma que gere relatórios de status mensais ou limpe dados antigos. Um objeto Job pode ser usado para configurar uma aplicação para inicializar e executar e, em seguida, sair quando a tarefa for concluída. Um objeto CronJob permite configurar uma aplicação para ser executado em uma hora, minuto, dia do mês, mês ou dia da semana específicos usando uma estrutura definida pelo formato crontab do Linux.

Serviços: como um pod pode ser movido para diferentes nós e endereços, um outro pod que precisasse se comunicar com o primeiro pod poderia enfrentar dificuldades para descobrir onde ele está. Para resolver esse problema, o Kubernetes permite representar uma aplicação como um Service. Com um serviço, é possível identificar um pod ou conjunto de pods com um nome específico e, em seguida, indicar qual porta expõe o serviço dessa aplicação do pod e quais portas outra aplicação poderia usar para entrar em contato com esse serviço. Outro pod em um cluster pode simplesmente solicitar um Service pelo nome, e o Kubernetes direcionará essa solicitação para a porta adequada para uma instância do pod executando esse serviço.

Entrada: Ingress é o que pode disponibilizar aplicações representadas por serviços do Kubernetesdisponíveis para clientes que estão fora do cluster. Os recursos básicos de Ingress incluem um balanceador de carga (gerenciado pelo Ingress), o controlador do Ingress e regras para rotear solicitações do controlador para o Service. Existem vários controladores de Ingress que você pode escolher com o Kubernetes.

Criar um cluster simples

Criar um cluster mais complexo

Implantar uma aplicação de exemplo

Explorar formas de gerenciar seu cluster