Kubernetes–Troubleshooting ImagePullBackOff errors

After deploying a new pod, I couldn’t access it. Time to take a look what was going on:

C:\Users\BaWu\Desktop>kubectl get pods --all-namespaces

NAMESPACE              NAME                                                              READY   STATUS             RESTARTS   AGE

kube-system            addon-http-application-routing-default-http-backend-7fc6fc27bj2   1/1     Running            0          93m

kube-system            addon-http-application-routing-external-dns-6c6465cf6f-hqn2w      1/1     Running            0          93m

kube-system            addon-http-application-routing-nginx-ingress-controller-668m4rb   1/1     Running            0          93m

kube-system            azure-cni-networkmonitor-cn57j                                    1/1     Running            0          10d

kube-system            azure-ip-masq-agent-4sjmw                                         1/1     Running            0          10d

kube-system            coredns-544d979687-5c7rt                                          1/1     Running            0          10d

kube-system            coredns-544d979687-rbbh9                                          1/1     Running            0          10d

kube-system            coredns-autoscaler-78959b4578-jdr24                               1/1     Running            0          10d

kube-system            dashboard-metrics-scraper-5f44bbb8b5-dfw47                        1/1     Running            0          10d

kube-system            kube-proxy-8d5sr                                                  1/1     Running            0          10d

kube-system            kubernetes-dashboard-785654f667-2gcbn                             1/1     Running            0          10d

kube-system            metrics-server-85c57978c6-bzsc2                                   1/1     Running            0          10d

kube-system            omsagent-rs-5f579fcfd-9pqpf                                       0/1     ImagePullBackOff   0          2d10h

kube-system            omsagent-rs-6b6cdf78fc-26mpb                                      1/1     Running            1531       10d

kube-system            omsagent-wfgtp                                                    0/1     ImagePullBackOff   0          2d10h

kube-system            tunnelfront-f7bd7ccb-t7g95                                        2/2     Running            1          6d20h

kubernetes-dashboard   dashboard-metrics-scraper-c79c65bb7-w9thj                         0/1     ImagePullBackOff   0          27m

kubernetes-dashboard   kubernetes-dashboard-56484d4c5-c4cwv                              0/1     ImagePullBackOff   0          27m

The deployment turned out to be in the imagepullbackoff  state. There can be various reasons on why this is the case. Let’s figure out what could cause this by calling describe. This gave us a lot of extra information:

C:\Users\BaWu\Desktop>kubectl describe pod kubernetes-dashboard-56484d4c5-c4cwv --namespace=kubernetes-dashboard

Name:         kubernetes-dashboard-56484d4c5-c4cwv

Namespace:    kubernetes-dashboard

Priority:     0

Node:         aks-agentpool-27676582-vmss000000/10.9.1.5

Start Time:   Fri, 24 Jul 2020 12:53:52 +0200

Labels:       k8s-app=kubernetes-dashboard

              pod-template-hash=56484d4c5

Annotations:  <none>

Status:       Pending

IP:           10.9.1.21

IPs:

  IP:           10.9.1.21

Controlled By:  ReplicaSet/kubernetes-dashboard-56484d4c5

Containers:

  kubernetes-dashboard:

    Container ID:

    Image:         kubernetesui/dashboard:v2.0.0

    Image ID:

    Port:          8443/TCP

    Host Port:     0/TCP

    Args:

      --auto-generate-certificates

      --namespace=kubernetes-dashboard

    State:          Waiting

      Reason:       ImagePullBackOff

    Ready:          False

    Restart Count:  0

    Liveness:       http-get https://:8443/ delay=30s timeout=30s period=10s #success=1 #failure=3

    Environment:    <none>

    Mounts:

      /certs from kubernetes-dashboard-certs (rw)

      /tmp from tmp-volume (rw)

      /var/run/secrets/kubernetes.io/serviceaccount from kubernetes-dashboard-token-bxq7s (ro)

Conditions:

  Type              Status

  Initialized       True

  Ready             False

  ContainersReady   False

  PodScheduled      True

Volumes:

  kubernetes-dashboard-certs:

    Type:        Secret (a volume populated by a Secret)

    SecretName:  kubernetes-dashboard-certs

    Optional:    false

  tmp-volume:

    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)

    Medium:

    SizeLimit:  <unset>

  kubernetes-dashboard-token-bxq7s:

    Type:        Secret (a volume populated by a Secret)

    SecretName:  kubernetes-dashboard-token-bxq7s

    Optional:    false

QoS Class:       BestEffort

Node-Selectors:  kubernetes.io/os=linux

Tolerations:     node-role.kubernetes.io/master:NoSchedule

                 node.kubernetes.io/not-ready:NoExecute for 300s

                 node.kubernetes.io/unreachable:NoExecute for 300s

Events:

  Type     Reason     Age                  From                                        Message

  ----     ------     ----                 ----                                        -------

  Normal   Scheduled  30m                  default-scheduler                           Successfully assigned kubernetes-dashboard/kubernetes-dashboard-56484d4c5-c4cwv to aks-agentpool-27676582-vmss000000

  Normal   Pulling    28m (x4 over 30m)    kubelet, aks-agentpool-27676582-vmss000000  Pulling image "kubernetesui/dashboard:v2.0.0"

  Warning  Failed     28m (x4 over 30m)    kubelet, aks-agentpool-27676582-vmss000000  Failed to pull image "kubernetesui/dashboard:v2.0.0": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

  Warning  Failed     28m (x4 over 30m)    kubelet, aks-agentpool-27676582-vmss000000  Error: ErrImagePull

  Normal   BackOff    27m (x6 over 30m)    kubelet, aks-agentpool-27676582-vmss000000  Back-off pulling image "kubernetesui/dashboard:v2.0.0"

  Warning  Failed     26s (x117 over 30m)  kubelet, aks-agentpool-27676582-vmss000000  Error: ImagePullBackOff

This indicates that the Kubernetes cluster cannot talk to https://registry-1.docker.io/v2/. This makes sense as I only configured a trust with ACR.

Kubernetes–the server could not find the requested resource

When trying to deploy the Kubernetes dashboard on an AKS cluster it failed with the following error message:

Error from server (NotFound): the server could not find the requested resource

Here was the full command I tried to execute:

C:\Users\BaWu>kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml

Error from server (NotFound): the server could not find the requested resource

The problem was related to the fact that kubectl supports one version (older or newer) of kube-apiserver.

I checked the installed version using:

C:\Users\BaWu>kubectl version

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T21:07:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"windows/amd64"}

Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.10", GitCommit:"89d8075525967c7a619641fabcb267358d28bf08", GitTreeState:"clean", BuildDate:"2020-06-23T02:52:37Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

I had version 1.9 installed where the api was on version 1.16. To solve it I had to download and install a newer version of kubectl. Instructions to do this can be found here: https://kubernetes.io/docs/tasks/tools/install-kubectl/

Using gRPC for your internal microservices

gRPC is a really great fit as a communication protocol between your (internal) microservices. It runs on top of HTTP/2 and gives you great performance.

One caveat is that the HTTP/2 prerequisite requires by default that all communication is happening securely. So you have to setup TLS and create certificates for all your services.

But what should you do when you are using Kubernetes and use TLS termination at the ingress controller level?

A new feature announced in .NET Core 3.0 brings rescue. You can turn on unencrypted connections for HTTP/2 by setting the DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT environment variable to 1 or by enabling it in the app context:

Razor Class Libraries–Static Content 404 issue –Part 2

I’ll continue my journey using Razor Class Libraries in ASP.NET Core.

Here are my previous posts:

• ASP.NET Core – Razor Class Libraries
• Razor Class Libraries -  Views not found
• Razor Class Libraries – Static Content
• Razor Class Libraries – Clean up your Content path
• Razor Class Libraries -  Static Content 404 issue – Part 1

After a first colleague returned to his desk with a solution for the problem I discussed yesterday, a second colleague arrived and explained he had a similar problem.

This time I could pinpoint the issue to the following PackageReference that was (still) used in a referenced project:

<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />

Static files worked differently in .NET Core 2.2 Razor Class Libraries. The inclusion of the Microsoft.AspNetCore.Mvc v2.2.0 library broke the behaviour in ASP.NET Core 3.x applications. This reference is no longer needed as it is now a part of the Microsoft.AspNetCore.App framework reference.

Razor Class Libraries–Static Content 404 issue –Part 1

I’ll continue my journey using Razor Class Libraries in ASP.NET Core.

Here are my previous posts:

• ASP.NET Core – Razor Class Libraries
• Razor Class Libraries -  Views not found
• Razor Class Libraries – Static Content
• Razor Class Libraries – Clean up your Content path

Today I want to share an issue a colleague got when he tried to use a Razor Class Library I created.

When he tried to load a static asset from the RCL, the asset was not found and a 404 error was returned to the browser.

It took me a while to pinpoint the issue but in the end it turned out that the following setting in his ASP.NET Core project caused the problem:

<ANCMPreConfiguredForIIS>true</ANCMPreconfiguredForIIS>

After commenting out this line in the csproj file, the static assets were loaded correctly

I have no clue why this solved the problem as I don’t see any relation between these features…

Razor Class libraries–Clean up your content path

I’ll continue my journey using Razor Class Libraries in ASP.NET Core.

Here are my previous posts:

• ASP.NET Core – Razor Class Libraries
• Razor Class Libraries -  Views not found
• Razor Class Libraries – Static Content

Today I want to write a small addition to my post from yesterday. As I mentioned yesterday to reference some content inside your razor views you need to use a path similar to _content/{LIBRARY NAME}.

This path doesn’t look so nice. Luckily you change it to a different path name by editing the RCL project properties and adding a StaticWebAssetBasePath.

Now you can access your files using /myownpath/example.css.

Razor Class Libraries–Static Content

I’ll continue my journey using Razor Class Libraries in ASP.NET Core.

Here are my previous posts:

• ASP.NET Core – Razor Class Libraries
• Razor Class Libraries -  Views not found

Today I want to cover how you can use static content inside your Razor Class library.

To include static content(images, fonts, stylesheets,…) in your RCL you need to create a wwwroot folder in the class library and include any required files there:

When packing an RCL, all content in the wwwroot folder is automatically included in the package.

As this content becomes part of the DLL you cannot just reference them from the root path(“~”. Instead the path is constructed using ‘_content/{LIBRARY NAME}/’.

For example to reference an example.css file that you stored inside a RCL named ‘Example.RCL’, the correct way to include this css file in your application becomes: