Publish the ecr-credential-provider as a container image about cloud-provider-aws

[cartermckinnon]

So the way this works today:

1. We increment the version.txt file on a given branch to get a new tag created.
2. Container images and artifacts are built async.
3. We open k8s.io PR's to promote the images/artifacts from the staging env to the prod env.

I think we're missing a final step to create a GitHub release with references to the images/artifacts. We need some type of tool/automation for that. That may already exist, or we may just be "doing it wrong" with the new registry/artifacts.k8s.io setup. I'll start a thread in the release-eng channel, I think they would know...

[k8s-ci-robot]

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]

I don't think a container image is the optimal way to distribute this tool. This binary is available on artifacts.k8s.io, we just need to automate/generate the release notes here to point to it, document it, etc.:

https://artifacts.k8s.io/binaries/cloud-provider-aws/v1.29.0/linux/amd64/ecr-credential-provider-linux-amd64

[kon-angelo]

This binary is available on artifacts.k8s.io

Thank you! I was not aware.

I don't think a container image is the optimal way to distribute this tool.

The container approach does have some advantages. A proper multi-arch build image basically abstracts the issue of picking the correct version and it also streamlines the consumption e.g. some binaries may be compressed or not. In an environment like a k8s node where you are guaranteed to have a container runtime, the CR can offload part of the process. It's a convenience so to say.

[cartermckinnon]

I do like the multi-arch magic, but having to pull the binary out of the container image is pretty awkward IMO. I can imagine some scenarios when you might want to grab the latest ecr-credential-provider at runtime on each node, but baking it in during the node image build process has it's benefits (the node image can be tested as a package deal, you know you're using a consistent version of the binary across all your nodes, etc.).

If you want to add the ecr-credential-provider to the CCM container image, I'm not opposed; but I think the preferred source should be artifacts.k8s.io (and if you're up for making that easier to discover, it'd be appreciated!)

[kon-angelo]

@cartermckinnon I very much liked your idea and created a pull request that adds the ecr binary to the cloud-provider image.

With regards to the discovery/visibility, can you please outline some more concrete ideas (here, or you can reach in slack) and let me see what I can contribute.

[k8s-triage-robot]

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]

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