Essa seção da documentação contém tutoriais. Um tutorial demonstra como realizar
um objetivo mais complexo que uma simples tarefa. Tipicamente,
um tutorial é dividido em várias seções, em que cada seção tem uma sequência de
passos.
Antes de iniciar um tutorial, é interessante que você salve a página do
Glossário Padronizado para futuras referências.
Noções Básicas
Noções Básicas do Kubernetes é um
tutorial interativo que auxilia no entendimento do ecossistema Kubernetes, bem
como permite testar algumas funcionalidades básicas do Kubernetes.
Se você desejar escrever um tutorial, consulte a documentação de
Tipos de Página de Conteúdo
para informações sobre o tipo de página de tutorial.
1 - Olá, Minikube!
Este tutorial demonstra como executar uma aplicação exemplo no Kubernetes utilizando
o minikube.
O tutorial fornece uma imagem de contêiner que utiliza o NGINX para repetir todas
as requisições.
Objetivos
Instalar uma aplicação exemplo no minikube.
Executar a aplicação.
Visualizar os logs da aplicação.
Antes de você começar
Este tutorial assume que você já tem uma instância do minikube configurada.
Veja a Etapa 1 em minikube start para instruções de como instalar.
Nota:
Execute apenas as instruções na Etapa 1, Instalação. O restante é coberto nesta página.
Você também irá precisar instalar o kubectl.
Veja instalando ferramentas para instruções de como
instalar.
Criando um cluster do minikube
minikube start
Abra o painel (dashboard)
Abra o painel (dashboard) do Kubernetes. Você pode fazer isso de duas formas
distintas:
# Inicie um novo terminal e deixe este comando rodando.minikube dashboard
Agora, retorne para o terminal onde você executou o comando minikube start.
Nota:
O comando dashboard habilita o complemento do painel e abre o proxy no navegador
padrão. Você pode criar recursos do Kubernetes no painel, como Deployment e
Service.
Para descobrir como evitar invocar diretamente o navegador do terminal e obter uma URL para o painel web, consulte a aba "Copiar e colar URL".
Por padrão, o painel só é acessível pela rede virtual interna do Kubernetes. O
comando dashboard cria um proxy temporário para tornar o painel acessível por
fora da rede virtual do Kubernetes.
Para parar o proxy, utilize o comando Ctrl+C para encerrar o processo.
Após o término do comando, o painel permanece executando no cluster do Kubernetes.
Você pode executar o comando dashboard novamente para criar outro proxy para
acessar o painel.
Se você não deseja que o minikube abra um navegador para você, rode o comando
dashboard com a opção de linha de comando --url. O minikube irá imprimir
uma URL que você poderá abrir no navegador de sua preferência.
Abra um novo terminal e rode o comando:
# Inicie um novo terminal e deixe este comando rodando.minikube dashboard --url
Agora, retorne para o terminal onde você executou o comando minikube start.
Criando um Deployment
Um Pod do Kubernetes consiste em um ou mais
contêineres agrupados para fins de administração e gerenciamento de rede. O Pod
deste tutorial possui apenas um contêiner. Um
Deployment do Kubernetes
verifica a integridade do seu Pod e reinicia o contêiner do Pod caso este seja
finalizado. Deployments são a maneira recomendada de gerenciar a criação e
escalonamento dos Pods.
Use o comando kubectl create para criar um Deployment que gerencia um Pod.
O Pod executa um contêiner baseado na imagem do Docker disponibilizada.
# Execute uma imagem de contêiner de teste que inclui um servidor webkubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.53 -- /agnhost netexec --http-port=8080
Visualize o Deployment:
kubectl get deployments
A saída será semelhante a:
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
(Pode levar algum tempo para que o pod fique disponível. Se você ver "0/1", tente novamente em alguns segundos.)
Visualize o Pod:
kubectl get pods
A saída será semelhante a:
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
Visualize os eventos do cluster:
kubectl get events
Visualize a configuração do kubectl:
kubectl config view
Visualize os logs da aplicação para um contêiner em um pod (substitua o nome do pod pelo que você obteve de kubectl get pods).
Nota:
Substitua hello-node-5f76cf6ccf-br9b5 no comando kubectl logs pelo nome do pod da saída do comando kubectl get pods.
kubectl logs hello-node-5f76cf6ccf-br9b5
A saída será semelhante a:
I0911 09:19:26.677397 1 log.go:195] Started HTTP server on port 8080
I0911 09:19:26.677586 1 log.go:195] Started UDP server on port 8081
Por padrão, um Pod só é acessível utilizando o seu endereço IP interno no cluster
Kubernetes. Para dispobiblilizar o contêiner hello-node fora da rede virtual do
Kubernetes, você deve expor o Pod como um
Service do Kubernetes.
Aviso:
O contêiner agnhost possui um endpoint /shell, que é útil para
depuração, mas perigoso de expor à internet pública. Não execute isso em um
cluster voltado para a internet ou em um cluster de produção.
O parâmetro --type=LoadBalancer indica que você deseja expor o seu serviço
fora do cluster Kubernetes.
A aplicação dentro da imagem de teste escuta apenas na porta TCP 8080. Se
você usou kubectl expose para expor uma porta diferente, os clientes não
conseguirão se conectar a essa outra porta.
Visualize o Service que você acabou de criar:
kubectl get services
A saída será semelhante a:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
Em provedores de nuvem que fornecem serviços de balanceamento de carga para
o Kubernetes, um IP externo seria provisionado para acessar o serviço. No
minikube, o tipo LoadBalancer torna o serviço acessível por meio do comando
minikube service.
Execute o comando a seguir:
minikube service hello-node
Este comando abre uma janela do navegador que serve o seu aplicativo e exibe
o retorno da requisição ao aplicativo.
Habilitando Complementos (addons)
A ferramenta minikube inclui um conjunto integrado de complementos
que podem ser habilitados, desabilitados e executados no ambiente Kubernetes local.
Este tutorial fornece instruções básicas sobre o sistema de orquestração
de cluster do Kubernetes. Cada módulo contém algumas informações básicas
sobre os principais recursos e conceitos do Kubernetes e inclui um tutorial
online interativo. Esses tutoriais interativos permitem que você mesmo
gerencie um cluster simples e seus aplicativos em contêineres.
Usando os tutoriais interativos, você pode aprender a:
Implantar um aplicativo em contêiner em um cluster.
Dimensionar a implantação.
Atualizar o aplicativo em contêiner com uma nova versão do software.
Depurar o aplicativo em contêiner.
Os tutoriais usam Katacoda para executar um terminal virtual em seu navegador da Web, executado em Minikube, uma implantação local em pequena escala do Kubernetes que pode ser executada em qualquer lugar. Não há necessidade de instalar nenhum software ou configurar nada; cada tutorial interativo é executado diretamente no navegador da web.
O que o Kubernetes pode fazer por você?
Com os serviços da Web modernos, os usuários esperam que os aplicativos estejam disponíveis 24 horas por dia, 7 dias por semana, e os desenvolvedores esperam implantar novas versões desses aplicativos várias vezes ao dia. A conteinerização ajuda a empacotar o software para atender a esses objetivos, permitindo que os aplicativos sejam lançados e atualizados de maneira fácil e rápida, sem tempo de inatividade. O Kubernetes ajuda a garantir que esses aplicativos em contêiner sejam executados onde e quando você quiser e os ajuda a encontrar os recursos e ferramentas de que precisam para funcionar. Kubernetes é uma plataforma de código aberto pronta para produção, projetada com a experiência acumulada do Google em orquestração de contêineres, combinada com as melhores idéias da comunidade.
Aprenda sobre clusters
do Kubernetes e crie um cluster simples utilizando o Minikube.
2.1.1 - Usando Minikube para criar um cluster
Aprenda o que é um cluster do Kubernetes.
Aprenda o que é Minikube.
Inicialize um cluster do Kubernetes.
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
Resumo:
Cluster do Kubernetes
Minikube
O Kubernetes é uma plataforma de código aberto de nível
de produção que orquestra a alocação e a execução de
contêineres de aplicativos dentro de e entre clusters de
computadores.
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.
A camada de gerenciamento gerencia o cluster e os nós que
são usados para hospedar os aplicativos em execução.
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.
Aprenda sobre objetos Deployment do Kubernetes.
Implante seu primeiro aplicativo no Kubernetes utilizando o kubectl.
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.
Resumo:
Deployments
Kubectl
O objeto Deployment é responsável por criar e atualizar instâncias
de seu aplicativo
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.
Os aplicativos precisam ser empacotados em um dos formatos de
contêiner suportados para serem implantados no Kubernetes
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).
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
Nota: se a porta 8001 não estiver acessível, certifique-se
de que o comando kubectl proxy que você iniciou acima está
rodando no segundo terminal.
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:
Aprenda como depurar aplicações do Kubernetes utilizando
kubectl get, kubectl describe, kubectl logs e
kubectl exec.
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.
Sumário:
Pods
Nós
Principais comandos do Kubectl
Um Pod é um grupo de um ou mais contêineres de
aplicativos (como Docker) que inclui armazenamento
compartilhado (volumes), endereço IP e informações
sobre como executá-los.
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.
Os contêineres só devem ser alocados juntos em um único Pod se
estiverem fortemente acoplados e precisarem compartilhar recursos,
como disco, por exemplo.
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.
Um nó é uma máquina de processamento do Kubernetes e pode ser
uma VM ou máquina física, dependendo do cluster. Vários Pods
podem ser executados em um nó.
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:
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.
Executando comandos no contêiner
Podemos executar comandos diretamente no contêiner uma vez que o
Pod esteja criado e rodando. Para isso, utilizaremos o subcomando
exec e o nome do Pod como um parâmetro. Vamos listar
as variáveis de ambiente:
kubectl exec "$POD_NAME" -- env
Novamente, vale a pena mencionar que o nome do contêiner pode ser
omitido pois temos apenas um contêiner no Pod.
A seguir, vamos iniciar uma sessão do bash no contêiner do Pod:
kubectl exec -ti $POD_NAME -- bash
Agora temos um terminal aberto no contêiner onde nossa aplicação
Node.js está executando. O código-fonte da aplicação encontra-se
no arquivo server.js:
cat server.js
Você pode verificar que a aplicação está rodando utilizando uma
requisição com o comando curl:
curl http://localhost:8080
Nota: aqui utilizamos localhost pois
executamos o comando dentro do Pod do Node.js. Se você não conseguir
conectar-se a localhost:8080, certifique-se de que você utilizou
o comando kubectl exec e que está rodando a requisição
curl de dentro do Pod.
Para encerrar sua conexão ao contêiner, digite exit.
2.4.1 - Utilizando um serviço para expor seu aplicativo
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.
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.
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.
Resumo
Exposição de Pods ao tráfego externo
Balanceamento de carga de tráfego entre múltiplos Pods
Utilização de rótulos (labels)
Um objeto Service do Kubernetes é uma camada de abstração que define
um conjunto lógico de Pods e habilita a exposição ao tráfego externo,
balanceamento de carga e descoberta de serviço para esses Pods.
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.
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)
O Deployment criou automaticamente um rótulo para o nosso Pod. Com o
subcomando describe deployment você pode ver o nome
(a chave) deste rótulo:
kubectl describe deployment
Vamos utilizar este rótulo para filtrar nossa lista de Pods.
Utilizaremos o comando kubectl get pods com o parâmetro
-l, seguido dos valores dos rótulos:
kubectl get pods -l app=kubernetes-bootcamp
Você pode fazer o mesmo para listar os Services existentes:
kubectl get services -l app=kubernetes-bootcamp
Obtenha o nome do Pod e armazene-o na variável de ambiente POD_NAME:
export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')" echo "Name of the Pod: $POD_NAME"
Para aplicar um novo rótulo podemos utilizar o subcomando label,
seguido pelo tipo de objeto, nome do objeto e o novo rótulo:
kubectl label pods "$POD_NAME" version=v1
Este comando aplicará um novo rótulo no Pod (nós fixamos a versão
da aplicação ao Pod) e podemos verificar com o comando
describe pod:
kubectl describe pods "$POD_NAME"
Vemos aqui que o rótulo está agora vinculado ao nosso Pod. E agora
podemos pesquisar a lista de Pods utilizando o novo label:
kubectl get pods -l version=v1
E vemos o Pod.
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:
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.
2.5.1 - Executando Múltiplas Instâncias da sua Aplicação
Escalone uma aplicação existente de forma manual utilizando kubectl.
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.
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.
Resumo:
Escalonando um Deployment
Você pode criar desde o início um Deployment com
múltiplas instâncias usando o parâmetro --replicas
do comando kubectl create deployment
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.
O escalonamento é obtido pela mudança do número de
réplicas em um Deployment.
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:
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:
2.5.2 - Tutorial Interativo - Escalando seu aplicativo
Conteúdo indisponível
O tutorial interativo de como escalonar um aplicativo que está rodando
no seu cluster não está disponível.
Para mais informações, veja o
anúncio de encerramento do Katacoda.
Criar um ConfigMap com valores de configuração para o Redis.
Criar um Pod do Redis que monte e use o ConfigMap criado.
Verificar se a configuração foi aplicada corretamente.
Antes de você começar
Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:
Examine o conteúdo do manifesto do Pod Redis e observe o seguinte:
Um volume chamado config é criado em spec.volumes[1]
A key e o path em spec.volumes[1].configMap.items[0] expõem a chave redis-config do ConfigMap
example-redis-config como um arquivo chamado redis.conf no volume config.
O volume config é então montado em /redis-master por spec.containers[0].volumeMounts[1].
O efeito final é expor os dados de data.redis-config do ConfigMap example-redis-config
acima como /redis-master/redis.conf dentro do Pod.
Verifique novamente o Pod Redis usando redis-cli via kubectl exec para confirmar se a configuração foi aplicada:
kubectl exec -it redis -- redis-cli
Verifique maxmemory:
127.0.0.1:6379> CONFIG GET maxmemory
Ele permanece no valor padrão de 0:
1)"maxmemory"2)"0"
Da mesma forma, maxmemory-policy permanece com a configuração padrão noeviction:
127.0.0.1:6379> CONFIG GET maxmemory-policy
Retorna:
1)"maxmemory-policy"2)"noeviction"
Os valores de configuração não mudaram porque o Pod precisa ser reiniciado para carregar os valores atualizados dos ConfigMaps associados. Vamos excluir e recriar o Pod:
kubectl delete pod redis
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml
Agora verifique os valores de configuração mais uma vez:
kubectl exec -it redis -- redis-cli
Verifique maxmemory:
127.0.0.1:6379> CONFIG GET maxmemory
Ele agora deve retornar o valor atualizado de 2097152:
1)"maxmemory"2)"2097152"
Da mesma forma, maxmemory-policy também foi atualizado:
127.0.0.1:6379> CONFIG GET maxmemory-policy
Ele agora reflete o valor desejado de allkeys-lru:
