O que é e como usar Ku­ber­ne­tes pod?

Um Ku­ber­ne­tes pod pode ter um ou mais con­têi­ne­res que se conectam e com­par­ti­lham recursos. Dessa forma, eles funcionam como um ambiente co­or­de­nado para as apli­ca­ções.

Ku­ber­ne­tes pod: Definição

Pod é o nome dado à unidade básica de im­ple­men­ta­ção no Ku­ber­ne­tes, que abrange um ou mais con­têi­ne­res in­ter­co­nec­ta­dos. Um pod é capaz de com­par­ti­lhar o mesmo espaço de rede, ar­ma­ze­na­mento e demais recursos. Por isso, ele re­pre­senta um agru­pa­mento lógico de con­têi­ne­res. Os con­têi­ne­res dentro de um Ku­ber­ne­tes 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 mi­cros­ser­viço precisa ser executada em um ambiente isolado, sem que seja ne­ces­sá­rio com­par­ti­lhar recursos e rede com outros con­têi­ne­res. Essa é a forma mais simples de pod que existe no Ku­ber­ne­tes e pos­si­bi­lita or­ques­tra­ção, es­ca­lo­na­mento e ge­ren­ci­a­mento.

Pod com múltiplos con­têi­ne­res

Pods que executam múltiplos con­têi­ne­res hospedam mais de um contêiner dentro de si. Esses con­têi­ne­res trabalham juntos e com­par­ti­lham o mesmo espaço e recursos de rede. Essa abordagem costuma ser usada quando os con­têi­ne­res estão es­trei­ta­mente co­nec­ta­dos e de­sem­pe­nham uma tarefa ou função em comum. Por exemplo, o contêiner da aplicação principal e o contêiner se­cun­dá­rio para registros ou mo­ni­to­ra­mento podem ser exe­cu­ta­dos em um único Ku­ber­ne­tes pod. Isso permite co­or­de­na­ção e co­mu­ni­ca­ção mais próximas entre con­tai­ners, enquanto eles são tratados como uma única entidade dentro do cluster do Ku­ber­ne­tes.

Como criar Ku­ber­ne­tes pod

Para criar um Ku­ber­ne­tes pod, você precisa de um arquivo YAML que faça a definição do pod. Este é um exemplo simples de con­fi­gu­ra­çã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 Ku­ber­ne­tes pod

O uso de níveis mais elevados de abstração, como De­ploy­ments ou Sta­te­ful­Sets, é re­co­men­dado para gerenciar pods em um ambiente produtivo. Esses con­tro­la­do­res assumem a definição do estado desejado da aplicação e asseguram que ele cor­res­ponda ao estado real. O es­ca­lo­na­mento, a atu­a­li­za­ção gradual e a re­cu­pe­ra­ção au­to­má­tica dos pods são im­ple­men­ta­dos.

Quando um pod é criado, seja di­re­ta­mente pelo ad­mi­nis­tra­dor ou in­di­re­ta­mente por um con­tro­la­dor, ele é agendado em um nó es­pe­cí­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 ma­nu­al­mente, 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á rei­ni­ci­ado em outro nó que estiver dis­po­ní­vel para garantir sua execução contínua.

O nome de um pod deve ser definido como um valor de sub­do­mí­nio DNS válido. Isso é im­por­tante para criar uma iden­ti­fi­ca­ção única para o pod dentro do cluster do Ku­ber­ne­tes. Labels de DNS devem ter menos de 253 ca­rac­te­res, conter apenas letras, números e hífenes e começar e terminar com um caractere al­fa­nu­mé­rico.

Sistema ope­ra­ci­o­nal do pod

Ku­ber­ne­tes pods costumam ser con­fi­gu­ra­dos para rodar em um sistema ope­ra­ci­o­nal Linux. No entanto, existem casos em que eles também podem ser exe­cu­ta­dos em um sistema ope­ra­ci­o­nal Windows, por exemplo, se a sua aplicação ou parte es­pe­cí­fica dela exigir recursos ex­clu­si­vos do Windows. Altere o sistema ope­ra­ci­o­nal no campo .spec.os.name nas es­pe­ci­fi­ca­ções do pod (arquivo YAML).

Gerenciar Ku­ber­ne­tes pod

Embora seja possível criar pods ma­nu­al­mente, esse pro­ce­di­mento não costuma ser prático devido à crescente com­ple­xi­dade das apli­ca­ções e cargas de trabalho. Por isso, muitos usuários recorrem aos con­tro­la­do­res do Ku­ber­ne­tes, que trazem uma camada abstrata baseada na con­fi­gu­ra­ção de­cla­ra­tiva. Existem di­fe­ren­tes tipos de con­tro­la­do­res:

• Ku­ber­ne­tes De­ploy­ment
• Ku­ber­ne­tes Sta­te­ful­Set
• Ku­ber­ne­tes DaemonSet

Con­tro­la­do­res do tipo “De­ploy­ment” monitoram con­ti­nu­a­mente o status do cluster. Isso pos­si­bi­lita a re­a­li­za­ção de ações au­to­ma­ti­za­das, como es­ca­lo­na­mento, atu­a­li­za­ção e ma­nu­ten­ção de apli­ca­ções. Con­tro­la­do­res “Re­pli­ca­Sets” garantem que um número constante de pods idênticos sejam exe­cu­ta­dos. Con­tro­la­do­res do tipo “Sta­te­ful­Set” são es­sen­ci­ais para apli­ca­ções com uso intensivo de dados, pois asseguram iden­ti­da­des de rede estáveis para os pods.

Templates do pod

O template de um pod é a parte da con­fi­gu­ra­ção de um con­tro­la­dor que descreve as pro­pri­e­da­des desejadas para um Ku­ber­ne­tes pod, o que inclui con­têi­ne­res, imagem Docker, variáveis do ambiente, re­qui­si­tos de recursos, entre outros. O con­tro­la­dor usa o template para con­fi­gu­rar ou atualizar o pod. Por exemplo, durante uma im­ple­men­ta­ção, ele cria novos pods quando o es­ca­lo­na­mento é ne­ces­sá­rio ou atualiza os pods exis­ten­tes durante uma atu­a­li­za­çã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, con­fi­gu­ra­mos 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 ten­ta­ti­vas de executar o job se houver algum erro.

Atualizar Ku­ber­ne­tes pod

O Ku­ber­ne­tes dis­po­ni­bi­liza diversos métodos para atualizar recursos, incluindo dois que são usados com maior frequên­cia: patch e replace.

O método Patch é empregado para realizar atu­a­li­za­ções di­re­ci­o­na­das e parciais de um recurso sem subs­ti­tuir todas as de­fi­ni­çõ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 al­te­ra­ções mínimas em um recurso, es­pe­ci­al­mente quando é ne­ces­sá­rio atualizar somente alguns campos.

Já o método Replace substitui todos os campos do recurso pelas novas de­fi­ni­ções. Esse método é usado quando é ne­ces­sá­rio realizar uma grande atu­a­li­za­ção ou al­te­ra­ções es­tru­tu­rais no recurso.

Existem metadados e campos fixos nas de­fi­ni­ções YAML dos recursos Ku­ber­ne­tes. 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 iden­ti­fi­ca­ção exclusiva do recurso.
• metadata.creationTimestamp: A data de criação de um recurso não é alterada e indica quando ele foi originado.

Com­par­ti­lhar recursos

Pods podem usar volumes para dividir dados entre os con­têi­ne­res dentro de um mesmo pod. Volume é nome dado a um sistema ou diretório de arquivos que é com­par­ti­lhado por um ou mais con­têi­ne­res no pod. Os volumes são me­ca­nis­mos eficazes para armazenar dados cuja exis­tên­cia vai além do ciclo de vida de um único contêiner.

Cada Ku­ber­ne­tes pod tem seu próprio endereço IP único dentro da rede do cluster. Esse endereço IP pos­si­bi­lita a co­mu­ni­ca­ção direta entre os pods. Se con­têi­ne­res múltiplos estiverem sendo exe­cu­ta­dos em um pod, eles con­se­gui­rão se comunicar via localhost e portas di­fe­ren­tes. Isso sim­pli­fica a interação entre as di­fe­ren­tes partes de uma aplicação no mesmo pod.

Modo pri­vi­le­gi­ado

Quando um contêiner é executado no modo pri­vi­le­gi­ado, ele tem pri­vi­lé­gios au­men­ta­dos e consegue acessar os recursos do sistema que não costumam ficar dis­po­ní­veis em um contêiner padrão isolado. No Ku­ber­ne­tes, o modo pri­vi­le­gi­ado é ativado pela opção securityContext.privileged nas es­pe­ci­fi­ca­ções do contêiner.

É im­por­tante observar que o uso do modo pri­vi­le­gi­ado traz sig­ni­fi­ca­ti­vos riscos à segurança. Devido aos pri­vi­lé­gios ampliados, a presença de um contêiner com­pro­me­tido ou uma aplicação maliciosa no sistema de host poderia causar graves problemas de segurança. Portanto, o modo pri­vi­le­gi­ado só deve ser usado quando for realmente ne­ces­sá­rio e depois de con­si­de­rar cui­da­do­sa­mente seus po­ten­ci­ais riscos de segurança.

Pods estáticos

Pods estáticos no Ku­ber­ne­tes não são mo­ni­to­ra­dos ou ge­ren­ci­a­dos por um plano de controle central do cluster. Ao contrário dos pods regulares, que dependem dos con­tro­la­do­res no Ku­ber­ne­tes, os pods estáticos são iniciados di­re­ta­mente por um nó. Esses pods são vin­cu­la­dos a um nó es­pe­cí­fico e suas de­fi­ni­ções são feitas no próprio nó, ge­ral­mente em um diretório como /etc/kubernetes/manifests/. O Kubelet no nó monitora e inicia o pod estático, rei­ni­ci­ando-o au­to­ma­ti­ca­mente se o pod travar.

Ao contrário dos pods regulares, os pods estáticos não são con­tro­la­dos pela API do Ku­ber­ne­tes e ficam in­vi­sí­veis no plano de controle central do cluster. Pods estáticos são uma forma simples de im­ple­men­tar apli­ca­ções ou serviços em um nó sem um cluster central do Ku­ber­ne­tes. No entanto, eles não têm todos os recursos dos pods regulares que são ad­mi­nis­tra­dos pelo ge­ren­ci­a­dor do con­tro­la­dor do Ku­ber­ne­tes.

Probes de contêiner

Probes de contêiner são me­ca­nis­mos do Ku­ber­ne­tes que monitoram o status e a in­te­gri­dade de um contêiner.

Para realizar um di­ag­nós­tico, o Kubelet pode acionar diversas ações:

• Exe­cAc­tion (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 é es­pe­ci­al­mente útil para realizar ve­ri­fi­ca­ções ou testes per­so­na­li­za­dos no contêiner. Após o comando ser chamado, o teste é con­si­de­rado bem-sucedido.
• TCP­Soc­ke­tAc­tion (ve­ri­fi­cada di­re­ta­mente pelo Kubelet): Esta ação permite que o Kubelet verifique a aces­si­bi­li­dade de uma porta TCP dentro do contêiner. Se a porta es­pe­ci­fi­cada estiver aberta, o teste é con­si­de­rado bem-sucedido.
• HTTP­Ge­tAc­tion (ve­ri­fi­cada di­re­ta­mente pelo Kubelet): Com esta ação, o Kubelet realiza uma so­li­ci­ta­ção HTTP GET para um caminho e uma porta es­pe­cí­fi­cos dentro do contêiner. Essa ação costuma ser usada com endpoints HTTP para assegurar que uma aplicação responda cor­re­ta­mente às so­li­ci­ta­ções. Se a so­li­ci­ta­ção acionar um código de status 2xx, o teste é con­si­de­rado bem-sucedido.