canonical / microk8s

MicroK8s is a small, fast, single-package Kubernetes for datacenters and the edge.
https://microk8s.io
Apache License 2.0
8.43k stars 770 forks source link

[1.27-strict] microk8s snap doesn't cleanup network calico net interfaces, and leaks them too #4126

Closed tonyespy closed 2 months ago

tonyespy commented 1 year ago

Summary

According to this microk8s doc page, microk8s uses:

Starting from version 1.19, MicroK8s clusters use the Calico CNI by default, configured with the vxlan backend.

That said, I think this is only used as the default on a machine that for which you've run add-node (and possible join-node too). I may have done this recently while testing at a sprint.

The problem is that once this has been done once, the vxlan.calico network interface and associated caliXXXX ethernet interfaces are not deleted if the microk8s snap is removed. If you re-install the snap, a new pair of caliXXXX eth interface get created (I now have 21 on my system). The number increases by two every time you remove and then re-install the snap.

Snap version: v1.27.3 5590 (arm64)

What Should Happen Instead?

When the microk8s snap is removed, it should clean up any network interfaces that it created.

Reproduction Steps

I've been able to reproduce this consistently on one machine running 22.04 LTS Desktop, but haven't reproduced it on another machine yet (see above comment about add-node command). I will try again when I have more bandwidth, and will update the issue with my findings.

  1. Run microk8s add-node (again I think this is what got me here)
  2. Run ipaddr or nmcli d and notice the vxlan.calico and caliXXXX interface(s)
  3. sudo snap remove microk8s --purge
  4. Check the network interfaces using the above command, notice that they're still there.
  5. Re-install the microk8s snap (1.27-strict)
  6. Re-check the network interfaces and see that there are now two more caliXXX interfaces

Introspection Report

inspection-report-20230803_181941.tar.gz

Can you suggest a fix?

Are you interested in contributing with a fix?

sachinkumarsingh092 commented 1 year ago

Hey @tonyespy, I see a lot of these messages when trying to see the system logs of services in the the report:

Journal file /var/log/journal/0794bfcccf8b402c87b2482afaa26392/system@ec1d3e5a7e354886b837239a7cb8b8ac-00000000003cee93-0006020bd9f098f0.journal uses an unsupported feature, ignoring file.
Use SYSTEMD_LOG_LEVEL=debug journalctl --file=/var/log/journal/0794bfcccf8b402c87b2482afaa26392/system@ec1d3e5a7e354886b837239a7cb8b8ac-00000000003cee93-0006020bd9f098f0.journal to see the details.

looks like some sort of unsupported journalctl feature issue. Can you run these commands to get more info on these services? For example in the above case, use:

SYSTEMD_LOG_LEVEL=debug journalctl --file=/var/log/journal/0794bfcccf8b402c87b2482afaa26392/system@ec1d3e5a7e354886b837239a7cb8b8ac-00000000003cee93-0006020bd9f098f0
stale[bot] commented 3 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.