0

I have a simple docker image which is working fine locally. It is basically the same as the example on apache's httpd page.

FROM httpd:2.4
COPY ./public-html/ /usr/local/apache2/htdocs/

As per the page example, I can build and run my image as follows:

$ docker build -t gcr.io/${PROJECT_ID}/hello-app:v1 .

$ docker run -dit --name my-running-app -p 8080:80 <img_id>

I then head over to http://localhost:8080 , and everything seems to be working as it should.

However, when I try to create a deployment for my Google Cloud Kubernetes instance, my pod fails and gets to the state of CrashLoopBackOff. (This is after I have pushed the image to Google Cloud Registry, so that the deployment may grab the image from there.)

I think that this CrashLoopBackOff problem is happening due to me not having an ENTRYPOINT to my container; ie, the pod spawns, no command is issued, and then it is completed and crashes.

I have 2 questions then:

  1. What command should I add to my Dockerfile to get the http server up and running on the pod (assuming my assessment of the problem is indeed correct)?
  2. How is this running locally? Locally I simply $ docker run -dit --name my-running-app -p 8080:80 <img_id>. I do not specify that the container should run httpd, yet it does? How is this happening?

Edit - additional information:

I deployed onto K8's by doing the following:

$ kubectl create deployment hello-app --image=gcr.io/${PROJECT_ID}/hello-app:v1

Kubectl logs:

$ kubectl logs <pod_name>

standard_init_linux.go:211: exec user process caused "exec format error"

kubectl describe:

$ kubectl describe pod hello-app-6b89cd98f6-gn65p

Name:         <name>
Namespace:    default
Priority:     0
Node:         <my_node>
Start Time:   Mon, 22 Mar 2021 12:32:51 +0200
Labels:       app=hello-app
              pod-template-hash=6b89cd98f6
Annotations:  <none>
Status:       Running
IP:           10.12.1.13
IPs:
  IP:           10.12.1.13
Controlled By:  <replica_set>
Containers:
  hello-app:
    Container ID:   <cid>
    Image:          <img>
    Image ID:       <img_id>
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 22 Mar 2021 15:12:18 +0200
      Finished:     Mon, 22 Mar 2021 15:12:18 +0200
    Ready:          False
    Restart Count:  36
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-b8p9t (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  default-token-b8p9t:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-b8p9t
    Optional:    false
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
  ----     ------   ----                   ----     -------
  Warning  BackOff  4m9s (x741 over 164m)  kubelet  Back-off restarting failed container
orrymr
  • 2,264
  • 4
  • 21
  • 29
  • could you post additional info like the logs getting it from `kubectl logs`, output of `kubectl describe` command and the deployment `yaml` file? – Krishna Chaurasia Mar 22 '21 at 12:58
  • 1
    CMD ["httpd-foreground"] is defined in your docker base image FROM httpd:2.4 so that is not the issue. As requested by above comment, please provide more information – Sagar Velankar Mar 22 '21 at 13:11
  • @KrishnaChaurasia please see the above edits. – orrymr Mar 22 '21 at 13:20
  • your added command to create the deployment `kubectl create deployment hello-app --image=gcr.io/${PROJECT_ID}/hello-app:v1` has different image than the one build for `httpd`: `docker build -t my-apache2 .`, so can you clarify if the image is correct or could `hello-app:v1` be some other image which do not have a long running process and leading to exit of the container? – Krishna Chaurasia Mar 22 '21 at 13:25
  • @KrishnaChaurasia -sorry, i made a mistake. gcr.io/${PROJECT_ID}/hello-app:v1 is the correct image. See the above edited question. – orrymr Mar 22 '21 at 13:37
  • 1
    I am beginning to think this is an architecture problem (https://stackoverflow.com/questions/58298774/standard-init-linux-go211-exec-user-process-caused-exec-format-error) the image I built has "Architecture": "arm64", whereas I think my cluster is amd64. – orrymr Mar 22 '21 at 13:41
  • 1
    ok, the first search for the error in the logs point to the [thread](https://stackoverflow.com/questions/58298774/standard-init-linux-go211-exec-user-process-caused-exec-format-error) implying the default command being run is not an executable but as Sagar mentioned, it would be `httpd-foreground` and should work correctly. Unfortunately, I don't have anything further to help you based on the error message. – Krishna Chaurasia Mar 22 '21 at 13:41
  • 1
    ahh, that could certainly be a problem as the executable formats could be different for different platforms and I suggest you give a try with the right image. – Krishna Chaurasia Mar 22 '21 at 13:42
  • Is the Machine where you are building the docker image arm64 ? – Sagar Velankar Mar 23 '21 at 05:00
  • Use FROM --platform flag to specify linux/amd64 as the target architecture. Check URL https://docs.docker.com/engine/reference/builder/#from. Or else you can use docker buildx https://docs.docker.com/docker-for-mac/multi-arch/ to build and push multi architecture images and kubelet will pull the image with correct architecture – Sagar Velankar Mar 23 '21 at 05:14
  • Yes. I was building from arm64 machine. It looks like using the buildx command was the way to go. Thank you for all the advice :) – orrymr Mar 23 '21 at 10:11

1 Answers1

1

CrashLoopBackOff error means the pod keeps crashing and kubernetes has given up on it. You have to determine what is causing the crash. Overally the cause of problem may be that:

You can type watch kubectl describe <pod-name> to check events as the pod is being created. But if the pod crashes after it starts up, you need to get the container logs kubectl logs -f <your-pod-name>.

Read more: kubernetes-crashloopbackoff.

As @Krishna Chaurasia said check the thread which is implying that the default command being run is not an executable - executable formats could be different for different platforms. As @Sagar Velankar mentioned use in Docker file in FROM line --platform flag to specify linux/amd64 as the target architecture. See: dockerfile-from.

You can use docker buildx docs.docker.com/docker-for-mac/multi-arch to build and push multi architecture images and kubelet will pull the image with correct architecture.

Malgorzata
  • 6,409
  • 1
  • 10
  • 27