5.1 step 6 getting "error: unable to upgrade connection: container not found ("simpleapp")"

quachout

Hello,

On 5.1, I'm getting stuck after trying to follow step 6. When I try to run
kubectl exec -c simpleapp -it try1-5db9bc6f85-whxbf \-- /bin/bash -c'echo $ilike'
I get this error error: unable to upgrade connection: container not found ("simpleapp")
When I run kubectl get pods all 6 of my try1 pods have the status of ImagePullBackOff.

How do I resolve this issue? Thanks in advance

chrispokorni

Hi @quachout,

When describing either one of the six try1 pods, what events are displayed at the bottom of the output?

Have the earlier issues from chapters 2 and 3 been fixed? Is the container runtime operational on both nodes? Is the private repository operational? Is access to the private repository properly configured on both nodes? Is the desired "simpleapp" container image in the repository?

Regards,
-Chris

quachout

@chrispokorni This is what is displayed after describing one of the try1 pods:

Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 84s default-scheduler Successfully assigned default/try1-69c9f5ff6b-2fn98 to ip-172-31-5-77 Normal Pulled 83s kubelet Container image "registry.k8s.io/goproxy:0.1" already present on machine Normal Created 83s kubelet Created container goproxy Normal Started 82s kubelet Started container goproxy Normal Pulling 35s (x3 over 83s) kubelet Pulling image "10.97.40.62:5000/simpleapp" Warning Failed 35s (x3 over 83s) kubelet Failed to pull image "10.97.40.62:5000/simpleapp": rpc error: code = NotFound desc = failed to pull and unpack image "10.97.40.62:5000/simpleapp:latest": failed to resolve reference "10.97.40.62:5000/simpleapp:latest": 10.97.40.62:5000/simpleapp:latest: not found Warning Failed 35s (x3 over 83s) kubelet Error: ErrImagePull Normal BackOff 8s (x6 over 82s) kubelet Back-off pulling image "10.97.40.62:5000/simpleapp" Warning Failed 8s (x6 over 82s) kubelet Error: ImagePullBackOff

Yes the earlier issues from ch2 and 3 have been fixed.
When I run sudo systemctl status docker to check if the container runtime is operational I get this error Unit docker.service could not be found.

I wasn't getting this error before when I ran kubectl get pods all of the try1 pods were Running but for some reason starting yesterday, my pods are in the ImagePullBackOff status. Is this a problem with the simpleapp server from the Linux Foundation?

chrispokorni

Hi @quachout,

If all installation and config steps were closely followed, then Docker should not be your runtime. We are using Containerd instead, as mentioned in my earlier responses to you as well.

The Linux Foundation does not run or own a "simpleapp" server.
The "simpleapp" container image is built by the learner/you in Lab 3, stored in a private repository - also built by the learner/you in your own Kubernetes cluster. This "simpleapp" container image will eventually be pulled by your container runtime (Containerd, not Docker) as requested by the Kubernetes framework on behalf of the try1 Deployment.

The failures listed in the Events may be caused either by an empty local repository if the "simpleapp" container image was not successfully pushed in the local repo, or a misconfiguration of the Containerd container runtime to access the local repo.

From both nodes, you can check the repo catalog with:

curl $repo/v2/_catalog

The command should return an empty repository if no images are stored, or "simpleapp" if the image was successfully pushed in the repo.

Regards,
-Chris

quachout

@chrispokorni

When I run curl $repo/v2/_catalog on both nodes I get:

curl: (3) URL using bad/illegal format or missing URL

What should I do to get "simpleapp" to be successfully pushed to the repo again?

quachout

@chrispokorni oh wait I remembered that I wasn't able to use $repo so instead I typed out the entire IP. So instead of using curl $repo/v2/_catalog I'm using curl 10.97.40.62:5000/v2/_catalog and this returned and empty repository {"repositories":[]}

What should I do to get "simpleapp" to be successfully pushed to the repo again?

quachout

@chrispokorni when I tried to follow the steps again in Lab 3. I'm now running into this issue of

The connection to the server 172.31.5.77:6443 was refused - did you specify the right host or port?

when I run kubectl get nodes

chrispokorni

Hi @quachout,

Isn't this the earlier reported issue that was eventually fixed, from another discussion thread?

Regards,
-Chris