k3s: CrashLoopBackOff / Error
Hello World!
I just installed k3s (Single Master Install), yet seeing Error and/or CrashLoopBackOff for few deployments (that came out of the box)
# k3s kubectl get pods --all-namespaces=true
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-57d8bbb86-jzhmv 1/1 Running 0 29m
kube-system local-path-provisioner-58fb86bdfd-bwhsj 0/1 CrashLoopBackOff 10 29m
kube-system helm-install-traefik-nmvrz 0/1 CrashLoopBackOff 10 29m
#
# k3s -v
k3s version v0.10.2 (8833bfd9)
#
# cat /etc/redhat-release
CentOS Linux release 8.0.1905 (Core)
# uname -a
Linux X.X.X 4.18.0-80.11.2.el8_0.x86_64 rancher/k3s#1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
#
Please advise.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 10
- Comments: 30 (9 by maintainers)
I finally got K3S working on Centos 7 and docker, it wasn’t working even after replace
firewalldbyiptables.Facts:
local-path-provisionerandmetrics-serverneeds to connect tok3son internal host.So I just added following rule to iptables in order to fix it:
Where
10.42.0.0/16is the defaultk3snetwork CIDR, change it if you defined a different value on--cluster-cidrflag.The step by step solution:
Replace firewalld by iptables
Configure iptables rules, my setup is based on this article: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-basic-iptables-firewall-on-centos-6
Here is where the magic happens, enable connections from k3s pods to your host internal ip:
Save changes and restart iptables
Install and run k3s
I’m seeing the same issue, with centos8 and k3s v1.0. Seems like the only way to get it working is to disable/stop firewalld (
systemctl stop firewalld) but that’s not really a solution.For what it’s worth I wrote a ufw application profile for this - I didn’t feel like turning the firewall off was a solution. Turned out my pods needed to have 6443 (TCP) and 8472 (UDP) as well as access to the host 443 (TCP).
To use this make sure you’ve got your CIDR identified and then run the following (after creating the file above):
This will allow access within the cluster. Seems to have fixed my problems, well at least some of them… 😉
On Ubuntu 20.04.2 LTS confirmed:
ErrorandCrashLoopBackOffk3s -vk3s version v1.21.2+k3s1 (5a67e8dc) go version go1.16.4Solution
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 && sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1 && sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1sudo ufw disablesudo rebootSorry? This doesn’t seem like a problem that k3s can easily fix. The root of the problem is with iptables and how they decided to implement the upgrade. If Kubernetes/containerization has issues with nftables support you would think that RHEL would provide legacy support, maybe should file an issue there? Any container which uses legacy iptables will cause problems if the host has switched to nftables.
this doesn’t seem to be working on Ubuntu 22.04. Any ideas on how to proceed?
@agilob and @criscola both of you appear to be on Raspberry Pi, whereas this issue appears to be reported against CentOS on amd64. I suggest one or both of you create new issues to track your problem; pods crash-looping is a generic symptom of many potential problems and we can’t troubleshoot them all in the same place.
I’m having the same problem with a raspberry pi 4, I tried a couple of times with a fresh install but I’m still getting the error each time:
OS is Raspberry Pi OS 64bit
PS If I execute the kill-all script and reboot the server with
k3s server startit starts working again, but this is inconvenient.I am seeing this error on a k3s install onto a RPi cluster using Rasbian:
The logs of the process:
kubectl logs local-path-provisioner-58b55cb6b6-fhn4k -n local-path-storage -f time=“2020-03-03T09:33:20Z” level=debug msg=“Applied config: {"nodePathMap":[{"node":"DEFAULT_PATH_FOR_NON_LISTED_NODES","paths":["/opt/local-path-provisioner"]}]}” time=“2020-03-03T09:33:20Z” level=debug msg=“Provisioner started” I0303 09:33:20.827795 1 leaderelection.go:242] attempting to acquire leader lease local-path-storage/rancher.io-local-path… I0303 09:33:47.163803 1 leaderelection.go:252] successfully acquired lease local-path-storage/rancher.io-local-path I0303 09:33:47.164705 1 controller.go:773] Starting provisioner controller rancher.io/local-path_local-path-provisioner-58b55cb6b6-fhn4k_7a01cc7c-f9b5-4015-b401-efeb8a1e86a7! I0303 09:33:47.166570 1 event.go:281] Event(v1.ObjectReference{Kind:“Endpoints”, Namespace:“local-path-storage”, Name:“rancher.io-local-path”, UID:“02dc6406-3334-4c75-a9c2-c388373e6403”, APIVersion:“v1”, ResourceVersion:“46969”, FieldPath:“”}): type: ‘Normal’ reason: ‘LeaderElection’ local-path-provisioner-58b55cb6b6-fhn4k_7a01cc7c-f9b5-4015-b401-efeb8a1e86a7 became leader I0303 09:33:47.265028 1 controller.go:822] Started provisioner controller rancher.io/local-path_local-path-provisioner-58b55cb6b6-fhn4k_7a01cc7c-f9b5-4015-b401-efeb8a1e86a7! I0303 09:39:12.199569 1 leaderelection.go:288] failed to renew lease local-path-storage/rancher.io-local-path: failed to tryAcquireOrRenew context deadline exceeded F0303 09:39:12.199642 1 controller.go:851] leaderelection lost