Re: [code-organization] Extracting hyperkube

[Lubomir I. Ivanov]

AFAIK, SAP have claimed to use hyperkube in production.
should / can we mark the image as deprecated in 1.16 and possibly
remove in 1.17?

lubomir
--

On Sat, 10 Aug 2019 at 01:22, Davanum Srinivas <dav...@gmail.com> wrote:
>
> Team,
>
> Do we know who is using hyperkube? We had an old issue where we were trying to transition everything to hyperkube[1], but i guess it feel out of favor and most folks just use the binaries. Right?
>
> Can we get rid of hyperkube binary and image from release artifacts?
>
> Why am i asking this? when revisiting all the cloud provider dependencies that we drag in, it turns out we don't really need to ship cloud-controller-manager as we will have external providers that have their own controller manager. To remove cloud-controller-manager, we first have to remove it from hyperkube (deprecation in [2]). Then the question was, do we really need hyperkube?
>
> Given that it's easy to just create a separate repo for hyperkube (prototype [3]). Do we have a set of folks who can sign up for this work? (Also there's k3s already! for the same use case).
>
> Note that the only hiccup in this prototype was that we don't check in generated code for openapi which i have a fix we can debate on in [4].
>
> WDYT? Can we give hyperkube images and binary the boot?
>
> Thanks,
> Dims
>
> [1] https://github.com/kubernetes/kubernetes/issues/16508
> [2] https://github.com/kubernetes/kubernetes/pull/81219
> [3] https://github.com/dims/hyperkube
> [4] https://github.com/kubernetes/kubernetes/pull/81239
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> --
> You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CANw6fcE%3DCyzCTRqA6LY6u-Ypoj%3DQLOho3_Kbc6n-7Nks7iwFPA%40mail.gmail.com.

[Jason D Detiberus]

I believe the Talos project (https://github.com/talos-systems/talos) uses Hyperkube as well. 

You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAGDbWi_SqGqWk_GtusJbW6xn8sUbUaUXah%2BNg%2BEOXNC9AXdHtw%40mail.gmail.com.

[Vallery Lancey]

Maybe mark as depreciated with tentative/gentle timeline, and try to gauge usage. I’m not sure what the cleanup benefit vs user cost is.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAGDbWi_SqGqWk_GtusJbW6xn8sUbUaUXah%2BNg%2BEOXNC9AXdHtw%40mail.gmail.com.

[Davanum Srinivas]

Vallery, Jason,

Please note that interested parties can maintain it in another repo. See prototype:

> [3] https://github.com/dims/hyperkube

-- Dims

[Andrew Rynhard]

As Jason pointed out, Talos does indeed use hyperkube. That being said I have been looking for a good reason to get away from it. The main reason we do this is because we use musl instead of glibc and IIRC kubelet is linked against glibc.

> You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/CAGDbWi_SqGqWk_GtusJbW6xn8sUbUaUXah%2BNg%2BEOXNC9AXdHtw%40mail.gmail.com.

[Davanum Srinivas]

Andrew,

Ack. If we move just hyperkube support to another repo, you can have custom Makefile/scripts for the musl use case as well :)

[Andrew Rynhard]

Sounds good to me.

[Stephen Augustus]

(looks like the threads forked off, so adding SIG Release back)

I'm in favor of moving hyperkube out of tree.

-- Stephen

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CANw6fcE1hsOgkRtNeFws3s65ZTRvFZonLRkTmfdd4c59hnVdRA%40mail.gmail.com.

[David Eads]

I like the idea of moving away from hyperkube.  I'm less sure that an out of tree hyperkube is practical long term if the mono-repo is someday divided.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAFQm5ySX1pDOni2usf8Y--Po2o94VvK-5R9PaCGptAozc0FLwA%40mail.gmail.com.