O que é e como usar Kubernetes pod?

Um Kubernetes pod pode ter um ou mais contêineres que se conectam e compartilham recursos. Dessa forma, eles funcionam como um ambiente coordenado para as aplicações.

Kubernetes pod: Definição

Pod é o nome dado à unidade básica de implementação no Kubernetes, que abrange um ou mais contêineres interconectados. Um pod é capaz de compartilhar o mesmo espaço de rede, armazenamento e demais recursos. Por isso, ele representa um agrupamento lógico de contêineres. Os contêineres dentro de um Kubernetes pod trabalham juntos e se comunicam entre si.

Pod com contêiner único

Esse tipo de pod tem um contêiner único. Essa estrutura costuma ser usada quando uma aplicação ou microsserviço precisa ser executada em um ambiente isolado, sem que seja necessário compartilhar recursos e rede com outros contêineres. Essa é a forma mais simples de pod que existe no Kubernetes e possibilita orquestração, escalonamento e gerenciamento.

Pod com múltiplos contêineres

Pods que executam múltiplos contêineres hospedam mais de um contêiner dentro de si. Esses contêineres trabalham juntos e compartilham o mesmo espaço e recursos de rede. Essa abordagem costuma ser usada quando os contêineres estão estreitamente conectados e desempenham uma tarefa ou função em comum. Por exemplo, o contêiner da aplicação principal e o contêiner secundário para registros ou monitoramento podem ser executados em um único Kubernetes pod. Isso permite coordenação e comunicação mais próximas entre containers, enquanto eles são tratados como uma única entidade dentro do cluster do Kubernetes.

Como criar Kubernetes pod

Para criar um Kubernetes pod, você precisa de um arquivo YAML que faça a definição do pod. Este é um exemplo simples de configuração de um pod Nginx:

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

O documento YAML apresenta a definição de um pod chamado nginx-pod. Ele contém apenas um contêiner, que foi nomeado como nginx-container. Esse contêiner usa a imagem Nginx mais recente do Docker Hub.

Execute o comando a seguir para criar o pod:

kubectl apply -f nginx-pod.yaml

Como usar Kubernetes pod

O uso de níveis mais elevados de abstração, como Deployments ou StatefulSets, é recomendado para gerenciar pods em um ambiente produtivo. Esses controladores assumem a definição do estado desejado da aplicação e asseguram que ele corresponda ao estado real. O escalonamento, a atualização gradual e a recuperação automática dos pods são implementados.

Quando um pod é criado, seja diretamente pelo administrador ou indiretamente por um controlador, ele é agendado em um nó específico no cluster. O pod permanece no nó designado até que uma dessas situações ocorra: ele pare de funcionar, o objeto do pod associado seja excluído manualmente, faltem recursos ou aconteçam outros problemas que exijam a evacuação do pod para outro nó, ou o nó atual falhe. Nesses casos, o pod será reiniciado em outro nó que estiver disponível para garantir sua execução contínua.

O nome de um pod deve ser definido como um valor de subdomínio DNS válido. Isso é importante para criar uma identificação única para o pod dentro do cluster do Kubernetes. Labels de DNS devem ter menos de 253 caracteres, conter apenas letras, números e hífenes e começar e terminar com um caractere alfanumérico.

Sistema operacional do pod

Kubernetes pods costumam ser configurados para rodar em um sistema operacional Linux. No entanto, existem casos em que eles também podem ser executados em um sistema operacional Windows, por exemplo, se a sua aplicação ou parte específica dela exigir recursos exclusivos do Windows. Altere o sistema operacional no campo .spec.os.name nas especificações do pod (arquivo YAML).

Gerenciar Kubernetes pod

Embora seja possível criar pods manualmente, esse procedimento não costuma ser prático devido à crescente complexidade das aplicações e cargas de trabalho. Por isso, muitos usuários recorrem aos controladores do Kubernetes, que trazem uma camada abstrata baseada na configuração declarativa. Existem diferentes tipos de controladores:

• Kubernetes Deployment
• Kubernetes StatefulSet
• Kubernetes DaemonSet

Controladores do tipo “Deployment” monitoram continuamente o status do cluster. Isso possibilita a realização de ações automatizadas, como escalonamento, atualização e manutenção de aplicações. Controladores “ReplicaSets” garantem que um número constante de pods idênticos sejam executados. Controladores do tipo “StatefulSet” são essenciais para aplicações com uso intensivo de dados, pois asseguram identidades de rede estáveis para os pods.

Templates do pod

O template de um pod é a parte da configuração de um controlador que descreve as propriedades desejadas para um Kubernetes pod, o que inclui contêineres, imagem Docker, variáveis do ambiente, requisitos de recursos, entre outros. O controlador usa o template para configurar ou atualizar o pod. Por exemplo, durante uma implementação, ele cria novos pods quando o escalonamento é necessário ou atualiza os pods existentes durante uma atualização contínua.

apiVersion: batch/v1
kind: Job
metadata:
    name: novo-job
spec:
    template:
        metadata:
            name: pod
        spec:
            containers:
            - name: container
                image: ubuntu:latest
                command: ["echo", "Oi do Kubernetes"]
    backoffLimit: 3

Nesse exemplo, configuramos um job com o nome novo-job. O template cria um único pod com um contêiner que usa a imagem do Ubuntu e executa o comando echo "Oi do Kubernetes". Devido à definição no campo backoffLimit, haverá no máximo três tentativas de executar o job se houver algum erro.

Atualizar Kubernetes pod

O Kubernetes disponibiliza diversos métodos para atualizar recursos, incluindo dois que são usados com maior frequência: patch e replace.

O método Patch é empregado para realizar atualizações direcionadas e parciais de um recurso sem substituir todas as definições dele. Isso é feito por meio de um patch que contém apenas os campos que serão alterados. Essa é uma maneira eficiente de fazer alterações mínimas em um recurso, especialmente quando é necessário atualizar somente alguns campos.

Já o método Replace substitui todos os campos do recurso pelas novas definições. Esse método é usado quando é necessário realizar uma grande atualização ou alterações estruturais no recurso.

Existem metadados e campos fixos nas definições YAML dos recursos Kubernetes. Alguns deles são:

• apiVersion e kind: Esses metadados definem o tipo e a versão do recurso e não costumam ser alterados.
• metadata.name e metadata.namespace: O nome e o namespace de um recurso costumam não ser alterados para garantir a identificação exclusiva do recurso.
• metadata.creationTimestamp: A data de criação de um recurso não é alterada e indica quando ele foi originado.

Compartilhar recursos

Pods podem usar volumes para dividir dados entre os contêineres dentro de um mesmo pod. Volume é nome dado a um sistema ou diretório de arquivos que é compartilhado por um ou mais contêineres no pod. Os volumes são mecanismos eficazes para armazenar dados cuja existência vai além do ciclo de vida de um único contêiner.

Cada Kubernetes pod tem seu próprio endereço IP único dentro da rede do cluster. Esse endereço IP possibilita a comunicação direta entre os pods. Se contêineres múltiplos estiverem sendo executados em um pod, eles conseguirão se comunicar via localhost e portas diferentes. Isso simplifica a interação entre as diferentes partes de uma aplicação no mesmo pod.

Modo privilegiado

Quando um contêiner é executado no modo privilegiado, ele tem privilégios aumentados e consegue acessar os recursos do sistema que não costumam ficar disponíveis em um contêiner padrão isolado. No Kubernetes, o modo privilegiado é ativado pela opção securityContext.privileged nas especificações do contêiner.

É importante observar que o uso do modo privilegiado traz significativos riscos à segurança. Devido aos privilégios ampliados, a presença de um contêiner comprometido ou uma aplicação maliciosa no sistema de host poderia causar graves problemas de segurança. Portanto, o modo privilegiado só deve ser usado quando for realmente necessário e depois de considerar cuidadosamente seus potenciais riscos de segurança.

Pods estáticos

Pods estáticos no Kubernetes não são monitorados ou gerenciados por um plano de controle central do cluster. Ao contrário dos pods regulares, que dependem dos controladores no Kubernetes, os pods estáticos são iniciados diretamente por um nó. Esses pods são vinculados a um nó específico e suas definições são feitas no próprio nó, geralmente em um diretório como /etc/kubernetes/manifests/. O Kubelet no nó monitora e inicia o pod estático, reiniciando-o automaticamente se o pod travar.

Ao contrário dos pods regulares, os pods estáticos não são controlados pela API do Kubernetes e ficam invisíveis no plano de controle central do cluster. Pods estáticos são uma forma simples de implementar aplicações ou serviços em um nó sem um cluster central do Kubernetes. No entanto, eles não têm todos os recursos dos pods regulares que são administrados pelo gerenciador do controlador do Kubernetes.

Probes de contêiner

Probes de contêiner são mecanismos do Kubernetes que monitoram o status e a integridade de um contêiner.

Para realizar um diagnóstico, o Kubelet pode acionar diversas ações:

• ExecAction (realizada usando o ambiente de execução do contêiner): Esta ação permite que o Kubelet execute um comando dentro do contêiner. Isso é especialmente útil para realizar verificações ou testes personalizados no contêiner. Após o comando ser chamado, o teste é considerado bem-sucedido.
• TCPSocketAction (verificada diretamente pelo Kubelet): Esta ação permite que o Kubelet verifique a acessibilidade de uma porta TCP dentro do contêiner. Se a porta especificada estiver aberta, o teste é considerado bem-sucedido.
• HTTPGetAction (verificada diretamente pelo Kubelet): Com esta ação, o Kubelet realiza uma solicitação HTTP GET para um caminho e uma porta específicos dentro do contêiner. Essa ação costuma ser usada com endpoints HTTP para assegurar que uma aplicação responda corretamente às solicitações. Se a solicitação acionar um código de status 2xx, o teste é considerado bem-sucedido.