Missing /root/.kube/k3s.yaml about k3s HOT 9 CLOSED

@MichaelJCole hmmm. Let me look into this. Does systemd do some automatic blackmagic and make /root a private directory?

from k3s.

@MichaelJCole I haven't looked at this yet but just wanted to call out that you can control where that file is written to with --write-kubeconfig /somewhere/else so putting somewhere besides /root might be a decent workaround.

from k3s.

Hi @ibuildthecloud I don't think systemd does any black magic on it.

The first line had an error: "server https://localhost:6443/cacerts is not trusted:" which may be the root cause. I'm not sure why that is or how to work around it. I used the systemd example in the README on a custom Raspberry Pi image.

The second line looks like a console messaging bug (printing success even on fail), possibly from upstream.

Thanks for looking at it!

Michael

from k3s.

Thanks, knowing it's raspberry pi helps a lot. Things are so much slower that I could be hitting a timeout somewhere. I'll test on rpi. @MichaelJCole Which Raspberry PI are you using? I typically just test on rpi3 b.

from k3s.

from k3s.

alpine Linux have the same issue.

It stuck in printing out server url, never move forward to write the yaml file

./k3s server &
alpine:/home/alpine/k3s/dist/artifacts# INFO[2019-02-07T23:35:50.644628589+01:00] Starting k3s dev                             
INFO[2019-02-07T23:35:50.647992304+01:00] Running kube-apiserver --allow-privileged=true --authorization-mode Node,RBAC --service-account-signing-key-file /var/lib/rancher/k3s/server/tls/service.key --service-cluster-ip-range 10.43.0.0/16 --advertise-port 6445 --advertise-address 127.0.0.1 --insecure-port 0 --secure-port 6444 --bind-address 127.0.0.1 --tls-cert-file /var/lib/rancher/k3s/server/tls/localhost.crt --tls-private-key-file /var/lib/rancher/k3s/server/tls/localhost.key --service-account-key-file /var/lib/rancher/k3s/server/tls/service.key --service-account-issuer k3s --api-audiences unknown --basic-auth-file /var/lib/rancher/k3s/server/cred/passwd --kubelet-client-certificate /var/lib/rancher/k3s/server/tls/token-node.crt --kubelet-client-key /var/lib/rancher/k3s/server/tls/token-node.key 
Flag --insecure-port has been deprecated, This flag will be removed in a future version.
INFO[2019-02-07T23:35:51.974079656+01:00] Running kube-scheduler --kubeconfig /var/lib/rancher/k3s/server/cred/kubeconfig-system.yaml --port 0 --secure-port 0 --leader-elect=false 
INFO[2019-02-07T23:35:51.976840854+01:00] Running kube-controller-manager --kubeconfig /var/lib/rancher/k3s/server/cred/kubeconfig-system.yaml --service-account-private-key-file /var/lib/rancher/k3s/server/tls/service.key --allocate-node-cidrs --cluster-cidr 10.42.0.0/16 --root-ca-file /var/lib/rancher/k3s/server/tls/token-ca.crt --port 0 --secure-port 0 --leader-elect=false 
Flag --port has been deprecated, see --secure-port instead.
INFO[2019-02-07T23:35:52.159121088+01:00] Listening on :6443

from k3s.

@MichaelJCole I haven't yet been able to reproduce this, could you possibly try v0.1.0-rc3 that I just released and see if you still get the same behavior.

@liyimeng I believe the issue you are seeing is different. There was a deadlock issue on startup while generating the TLS certs that would cause the server to hang on startup

from k3s.

@ibuildthecloud I moved on to another project, so I won't have the hardware for it :-( If you're not able to reproduce, then it can probably be closed. It would be cool to have a "known working config" to use k3s with on Pi 3's - or a blog post. I'm really interested in your project!

from k3s.

@MichaelJCole Thanks. We definitely have writes up in the works right. I'll close this issue for now.

from k3s.