Plotseling kan ik sommige afbeeldingen die eerder konden worden geïmplementeerd, niet implementeren. Ik heb de volgende pod-status:
[root@webdev2 origin]# oc get pods
NAME READY STATUS RESTARTS AGE
arix-3-yjq9w 0/1 ImagePullBackOff 0 10m
docker-registry-2-vqstm 1/1 Running 0 2d
router-1-kvjxq 1/1 Running 0 2d
De applicatie wil gewoon niet starten. De pod probeert de container niet uit te voeren. Van de evenementpagina heb ik Back-off pulling image "172.30.84.25:5000/default/arix@sha256:d326. Ik heb geverifieerd dat ik de afbeelding met de tag kan ophalen met docker pull.
Ik heb ook het logboek van de laatste container gecontroleerd. Het was om een of andere reden gesloten. Ik denk dat de pod op zijn minst moet proberen hem opnieuw op te starten.
Ik heb geen ideeën meer om de problemen op te lossen. Wat kan ik meer controleren?
Antwoord 1, autoriteit 100%
U kunt de syntaxis ‘beschrijf pod‘ gebruiken
Voor gebruik met OpenShift:
oc describe pod <pod-id>
Voor vanille Kubernetes:
kubectl describe pod <pod-id>
Bekijk de gebeurtenissen van de uitvoer.
In mijn geval toont het Back-off pulling image unreachableserver/nginx:1.14.22222
In dit geval kan de afbeelding unreachableserver/nginx:1.14.22222niet van internet worden gehaald omdat er geen Docker registry unreachableserver is en de afbeelding nginx:1.14.22222bestaat niet.
NB: als u geen interessante gebeurtenissen ziet en de pod heeft al een tijdje de status ‘ImagePullBackOff’ (lijkt meer dan 60 minuten), moet u de pod verwijderen en naar de evenementen uit de nieuwe pod.
Voor gebruik met OpenShift:
oc delete pod <pod-id>
oc get pods
oc get pod <new-pod-id>
Voor vanille Kubernetes:
kubectl delete pod <pod-id>
kubectl get pods
kubectl get pod <new-pod-id>
Voorbeelduitvoer:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 32s default-scheduler Successfully assigned rk/nginx-deployment-6c879b5f64-2xrmt to aks-agentpool-x
Normal Pulling 17s (x2 over 30s) kubelet Pulling image "unreachableserver/nginx:1.14.22222"
Warning Failed 16s (x2 over 29s) kubelet Failed to pull image "unreachableserver/nginx:1.14.22222": rpc error: code = Unknown desc = Error response from daemon: pull access denied for unreachableserver/nginx, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Warning Failed 16s (x2 over 29s) kubelet Error: ErrImagePull
Normal BackOff 5s (x2 over 28s) kubelet Back-off pulling image "unreachableserver/nginx:1.14.22222"
Warning Failed 5s (x2 over 28s) kubelet Error: ImagePullBackOff
Aanvullende stappen voor foutopsporing
- Probeer de Docker-afbeelding en tag handmatig op uw computer te trekken
- Identificeer het knooppunt door een ‘KUBECTL / OC GET PODS -O WIDE’
- SSH in het knooppunt (als u kunt) die de Docker-afbeelding niet kan trekken
- Controleer of het knooppunt de DNS van het Docker-register kan oplossen door een ping uit te voeren.
- Probeer de afbeelding van de docker handmatig op het knooppunt te trekken
- Als u een privéregister gebruikt, controleer dan of uw Secret bestaat en het geheim is correct. Je geheim moet ook in dezelfde naamruimte zijn. Bedankt Swenzel
- Sommige registers hebben firewalls die IP-adrestoegang beperken. De firewall kan de pull
- Sommige CIS creëren implementaties met tijdelijke docker-geheimen. Dus het geheim vervalt na een paar dagen (u vraagt om productiefoles …)
blokkeren
Antwoord 2
Heb je geprobeerd te bewerken om te zien wat er mis is (ik had de verkeerde beeldlocatie)
kubectl edit pods arix-3-yjq9w
of zelfs uw pod verwijderen?
kubectl delete arix-3-yjq9w
Antwoord 3
Ik keek voor de vergelijkbare situatie en het bleek dat met de actualisering van Docker Desktop ik was ondertekend en nadat ik in alle werken weer goed heb gemaakt.
Antwoord 4
Ik heb dit probleem op GKE gehaald en de reden was geen inloggegevens voor Docker.
Draait deze opgelost het:
gcloud auth configure-docker
Antwoord 5
Op GKE, als de pod dood is, is het het beste om te controleren op de gebeurtenissen.
Het zal in meer detail laten zien waar de fout over gaat.
In mijn geval had ik:
Failed to pull image "gcr.io/project/imagename@sha256:c8e91af54fc17faa1c49e2a05def5cbabf8f0a67fc558eb6cbca138061a8400a":
rpc error: code = Unknown desc = error pulling image configuration: unknown blob
Het bleek dat de afbeelding op de een of andere manier beschadigd was.
Na het opnieuw te hebben gepusht en te implementeren met de nieuwe hash, werkte het weer.
[update] achteraf, ik denk dat de afbeeldingen beschadigd zijn geraakt omdat de bucket in GCP die de afbeeldingen host, een opschoonbeleid had ingesteld, waardoor de afbeeldingen in feite werden verwijderd. Als gevolg hiervan is het bericht zoals hierboven te zien in evenementen.
Andere veelvoorkomende problemen zijn een verkeerde naam (gcr.io vs eu.gcr.io) en het kan ook zijn dat het register op de een of andere manier niet kan worden bereikt. Nogmaals, er zijn hints in de evenementen, het bericht daar zou je genoeg moeten vertellen.
Meer algemene informatie is hier te vinden (zoals voor authenticatie):
https://cloud.google.com/container-registry /docs/duwen-en-trekken
Antwoord 6
Ik ben vergeten de afbeelding met het label 1.0.8 naar de ECR (AWS-afbeeldingshub) te pushen…
Als u Helm gebruikt en upgrade door:
helm upgrade minta-user ./src/services/user/helm-chart
zorg ervoor dat de afbeeldingstag in values.yaml wordt gepusht (naar ECR of Docker Hub, enz.), bijvoorbeeld: (dit is mijn helm-chart/values.yaml)
replicaCount: 1
image:
repository:dkr.ecr.us-east-1.amazonaws.com/minta-user
tag: 1.0.8
u moet ervoor zorgen dat de afbeelding:1.0.8 wordt gepusht!
Antwoord 7
Voer de onderstaande opdracht uit:
eval $(minikube -p minikube docker-env)
Maak nu uw afbeeldingen. Gebruik dan dezelfde afbeeldingen in K8S.
Doe dit elke keer wanneer u een nieuwe CMD opent.
Antwoord 8
1.kubectl get pod -n kube-system
2.laat zien welke ImagePullBackOff kube-system-pods
3.kubectl delete pod <POD NAME> -n kube-system(herstart pod en maak container opnieuw)
4.kubectl get pod -n <NAME SPACE>
geniet ervan.
Antwoord 9
In mijn geval had ik met een Fargate-profiel het netwerk in mijn VPC verkeerd geconfigureerd. De Fargate-containers hebben toegang tot ECR nodig, waarvoor een route naar het openbare internet nodig is. Ik had de NAT-gateways voor mijn privé-subnetten in diezelfde privé-subnetten, terwijl ze zich in openbare subnetten hadden moeten bevinden. Deze foutmelding was in mijn geval het resultaat van die verkeerde configuratie.
Antwoord 10
Ik had hetzelfde probleem, maar in plaats van één waren al mijn pods niet gereed en gaven de status Gereed 0/1 weer
Zoiets als
Ik heb veel geprobeerd, maar uiteindelijk ontdekte ik dat de context niet correct was ingesteld.
Gebruik de volgende opdracht en zorg ervoor dat u zich in de juiste context bevindt
kubectl config get-contexts
Antwoord 11
Voer docker-login uit
Duw de afbeelding naar de docker-hub
Pod opnieuw maken
Dit loste het probleem voor mij op. Ik hoop dat het helpt.