kubernetes/cloud-provider-aws

AWS CCM DockerFile build for more than one platform

mixeract opened this issue · 11 comments

mixeract commented

What would you like to be added:
The current Dockerfile for Cloud Provider AWS is primarily configured for the amd64 architecture. As the usage of different architectures (like ARM) is becoming more prevalent, especially in cloud-native environments, it would be beneficial for this project to support multi-platform Docker builds.

DockerFile reference https://github.com/kubernetes/cloud-provider-aws/blob/master/Dockerfile#L32

Why is this needed:
Supports users on different architectures, particularly important for ARM-based systems like AWS Graviton instance types.

/kind feature

k8s-ci-robot commented

This issue is currently awaiting triage.

If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

cartermckinnon commented

The Dockerfile is already set up to target whatever --platform you pass to buildx; I don't know why the platform of the golang image for the builder stage is hard-coded here. Removing it seems to work fine. @hakman did this have something to do with reproduceable builds?

hakman commented

@cartermckinnon I think so, probably can be removed now.
ko builds could also be used. Probably we should drop the Dockerfile in the future.

  • 👍1
cartermckinnon commented

thanks! If you want to put up a PR to remove this line @mixeract, feel free 👍

k8s-triage-robot commented

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle stale
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue as fresh with /remove-lifecycle rotten
  • Close this issue with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

olemarkus commented

As mentioned in the PR, arm64 is already supported and published together with the amd64 images.

et304383 commented

As mentioned in the PR, arm64 is already supported and published together with the amd64 images.

My mistake. So is this issue already resolved? Should it be closed?

k8s-triage-robot commented

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Reopen this issue with /reopen
  • Mark this issue as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

k8s-ci-robot commented

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Reopen this issue with /reopen
  • Mark this issue as fresh with /remove-lifecycle rotten
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.