Objetivos

• Aprenda o que é um cluster do Kubernetes.
• Aprenda o que é Minikube.
• Inicialize um cluster Kubernetes no seu computador.

Clusters do Kubernetes

O Kubernetes coordena um cluster de computadores de alta disponibilidade, conectados para funcionar como uma única unidade. As abstrações no Kubernetes permitem implantar aplicativos em contêineres em um cluster sem vinculá-los especificamente à uma máquina individual. Para fazer uso desse novo modelo de implantação, os aplicativos precisam ser empacotados de uma forma que os desacoplem dos hosts individuais: eles precisam ser empacotados em contêineres. Os aplicativos em contêineres são mais flexíveis e disponíveis do que nos modelos de implantação anteriores, nos quais os aplicativos eram instalados diretamente em máquinas específicas como pacotes profundamente integrados ao host. O Kubernetes automatiza a distribuição e o agendamento de contêineres de aplicativos em um cluster de maneira mais eficiente. O Kubernetes é uma plataforma de código aberto e está pronto para produção.

Um cluster Kubernetes consiste em dois tipos de recursos:

• A Camada de Gerenciamento (Control Plane) coordena o cluster
• Os Nós (Nodes) são as máquinas de processamento que executam aplicativos

Diagrama do Cluster

A camada de gerenciamento é responsável por gerenciar o cluster. A camada de gerenciamento coordena todas as atividades em seu cluster, como a alocação de aplicativos, manutenção do estado desejado dos aplicativos, escalonamento de aplicativos e lançamento de novas atualizações.

Um nó é uma máquina virtual ou um computador físico que atua como um nó de processamento em um cluster Kubernetes. Cada nó tem um Kubelet, que é um agente para gerenciar o nó e comunicar-se com a camada de gerenciamento do Kubernetes. O nó também deve ter ferramentas para gerenciar operações de contêiner, como containerd ou Docker. Um cluster Kubernetes que lida com o tráfego de produção deve ter no mínimo três nós, pois se um dos nós tornar-se indisponível, um membro do etcd e um nó da camada de gerenciamento serão perdidos, comprometendo a redundância. Você pode mitigar este risco aumentando o número de nós da camada de gerenciamento.

Ao implantar aplicativos no Kubernetes, você solicita que a camada de gerenciamento inicie os contêineres de aplicativos. A camada de gerenciamento aloca os contêineres para serem executados nos nós do cluster. Os nós se comunicam com a camada de gerenciamento usando a API do Kubernetes , que a camada de gerenciamento expõe. Os usuários finais também podem usar a API do Kubernetes diretamente para interagir com o cluster.

Um cluster do Kubernetes pode ser implantado em máquinas físicas ou virtuais. Para começar a ambientar-se com desenvolvimento de aplicações para o Kubernetes, você pode usar o Minikube. O Minikube é uma implementação leve do Kubernetes que cria uma VM em sua máquina local e implanta um cluster simples contendo apenas um nó. O Minikube está disponível para sistemas Linux, macOS e Windows. O utilitário de linha de comando (CLI) do Minikube fornece operações básicas de inicialização para trabalhar com seu cluster, incluindo iniciar, parar, status e excluir.

Agora que você sabe mais sobre o que é Kubernetes, visite Olá, Minikube! para testar as operações no seu computador.

Objetivos

• Saiba mais sobre implantações de aplicativos.
• Implante seu primeiro aplicativo no Kubernetes com o kubectl.

Deployments do Kubernetes

Assim que o seu cluster Kubernetes estiver em execução você pode implantar seu aplicativo contêinerizado nele. Para fazer isso, você precisa criar um objeto Deployment do Kubernetes. O Deployment instrui o Kubernetes sobre como criar e atualizar instâncias do seu aplicativo. Depois de criar um Deployment, a camada de gerenciamento do Kubernetes aloca as instâncias do aplicativo incluídas nesse Deployment para serem executadas em nós individuais do cluster.

Depois que as instâncias do aplicativo são criadas, o controlador de Deployment do Kubernetes monitora continuamente essas instâncias. Se o nó em que uma instância está alocada ficar indisponível ou for excluído, o controlador de Deployment substituirá a instância por uma instância em outro nó no cluster. Isso fornece um mecanismo de autocorreção para lidar com falhas ou manutenção da máquina.

Em um mundo de pré-orquestração, os scripts de instalação eram utilizados para iniciar aplicativos, mas não permitiam a recuperação de falha da máquina. Ao criar suas instâncias de aplicativo e mantê-las em execução entre nós, os Deployments do Kubernetes fornecem uma abordagem fundamentalmente diferente para o gerenciamento de aplicativos.

Implante seu primeiro aplicativo no Kubernetes

Você pode criar e gerenciar uma implantação usando a interface de linha de comando do Kubernetes, o kubectl. O kubectl usa a API do Kubernetes para interagir com o cluster. Neste módulo, você aprenderá os comandos Kubectl mais comuns necessários para criar Deployments que executam seus aplicativos em um cluster Kubernetes.

Quando você cria um Deployment, você precisa especificar a imagem de contêiner para seu aplicativo e o número de réplicas que deseja executar. Você pode alterar essas informações posteriormente, atualizando seu Deployment; os Módulos 5 e 6 do bootcamp explicam como você pode dimensionar e atualizar seus Deployments.

Para criar seu primeiro Deployment, você usará o aplicativo hello-node empacotado em um contêiner que utiliza o NGINX para repetir todas as requisições. (Se você ainda não tentou criar o aplicativo hello-node e implantá-lo usando um contêiner, você pode fazer isso primeiro seguindo as instruções do tutorial Olá, Minikube!).

Você precisará ter o kubectl instalado também. Se você precisar de instruções de instalação, veja instalando ferramentas.

Agora que você já sabe o que são Deployments, vamos implantar nosso primeiro aplicativo!

Noções básicas do kubectl

O formato comum de um comando kubectl é: kubectl ação recurso

Isto executa a ação especificada (como por exemplo create, describe ou delete) no recurso especificado (por exemplo, node ou deployment). Você pode utilizar --help após o subcomando para obter informações adicionais sobre parâmetros permitidos (por exemplo, kubectl get nodes --help).

Verifique que o kubectl está configurado para comunicar-se com seu cluster rodando o comando kubectl version.

Certifique-se de que o kubectl está instalado e que você consegue ver as versões do cliente e do servidor.

Para visualizar os nós do cluster, execute o comando kubectl get nodes.

Você verá os nós disponíveis. Posteriormente, o Kubernetes irá escolher onde implantar nossa aplicação baseado nos recursos disponíveis nos nós.

Implante uma aplicação

Vamos implantar nossa primeira aplicação no Kubernetes utilizando o comando kubectl create deployment. Precisaremos fornecer o nome do Deployment e a localização da imagem de contêiner do aplicativo (inclua a URL completa do repositório para images hospedadas fora do Docker Hub).

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

Excelente! Você acabou de implantar sua primeira aplicação através da criação de um Deployment. Este comando efetuou algumas ações para você:

• buscou um nó utilizável onde a instância da aplicação pode ser executada (temos somente um nó disponível)
• alocou a aplicação para rodar naquele nó
• configurou o cluster para realocar a instância em um novo nó sempre que necessário

Para listar seus Deployments existentes, utilize o comando kubectl get deployments:

kubectl get deployments

Podemos observar que há um Deployment rodando uma única instância da sua aplicação. A instância está executando dentro de um contêiner no seu nó.

Visualize o aplicativo

Pods que rodam dentro do Kubernetes estão rodando em uma rede privada e isolada. Por padrão, eles são visíveis a outros Pods e Services dentro do mesmo cluster do Kubernetes, mas não de fora daquela rede. Ao usarmos kubectl, estamos interagindo através de um endpoint de API para comunicar-nos com a nossa aplicação.

Iremos discutir outras opções de como expor sua aplicação fora do cluster do Kubernetes no Módulo 4.

O comando kubectl pode criar um proxy que encaminha comunicações para dentro da rede privada que engloba todo o cluster. O proxy pode ser encerrado utilizando a sequência control-C e não irá imprimir nenhum tipo de saída enquanto estiver rodando.

Você precisa abrir uma segunda janela do terminal para executar o proxy.

kubectl proxy

Agora temos uma conexão entre nosso host (o terminal online) e o cluster do Kubernetes. O proxy habilita acesso direto à API através destes terminais.

Você pode ver todas as APIs hospedadas através do endpoint do proxy. Por exemplo, podemos obter a versão diretamente através da API utilizando o comando curl:

curl http://localhost:8001/version

O servidor da API irá automaticamente criar um endpoint para cada Pod, baseado no nome do Pod, que também estará acessível através do proxy.

Primeiro, precisaremos obter o nome do Pod. Iremos armazená-lo na variável de ambiente POD_NAME:

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Nome do Pod: $POD_NAME

Você pode acessar o Pod através da API encaminhada, rodando o comando:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/

Para que o novo Deployment esteja acessível sem utilizar o proxy, um Service é requerido. Isto será explicado nos próximos módulos.

Objetivos

• Aprenda sobre Pods do Kubernetes.
• Aprenda sobre Nós do Kubernetes.
• Solucione problemas de aplicativos implantados no Kubernetes.

Kubernetes Pods

Quando você criou um Deployment no Módulo 2, o Kubernetes criou um Pod para hospedar a instância do seu aplicativo. Um Pod é uma abstração do Kubernetes que representa um grupo de um ou mais contêineres de aplicativos (como Docker) e alguns recursos compartilhados para esses contêineres. Esses recursos incluem:

• Armazenamento compartilhado, como Volumes
• Rede, como um endereço IP único no cluster
• Informações sobre como executar cada contêiner, como a versão da imagem do contêiner ou portas específicas a serem usadas

Um Pod define um "host lógico" específico para o aplicativo e pode conter diferentes contêineres de aplicativos que, na maioria dos casos, são fortemente acoplados. Por exemplo, um Pod pode incluir tanto o contêiner com seu aplicativo Node.js quanto um outro contêiner que alimenta os dados a serem publicados pelo servidor web do Node.js. Os contêineres de um Pod compartilham um endereço IP e intervalo de portas, são sempre co-localizados, co-alocados e executam em um contexto compartilhado no mesmo Nó.

Pods são a unidade atômica na plataforma Kubernetes. Quando criamos um Deployment no Kubernetes, esse Deployment cria Pods com contêineres dentro dele (em vez de você criar contêineres diretamente). Cada Pod está vinculado ao nó onde está alocado e lá permanece até o encerramento (de acordo com a política de reinicialização) ou exclusão. Em caso de falha do nó, Pods idênticos são alocados em outros nós disponíveis no cluster.

Visão geral sobre os Pods

Nós

Um Pod sempre será executado em um Nó. Um Nó é uma máquina de processamento em um cluster Kubernetes e pode ser uma máquina física ou virtual. Cada Nó é gerenciado pela Camada de Gerenciamento. Um Nó pode possuir múltiplos Pods e a Camada de Gerenciamento do Kubernetes gerencia automaticamente a alocação dos Pods nos nós do cluster. A alocação automática dos Pods pela Camada de Gerenciamento leva em consideração os recursos disponíveis em cada Nó.

Cada Nó do Kubernetes executa pelo menos:

• O Kubelet, que é o processo responsável pela comunicação entre a Camada de Gerenciamento e o Nó; gerencia os Pods e os contêineres rodando em uma máquina.
• Um agente de execução de contêiner (por exemplo, Docker) responsável por baixar a imagem do contêiner de um registro de imagens (por exemplo, o Docker Hub), extrair o contêiner e executar a aplicação.

Visão Geral sobre os Nós

Solucionando problemas usando o comando kubectl

No Módulo 2, você usou a ferramenta de linha de comando kubectl. Você irá continuar utilizando o kubectl no Módulo 3 para obter informação sobre aplicações implantadas e seus recursos. As operações mais comuns podem ser efetuadas com os comandos abaixo:

• kubectl get - listar recursos
• kubectl describe - mostrar informações detalhadas sobre um recurso
• kubectl logs - mostrar os logs de um contêiner em um Pod
• kubectl exec - executar um comando em um contêiner em um Pod

Você pode usar esses comandos para verificar quando o Deployment foi criado, qual seu status atual, onde os Pods estão rodando e quais são as suas configurações.

Agora que sabemos mais sobre os componentes de um cluster Kubernetes e o comando kubectl, vamos explorar a nossa aplicação.

Verifique a configuração da aplicação

Vamos verificar que a aplicação que implantamos no cenário anterior está executando. Iremos utilizar o comando kubectl get e procurar por Pods existentes:

kubectl get pods

Se nenhum Pod estiver rodando, aguarde alguns instantes e liste os Pods novamente. Você pode continuar assim que ver um Pod rodando.

A seguir, para visualizar quais contêineres encontram-se no Pod e quais imagens foram utilizadas para criar tais contêineres iremos usar o comando kubectl describe pods:

kubectl describe pods

Vemos aqui detalhes a respeito dos contêineres do Pod: endereço IP, portas utilizadas e uma lista de eventos relacionados ao ciclo de vida do Pod.

A saída do subcomando describe é extensa e cobre alguns conceitos que não foram explicados ainda. Não se preocupe, estes conceitos serão familiares até o fim deste bootcamp.

Nota: o subcomando describe pode ser utilizado para obter informações detalhadas sobre a maioria das primitivas do Kubernetes, incluindo Nós (Nodes), Pods e Deployments. A saída do subcomando describe é projetada para ser legível por humanos, não para ser consumida por processos automatizados.

Exiba a aplicação no terminal

Lembre-se que Pods estão executando em uma rede isolada e privada - portanto, precisaremos de um proxy para acessá-los, a fim de tornar possível a depuração e a interação com estes objetos. Para inicializar um proxy, utilizaremos o comando kubectl proxy em um segundo terminal. Abra uma nova janela do terminal, e nesta nova janela, execute o comando:

kubectl proxy

Agora iremos novamente obter o nome do Pod e obter informações do Pod diretamente através do proxy. Para obter o nome do Pod e armazená-lo na variável de ambiente POD_NAME, utilize o comando:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Nome do Pod: $POD_NAME

Para ver a saída da aplicação, execute uma requisição com o comando curl:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

A URL é a rota para a API do Pod.

Visualize os logs do contêiner

Qualquer mensagem que normalmente seria impressa na saída padrão (stdout) torna-se parte do log do contêiner dentro do Pod. Podemos obter tais logs utilizando o comando kubectl logs:

kubectl logs "$POD_NAME"

Nota: não é necessário especificarmos o nome do contêiner pois temos apenas um contêiner neste Pod.

Objetivos

• Aprenda sobre Services no Kubernetes
• Entenda como rótulos (labels) e seletores (selectors) relacionam-se aos Services
• Exponha uma aplicação externamente ao cluster Kubernetes usando um Service

Visão Geral dos Services no Kubernetes

Pods do Kubernetes são efêmeros. Na verdade, Pods possuem um ciclo de vida. Quando um nó de processamento morre, os Pods executados no nó também são perdidos. A partir disso, o ReplicaSet pode dinamicamente retornar o cluster ao estado desejado através da criação de novos Pods para manter sua aplicação em execução. Como outro exemplo, considere um backend de processamento de imagens com 3 réplicas. Estas réplicas são permutáveis; o sistema front-end não deveria se importar com as réplicas backend ou ainda se um Pod foi perdido ou recriado. Dito isso, cada Pod em um cluster Kubernetes tem um endereço IP único, incluindo Pods que estejam rodando no mesmo nó, então há necessidade de ter uma forma de reconciliar automaticamente mudanças entre Pods de modo que sua aplicação continue funcionando.

Um objeto Service no Kubernetes é uma abstração que define um conjunto lógico de Pods e uma política pela qual acessá-los. Serviços permitem um baixo acoplamento entre os Pods dependentes. Um serviço é definido usando YAML ou JSON, como todos os manifestos de objetos Kubernetes. O conjunto de Pods selecionados por um Service é geralmente determinado por um seletor de rótulos (veja abaixo o motivo pelo qual você poderia desejar um Service que não inclui um seletor (selector) na especificação (spec)).

Embora cada Pod tenha um endereço IP único, estes IPs não são expostos externamente ao cluster sem um objeto Service. Objetos Service permitem que suas aplicações recebam tráfego. Services podem ser expostos de formas diferentes especificando um tipo (campo type) na especificação do serviço (campo spec):

• ClusterIP (padrão) - Expõe o serviço sob um endereço IP interno no cluster. Este tipo de serviço é acessível somente dentro do cluster.
• NodePort - Expõe o serviço sob a mesma porta em cada nó selecionado no cluster usando NAT. Torna o serviço acessível externamente ao cluster usando o endereço <NodeIP>:<NodePort>. É um superconjunto do tipo ClusterIP.
• LoadBalancer - Cria um balanceador de carga externo no provedor de nuvem atual (se suportado) e atribui um endereço IP fixo e externo para o serviço. É um superconjunto do tipo NodePort.
• ExternalName - Mapeia o Service para o conteúdo do campo externalName (por exemplo, foo.bar.example.com), retornando um registro DNS do tipo CNAME com o seu valor. Nenhum tipo de proxy é configurado. Este tipo requer a versão 1.7 ou mais recente do kube-dns, ou o CoreDNS versão 0.0.8 ou superior.

Mais informações sobre diferentes tipos de Services podem ser encontradas no tutorial Utilizando IP de origem. Veja também Conectando aplicações com serviços.

Adicionalmente, note que existem alguns casos de uso com serviços que envolvem a ausência de um selector no campo spec. Services criados sem selector também não criarão objetos Endpoints correspondentes. Isto permite que usuários mapeiem manualmente um serviço a endpoints específicos. Outro motivo pelo qual seletores podem estar ausentes é que você esteja utilizando estritamente type: ExternalName.

Serviços e Rótulos

Um Service roteia tráfego entre um conjunto de Pods. Service é a abstração que permite Pods morrerem e se replicarem no Kubernetes sem impactar sua aplicação. A descoberta e o roteamento entre Pods dependentes (tal como componentes frontend e backend dentro de uma aplicação) são controlados por Services do Kubernetes.

Services relacionam um conjunto de Pods usando rótulos e seletores, uma primitiva de agrupamento que permite operações lógicas sobre objetos do Kubernetes. Rótulos são pares chave/valor anexados à objetos e podem ser usados de diversas formas:

• Designar objetos para desenvolvimento, teste e produção
• Adicionar tags de versão
• Classificar um objeto usando tags

Rótulos podem ser anexados aos objetos no momento de sua criação ou posteriormente. Eles podem ser modificados a qualquer momento. Vamos expor nossa aplicação usando um Service e aplicar alguns rótulos.

Crie um novo Service

Vamos verificar que nossa aplicação está rodando. Utilizaremos o comando kubectl get e procuraremos por Pods existentes:

kubectl get pods

Se não houver Pods rodando, isso significa que o ambiente interativo ainda está recarregando o estado anterior. Por favor, aguarde alguns instantes e liste os Pods novamente. Você poderá prosseguir assim que vir um Pod rodando.

A seguir, vamos listar os Services existentes no momento no nosso cluster:

kubectl get services

Temos um Service chamado kubernetes que é criado por padrão quando o minikube inicializa o cluster. Para criar um novo Service e expô-lo para tráfego externo utilizaremos o comando expose com o tipo NodePort.

kubectl expose deployment/kubernetes-bootcamp --type=NodePort --port 8080

Vamos rodar novamente o subcomando get services:

kubectl get services

Temos agora um Service chamado kubernetes-bootcamp rodando. Aqui vemos que o Service recebeu um ClusterIP único, uma porta interna e um IP externo (o IP do nó).

Para descobrir qual porta foi aberta externamente (para o Service com tipo NodePort) iremos rodar o subcomando describe service:

kubectl describe services/kubernetes-bootcamp

Crie uma variável de ambiente chamada NODE_PORT que armazena o número da porta do nó:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

Agora podemos verificar que a aplicação está exposta externamente ao cluster utilizando curl, o endereço IP do nó e a porta exposta externamente:

curl http://"$(minikube ip):$NODE_PORT"

E receberemos uma resposta do servidor. O Service está exposto.

Passo 2: Utilizando rótulos (labels)

Removendo um Service

Para remover um Service você pode utilizar o subcomando delete service. Rótulos também podem ser utilizados aqui:

kubectl delete service -l app=kubernetes-bootcamp

Confirme que o Service foi removido com sucesso:

kubectl get services

Isto confirma que nosso Service foi removido. Para confirmar que a rota não está mais exposta, você pode disparar uma requisição para o endereço IP e porta previamente expostos através do comando curl:

curl http://"$(minikube ip):$NODE_PORT"

Isto prova que a aplicação não está mais acessível de fora do cluster. Você pode confirmar que a aplicação ainda está rodando com um curl de dentro do Pod:

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

Vemos aqui que a aplicação ainda está rodando. Isto se deve ao fato de que o Deployment está gerenciando a aplicação. Para encerrar a aplicação, você precisaria remover o Deployment também.

Objetivos

• Escalonar uma aplicação usando kubectl.

Escalonando uma aplicação

Nos módulos anteriores, criamos um Deployment, e então o expusemos publicamente através de um serviço (Service). O Deployment criou apenas um único Pod para executar nossa aplicação. Quando o tráfego aumentar, precisaremos escalonar a aplicação para suportar a demanda de usuários.

Se você ainda não tiver estudado as seções anteriores, inicie pelo tutorial Usando Minikube para criar um cluster.

O escalonamento é obtido pela mudança do número de réplicas em um Deployment

NOTA Se você estiver seguindo este tutorial após a seção anterior, poderá ser necessário refazer a seção criando um cluster, pois os serviços podem ter sido removidos.

Visão geral sobre escalonamento

Escalonar um Deployment garantirá que novos Pods serão criados e alocados em nós de processamento com recursos disponíveis. O escalonamento aumentará o número de Pods para o novo estado desejado. O Kubernetes também suporta o auto-escalonamento (autoscaling) de Pods, mas isso está fora do escopo deste tutorial. Escalonar para zero também é possível, e encerrará todos os Pods do Deployment especificado.

Executar múltiplas instâncias de uma aplicação requer uma forma de distribuir o tráfego entre todas elas. Serviços possuem um balanceador de carga integrado que distribui o tráfego de rede entre todos os Pods de um Deployment exposto. Serviços irão monitorar continuamente os Pods em execução usando endpoints para garantir que o tráfego seja enviado apenas para Pods disponíveis.

Uma vez que você tenha múltiplas instâncias de uma aplicação em execução será possível realizar atualizações graduais no cluster sem que ocorra indisponibilidade. Cobriremos isso no próximo módulo. Agora, vamos ao terminal escalonar nossa aplicação.

Escalonando um Deployment

Para listar seus Deployments, utilize o subcomando get deployments: kubectl get deployments

A saída deve ser semelhante a:

                NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
                kubernetes-bootcamp   1/1     1            1           11m
                

Teremos um único Pod. Se nenhum Pod aparecer, tente rodar o comando novamente.

• NAME lista os nomes dos Deployments no cluster.
• READY exibe a proporção de réplicas atuais/desejadas (CURRENT/DESIRED).
• UP-TO-DATE exibe o número de réplicas que foram atualizadas para atingir o estado desejado.
• AVAILABLE exibe o número de réplicas da aplicação que estão disponíveis para seus usuários.
• AGE exibe há quanto tempo a aplicação está rodando.

Para ver o ReplicaSet criado pelo Deployment, execute kubectl get rs

Observe que o nome do ReplicaSet sempre é exibido no formato [NOME-DO-DEPLOYMENT]-[TEXTO-ALEATÓRIO]. O texto aleatório é gerado e utiliza o valor do pod-template-hash como semente.

Duas colunas importantes desta saída são:

• DESIRED exibe o número desejado de réplicas da aplicação, que você define quando cria o objeto Deployment. Este é o estado desejado.
• CURRENT exibe quantas réplicas estão em execução atualmente.

A seguir, vamos escalonar o Deployment para 4 réplicas. Utilizaremos o comando kubectl scale, seguido pelo tipo Deployment, nome e o número desejado de instâncias:

kubectl scale deployments/kubernetes-bootcamp --replicas=4

Para listar seus Deployments mais uma vez, utilize get deployments:

kubectl get deployments

A mudança foi aplicada, e temos 4 instâncias da aplicação disponíveis. A seguir, vamos verificar se o número de Pods mudou:

kubectl get pods -o wide

Temos 4 Pods agora, com endereços IP diferentes. A mudança foi registrada no log de eventos do Deployment. Para verificar esta mudança, utilize o subcomando describe:

kubectl describe deployments/kubernetes-bootcamp

Você pode ver na saída deste comando que temos 4 réplicas agora.

Balanceamento de carga

Vamos verificar que o Service está efetuando o balanceamento de carga do tráfego recebido. Para encontrar o endereço IP exposto e a porta podemos utilizar o comando para descrever o serviço como aprendemos na seção anterior:

kubectl describe services/kubernetes-bootcamp

Crie uma variável de ambiente chamada NODE_PORT que possui o valor da porta do nó:

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"

echo NODE_PORT=$NODE_PORT

A seguir, iremos executar o comando curl para efetuar uma requisição para o endereço IP e porta expostos. Rode este comando múltiplas vezes:

curl http://"$(minikube ip):$NODE_PORT"

Cada requisição é atendida por um Pod diferente. Isso demonstra que o balanceamento de carga está funcionando.

Reduzir o número de réplicas

Para reduzir o número de réplicas do Deployment para 2, execute o subcomando scale novamente:

kubectl scale deployments/kubernetes-bootcamp --replicas=2

Liste os Deployments para verificar se a mudança foi aplicada com o subcomando get deployments:

kubectl get deployments

O número de réplicas reduziu para 2. Liste o número de Pods com o comando get pods:

kubectl get pods -o wide

Isso confirma que 2 Pods foram encerrados.