Introduction

When remote kubectl access to a MicroK8s cluster fails with “You must be logged in to the server (Unauthorized)”, the issue is usually in the kubeconfig, not in kubectl itself. The most common causes are a localhost API server address, stale credentials, or a context mix-up after merging several cluster configs.

Export a Fresh Config from the MicroK8s Node

Start on the machine that runs MicroK8s and export the current kubeconfig.

microk8s config > /tmp/microk8s.yaml

Open the file and inspect the clusters, contexts, and users sections. The important detail is the server value. A freshly exported MicroK8s config often points at 127.0.0.1, which works locally on the node but not from another machine.

Update it to the real node IP or DNS name:

clusters:
- cluster:
    server: https://10.0.0.25:16443

Without that change, the remote client may talk to the wrong endpoint or fail before authentication even becomes meaningful.

Test with an Explicit Kubeconfig File

Before merging anything into ~/.kube/config, test the exported file directly.

kubectl --kubeconfig ~/microk8s.yaml cluster-info
kubectl --kubeconfig ~/microk8s.yaml get nodes
kubectl --kubeconfig ~/microk8s.yaml auth can-i get pods -A

This isolates the problem. If these commands work, the cluster credentials are valid and the problem is likely in your normal kubeconfig setup rather than in MicroK8s itself.

It is also worth checking which context the file actually activates:

kubectl --kubeconfig ~/microk8s.yaml config get-contexts
kubectl --kubeconfig ~/microk8s.yaml config current-context

Verify the API Server Is Reachable

MicroK8s uses port 16443 for the Kubernetes API by default. The remote machine must be able to reach that port on the node.

nc -vz 10.0.0.25 16443
curl -k https://10.0.0.25:16443/version

These checks help separate network reachability problems from authentication problems. If the port is blocked by a firewall, security rule, or VPN policy, you can waste time debugging credentials that were never used.

Refresh the File After Cluster Changes

If remote access used to work and suddenly stopped, export the config again. MicroK8s can regenerate certificates during upgrades, resets, or cluster rebuilds. An old kubeconfig may still point at the right server but contain client credentials that no longer match the cluster.

That often looks like an authorization error even though the real issue is stale identity material.

Watch for Context Collisions

On workstations that talk to several clusters, unauthorized errors are often caused by the wrong context being active rather than by bad credentials. Testing with --kubeconfig avoids that confusion and is usually faster than untangling a merged config too early.

Merge Only After the Standalone File Works

Once the explicit file succeeds, then merge it into your default kubeconfig if you want a smoother workflow.

KUBECONFIG=~/.kube/config:~/microk8s.yaml kubectl config view --flatten > /tmp/merged.yaml
mv /tmp/merged.yaml ~/.kube/config

Doing this too early makes debugging harder because kubectl may silently choose the wrong context or cluster entry.

Common Pitfalls

• Copying the exported config but leaving the API server set to localhost.
• Testing against the default kubeconfig instead of the fresh MicroK8s file.
• Forgetting that certificates may have rotated after an upgrade or rebuild.
• Debugging authorization first when the real problem is network reachability to port 16443.

Summary

• Export a fresh config from the MicroK8s node with microk8s config.
• Replace the localhost server address with the real node IP or DNS name.
• Test with kubectl --kubeconfig before merging the file into your default config.
• Confirm the remote machine can reach port 16443.
• If the setup worked before, refresh the kubeconfig after upgrades, resets, or certificate changes.