4

Following Les Jackson's tutorial on microservices, on local installation of Docker with Kubernetes enabled, I wanted to create a new pod in Kubernetes that would contain an image of ms sql server express, available here. The deployment file is exactly the same as in the video, but I can't get it to work. Each time the pod ends with status ImagePullBack. After running kubectl describe pod:

Name: mssql-depl-5cd6d7d486-nrrkn Namespace: default Priority: 0 Node: docker-desktop/192.168.65.4 Start Time: Thu, 28 Jul 2022 12:09:34 +0200 Labels: app=mssql pod-template-hash=5cd6d7d486 Annotations: <none> Status: Pending IP: 10.1.0.27 IPs: IP: 10.1.0.27 Controlled By: ReplicaSet/mssql-depl-5cd6d7d486 Containers: mssql: Container ID: Image: mcr.microsoft.com/mssql/server:2017-latest Image ID: Port: 1433/TCP Host Port: 0/TCP State: Waiting Reason: ImagePullBackOff Ready: False Restart Count: 0 Environment: MSSQL_PID: Express ACCEPT_EULA: Y SA_PASSWORD: <set to the key 'SA_PASSWORD' in secret 'mssql'> Optional: false Mounts: /var/opt/mssql/data from mssqldb (rw) /var/run/secrets/kubernetes.io/serviceaccount from kube- api-access-xqzks (ro) Conditions: Type Status Initialized True Ready False ContainersReady False PodScheduled True Volumes: mssqldb: Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace) ClaimName: mssql-claim ReadOnly: false kube-api-access-xqzks: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: <nil> DownwardAPI: true QoS Class: BestEffort Node-Selectors: <none> Tolerations: node.kubernetes.io/not- ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 3m42s default-scheduler Successfully assigned default/mssql-depl-5cd6d7d486-nrrkn to docker-desktop Warning Failed 102s kubelet Failed to pull image "mcr.microsoft.com/mssql/server:2017-latest": rpc error: code = Unknown desc = context deadline exceeded Warning Failed 102s kubelet Error: ErrImagePull Normal BackOff 102s kubelet Back-off pulling image "mcr.microsoft.com/mssql/server:2017-latest" Warning Failed 102s kubelet Error: ImagePullBackOff Normal Pulling 87s (x2 over 3m41s) kubelet Pulling image "mcr.microsoft.com/mssql/server:2017-latest" 

I discovered the underlying error

"rpc error: code = Unknown desc = context deadline exceeded"

And I'm not sure how to proceed further to fix this issue, I would really appreciate any help.

I posted this originally on stackoverflow here and was redirected with my issue to this site as it's potentially a networking problem.

2
  • From that node (docker-desktop / 192.168.65.4), have you tried to pull this image? Assuming container runtime is docker: docker pull mcr.microsoft.com/mssql/server:2017-latest. Check systemd logs (all units), that "context deadline exceeded" suggests kubelet could not get an answer from docker in a timely manner: your host could be overloaded, some service could be crashed, ... Can you check back on that pod events: currently we only have one context deadline exceeded, second attempt to pull started: later on, do we still see that same timeout, or do you have anything else? Commented Jul 31, 2022 at 11:27
  • The command docker pull mcr.microsoft.com/mssql/server:2017-latest worked just fine from powershell on my computer right now. I deleted the deployment afterwards and applied it again and I think it might have fixed the issue as the pod now has a running status. I don't have access to the events from the last pod anymore, but from previous attempts I remember that it continued to timeout until the limit of 5mins was reached. Thank you for your help! Commented Jul 31, 2022 at 12:18

2 Answers 2

3

I fixed it by running docker pull mcr.microsoft.com/mssql/server:2017-latest, deleting and re-applying the deployment.

1
  • 1
    That's a workaround I'm using too, it. Problem actually is docker (as the container runtime): github.com/kubernetes/minikube/issues/… - there are internal timeouts and depending on your internet line's speed and image size, you may never successfully pull the image through K8s before the context exceeds. A manual pull doesn't have these restrictions, actually you don't even have to delete the deployment, after pulling the image into local cache, the pod should come up after next try to pull the image (this time from local store in seconds). Commented Oct 25, 2022 at 11:40
3

Same problem, but I needed to pull the image to minikube first minikube ssh docker pull <the_image>

Then the deployment works

1

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.