How to change the default port of microk8s?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
MicroK8s exposes several ports, and the one people usually mean by “the default port” is the Kubernetes API server on 16443. You can change that port by editing the API server arguments and restarting MicroK8s, but you should do it only if you really mean the control-plane API port. If your actual goal is to expose an application on another port, you probably want a Service, NodePort, LoadBalancer, or ingress rule instead.
Know Which Port You Are Changing
MicroK8s has multiple network-facing components. The commonly discussed one is the secure Kubernetes API server port. Changing it affects:
- local
kubectlaccess - CI or automation that talks to the cluster
- firewall rules
- any kubeconfig files that point to the cluster
So the first step is to confirm that you really need to move the API endpoint instead of a workload endpoint.
Where the API Server Port Is Defined
MicroK8s stores the API server arguments in this file:
In a default installation, you will usually find a line like:
Change that value to the port you want.
Example Change
Open the file with root privileges and edit the secure-port setting.
Update the relevant line, for example:
Then restart MicroK8s so the API server picks up the new setting.
After restart, confirm the cluster is healthy:
Update Client Configuration Too
Changing the API server port is only half the job. Clients still need to know where the cluster moved.
If you use the generated kubeconfig, refresh or edit it so the server entry points to the new port. A typical server value looks like this:
Any CI job, local shell alias, or external machine using the old 16443 value must be updated as well.
Firewall and Network Considerations
If a firewall was allowing 16443, it now needs to allow the new port and possibly remove the old one. If the cluster is being accessed remotely, check security groups, host firewalls, VPN policy, or reverse-proxy configuration.
Port changes also matter when documentation or scripts assume the default endpoint. A control-plane port change is operationally small on one machine but surprisingly disruptive in automation.
When This Is the Wrong Fix
A lot of MicroK8s questions are really about exposing an application or avoiding conflict with another local service. In those cases, changing the API server port is often unnecessary.
Examples:
- to expose a Kubernetes app, use a
Serviceor ingress - to publish a workload on a host port, use a
NodePortor host networking where appropriate - to access the dashboard or registry add-on, configure those services directly instead of moving the whole API server
Changing the control-plane port should be the exception, not the first move.
Common Pitfalls
The biggest pitfall is changing --secure-port and forgetting to update kubeconfig files. The cluster may be healthy while every client still fails to connect.
Another mistake is editing the API server arguments when the real problem is an application service port collision. That adds control-plane churn without solving the workload issue cleanly.
Developers also forget firewall rules. Moving the port locally is easy; remembering all the network paths that depended on the old one is harder.
Finally, avoid unsupported drift unless you need it. The more you diverge from default ports, the more operational context every future maintainer must remember.
Summary
- The MicroK8s API server commonly listens on
16443, configured through/var/snap/microk8s/current/args/kube-apiserver. - Change
--secure-portonly if you really mean to move the Kubernetes API endpoint. - Restart MicroK8s after editing the file and verify cluster readiness.
- Update kubeconfig files, automation, and firewall rules to match the new port.
- If your goal is exposing an app, use Kubernetes service mechanisms instead of changing the control-plane port.
Related reading
- How to check if Kubernetes cluster is running fine
- How to check if pod security policy is enabled?
- How to check that a Cassandra node is ready?
- How to check the actual number of incremental fetch session cache slots used in Kafka cluster?
- How to check the containers running on a pod in kubernettes?
- how to check whether RBAC is enabled, using kubectl
- How to choose Kafka transactional.id in a Kubernetes (Producer side only transaction) set up
- How to clean-up old unused Kubernetes images/tags?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.