Closed rmelilloii closed 3 weeks ago
Hi! In the first case I think the problem is that you have enabled the embedded registry mirror with v1.26.7+k3s1, which seems unsupported - see https://docs.k3s.io/installation/registry-mirror.
In 2.0.1 I will add a constraint/check to catch this kind of condition and abort telling the user why.
With the newer version of k3s, 1.30, did you try re-running the create command? If you do kubectl get nodes
does worker 1 appear or not?
I'll do a quick test with your config now.
Hi, I found the problem. It's due to the firewall restriction. I'm about to implement a fix now.
Fantastic! Thank you very much for that. Will it be under the same 2.0.0? I’ll do further tests as I do a bunch of other extra confit to my nodes and also enable k3s audit.
Cheers!
Romulo
On Mon, 19 Aug 2024 at 12:23, Vito Botta @.***> wrote:
Hi, I found the problem. It's due to the firewall restriction. I'm about to implement a fix now.
— Reply to this email directly, view it on GitHub https://github.com/vitobotta/hetzner-k3s/issues/413#issuecomment-2296338119, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3HX5BNSFZHKN5WC75WZG3ZSHISDAVCNFSM6AAAAABMXMSQOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGMZTQMJRHE . You are receiving this because you authored the thread.Message ID: @.***>
I am releasing 2.0.1 with the fix as it's easier with a new version. Description of the problem:
In previous versions of the tool, a load balancer was created for the Kubernetes API when the cluster was HA (with multiple masters). Due to popular demand, I have removed this requirement so in v2, instead of creating the load balancer, a multi-context kubeconfig is generated to connect directly to any master without load balancer. This saves money on the load balancer and is more secure since access to the nodes can be restricted by IP address while this cannot be done with the load balancers.
The problem you encountered, and which I just fixed, is that the nodes were still using the public IP of the master(s) to set up k3s as agent, because that was the behavior with the load balancer. Now that the nodes are connecting directly to the master, they need to use the private IP if the private network is in use, since traffic in the private network is unrestricted and therefore even if you restrict access to the API from the Internet to specific addresses, this won't affect worker nodes.
v2.0.1 is now building - https://github.com/vitobotta/hetzner-k3s/actions/runs/10452534522
You can already test with the binary when it's available for your OS. I will update the brew formula for mac soon.
The new release is now ready. Please upgrade and try again. Thanks :)
Brilliant, working perfectly now. I will proceed with all my extras and report back.
Again, thank you and everyone involved in this project.
Romulo
On Mon, 19 Aug 2024 at 12:50, Vito Botta @.***> wrote:
The new release is now ready. Please upgrade and try again. Thanks :)
— Reply to this email directly, view it on GitHub https://github.com/vitobotta/hetzner-k3s/issues/413#issuecomment-2296386310, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3HX5H5UIV2SL2DZTAF473ZSHLY3AVCNFSM6AAAAABMXMSQOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGM4DMMZRGA . You are receiving this because you authored the thread.Message ID: @.***>
Nice! Can we close this now? You can open separate issues if you run into other problems :)
Please close yes.
Cheers.
Romulo
On Mon, 19 Aug 2024 at 13:07, Vito Botta @.***> wrote:
Nice! Can we close this now? You can open separate issues if you run into other problems :)
— Reply to this email directly, view it on GitHub https://github.com/vitobotta/hetzner-k3s/issues/413#issuecomment-2296416443, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3HX5EXEX7K6SA5Q5FLCBLZSHNW7AVCNFSM6AAAAABMXMSQOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGQYTMNBUGM . You are receiving this because you authored the thread.Message ID: @.***>
Thanks
Hello, good morning and happy Monday!
My deployment is failing without a clear reason.
My deploy.yaml
Log:
The error occurs at around 3 min from start. And The maximum time I waited was 15 min. The log didn't change. The VMs and network are deployed but Kubernetes is not deployed on any node.
Trying to deploy the cluster using the latest k3s "v1.30.3k3s1", changes the outcome a little bit. Kubernetes is now deployed on the master1 node. Log:
Should I try to enforce versions for the hetzner manifests?