[BUG] Kanister controller images built on Mac M1s do not work.

[mellon-collie]

Describe the bug
Based on the documentation steps available in the Build.md file to build a custom Kanister image, an image built on Mac M1 machine (ARM architecture) fails to run the Kubernetes Operator Container successfully. On investigating the container logs, the following error is shown:

standard_init_linux.go:228: exec user process caused: no such file or directory

To Reproduce
Steps to reproduce the behavior:
On a Mac M1 machine, and in the root directory of the Kanister Repository, run the following commands:

1. make check
2. make build-controller
3. make release-controller
   IMAGE=<your_registry>/<your_controller_image>
   VERSION=<your_image_tag>
4. helm install kanister ./helm/kanister-operator
   --create-namespace
   --namespace kanister
   --set image.repository=<your_registry>/<your_controller_image>
   --set image.tag=<your_image_tag>
5. kubectl get pods -n kanister

Expected behavior
The Kanister operator container should start running successfully when its brought up using helm install

Screenshots

Container description with event logs:

Name:             <container_name>
Namespace:        kanister
Priority:         0
Service Account:  <service_account_name>
Node:             <node_name>
Start Time:       Mon, 05 Jun 2023 16:30:30 -0400
Labels:           app=kanister-operator
                  chart=kanister-operator-0.2.3
                  heritage=Helm
                  pod-template-hash=597cd8c788
                  release=kanister
Annotations:      <none>
Status:           Running
IP:               10.244.0.27
IPs:
  IP:           10.244.0.27
Controlled By:  ReplicaSet/kanister-kanister-operator-<container_id>
Containers:
  kanister-kanister-operator:
    Container ID:   containerd://<container_id>
    Image:          <image_id>
    Image ID:       <docker_image_id>
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 05 Jun 2023 16:32:03 -0400
      Finished:     Mon, 05 Jun 2023 16:32:03 -0400
    Ready:          False
    Restart Count:  4
    Environment:
      CREATEORUPDATE_CRDS:         true
      LOG_LEVEL:                   info
      DATA_STORE_PARALLEL_UPLOAD:  8
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-rhj48 (ro)
      /var/run/webhook/serving-cert from webhook-certs (rw)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  webhook-certs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  <kanister secret>
    Optional:    false
  kube-api-access-rhj48:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           <config_map_name>
    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  2m39s                default-scheduler  Successfully assigned kanister/kanister-kanister-operator-<id> to <node_name>
  Normal   Pulling    2m38s                kubelet            Pulling image "<container_image>"
  Normal   Pulled     2m30s                kubelet            Successfully pulled image "<container_image>" in 8.159172895s
  Normal   Created    66s (x5 over 2m30s)  kubelet            Created container kanister-kanister-operator
  Normal   Started    66s (x5 over 2m29s)  kubelet            Started container kanister-kanister-operator
  Normal   Pulled     66s (x4 over 2m29s)  kubelet            Container image "<container_image>" already present on machine
  Warning  BackOff    66s (x9 over 2m28s)  kubelet            Back-off restarting failed container

Environment
Kubernetes Version/Provider: ...

Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.9", GitCommit:"a1a87a0a2bcd605820920c6b0e618a8ab7d117d4", GitTreeState:"clean", BuildDate:"2023-04-12T12:16:51Z", GoVersion:"go1.19.8", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.13", GitCommit:"49433308be5b958856b6949df02b716e0a7cf0a3", GitTreeState:"clean", BuildDate:"2023-04-12T12:08:36Z", GoVersion:"go1.19.8", Compiler:"gc", Platform:"linux/amd64"}

Storage Provider: ... N/A
Cluster Size (#nodes): ... N/A
Data Size: ... N/A

Additional context
When Kanister's production version, for instance, version 0.92.0 is installed out of the box, the Kanister operator container runs successfully. Hence the problem could point to an issue where the Kanister operator images are not being built correctly on Mac M1 machines.

[github-actions]

Thanks for opening this issue 👍. The team will review it shortly.

If this is a bug report, make sure to include clear instructions how on to reproduce the problem with minimal reproducible examples, where possible. If this is a security report, please review our security policy as outlined in SECURITY.md.

If you haven't already, please take a moment to review our project's Code of Conduct document.

[github-actions]

This issue is marked as stale due to inactivity. Add a new comment to reactivate it.