Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XKCD addon is missing arm64 #665

Closed
kingdonb opened this issue May 5, 2023 · 4 comments · Fixed by #693
Closed

XKCD addon is missing arm64 #665

kingdonb opened this issue May 5, 2023 · 4 comments · Fixed by #693
Assignees
Labels
bug Something isn't working

Comments

@kingdonb
Copy link

kingdonb commented May 5, 2023

Report

The http-add-on has arm64 support, but the example arschles/xkcd does not publish a multi-arch image.

Expected Behavior

The example should run with amd64 or arm64 workers

Actual Behavior

So, in a multi-arch cluster, if your pod lands on an arm64 node when it scales up you'll sit waiting for a while and then see:

error on backend (context marked done while waiting for deployment xkcd to reach > 0 replicas (context deadline exceeded))

The pod, having landed on an arm64 node (on the cluster I've prepared for OSSNA/GitOpsCon!) has the predictable error:

$ k logs -f xkcd-bb4b89d74-qhrnr
exec /usr/local/bin/docker-entrypoint.sh: exec format error

Steps to Reproduce the Problem

I spun up an eks cluster with eksctl create cluster --config=file=cluster.config and the repro is in kingdon-ci/fleet-infra with the cluster name multiarch-ossna23.

If you omit the amd64 node group then it would fail every time. I included my cluster definition below. (For me it only fails a random percent of the time, because only 50% of nodes are arm64, it depends if xkcd gets scheduled to an arm64 node or not.)

Logs from KEDA HTTP operator

Not relevant, but here are the chart versions anyway:

http-addon           	keda-test                  	1       	2023-05-04 19:51:41.98488364 +0000 UTC 	deployed	keda-add-ons-http-0.4.1      	0.4.0
ingress-public       	ingress-nginx              	2       	2023-05-04 19:47:20.179020377 +0000 UTC	deployed	ingress-nginx-4.6.0          	1.7.0
keda                 	keda-test                  	1       	2023-05-04 19:50:57.338495283 +0000 UTC	deployed	keda-2.10.2                  	2.10.1

What version of the KEDA HTTP Add-on are you running?

chart 0.4.1

Kubernetes Version

1.25

Platform

Amazon Web Services

Anything else?

The content of the cluster is here:

$ cat ~/w/eks-cluster/cluster.config
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: multiarch-ossna23
  region: ca-central-1

managedNodeGroups:
  - name: ng-3
    instanceType: m5.large
    desiredCapacity: 1
    iam:
      withAddonPolicies:
        autoScaler: true
    # tags:
    #   k8s.io/cluster-autoscaler/enabled: true
    #   k8s.io/cluster-autoscaler/multiarch-ossna23: owned
  - name: ng-4
    instanceType: m6g.large
    desiredCapacity: 1
    iam:
      withAddonPolicies:
        autoScaler: true
    # tags:
    #   k8s.io/cluster-autoscaler/enabled: true
    #   k8s.io/cluster-autoscaler/multiarch-ossna23: owned

# nodeGroups:
#   - name: ng-1
#     instanceType: m5.large
#     desiredCapacity: 1
#     iam:
#       withAddonPolicies:
#         autoScaler: true
#   - name: ng-2
#     instanceType: m6g.large
#     desiredCapacity: 1
#     iam:
#       withAddonPolicies:
#         autoScaler: true

gitops:
  flux:
    gitProvider: github             # required. options are github or gitlab
    flags:                          # required. arbitrary map[string]string for all flux args.
    # these args are not controlled by eksctl. see https://fluxcd.io/docs/get-started/ for all available flags
      owner: "kingdon-ci"
      repository: "fleet-infra"
      private: "false"
      branch: "main"
      namespace: "flux-system"
      path: "clusters/multiarch-ossna"
      # team: "team1,team2"
@kingdonb kingdonb added the bug Something isn't working label May 5, 2023
@kingdonb
Copy link
Author

kingdonb commented May 5, 2023

I pushed a new image at kingdonb/xkcd:latest from https://github.com/kingdonb/xkcd with:

docker buildx build --platform linux/amd64,linux/arm64 -t kingdonb/xkcd:latest . --push

It seems to be working!

The easy thing to do would be to s/arschles/kingdonb/ in the values.yaml

(Or, @arschles you can push over a new image, I think I have managed a clone of your repo, it didn't seem to be pushed anywhere public except for inside of the docker image itself?) I was able to extract it, and my arm64 nodes are now singing:

Hello from XKCD-serv! 👋

@kingdonb
Copy link
Author

kingdonb commented May 5, 2023

There's now a callout that leads to this issue Bonus: KEDA in a doc that will get embedded in several talks at OSS Summit

(Hope to see some KEDA authors there!)

@JorTurFer
Copy link
Member

Hi,
You are right, as KEDA supports ARM64 we should use an image with ARM64 support. We are also getting the control (or at least trying to do it) over all the resources used for e2e/tests/demos/etc, so I'll an image with AMD64/ARM64 support to this repo.

(Hope to see some KEDA authors there!)

Do you mean in Bilbao on September? If yes, I live 50 km around Bilbao, and we are planing to organize something during the event as CNCF Bilbao chapter :)

@kingdonb
Copy link
Author

kingdonb commented Jun 2, 2023

I would like to go to Bilbao! But I meant OSS Summit that was just two weeks ago in Vancouver. Thanks for knocking this out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants