ARM support

[jalberto]

Would be great to have a tag for ARM so raspberryPI adn scaleway C1 can be used as kong hosts

[joeblew99]

This is also important for me.

The raspberry pi 3 does not support 64 bit yet. The team have not released the 64 bit kernel yet, and it sounds like they won't for a while.
Ubuntu core guys can't because element 14 have the strings on this I suspect.

But there are better boards with property arm64 and eMMC storage. The odroid for example.

So a docker for rasp pi 3 32 bit is welcome.
But also one for 64bit too

[joeblew99]

Is scale way c1 arm 32 bit kernel ?

[shawnguo2]

@thefosk Is there any update for arm64 architecture support?

I tried to build the image on arm64, and it succeeded. But it runs into a failure like below.

Can't exec "/usr/local/openresty/bin/../nginx/sbin/nginx": Exec format error at /usr/local/openresty/bin/resty line 541.
Failed to run command "/usr/local/openresty/bin/../nginx/sbin/nginx -p /tmp/2J6UtJWhSu/ -c conf/nginx.conf": Exec format error

This is because the kong package downloaded from https://bintray.com/kong/ has the binary /usr/local/openresty/nginx/sbin/nginx in x86_64 format. It looks like we need to have an architecture specific kong package in order to support arm64 architecture?

I really want to get arm64 supported by this docker image. Can you please suggest what I can do to help move this forward? Thanks!

[tianon]

Given that Kong is based on OpenResty, openresty/luajit2#24 might be relevant here (and the other things it links to) -- OpenResty currently has issues with LuaJIT on arm64.

[fulvi0]

Hi,

How is going with this? it's in the roadmap? Kong ARM support, for Raspberry Pi.

Will be cool play with Kong on Pi Cluster

[hutchic]

Some lua modules we're using don't have arm64 support. We're working on a patch Kong/openresty-patches#47 to allow them to run successfully.

FWIW you can use https://github.com/svenwal/kong-arm to run Kong compiled for arm32 on Pi

[vcunat]

Unless you use the Pi with a 48-bit VA kernel (or larger), lua stuff shouldn't have problems with this in 64-bit mode. On embedded HW it fortunately seems normal to have smaller VA by default.

[hutchic]

resolved by #297

[mrsimpson]

@hutchic I was eager to try out Kong as API-gateway on my PI 4 running K8S, but was unsuccessful spinning up a pod of arm64v8/kong:ubuntu.
Output on stdout:

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

This indicates the platform does not match.

I am not 100% sure this is the place to ask, since my setup is K8S (K3S distribution) and deployment via Helm, so feel free to redirect!

I deployed with

helm install kong --namespace=kong --skip-crds --set ingressController.installCRDs=false --set image.repository=arm64v8/kong --set image.tag=ubuntu kong/kong

The pod triggered seems to hold the proper image (from kubectl describe):

proxy:
    Container ID:   containerd://211e508357f16194b8a6c003579c26ace13c87408a91396b479a5f52f91d3a19
    Image:          arm64v8/kong:ubuntu
    Image ID:       docker.io/arm64v8/kong@sha256:39e4b224efc8b79152c7f2cdc7fd9f89e86dbb514b8257cf2e246bcc41f78a8a

Thanks for your support and the great work on Kong!
Oliver

[hbagdi]

@mrsimpson Can you try withe Ingress Controller disabled to narrow down this issue? There is no arm64 Docker image for the Ingress Controller and the above error might be coming from the controller instead of Kong.

[mrsimpson]

@hbagdi no, disabling the ingress controller doesn't fix it:

helm install kong --namespace=kong --skip-crds --set ingressController.enabled=false --set ingressController.installCRDs=false --set image.repository=arm64v8/kong --set image.tag=ubuntu kong/kong

Same result.

The pod in question is the "proxy", see the yaml in the details

Name:         kong-kong-86fc59cd7-mskqk
Namespace:    kong
Priority:     0
Node:         raspberrypi/192.168.13.33
Start Time:   Wed, 19 Feb 2020 19:10:12 +0100
Labels:       app.kubernetes.io/component=app
              app.kubernetes.io/instance=kong
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=kong
              app.kubernetes.io/version=1.4
              helm.sh/chart=kong-1.2.0
              pod-template-hash=86fc59cd7
Annotations:  checksum/dbless.config: 4adea139e49ff8a8b2a65e52b8c67bcb47b1e8521a09d2092007e1986898549c
Status:       Running
IP:           10.42.0.34
IPs:
  IP:           10.42.0.34
Controlled By:  ReplicaSet/kong-kong-86fc59cd7
Containers:
  proxy:
    Container ID:   containerd://e55f9fadb8cdebe3e18c66feda3b9ab9e72b6260d7cf08421714e559b300721f
    Image:          arm64v8/kong:ubuntu
    Image ID:       docker.io/arm64v8/kong@sha256:39e4b224efc8b79152c7f2cdc7fd9f89e86dbb514b8257cf2e246bcc41f78a8a
    Ports:          8444/TCP, 8000/TCP, 8443/TCP, 9542/TCP
    Host Ports:     0/TCP, 0/TCP, 0/TCP, 0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Wed, 19 Feb 2020 19:13:14 +0100
      Finished:     Wed, 19 Feb 2020 19:13:14 +0100
    Ready:          False
    Restart Count:  5
    Liveness:       http-get http://:metrics/status delay=5s timeout=5s period=10s #success=1 #failure=3
    Readiness:      http-get http://:metrics/status delay=5s timeout=5s period=10s #success=1 #failure=3
    Environment:
      KONG_ADMIN_ACCESS_LOG:        /dev/stdout
      KONG_ADMIN_ERROR_LOG:         /dev/stderr
      KONG_ADMIN_GUI_ACCESS_LOG:    /dev/stdout
      KONG_ADMIN_GUI_ERROR_LOG:     /dev/stderr
      KONG_ADMIN_LISTEN:            0.0.0.0:8444 ssl
      KONG_DATABASE:                off
      KONG_DECLARATIVE_CONFIG:      /kong_dbless/kong.yml
      KONG_LUA_PACKAGE_PATH:        /opt/?.lua;;
      KONG_NGINX_HTTP_INCLUDE:      /kong/servers.conf
      KONG_NGINX_WORKER_PROCESSES:  1
      KONG_PLUGINS:                 bundled
      KONG_PORTAL_API_ACCESS_LOG:   /dev/stdout
      KONG_PORTAL_API_ERROR_LOG:    /dev/stderr
      KONG_PREFIX:                  /kong_prefix/
      KONG_PROXY_ACCESS_LOG:        /dev/stdout
      KONG_PROXY_ERROR_LOG:         /dev/stderr
      KONG_PROXY_LISTEN:            0.0.0.0:8000,0.0.0.0:8443 ssl
      KONG_NGINX_DAEMON:            off
    Mounts:
      /kong from custom-nginx-template-volume (rw)
      /kong_dbless/ from kong-custom-dbless-config-volume (rw)
      /kong_prefix/ from kong-kong-prefix-dir (rw)
      /tmp from kong-kong-tmp (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-gv8hs (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kong-kong-prefix-dir:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  
  kong-kong-tmp:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  
  custom-nginx-template-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      kong-kong-default-custom-server-blocks
    Optional:  false
  kong-custom-dbless-config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      kong-kong-custom-dbless-config
    Optional:  false
  default-token-gv8hs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-gv8hs
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                    From                  Message
  ----     ------     ----                   ----                  -------
  Normal   Scheduled                default-scheduler     Successfully assigned kong/kong-kong-86fc59cd7-mskqk to raspberrypi
  Warning  BackOff    107s (x10 over 3m10s)  kubelet, raspberrypi  Back-off restarting failed container
  Normal   Pulled     95s (x5 over 3m13s)    kubelet, raspberrypi  Container image "arm64v8/kong:ubuntu" already present on machine
  Normal   Created    94s (x5 over 3m12s)    kubelet, raspberrypi  Created container proxy
  Normal   Started    94s (x5 over 3m12s)    kubelet, raspberrypi  Started container proxy

But if there's no ingress controller for arm64, does it make sense after all to venture any further?

[hbagdi]

arm64 image for ingress controller can be built pretty easily. There is an open issue for it but we haven't worked on it yet.

[mrsimpson]

@hbagdi Since the ingress seems not to be the issue: Any ideas about what's causing deployment to fail?

[hbagdi]

No. can you open a new Github issue in this or the main Kong repository?