1 - Imagens
Uma imagem de contêiner representa dados binários que encapsulam uma aplicação e todas as suas dependências de software. As imagens de contêiner são pacotes de software executáveis que podem ser executados de forma autônoma e que fazem suposições muito bem definidas sobre seu agente de execução do ambiente.
Normalmente, você cria uma imagem de contêiner da sua aplicação e a envia para um registro antes de fazer referência a ela em um Pod
Esta página fornece um resumo sobre o conceito de imagem de contêiner.
Nomes das imagens
As imagens de contêiner geralmente recebem um nome como pause, exemplo/meuconteiner, ou kube-apiserver.
As imagens também podem incluir um hostname de algum registro; por exemplo: exemplo.registro.ficticio/nomeimagem,
e um possível número de porta; por exemplo: exemplo.registro.ficticio:10443/nomeimagem.
Se você não especificar um hostname de registro, o Kubernetes presumirá que você se refere ao registro público do Docker.
Após a parte do nome da imagem, você pode adicionar uma tag (como também usar com comandos como docker e podman).
As tags permitem identificar diferentes versões da mesma série de imagens.
Tags de imagem consistem em letras maiúsculas e minúsculas, dígitos, sublinhados (_),
pontos (.) e travessões ( -).
Existem regras adicionais sobre onde você pode colocar o separador
caracteres (_,- e .) dentro de uma tag de imagem.
Se você não especificar uma tag, o Kubernetes presumirá que você se refere à tag latest (mais recente).
Cuidado: Você deve evitar usar a tag latest quando estiver realizando o deploy de contêineres em produção,
pois é mais difícil rastrear qual versão da imagem está sendo executada, além de tornar mais difícil o processo de reversão para uma versão funcional.
Em vez disso, especifique uma tag significativa, como v1.42.0.
Atualizando imagens
A política padrão de pull é IfNotPresent a qual faz com que o
kubelet ignore
o processo de pull da imagem, caso a mesma já exista. Se você prefere sempre forçar o processo de pull,
você pode seguir uma das opções abaixo:
- defina a
imagePullPolicy do contêiner para Always.
- omita
imagePullPolicy e use: latest como a tag para a imagem a ser usada.
- omita o
imagePullPolicy e a tag da imagem a ser usada.
- habilite o AlwaysPullImages controlador de admissão.
Quando imagePullPolicy é definido sem um valor específico, ele também é definido como Always.
Além de fornecer o binário das imagens, um registro de contêiner também pode servir um índice de imagem do contêiner. Um índice de imagem pode apontar para múltiplos manifestos da imagem para versões específicas de arquitetura de um contêiner. A ideia é que você possa ter um nome para uma imagem (por exemplo: pause, exemple/meuconteiner, kube-apiserver) e permitir que diferentes sistemas busquem o binário da imagem correta para a arquitetura de máquina que estão usando.
O próprio Kubernetes normalmente nomeia as imagens de contêiner com o sufixo -$(ARCH). Para retrocompatibilidade, gere as imagens mais antigas com sufixos. A ideia é gerar a imagem pause que tem o manifesto para todas as arquiteturas e pause-amd64 que é retrocompatível com as configurações anteriores ou arquivos YAML que podem ter codificado as imagens com sufixos.
Usando um registro privado
Os registros privados podem exigir chaves para acessar as imagens deles.
As credenciais podem ser fornecidas de várias maneiras:
- Configurando nós para autenticação em um registro privado
- todos os pods podem ler qualquer registro privado configurado
- requer configuração de nó pelo administrador do cluster
- Imagens pré-obtidas
- todos os pods podem usar qualquer imagem armazenada em cache em um nó
- requer acesso root a todos os nós para configurar
- Especificando ImagePullSecrets em um Pod
- apenas pods que fornecem chaves próprias podem acessar o registro privado
- Extensões locais ou específicas do fornecedor
- se estiver usando uma configuração de nó personalizado, você (ou seu provedor de nuvem) pode implementar seu mecanismo para autenticar o nó ao registro do contêiner.
Essas opções são explicadas com mais detalhes abaixo.
Configurando nós para autenticação em um registro privado
Se você executar o Docker em seus nós, poderá configurar o contêiner runtime do Docker
para autenticação em um registro de contêiner privado.
Essa abordagem é adequada se você puder controlar a configuração do nó.
Nota: O Kubernetes padrão é compatível apenas com as seções auths e HttpHeaders na configuração do Docker.
Auxiliares de credencial do Docker (credHelpers ou credsStore) não são suportados.
Docker armazena chaves de registros privados no arquivo $HOME/.dockercfg ou $HOME/.docker/config.json. Se você colocar o mesmo arquivo na lista de caminhos de pesquisa abaixo, o kubelet o usa como provedor de credenciais ao obter imagens.
{--root-dir:-/var/lib/kubelet}/config.json{cwd of kubelet}/config.json${HOME}/.docker/config.json/.docker/config.json{--root-dir:-/var/lib/kubelet}/.dockercfg{cwd of kubelet}/.dockercfg${HOME}/.dockercfg/.dockercfg
Nota: Você talvez tenha que definir HOME=/root explicitamente no ambiente do processo kubelet.
Aqui estão as etapas recomendadas para configurar seus nós para usar um registro privado. Neste
exemplo, execute-os em seu desktop/laptop:
- Execute
docker login [servidor] para cada conjunto de credenciais que deseja usar. Isso atualiza o $HOME/.docker/config.json em seu PC.
- Visualize
$HOME/.docker/config.json em um editor para garantir que contém apenas as credenciais que você deseja usar.
- Obtenha uma lista de seus nós; por exemplo:
- se você quiser os nomes:
nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )
- se você deseja obter os endereços IP:
nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )
- Copie seu
.docker/config.json local para uma das listas de caminhos de busca acima.
- por exemplo, para testar isso:
for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done
Nota: Para clusters de produção, use uma ferramenta de gerenciamento de configuração para que você possa aplicar esta
configuração em todos os nós que você precisar.
Verifique se está funcionando criando um pod que usa uma imagem privada; por exemplo:
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: private-image-test-1
spec:
containers:
- name: uses-private-image
image: $PRIVATE_IMAGE_NAME
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
EOF
pod/private-image-test-1 created
Se tudo estiver funcionando, então, após algum tempo, você pode executar:
kubectl logs private-image-test-1
e veja o resultado do comando:
SUCCESS
Se você suspeitar que o comando falhou, você pode executar:
kubectl describe pods/private-image-test-1 | grep 'Failed'
Em caso de falha, a saída é semelhante a:
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
Você deve garantir que todos os nós no cluster tenham o mesmo .docker/config.json. Caso contrário, os pods serão executados com sucesso em alguns nós e falharão em outros. Por exemplo, se você usar o escalonamento automático de nós, cada modelo de instância precisa incluir o .docker/config.json ou montar um drive que o contenha.
Todos os pods terão premissão de leitura às imagens em qualquer registro privado, uma vez que
as chaves privadas do registro são adicionadas ao .docker/config.json.
Imagens pré-obtidas
Nota: Essa abordagem é adequada se você puder controlar a configuração do nó. Isto
não funcionará de forma confiável se o seu provedor de nuvem for responsável pelo gerenciamento de nós e os substituir
automaticamente.
Por padrão, o kubelet tenta realizar um "pull" para cada imagem do registro especificado.
No entanto, se a propriedade imagePullPolicy do contêiner for definida como IfNotPresent ou Never,
em seguida, uma imagem local é usada (preferencial ou exclusivamente, respectivamente).
Se você quiser usar imagens pré-obtidas como um substituto para a autenticação do registro,
você deve garantir que todos os nós no cluster tenham as mesmas imagens pré-obtidas.
Isso pode ser usado para pré-carregar certas imagens com o intuíto de aumentar a velocidade ou como uma alternativa para autenticação em um registro privado.
Todos os pods terão permissão de leitura a quaisquer imagens pré-obtidas.
Especificando imagePullSecrets em um pod
Nota: Esta é a abordagem recomendada para executar contêineres com base em imagens
de registros privados.
O Kubernetes oferece suporte à especificação de chaves de registro de imagem de contêiner em um pod.
Execute o seguinte comando, substituindo as palavras em maiúsculas com os valores apropriados:
kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
Se você já tem um arquivo de credenciais do Docker, em vez de usar o
comando acima, você pode importar o arquivo de credenciais como um Kubernetes
Secrets.
Criar um segredo com base nas credenciais Docker existentes explica como configurar isso.
Isso é particularmente útil se você estiver usando vários registros privados de contêineres, como kubectl create secret docker-registry cria um Segredo que
só funciona com um único registro privado.
Nota: Os pods só podem fazer referência a pull secrets de imagem em seu próprio namespace,
portanto, esse processo precisa ser feito uma vez por namespace.
Referenciando um imagePullSecrets em um pod
Agora, você pode criar pods que fazem referência a esse segredo adicionando uma seção imagePullSecrets
na definição de Pod.
Por exemplo:
cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF
Isso precisa ser feito para cada pod que está usando um registro privado.
No entanto, a configuração deste campo pode ser automatizada definindo o imagePullSecrets
em um recurso de ServiceAccount.
Verifique Adicionar ImagePullSecrets a uma conta de serviço para obter instruções detalhadas.
Você pode usar isso em conjunto com um .docker / config.json por nó. As credenciais
serão mescladas.
Casos de uso
Existem várias soluções para configurar registros privados. Aqui estão alguns
casos de uso comuns e soluções sugeridas.
- Cluster executando apenas imagens não proprietárias (por exemplo, código aberto). Não há necessidade de ocultar imagens.
- Use imagens públicas no Docker hub.
- Nenhuma configuração necessária.
- Alguns provedores de nuvem armazenam em cache ou espelham automaticamente imagens públicas, o que melhora a disponibilidade e reduz o tempo para extrair imagens.
- Cluster executando algumas imagens proprietárias que devem ser ocultadas para quem está fora da empresa, mas
visível para todos os usuários do cluster.
- Use um registro Docker privado hospedado.
- Pode ser hospedado no Docker Hub ou em outro lugar.
- Configure manualmente .docker/config.json em cada nó conforme descrito acima.
- Ou execute um registro privado interno atrás de seu firewall com permissão de leitura.
- Nenhuma configuração do Kubernetes é necessária.
- Use um serviço de registro de imagem de contêiner que controla o acesso à imagem
- Funcionará melhor com o escalonamento automático do cluster do que com a configuração manual de nós.
- Ou, em um cluster onde alterar a configuração do nó é inconveniente, use
imagePullSecrets.
- Cluster com imagens proprietárias, algumas das quais requerem controle de acesso mais rígido.
- Certifique-se de que o controlador de admissão AlwaysPullImages está ativo. Caso contrário, todos os pods têm potencialmente acesso a todas as imagens.
- Mova dados confidenciais para um recurso "secreto", em vez de empacotá-los em uma imagem.
- Um cluster multilocatário em que cada locatário precisa de seu próprio registro privado.
- Certifique-se de que o controlador de admissão AlwaysPullImages está ativo. Caso contrário, todos os Pods de todos os locatários terão potencialmente acesso a todas as imagens.
- Execute um registro privado com autorização necessária.
- Gere credenciais de registro para cada locatário, coloque em segredo e preencha o segredo para cada namespace de locatário.
- O locatário adiciona esse segredo a imagePullSecrets de cada namespace.
Se precisar de acesso a vários registros, você pode criar um segredo para cada registro.
O Kubelet mesclará qualquer imagePullSecrets em um único .docker/config.json virtual
Qual é o próximo
2 - Ambiente de Contêiner
Essa página descreve os recursos disponíveis para contêineres no ambiente de contêiner.
Ambiente de contêiner
O ambiente de contêiner do Kubernetes fornece recursos importantes para contêineres:
- Um sistema de arquivos, que é a combinação de uma imagem e um ou mais volumes.
- Informação sobre o contêiner propriamente.
- Informação sobre outros objetos no cluster.
O hostname de um contêiner é o nome do Pod em que o contêiner está executando.
Isso é disponibilizado através do comando hostname ou da função gethostname chamada na libc.
O nome do Pod e o Namespace são expostos como variáveis de ambiente através de um mecanismo chamado downward API.
Variáveis de ambiente definidas pelo usuário a partir da definição do Pod também são disponíveis para o contêiner, assim como qualquer variável de ambiente especificada estáticamente na imagem Docker.
Uma lista de todos os serviços que estão executando quando um contêiner foi criado é disponibilizada para o contêiner como variáveis de ambiente.
Essas variáveis de ambiente são compatíveis com a funcionalidade docker link do Docker.
Para um serviço nomeado foo que mapeia para um contêiner nomeado bar, as seguintes variáveis são definidas:
FOO_SERVICE_HOST=<o host em que o serviço está executando>
FOO_SERVICE_PORT=<a porta em que o serviço está executando>
Serviços possuem endereço IP dedicado e são disponibilizados para o contêiner via DNS,
se possuírem DNS addon habilitado.
Qual é o próximo
3 - Classes de execução
FEATURE STATE: Kubernetes v1.20 [stable]
Essa página descreve o recurso RuntimeClass e a seleção do mecanismo do agente de execução.
RuntimeClass é uma funcionalidade para selecionar as configurações do agente de execução do contêiner.
A configuração do agente de execução de contêineres é usada para executar os contêineres de um Pod.
Motivação
Você pode configurar um RuntimeClass diferente entre os diferentes Pods para prover
um equilíbrio entre performance versus segurança. Por exemplo, se parte de sua carga de
trabalho necessita de um alto nível de garantia de segurança da informação, você pode
optar em executar esses Pods em um agente de execução que usa virtualização de hardware.
Você então terá o benefício do isolamento extra de um agente de execução alternativo, ao
custo de uma latência adicional.
Você pode ainda usar um RuntimeClass para executar diferentes Pods com o mesmo agente
de execução de contêineres mas com diferentes configurações.
Configuração
- Configure a implementação do CRI nos nós (depende do agente de execução)
- Crie o recurso RuntimeClass correspondente.
As configurações disponíveis através do RuntimeClass sáo dependentes da implementação do
Container Runtime Interface (Container runtime interface (CRI)). Veja a documentação correspondente abaixo para a
sua implementação CRI para verificar como configurar.
Nota: RuntimeClass assume uma configuração homogênea de nós entre todo o cluster por padrão
(o que significa que todos os nós estão configurados do mesmo jeito referente aos agentes de
execução). Para suportar configurações heterogêneas, veja
Associação abaixo.
As configurações possuem um nome handler correspondente, referenciado pelo RuntimeClass.
Esse nome deve ser um valor DNS 1123 válido (letras, números e o carácter -).
2. Crie o recurso RuntimeClass correspondente
As etapas de configuração no passo 1 devem todas estar associadas a um nome para o campo handler
que identifica a configuração. Para cada um, crie o objeto RuntimeClass correspondente.
O recurso RuntimeClass atualmente possui apenas 2 campos significativos: o nome do RuntimeClass
(metadata.name) e o agente (handler). A definição do objeto se parece conforme a seguir:
apiVersion: node.k8s.io/v1 # RuntimeClass é definido no grupo de API node.k8s.io
kind: RuntimeClass
metadata:
name: myclass # O nome que o RuntimeClass será chamado como
# RuntimeClass é um recurso global, e não possui namespace.
handler: myconfiguration # Nome da configuração CRI correspondente
O nome de um objeto RuntimeClass deve ser um
nome de subdomínio DNS válido.
Nota: É recomendado que operações de escrita no objeto RuntimeClass (criar/atualizar/patch/apagar)
sejam restritas a administradores do cluster. Isso geralmente é o padrão. Veja
Visão Geral
de autorizações para maiores detalhes.
Uso
Uma vez que as classes de execução estão configuradas no cluster, usar elas é relativamente
simples. Especifique um runtimeClassName na especificação do Pod. Por exemplo:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: myclass
# ...
Isso irá instruir o kubelet a usar o RuntimeClass nomeado acima (myclass) para esse Pod. Se
o nome do RuntimeClass não existir, ou o CRI não puder executar a solicitação, o Pod entrará na fase
final Failed. Procure por um
evento correspondente
para uma mensagem de erro.
Se nenhum runtimeClassName for especificado, o RuntimeHandler padrão será utilizado, que é equivalente
ao comportamento quando a funcionalidade de RuntimeClass está desativada.
Configuração do CRI
Para maiores detalhes de configuração dos agentes de execução CRI, veja instalação do CRI.
dockershim
O CRI dockershim embutido no Kubernetes não suporta outros agentes de execução.
Agentes de execução são configurados através da configuração do containerd em
/etc/containerd/config.toml. Agentes válidos são configurados sob a seção de runtimes:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
Veja a documentação de configuração do containerd para maiores detalhes:
https://github.com/containerd/cri/blob/master/docs/config.md
Agentes de execução são configurados através da configuração do CRI-O em /etc/crio/crio.conf.
Agentes válidos são configurados na seção crio.runtime
table:
[crio.runtime.runtimes.${HANDLER_NAME}]
runtime_path = "${PATH_TO_BINARY}"
Veja a documentação de configuração do CRI-O para maiores detalhes.
Associação
FEATURE STATE: Kubernetes v1.16 [beta]
Ao especificar o campo scheduling para um RuntimeClass, você pode colocar limites e
garantir que os Pods executando dentro de uma RuntimeClass sejam associados a nós que
suportem eles. Se o scheduling não estiver configurado, assume-se que esse RuntimeClass
é suportado por todos os nós.
Para garantir que os Pods sejam executados em um nó que suporte um RuntimeClass específico,
aquele conjunto de nós deve possuir uma marca/label padrão que é selecionado pelo campo
runtimeclass.scheduling.nodeSelector. O nodeSelector do RuntimeClass é combinado com o
nodeSelector do Pod em tempo de admissão, obtendo a intersecção do conjunto de nós selecionado
por cada. Se existir um conflito, o pod será rejeitado.
Se os nós suportados possuírem marcação de restrição para prevenir outros Pods com uma
classe de execução diferente de executar no nó, você pode adicionar o campo tolerations
ao objeto RuntimeClass. Assim como com o nodeSelector, o tolerations é combinado com
o campo tolerations do Pod em tempo de admissão, efetivamente pegando a intersecção do
conjunto de nós aplicáveis para cada.
Para saber mais sobre a configuração de seleção de nós e tolerâncias, veja Associando Pods a
Nós.
Sobrecarga de Pods
FEATURE STATE: Kubernetes v1.18 [beta]
Você pode especificar os recursos extra que estão associados à execução de um Pod. Declarar esses
recursos extra permite ao cluster (incluindo o agendador/scheduler de pods) contabilizar por
esses recursos quando estiver decidindo sobre Pods e recursos. Para usar a contabilização
desses recursos extras, você deve estar com o feature gate
PodOverhead habilitado (ele já está habilitado por padrão).
Os recursos extras utilizados são especificados no objeto RuntimeClass através do campo overhead.
Ao usar esses campos, você especifica o uso extra de recursos necessários para executar
Pods utilizando-se desse Runtimeclass e assim contabilizar esses recursos para o Kubernetes.
Qual é o próximo
4 - Hooks de Ciclo de Vida do Contêiner
Essa página descreve como os contêineres gerenciados pelo kubelet podem usar a estrutura de hook de ciclo de vida do contêiner para executar código acionado por eventos durante seu ciclo de vida de gerenciamento.
Visão Geral
Análogo a muitas estruturas de linguagem de programação que tem hooks de ciclo de vida de componentes, como angular,
o Kubernetes fornece aos contêineres hooks de ciclo de vida.
Os hooks permitem que os contêineres estejam cientes dos eventos em seu ciclo de vida de gerenciamento
e executem código implementado em um manipulador quando o hook de ciclo de vida correspondente é executado.
Hooks do contêiner
Existem dois hooks que são expostos para os contêiners:
PostStart
Este hook é executado imediatamente após um contêiner ser criado.
Entretanto, não há garantia que o hook será executado antes do ENTRYPOINT do contêiner.
Nenhum parâmetro é passado para o manipulador.
PreStop
Esse hook é chamado imediatamente antes de um contêiner ser encerrado devido a uma solicitação de API ou um gerenciamento de evento como liveness/startup probe failure, preemption, resource contention e outros.
Uma chamada ao hook PreStop falha se o contêiner já está em um estado finalizado ou concluído e o hook deve ser concluído antes que o sinal TERM seja enviado para parar o contêiner. A contagem regressiva do período de tolerância de término do Pod começa antes que o hook PreStop seja executado, portanto, independentemente do resultado do manipulador, o contêiner será encerrado dentro do período de tolerância de encerramento do Pod. Nenhum parâmetro é passado para o manipulador.
Uma descrição mais detalhada do comportamento de término pode ser encontrada em Término de Pods.
Implementações de manipulador de hook
Os contêineres podem acessar um hook implementando e registrando um manipulador para esse hook.
Existem dois tipos de manipuladores de hooks que podem ser implementados para contêineres:
- Exec - Executa um comando específico, como
pre-stop.sh, dentro dos cgroups e Namespaces do contêiner.
- HTTP - Executa uma requisição HTTP em um endpoint específico do contêiner.
Execução do manipulador de hook
Quando um hook de gerenciamento de ciclo de vida do contêiner é chamado, o sistema de gerenciamento do Kubernetes executa o manipulador de acordo com a ação do hook, httpGet e tcpSocket são executados pelo processo kubelet e exec é executado pelo contêiner.
As chamadas do manipulador do hook são síncronas no contexto do Pod que contém o contêiner.
Isso significa que para um hook PostStart, o ENTRYPOINT do contêiner e o hook disparam de forma assíncrona.
No entanto, se o hook demorar muito para ser executado ou travar, o contêiner não consegue atingir o estado running.
Os hooks PreStop não são executados de forma assíncrona a partir do sinal para parar o contêiner, o hook precisa finalizar a sua execução antes que o sinal TERM possa ser enviado.
Se um hook PreStop travar durante a execução, a fase do Pod será Terminating e permanecerá até que o Pod seja morto após seu terminationGracePeriodSeconds expirar. Esse período de tolerância se aplica ao tempo total necessário
para o hook PreStopexecutar e para o contêiner parar normalmente.
Se por exemplo, o terminationGracePeriodSeconds é 60, e o hook leva 55 segundos para ser concluído, e o contêiner leva 10 segundos para parar normalmente após receber o sinal, então o contêiner será morto antes que possa parar
normalmente, uma vez que o terminationGracePeriodSeconds é menor que o tempo total (55 + 10) que é necessário para que essas duas coisas aconteçam.
Se um hook PostStart ou PreStop falhar, ele mata o contêiner.
Os usuários devem tornar seus hooks o mais leve possíveis.
Há casos, no entanto, em que comandos de longa duração fazem sentido, como ao salvar o estado
antes de parar um contêiner.
Garantias de entrega de hooks
A entrega do hook é destinada a acontecer pelo menos uma vez,
o que quer dizer que um hook pode ser chamado várias vezes para qualquer evento,
como para PostStart ou PreStop.
Depende da implementação do hook lidar com isso corretamente.
Geralmente, apenas entregas únicas são feitas.
Se, por exemplo, um receptor de hook HTTP estiver inativo e não puder receber tráfego,
não há tentativa de reenviar.
Em alguns casos raros, no entanto, pode ocorrer uma entrega dupla.
Por exemplo, se um kubelet reiniciar no meio do envio de um hook, o hook pode ser
reenviado depois que o kubelet voltar a funcionar.
Depurando manipuladores de hooks
Os logs para um manipulador de hook não são expostos em eventos de Pod.
Se um manipulador falhar por algum motivo, ele transmitirá um evento.
Para PostStart é o evento FailedPostStartHook e para PreStop é o evento
FailedPreStopHook.
Você pode ver esses eventos executando kubectl describe pod <nome_do_pod>.
Aqui está um exemplo de saída de eventos da execução deste comando:
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
Qual é o próximo