-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Can't start k3s from private registry #2093
Comments
|
@brandond, Thank you for your quick response!
All the other logged messages in this log file seemed to be only 'info' level logs messages |
The issue template is the bit of content that you see when you click 'New issue' and select 'Bug report' instead of clicking the option to create a new blank issue. You can find it here: For the configs section, can you try specifying a URI that matches the endpoint, vs just the hostname? See: https://github.com/containerd/cri/blob/master/docs/registry.md#configure-registry-credentials . that would look something like this: mirrors:
docker.io:
endpoint:
- "https://registry.sys"
configs:
"https://registry.sys":
auth:
username: username
password: password
tls:
cert_file: /path/certs/ca.cert # path to the cert file used in the registry
key_file: /path/certs/ca.key # path to the key file used in the registry
ca_file: /apth/certs/ca.crt # path to the ca file used in the registry The private registry docs could use some work - both on our side and in containerd. I'm hoping to get to that shortly. Related docs tracking issue: #1802 |
Your issue also sounds similar to this, although it sounds like you are not using multiarch. I wonder if you may need to take some extra steps to get all the right layers tagged and pushed: #1285 |
Environmental Info: k3s version v1.18.4+k3s1 (97b7a0e) Node(s) CPU architecture, OS, and Version: Linux hostname.sys 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Cluster Configuration: Single node configuration Describe the bug: K3s does not start when using a secured, private registry
Expected behavior:
Actual behavior:
This behavior prevents me from using any of the k3s features Additional context / logs: |
It is possible this is a certificates issue. I am not very familiar with how to use certs properly, I have just followed a couple of online tutorials to get to where I am. |
You only need a cert_file and key_file if you want to use a client certificate to authenticate to the registry. You should NOT be providing the registry's HTTPS cert and key as cert_file and key_file. If you're using a self-signed cert on the registry's https endpoint, then you can provide that cert as the ca_file in order to avoid certificate validation failures. For an internal registry, you can also use http instead of https and skip messing about with certs at all. |
It is an internal registry, however, as of now it is a req that it is secured. Maybe I'll be able to persuade otherwise. Do you know why this would be? I ran a sanity check with curl: |
Are you using the same ca.cert file in the curl command as you are specifying as ca_file in your registries.yaml? Is the cert on the registry self-signed, or signed by another private CA? Do you see any different behavior if you specify configs:
"https://registry.sys": vs configs:
"registry.sys": |
Yes, the ca.cert file is the same between the registries.yaml and the curl command. Also I should mention that the |
Yes, that would be the sandbox image. It should use the same settings as all the other image pulls, but I'm not sure why it's not liking the certificate. upstream containerd has had some issues in this space for a while, so you may be running in to that. Just for testing purposes, you may see if you can get it working via http instead of https, then try to turn on https. |
@brandond thanks for your help and suggestions! I went ahead and tried to install just using http but it didn't work and I actually ended up with a error I had seen before where the sandbox image doesn't start properly. |
It looks like there are some multiarch problems with the upstream images. This is causing issues both for arm users, as well as folks trying to push the airgap images to a private registry. Keep an eye on #1285 for updates. |
Same issue with airgap installation kubectl get pods -A -o wide
kubectl -n kube-system describe pod svclb-traefik-nv5cr
|
@rerime what architecture are you using? I believe there are issues with one of the upstream arm64 images that we're hoping to resolve by the 1.19 release. |
@brandond AMD64. Ok, thx! |
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions. |
I am trying to start a single-node k3s server on centos7 in an air-gapped environment. I can start it using the manual deployed method where you put the tar ball of docker images in /var/lib/rancher/k3s/agent/images.
But I want to put the images on my secured, private docker registry and deploy that way.
I created the registries.yaml file that goes in /etc/rancher/k3s/ and included the FQDN of my registry and the path to the appropriate certificates. SELinux is disabled, and I have tried it in permissive.
When I run the install script like this:
INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh
It runs successfully but if I check the status of the pods they are in the "CrashLoopBackOff" state.
From there I run :
k3s kubectl describe pods --all-namepsaces
To see what is the problem with the pods and this is the output I see:
Anyone have any clue as to why the sandbox container is not starting and what I need to so to fix this?
The text was updated successfully, but these errors were encountered: