Microk8s not running correctly

[lbarboi]

Summary

Microk8s seems to not install correctly
When I run "microk8s inspect" it complains about
Inspecting dqlite
Inspect dqlite
cp: cannot stat '/var/snap/microk8s/7394/var/kubernetes/backend/localnode.yaml': No such file or directory

What Should Happen Instead?

I am guessing the file should exist as it messes up the kubernetes network stack

Reproduction Steps

Issue happens on all out Azure vm's where we install microk8s with : snap install microk8s --classic
2. ...

Introspection Report

Inspecting system
Inspecting Certificates
Inspecting services
Service snap.microk8s.daemon-cluster-agent is running
Service snap.microk8s.daemon-containerd is running
Service snap.microk8s.daemon-kubelite is running
Service snap.microk8s.daemon-k8s-dqlite is running
Service snap.microk8s.daemon-apiserver-kicker is running
Copy service arguments to the final report tarball
Inspecting AppArmor configuration
Gathering system information
Copy processes list to the final report tarball
Copy disk usage information to the final report tarball
Copy memory usage information to the final report tarball
Copy server uptime to the final report tarball
Copy openSSL information to the final report tarball
Copy snap list to the final report tarball
Copy VM name (or none) to the final report tarball
Copy current linux distribution to the final report tarball
Copy asnycio usage and limits to the final report tarball
Copy inotify max_user_instances and max_user_watches to the final report tarball
Copy network configuration to the final report tarball
Inspecting kubernetes cluster
Inspect kubernetes cluster
Inspecting dqlite
Inspect dqlite
cp: cannot stat '/var/snap/microk8s/7394/var/kubernetes/backend/localnode.yaml': No such file or directory

Can you suggest a fix?

We manually do the following:

1. stop microk8s
2. create the file
3. chmod/chown the file correctly
4. start microk8s

Are you interested in contributing with a fix?

[ktsakalozos]

Hi @lbarboi, could you please attach the inspection report so as to see what really failed?

[khrystoph]

I'm actually running into the same issue where it's complaining about the file being missing (and indeed, it's nowhere to be found): localnode.yaml is not in the location described.

inspection-report-20250206_051226.tar.gz

This is happening on Ubuntu 24.04 LTS server ARM64 on a raspberry pi CM4 (so, bare metal and not azure).

You can see in the stat file that's included in the report that there's no localnode.yaml in /var/snap/microk8s/current/var/kubernetes/backend/ where it's looking for that file to be present. Not sure whether or not that's actually causing an issue or not though.

Is there anywhere in particular that's useful to look as to why it failed to start up?

Edit: I found a workaround. I removed and re-installed the snap and microk8s starts up again, but my cluster is lost. I should be able to recover at this point.

[Dibz15]

Hi there. I just came across this issue after finding the same error on my system in a new installation. Completely different setup, as we are using RHEL 9 on an x86-64 platform. Seeing the same cp: cannot stat '/var/snap/microk8s/7665/var/kubernetes/backend/localnode.yaml': No such file or directory. Is this something that can be ignored? I've removed and reinstalled via snap but it is still happening.

As the first comment mentioned, I can get the error to go away by manually adding the missing file. However, I don't know if this will bite me later.

[khrystoph]

I bailed on microk8s and moved to k3s because I couldn't easily get around the issue. K3s is much easier to clean up (such as with k3s-ansible where there's a "reset.yaml" file, that will uninstall everything k3s to allow being removed.

I don't know enough about the file to know for sure what was wrong because it was missing on all the nodes for me.

[eaudetcobello]

Hi @Dibz15, @khrystoph, @lbarboi,

localnode.yaml is a file that was used in an older version of dqlite (the data store microk8s uses instead of etcd). It's completely safe to ignore this error. We simply forgot to remove the cp of this file from the inspection script.