Azure AKS: Kubernetes pod keeps showing CrashLoopBackOff status after assigning static IP

10/4/2020

Hi I am following the following guide on Microsft, https://docs.microsoft.com/en-us/azure/aks/static-ip, to assign a static ip for my AKS Cluster. However, I am faced with Kubernetes pod keeps showing CrashLoopBackOff status after assigning static IP.

This is the static ip I have created: enter image description here

The services are working as intended: enter image description here

Screenshot of the error: enter image description here

This is the stack trace after printing kubectl describe pod

Name:         dashboardbackend-6d9d56bbfb-l5fbx
Namespace:    default
Priority:     0
Node:         aks-agentpool-40731879-vmss000000/10.240.0.4
Start Time:   Mon, 05 Oct 2020 02:16:25 +0800
Labels:       app=dashboardbackend
              pod-template-hash=6d9d56bbfb
Status:       Running
IP:           10.244.0.15
  IP:           10.244.0.15
Controlled By:  ReplicaSet/dashboardbackend-6d9d56bbfb
Containers:
    Container ID:   docker://83bf57b5f899ba57271b3be85054ea8e03b8e92b6d4dd21cb5623568c73ea030
    Image ID:       docker-pullable://julio02.azurecr.io/dashboardbackend@sha256:2ae7ed770fd890c147710e73245ece19958cbc8e0fcd8d5a3be716ef9c2a35de
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 05 Oct 2020 02:17:01 +0800
      Finished:     Mon, 05 Oct 2020 02:17:09 +0800
    Ready:          False
    Restart Count:  2
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-lt49b (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  default-token-lt49b:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-lt49b
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From                                        Message
  ----     ------     ----               ----                                        -------
  Normal   Scheduled  65s                default-scheduler                           Successfully assigned default/dashboardbackend-6d9d56bbfb-l5fbx to aks-agentpool-40731879-vmss000000
  Normal   Pulling    29s (x3 over 64s)  kubelet, aks-agentpool-40731879-vmss000000  Pulling image "julio02.azurecr.io/dashboardbackend:55"
  Normal   Pulled     29s (x3 over 63s)  kubelet, aks-agentpool-40731879-vmss000000  Successfully pulled image "julio02.azurecr.io/dashboardbackend:55"
  Normal   Created    29s (x3 over 60s)  kubelet, aks-agentpool-40731879-vmss000000  Created container dashboardbackend
  Normal   Started    29s (x3 over 59s)  kubelet, aks-agentpool-40731879-vmss000000  Started container dashboardbackend
  Warning  BackOff    5s (x3 over 42s)   kubelet, aks-agentpool-40731879-vmss000000  Back-off restarting failed container
-- Richard Rodjues
azure
azure-aks
kubernetes
kubernetes-pod

1 Answer

10/5/2020

As requested by @Vitalli, I have resolved my problem after running through the Kubernetes logs for the pod that was created. After typing the kubectl logs [podname], I realised that the ip address for the Azure SQL DB was not added into the whitelist for the connectivity settings. After adding it and deleting pod, it will recreate the pod and the application is running as intended.

enter image description here

-- Richard Rodjues
Source: StackOverflow