Skip to content
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

Clarify use of private registries #533

Closed
evilnick opened this issue Feb 3, 2021 · 0 comments · Fixed by #534
Closed

Clarify use of private registries #533

evilnick opened this issue Feb 3, 2021 · 0 comments · Fixed by #534
Assignees

Comments

@evilnick
Copy link
Collaborator

evilnick commented Feb 3, 2021

The note about images in particular:

davecore
4:17 PM
What does the mention mean https://ubuntu.com/kubernetes/docs/docker-registry :

Note:Currently, when using a custom private registry, Charmed Kubernetes requires ALL the required images to be served from that registry. The list of images used by Charmed Kubernetes itself can be found in the bundle repository .
	
evilnick
4:28 PM
it means that if you specify a private registry, you need to put all the required images in it

4:30 PM
you can find a versioned list of the images required in the docs, e.g. https://ubuntu.com/kubernetes/docs/1.20/components#images

Ubuntu
Components of Charmed Kubernetes 1.20 | Ubuntu
Detailed description of Charmed Kubernetes release
	
davecore
4:30 PM
@evilnick Just to be sure, at what point (which juju relation) does that happen?  I'm 95% done with a k8s deployment and need to add in a private registry, and just saw this now.  

	
evilnick
4:31 PM
hmm. I'm not certain. I bet @kwmonroe will know though

	
kwmonroe
4:47 PM
@davecore for CK, k8s-master learns of the registry via config and will use that to set the location for images that come from the cdk-addons snap.

k8s-master then sends this registry info to k8s-workers.

k8s-worker then gets this for use by things like the kubelet pod infra image and default backend image.

this covers setting any registry as an appropriate prefix for all images needed by k8s-master/worker charms.

if you are deploying the docker-registry charm to act as your private registry, you'll then relate that to your container runtime.  this tells the runtime about things like auth and tls so it can pull from your d-r unit.

4:51 PM
if you are not using d-r as the registry, you'll need to configure containerd to specify things like auth since we won't be getting that from a relation

	
cynerva
4:51 PM
basically the note about the registry needing all images is only relevant if you go as far as juju config kubernetes-master image-registry=$REGISTRY in the doc, right?

	
kwmonroe
4:53 PM
right, if you don't configure image-registry, the charms will pull from rocks.

4:55 PM
so you could have a private registry for workload images and configure/relate to containerd.  this would let you pull workload images from your registry while the rest of k8s images come from rocks.

	
davecore
5:37 PM
thanks @kwmonroe this is very useful.  Just one question: If I configure/relate docker to my private registry, will it try to hijack the location of all my workload images? or it will just let me use the private registry if I want to and specify it in a workload?

	
kwmonroe
6:26 PM
@davecore i'm pretty sure the related registry is simply added as a dockerd option that says "this registry is here too".  i don't think it will hijack other image locations or prevent images coming from other registries.

@joeborg may be able to weigh in as he wired up the registry relation when docker became a subordinate charm.  Joe, do you recall if a related registry means that the docker sub can only talk to that registry, or is it simply informing docker that another registry is usable?

	
joeborg
6:41 PM
i don't know for certain, but i'm pretty sure it's just the first place it looks, followed by docker hub (if on docker)

	
evilnick
6:53 PM
I feel like i didn't just randomly add that note, but possibly I misunderstood the implementation. If it works as an optional alternative, we should change the note

	
joeborg
6:55 PM
i'll check

	
evilnick
6:56 PM
thanks!

	
davecore
7:04 PM
@evilnick   FYI, this is my simple recap if it helps with the note on the webpage: 

We can use the private Docker registry as either the source of all images in Charmed Kubernetes by configuring the kubernetes-master charm option image-registry, or we can just use it as an extra source by juju relating docker-registry to the container runtime (ie. docker at TCS). This relation tells the runtime about things like auth and tls so it can pull from my docker-registry unit.

	
joeborg
7:36 PM
I've done this with containerd and I can attach a private reg, before the cluster comes up and everything still settles fine

	
evilnick
7:38 PM
ok cool, i will adjust that page accordingly. thanks for checking

	
joeborg
7:38 PM
i'll check with docker too, just in case it behaves differently

	
davecore
7:42 PM
@joeborg to be clear, in my case I don't want to use the docker registry for the entire cluster. I just want the registry there for customers to have a place to put their workloads images in

	
joeborg
7:43 PM
yep, i just want to check containerd and docker charms behave the same way

	
kwmonroe
7:56 PM
I feel like i didn't just randomly add that note

@evilnick you didn't.  but i think this doc initially focused on air-gapped or net-restricted deployments where registries need to be all-or-nothing.

i like @davecore's use-case and think a little blurb to set the stage for both would be great.  i look forward to seeing what you come up with :wink:

	
joeborg
7:57 PM
the docker deployment seems to fail though (pre-pulling images).  I'll log it in LP in case it's not just me

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

Successfully merging a pull request may close this issue.

1 participant