Domine a solução de problemas do POD KUBERNETES: estratégias e cenários avançados

[Antevisão da transmissão ao vivo] Os modelos grandes substituirão os programadores? "

As implantações de Kubernetes (K8s) geralmente apresentam desafios de diversas perspectivas, incluindo pods, serviços, entrada, clusters que não respondem, planos de controle e configuração de alta disponibilidade. O pod Kubernetes é a menor unidade implantável no ecossistema Kubernetes, encapsulando um ou mais contêineres que compartilham recursos e redes. Os pods são projetados para executar uma única instância de um aplicativo ou processo e são criados e descartados conforme necessário. Os pods são essenciais para dimensionar, atualizar e manter aplicativos em um ambiente K8s.

Traduzido de Master Kubernetes Pods: Advanced Troubleshooting Strategies , autor Nenhum.

Este artigo explora os desafios enfrentados pelos pods do Kubernetes e as etapas de solução de problemas a serem seguidas. Algumas das mensagens de erro encontradas ao executar pods do Kubernetes incluem:

ImagemPullBackoff
ErrImagePull
Nome de imagem inválido
CrashLoopBackOff

Às vezes, você nem encontrará os erros listados, mas ainda assim descobrirá que seu pod falha. Primeiro, é importante observar que ao depurar qualquer recurso do Kubernetes, você deve entender a referência da API . Ele explica como as várias APIs do Kubernetes são definidas e como funcionam vários objetos em um pod/implantação. A documentação está claramente definida na referência da API no site do Kubernetes . Nesse caso, ao depurar o pod, selecione o objeto pod na referência da API para saber mais sobre como o pod funciona. Ele define os campos que vão para o pod, nomeadamente versão, tipo, metadados, especificação e status. O Kubernetes também fornece uma folha de dicas com um guia para os comandos necessários.

pré-requisitos

Este artigo pressupõe que os leitores tenham as seguintes condições:

Tipo instalado para demonstração de cenário
Compreensão intermediária da arquitetura Kubernetes
Ferramenta de linha de comando Kubectl

Erro de pod do Kubernetes - ImagePullBackoff

Este erro aparece por três motivos diferentes:

Imagem inválida
Etiqueta inválida
Permissões inválidas

Essas situações surgem quando você não tem as informações corretas sobre a imagem. Você também pode não ter permissão para extrair a imagem de seu repositório (repositório privado). Para demonstrar isso no exemplo abaixo, criamos uma implantação nginx:

➜ ~ kubectl create deploy nginx --image=nginxdeployment.apps/nginx created

Depois que o pod estiver em execução, obtenha o nome do pod:

➜ ~ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-8f458dc5b-hcrsh 1/1 Running 0 100s

Copie o nome do pod em execução e obtenha mais informações sobre ele:

➜ ~ kubectl describe pod nginx-8f458dc5b-hcrsh
Name:             nginx-8f458dc5b-hcrsh
hable:NoExecute op=Exists for 300s
Events:
 Type    Reason     Age    From               Message
 ----    ------     ----   ----               -------
 Normal  Scheduled  2m43s  default-scheduler  Successfully assigned default/nginx-8f458dc5b-hcrsh to k8s-troubleshooting-control-plane
 Normal  Pulling    2m43s  kubelet            Pulling image "nginx"
 Normal  Pulled     100s   kubelet            Successfully pulled image "nginx" in 1m2.220189835s
 Normal  Created    100s   kubelet            Created container nginx
 Normal  Started    100s   kubelet            Started container nginx

A imagem foi extraída com sucesso. Seu pod do Kubernetes está funcionando sem erros.

Para demonstrar o ImagePullBackoff, edite o arquivo YAML de implantação e especifique uma imagem inexistente:

➜ kubectl edit deploy nginx
 containers:
 -image: nginxdoestexist
  imagePullPolicy: Always
  name: nginx

O novo pod não foi implantado com êxito

➜ ~ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-5b847fdb95-mx4pq 0/1 ErrImagePull 0 3m40s
nginx-8f458dc5b-hcrsh 1/1 Running 0 38m

Erro ImagePullBackoff exibido

➜  ~ kubectl describe pod nginx-6f46cbfbcb-c92bl
Events:
 Type     Reason     Age                From               Message
 ----     ------     ----               ----               -------
 Normal   Scheduled  88s                default-scheduler  Successfully assigned default/nginx-6f46cbfbcb-c92bl to k8s-troubleshooting-control-plane
 Normal   Pulling    40s (x3 over 88s)  kubelet            Pulling image "nginxdoesntexist"
 Warning  Failed     37s (x3 over 85s)  kubelet            Failed to pull image "nginxdoesntexist": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/nginxdoesntexist:latest": failed to resolve reference "docker.io/library/nginxdoesntexist:latest": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
 Warning  Failed     37s (x3 over 85s)  kubelet            Error: ErrImagePull
 Normal   BackOff    11s (x4 over 85s)  kubelet            Back-off pulling image "nginxdoesntexist"
 Warning  Failed     11s (x4 over 85s)  kubelet            Error: ImagePullBackOff

Erro do pod do Kubernetes: a imagem foi extraída, mas o pod está com status pendente.

Sempre que você executa K8s em um ambiente de produção, o administrador do K8s aloca cotas de recursos para cada namespace com base nos requisitos dos namespaces em execução no cluster. Namespaces são usados para separação lógica dentro de um cluster.

O erro "Imagem extraída, mas o pod ainda está pendente" é gerado quando as especificações na cota de recursos não atendem aos requisitos mínimos do aplicativo no pod. No exemplo a seguir, crie um namespace chamado pagamentos:

➜ ~ kubectl create ns payments

namespace/payments created

Crie cotas de recursos usando especificações relevantes

➜  ~ cat resourcequota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
 name: compute-resources
spec:
 hard:
   requests.cpu: "1"
   requests.memory: 1Gi
   limits.cpu: "2"
   limits.memory: 4Gi

Atribuir cotas de recursos a pagamentos de namespace

➜ ~ kubectl apply -f resourcequota.yaml -n paymentsresourcequota/compute-resources created

Cota de recursos/recursos de computação criados

Crie uma nova implantação em um namespace com restrições de cota de recursos:

kubectl create deploy nginx --image=nginx -n paymentsdeployment.apps/nginx created

Embora a implantação tenha sido criada com êxito, não existem pods:

➜ ~ kubectl get pods -n payments

No resources found in payments namespace

A implantação foi criada, mas não há pods no estado pronto, nem pods para atualizar, nem pods disponíveis:

➜  ~ kubectl get deploy -n payments
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   0/1     0            0           7m4s

Para depurar ainda mais, descreva a implantação do nginx. Falha na criação do pod:

➜  ~ kubectl describe deploy nginx -n payments
Name:                   nginx
Namespace:              payments
CreationTimestamp:      Wed, 24 May 2023 21:37:55 +0300
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=nginx
Replicas:               1 desired | 0 updated | 0 total | 0 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
 Labels:  app=nginx
 Containers:
  nginx:
   Image:        nginx
   Port:         <none>
   Host Port:    <none>
   Environment:  <none>
   Mounts:       <none>
 Volumes:        <none>
Conditions:
 Type             Status  Reason
 ----             ------  ------
 Available        False   MinimumReplicasUnavailable
 ReplicaFailure   True    FailedCreate
 Progressing      False   ProgressDeadlineExceeded
OldReplicaSets:    <none>
NewReplicaSet:     nginx-8f458dc5b (0/1 replicas created)
Events:
 Type    Reason             Age   From                   Message
 ----    ------             ----  ----                   -------
 Normal  ScalingReplicaSet  10m   deployment-controller  Scaled up replica set nginx-8f458dc5b to 1

Análises adicionais dos eventos do Kubernetes revelaram memória insuficiente necessária para a criação do pod.

➜ ~ kubectl get events --sort-by=/metadata.creationTimestamp

Este erro ocorre quando sua imagem é extraída com sucesso e seu contêiner é criado, mas sua configuração de tempo de execução falha. Por exemplo, se você tiver um aplicativo Python em funcionamento que está tentando gravar em uma pasta que não existe ou não tem permissão para gravar na pasta. Inicialmente, o aplicativo é executado e depois encontra um erro. Se ocorrer um pânico na lógica do seu aplicativo, o contêiner será interrompido. O contêiner irá para CrashLoopBackOff. Eventualmente, você observa que a implantação não tem pods, ou seja, há um pod, mas ele não está em execução e gera um erro CrashLoopbackoff.

Falha nas sondagens de atividade e prontidão

A detecção de atividade detecta se um pod entrou em estado danificado e não pode mais fornecer tráfego. O Kubernetes reiniciará o pod para você. As sondagens de prontidão verificam se seu aplicativo está pronto para lidar com o tráfego. As sondagens de preparação garantem que seu aplicativo busque todas as configurações necessárias do mapa de configuração e inicie seus threads. Somente após concluir esse processo seu aplicativo estará pronto para receber tráfego. Se seu aplicativo encontrar um erro durante esse processo, ele também entrará em CrashLoopBackoff.

Comece a solucionar problemas!

Este artigo fornece uma visão geral das técnicas de solução de problemas para pods do Kubernetes. Ele aborda erros comuns encontrados durante a implantação de pods e fornece soluções práticas para resolvê-los. Ele também fornece informações sobre páginas de referência e folhas de dicas que são essenciais para entender como o Kubernetes funciona e identificar e resolver problemas de maneira eficaz. Seguindo as orientações fornecidas neste artigo, os leitores podem melhorar suas habilidades de solução de problemas e simplificar a implantação e o gerenciamento de seus pods Kubernetes.

Este artigo foi publicado pela primeira vez em Yunyunzhongsheng ( https://yylives.cc/ ), todos são bem-vindos para visitar.