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

kubelet-wrapper: quay.io/coreos/hyperkube is deprecated #2470

Open
lucab opened this Issue Jul 2, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@lucab
Member

lucab commented Jul 2, 2018

The current (from 2018-04-27) status of quay.io/coreos/hyperkube as reported in upstream announcement is:

[we] don't plan on releasing images for the 1.11 series. If you currently depend on 
our quay images, the k8s.gcr.io ones are a drop in replacement.

However, the GCR image is unfortunately not a drop-in replacement. The kubelet-wrapper consumes the ACI image out of quay.io. Such transport format is not supported by gcr.io.
This means that just changing the ${KUBELET_IMAGE_URL} to GCR will fail when trying to discover the ACI endpoint (run: discovery failed).

For this to work, it will additionally require an explicit docker:// schema and --insecure-options=image.
However I'm not exactly sure if this can be done in a compatible way without breaking existing users that customized the image/tag it via a drop-in (IIRC tectonic does this).

/cc @coverprice

@lucab

This comment has been minimized.

Show comment
Hide comment
@lucab

lucab Jul 4, 2018

Member

I'm still not optimistic that we can accommodate all usecases in retro-compatible way, at least not without making the script a shell-soup.

After quick brainstorming, some alternative options that have been suggested:

  • investigate quay.io support for auto-mirroring and syncing images from GCR
  • put the kubelet-wrapper in maintenance mode, track down and change all documentation around it, announce to the user-list that support stops at 1.10.x and newer versions of kubernetes requires a different service config (as mentioned above)
Member

lucab commented Jul 4, 2018

I'm still not optimistic that we can accommodate all usecases in retro-compatible way, at least not without making the script a shell-soup.

After quick brainstorming, some alternative options that have been suggested:

  • investigate quay.io support for auto-mirroring and syncing images from GCR
  • put the kubelet-wrapper in maintenance mode, track down and change all documentation around it, announce to the user-list that support stops at 1.10.x and newer versions of kubernetes requires a different service config (as mentioned above)
@nstielau

This comment has been minimized.

Show comment
Hide comment
@nstielau

nstielau Jul 10, 2018

Member

Automirroring in coming in Quay next quarter, which is probably too late. Perhaps we could make an internal scheduled job to manually mirror from GCR until then? A bit of shell-soup, but should definitely work, and we could remove after Quay adds the functionality.

Member

nstielau commented Jul 10, 2018

Automirroring in coming in Quay next quarter, which is probably too late. Perhaps we could make an internal scheduled job to manually mirror from GCR until then? A bit of shell-soup, but should definitely work, and we could remove after Quay adds the functionality.

@primeroz

This comment has been minimized.

Show comment
Hide comment
@primeroz

primeroz Jul 23, 2018

It was very easy for me to move from quay.io to the docker gcr.io , i am using a systemd drop in /etc/systemd/system/kubelet.service as documented here

I am using CoreOS 1745.7.0

There are the 3 changes i applied to convert

[Service]
Environment=RKT_GLOBAL_ARGS="--insecure-options=image"
Environment=KUBELET_IMAGE_URL=docker://gcr.io/google-containers/hyperkube-amd64
Environment=KUBELET_IMAGE_TAG=v1.9.8

primeroz commented Jul 23, 2018

It was very easy for me to move from quay.io to the docker gcr.io , i am using a systemd drop in /etc/systemd/system/kubelet.service as documented here

I am using CoreOS 1745.7.0

There are the 3 changes i applied to convert

[Service]
Environment=RKT_GLOBAL_ARGS="--insecure-options=image"
Environment=KUBELET_IMAGE_URL=docker://gcr.io/google-containers/hyperkube-amd64
Environment=KUBELET_IMAGE_TAG=v1.9.8
@rushins

This comment has been minimized.

Show comment
Hide comment
@rushins

rushins Aug 1, 2018

i hit the same issue on 1.96 and hyperkube rkt is exiting everytime...any idea what to do.

rushins commented Aug 1, 2018

i hit the same issue on 1.96 and hyperkube rkt is exiting everytime...any idea what to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment