Move hyperkube binary and images out from main k/k repository

[dims]

At one point hyperkube was going to take everything over but that day is gone:
#16508

We don't have any owners for hyperkube and we have pending issues like #80374 and #71719

hyperkube is a magnet for pulling all kinds of dependencies (especially cloud providers)

We asked this question once earlier in:
#69896

And it's easy to pull it out of k/k repository - POC is here : https://github.com/dims/hyperkube

floated the idea on mailing lists:

• https://groups.google.com/d/msg/kubernetes-sig-architecture/4uTHr74ucv0/KImea_0RFAAJ
• https://groups.google.com/d/msg/kubernetes-sig-release/p9WHaLjvFhM/lfKoNj5IDwAJ

found some folks who may want / be able to help: @feiskyer @adelina-t @PatrickLang @markyjackson-taulia

/area code-organization

[dims]

We will need the generated openapi check in if we want k/k to be vendorable, see #81239

[neolit123]

/sig architecture

[adelina-t]

@dims Yeah, Hyperkube is of interest to our Windows testing effort, as we depend on it to deploy our test clusters with aks-engine. I can help with moving it and making the transition smooth.

[PatrickLang]

cc @ritazh @jackfrancis

I filed Azure/aks-engine#1842 to track removing this dependency in AKS-Engine

[feiskyer]

@dims any updates on this?

[adelina-t]

I started some work on pulling it from the main k/k repo, I'm still slowly working on build scripts. Will update when I have a PR in a week or two ( depending on the volume of my other commitments ).

[dims]

thanks @adelina-t

[dims]

As mentioned earlier, i have https://github.com/dims/hyperkube and looks like @adelina-t will be surfacing another repository as well. We can pick either one ( preferably @adelina-t 's) and request a new repository under kubernetes-sigs.

We will need folks who want to own this code and take it forward. So if you are interested, please chime in on this issue.

cc @dghubble @PatrickLang @MikeSpreitzer @neolit123 @vllry @deads2k @justaugustus

[justaugustus]

@dims -- SIG Release is on the hook to own and I'll steward.

From the contributors you mentioned, I'll find some key approvers.

[neolit123]

i think we should create the k/k-sig hosted hyperkube repo and start moving bits to there.

[adelina-t]

You can have a look here at the initial move: https://github.com/adelina-t/hyperkube

Hyperkube can be built, images can be built here.
Next steps: create dependancy pinning / vendor update scripts.

[dims]

@justaugustus @adelina-t thanks! https://github.com/adelina-t/hyperkube is a great way to get us started.

[dghubble]

@dims Kubernetes core still plans to package other container images like kube-apiserver, kube-scheduler, kube-controller-manager? The desire is specific to moving the hyperkube image management, not container images distributables right?

[dims]

@dghubble correct

[justaugustus]

/assign

[dims]

@uablrek when we have a new github repository where you can do the same thing.

@justaugustus do we want to do that this week?

[justaugustus]

@dims -- Yep, it's top of mind to get the ball rolling on the migration this week!

[ereslibre]

/cc

[justaugustus]

Migration issue opened in k/org: kubernetes/org#1365

[liggitt]

If we want to provide the same functionality as hyperkube via another project, I think it would make more sense to do so with a shim executable that delegates to actual binaries, and to build an image that actually contained the official binaries. That could be done with a single go file, a Dockerfile, and a build script, with no go dependency on k8s.io/kubernetes.

[liggitt]

That lets the hyperkube image just be a packaging mechanism, and the hyperkube binary avoid dependency entanglement.

[dghubble]

In the immediate term, I noticed v1.17 beta images for hyperkube were never published. I was hoping to do my usual testing now that beta's are out, especially if its moving. Seems like its no longer in the release flow, but also doesn't have the new home?

[dims]

@dghubble we are re-working the hyperkube image like @liggitt mentioned, please follow along in #84662

[dims]

/close

TL;DR we are not moving the binary/image from k/k, we have an alternative container image based on a script now.

[k8s-ci-robot]

@dims: Closing this issue.

In response to this:

/close

TL;DR we are not moving the binary/image from k/k, we have an alternative container image based on a script now.

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.