How to Install Kubernetes: minikube and k3s Step by Step

How to install Kubernetes, and which route fits you?

Kubernetes is an open source system that runs containers on one or many machines, restarts them when they fail, and keeps your desired state. To install it, you use minikube for a local learning cluster on your computer, or k3s for a lightweight cluster on one Linux server. Also, you manage both with kubectl.

We are a digital marketing and web team, not a hosting company. So every command and requirement here comes from the official minikube, k3s and Kubernetes documentation. We give no version numbers. You install the current stable release and check the official page yourself.

So how to install Kubernetes safely, and what should you decide first? Ask one question: do you want a cluster to learn on, or to run a real application? Your answer sets the route, because a practice cluster and an always-on cluster need very different care.

By the end of this guide you will know two things. First, you will see how to start a cluster and run a first app. Second, you will know when to skip this job and leave it to your hosting provider.

What are a pod, a deployment and a service in Kubernetes?

Three terms cover most of the basics. A pod is the smallest unit in a cluster, and it holds one or more containers. Then a deployment describes how many pods should run and how updates roll out. Finally, a service gives those pods a stable network address.

According to the official tutorial, a Deployment creates and updates instances of your application. For example, if a node goes down, the Deployment controller replaces the instance on another node. In other words, you say "run two copies", and Kubernetes keeps that promise.

The Service documentation defines it as a method for exposing a network application that runs as one or more pods. However, pod IP addresses can change. A service, however, gives you one address that stays the same.

• Pod: the smallest unit where containers run.
• Deployment: declares the pod count and the update strategy.
• Service: gives pods a stable network address.
• Node: the machine that runs your pods.
• Namespace: a logical group that separates resources.

Do you really need Kubernetes?

For most company websites, blogs and small online shops, the answer is no. For example, a WordPress, Laravel or Node.js app on a single server is simpler, cheaper and calmer to run without Kubernetes. So it is an investment in complexity.

If containers are new to you, read our guide to Docker and containers first. Its "Is Kubernetes necessary" section answers this question in detail, so we do not repeat it here. In short, one server and a few containers usually work fine with Docker Compose. Weighing that option before you start can save you weeks of effort.

However, Kubernetes starts to make sense in a few cases. Your app may have many services, your traffic may swing, or you may want autoscaling and zero-downtime updates. It also pays off when your team has the skills to run it. Otherwise, the learning curve eats time you need for your real work.

• One site on one server: you do not need Kubernetes.
• A few containers and low traffic: Docker Compose is often enough.
• Many services, heavy traffic and autoscaling: consider Kubernetes.
• Learning or a portfolio project: start with minikube.

What should you check before you install?

First, check your hardware. The official minikube page asks for at least 2 CPUs, 2 GB of free memory and 20 GB of free disk space. It also needs an internet connection and a container or virtual machine manager such as Docker. On a small laptop, close other apps before you start.

The k3s requirements look lighter. The official page lists 2 cores and 2 GB of RAM for a server node, and 1 core and 512 MB of RAM for an agent node. These are minimums, so your own workloads will add to them.

On the operating system side, k3s runs on most modern Linux systems, and the documentation mentions Ubuntu and Debian. If you are still choosing a server, our article on the difference between VPS, cloud server and VDS helps.

• First, a Linux user with sudo rights to run the commands.
• Second, a current package manager and internet access.
• Also, a backup or snapshot, so you can roll back after a server test.
• Enough memory, because cluster components use RAM on their own.

How to install Kubernetes with minikube?

Minikube starts a single-node local Kubernetes cluster on your computer. It is the safest way to learn, because if you make a mistake you delete the cluster and start again. Instead, use a managed or well-planned setup for production.

On macOS with Homebrew, the install is one line. For example, the official getting started page gives this command.

brew install minikube

On Linux (x86-64), you download the stable binary from the official page and place it on your path. Download the file first, then install it.

curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64sudo install minikube-linux-amd64 /usr/local/bin/minikuberm minikube-linux-amd64

If you use Windows or another CPU architecture, follow the selector on the official minikube getting started page. It shows the current commands for each operating system.

Which driver does minikube use, and which should you pick?

Minikube does not run the cluster directly on your operating system. Instead, it runs it inside a container or a virtual machine. The official page lists managers such as Docker, QEMU, Hyperkit, Hyper-V and KVM as drivers. However, which one fits depends on your system.

If Docker is already installed, starting with it is the most practical choice. Because you need no extra virtual machine software, minikube simply runs its own container. If you do not know Docker yet, learning container basics first makes this step easier.

If the driver choice fails, do not panic. The minikube message tells you which driver is missing and points to the official drivers page. You can also change the driver later, but you need to delete the cluster and start it again.

• Docker installed: you can start with the least extra software.
• Prefer a virtual machine: pick a driver your operating system supports.
• Getting an error: read the matching section of the official drivers page.

How do you start and check a minikube cluster?

Then, after the install, you start the cluster with one command. Minikube picks a suitable driver, for example Docker, if it finds one. If it finds none, it prints an error and sends you to the drivers page.

minikube start

Next, confirm that the cluster is up. The command from the official docs lists the pods in all namespaces. If you did not install kubectl separately, minikube also ships its own copy.

kubectl get po -Aminikube kubectl -- get po -A

If you want a visual panel, minikube dashboard opens a web interface. Finally, when you finish, minikube stop pauses the cluster. To remove every minikube cluster, run minikube delete --all.

In short, the daily flow has three steps: start, experiment, stop. Leaving the cluster running all day drains your memory and battery.

What is k3s, and how does it differ from minikube?

K3s is a lightweight Kubernetes distribution that ships as a single binary. It is built to run with few resources, so people choose it for small servers and edge devices. Minikube, on the other hand, is a local learning tool.

The difference lies in the goal, because the two tools serve different jobs. You open minikube on your computer to experiment, then shut it down. Meanwhile, you install k3s on a Linux server and leave it running as an always-on cluster. Therefore k3s brings a bigger security and maintenance load. When you ask how to install Kubernetes on a server, accept that difference up front, and you will avoid unpleasant surprises later.

How to install Kubernetes on one server with k3s?

The official quick start shows the install as a single line. So we do not print that line as is. Running a script from the internet without reading it means giving your server's admin rights to unknown code. So download it first, read it, and only then run it.

First, save the script to a file. Second, look through its contents.

curl -sfL https://get.k3s.io -o k3s-install.shless k3s-install.sh

Once you understand the script and trust it, run it with admin rights. According to the docs, the install creates a single-node server and starts k3s as a service.

sudo sh k3s-install.sh

The install also brings tools such as kubectl, crictl and ctr, plus the k3s-killall.sh and k3s-uninstall.sh scripts. Then, within a few minutes, your cluster is ready. You do not need to install a separate kubectl.

Our answer to how to install Kubernetes on a server comes down to three steps: download, read, run. Also, do not skip any of them. Always check the exact parameters and current behavior of the script on the k3s quick start page. If you want to pin a specific release, learn the method from the official docs as well.

How do you verify k3s and use the kubeconfig file?

After the install, first check that the node is ready. K3s ships its own kubectl, so you can run it as k3s kubectl. When the node shows the "Ready" status, the cluster works. If it is not ready yet, wait a minute or two and run the command again, because k3s components can take a moment to start.

sudo k3s kubectl get nodessudo k3s kubectl get pods -A

The kubeconfig file holds the address and credentials that kubectl needs to reach the cluster. K3s writes it to /etc/rancher/k3s/k3s.yaml. If you connect from another computer, you copy this file over.

However, here is a critical warning. This file gives admin access to the cluster. Treat it like a password: never email it and never commit it to a public repository. Then edit the server address to match your own server. In our example you would see a documentation address such as 203.0.113.10.

• Move the kubeconfig file only over a secure channel.
• Keep file permissions open only to the users who need it.
• Delete copies when the job is done.
• Do not use admin access for everyday tasks.

What errors can you hit during installation, and how do you fix them?

Install errors usually come from three sources: low resources, a missing driver, and network or firewall problems. Reading the error message solves half of the problem, so we suggest you copy the message and search for it in the official docs.

If memory is short, minikube or k3s may not start properly. In that case, close other apps or add memory to the server. If you stay below the official minimums, the cluster may look fine at first but turn unstable under load.

If you cannot connect to the server from a remote computer, check the firewall first. The k3s docs list port 6443/TCP for the API server. However, you should not open it to everyone. Allow only your own IP address.

• Driver not found: install Docker or another manager and try again.
• Memory or disk is too low: add resources or close unneeded apps.
• Cannot reach the cluster: check the kubeconfig address and the firewall.
• Node not ready: wait a few minutes, then run kubectl describe node to see why.

What are the basic kubectl commands?

Kubectl is the command line tool that talks to Kubernetes. Its form is simple: kubectl, an action and a resource. For example, kubectl get pods lists your pods. The table below covers most of the daily work.

With most of these commands, you name a namespace with the -n flag. If you skip it, kubectl uses the default namespace. The -A flag also shows all namespaces at once.

One tip: first, before you type a resource name in a new command, list the resources with kubectl get. That way you also lower the risk of deleting the wrong one.

How do you deploy your first app with a Deployment?

For your first app, write a YAML file. This file describes a simple web server with two copies. We use the official nginx image as the container. However, in production, pin the image tag and use your own image. Think of the example as a demo page for example.com.

apiVersion: apps/v1kind: Deploymentmetadata:  name: hello-webspec:  replicas: 2  selector:    matchLabels:      app: hello-web  template:    metadata:      labels:        app: hello-web    spec:      containers:        - name: web          image: nginx          ports:            - containerPort: 80          resources:            requests:              cpu: 50m              memory: 64Mi            limits:              memory: 128Mi

Save the file as deployment.yaml and apply it. Then watch the status.

kubectl apply -f deployment.yamlkubectl get deploymentskubectl get pods

The official tutorial shows the same job with one command: kubectl create deployment builds a Deployment from an image. The YAML route, however, keeps your changes in a file. That way you can reapply the same definition and keep it in version control. For details, read the Kubernetes Deployment tutorial.

How do you expose the app with a Service?

According to the docs, pods run on a private, isolated network. In other words, other pods and services in the same cluster can see them, but the outside world cannot. To reach them from outside, you create a Service.

The default Service type, ClusterIP, makes the app reachable only inside the cluster. NodePort opens a static port on each node's IP address. LoadBalancer uses the load balancer of a cloud provider.

apiVersion: v1kind: Servicemetadata:  name: hello-webspec:  type: NodePort  selector:    app: hello-web  ports:    - protocol: TCP      port: 80      targetPort: 80      nodePort: 30080

After you apply the file, the access path depends on the environment. In minikube, minikube service hello-web opens the address. On k3s, you connect with the server IP and the NodePort. For the example address 203.0.113.10, that is http://203.0.113.10:30080.

For a quick test, kubectl port-forward deployment/hello-web 8080:80 also works. It lets you try the app locally without opening any port to the outside. Whenever you open a NodePort, review your firewall rules.

Read the Kubernetes Service documentation for the full list of service types.

How do you scale and update the app?

Scaling means changing the number of copies in a Deployment. For example, when traffic grows, you add copies, and when it drops, you remove them. So one command does the job. Scaling helps, but if the node lacks resources, the extra pods cannot start and stay in the Pending state.

kubectl scale deployment hello-web --replicas=3kubectl get pods

To update, you change the image. The Deployment replaces old pods with new ones step by step, so the app updates without downtime. Fixing the image tag in the YAML file and running kubectl apply again is the cleanest way.

kubectl rollout status deployment/hello-webkubectl rollout undo deployment/hello-web

The first command shows how the update progresses. The second one returns to the previous version if something breaks. However, it cannot undo changes that are irreversible, such as a database schema change. Therefore, before database updates, follow our website backup strategy guide.

How do you diagnose a pod that does not run?

When something breaks, do not panic. So the order is always the same. First look at the status, then dig into the details, and last read the log. Then these three steps solve most problems.

1. Run kubectl get pods and read the status column. Pending, ImagePullBackOff and CrashLoopBackOff are the most common problem states.
2. Run kubectl describe pod NAME and read the events section. Reasons such as a missing image or too few resources show up there.
3. Run kubectl logs NAME to read the error output of the app itself.
4. Check resources if needed. If the node has no free memory or CPU, the pod cannot start.

For example, ImagePullBackOff usually means the image name is wrong or you lack access to a private registry. Pending, on the other hand, often points to a shortage of resources.

The cause is often the application, not Kubernetes. A wrong environment variable, for instance, can stop an app from starting. So reading the log first gives faster results than guessing.

If you still cannot solve it, copy the error message and search the official docs. When you share error output, hide your kubeconfig, passwords and real domain names.

What should you watch for in Kubernetes security?

The Kubernetes API server is the front door of the cluster. The k3s requirements list port 6443/TCP for the API server. Opening this port to the whole internet is a serious risk. If possible, open it only to your own IP address or a VPN.

On the network side, note another warning in the docs. If you do not restrict port 8472/UDP, which Flannel VXLAN uses, anyone may reach the cluster network. The official page also says that if a firewall stays on, you need to allow the required rules yourself.

A few habits on the app side make a difference too. Pull images from trusted sources, pin image tags, and never write passwords into YAML files. On the server side, our guides to protecting a server with Fail2ban and the CSF firewall will help.

• Do not open port 6443 to everyone; limit it by IP.
• Protect the kubeconfig file like a password.
• Pin image tags and use trusted sources.
• Track system and cluster updates regularly.
• If your app handles web risk, review the OWASP Top 10 list.

What should you know about resource use and cost?

Kubernetes spends memory and CPU even on its own components. The official numbers show it: minikube asks for 2 GB of free memory, and a k3s server node asks for 2 GB of RAM. On a small VPS, your own app may have little room left once the cluster runs.

That is why you should set resource requests and limits in your pod definitions. We added the requests and limits fields to the example above for this reason. Without a limit, one pod can eat all the memory and push the others out.

On the cost side, three items matter: server rent, maintenance time and the risk of mistakes. For most small businesses, time and risk cost more than the rent. Also, your page speed depends on whether the server is truly enough, so read our piece on how site speed affects SEO.

Example calculation (hypothetical): if your server has 4 GB of RAM and cluster components take 2 GB, about 2 GB remains for apps. This shows why you should measure real use before you decide. A memory limit set too low also makes the app restart often, so tune the values by watching them.

When should you not install Kubernetes yourself and leave it to your hosting provider?

The honest answer is this: running infrastructure is not our job. We work on digital marketing and web development. So we suggest a clear limit. Do not set up and run your first cluster alone for a store that earns revenue, or for a system that stores customer data.

In production, backups, updates, monitoring and security patches need constant work. If you cannot give them time, a managed Kubernetes service or your hosting provider's supported option is safer. When you pick a provider, use the criteria in our guide to choosing web hosting.

• Live store or payment system: use a managed service or provider support.
• Customer data and legal duties: get expert help.
• No one to watch the server: do not build your own cluster.
• Learning and short tests: minikube or k3s on one VPS fits.

To check your domain, DNS and SSL setup, you can use our free DNS lookup and SSL checker tools.

Which good habits should you build after the cluster runs?

When the cluster is up, the real work begins. The first habit is to keep all YAML files in version control. That way you see which change you made and when, and you can go back if needed. To refresh the commands, check our essential Git and GitHub commands guide.

The second habit is to separate resources with namespaces. If you keep test and live work in one namespace, you may delete the wrong thing by mistake. The third is to write requests and limits for every Deployment.

The fourth habit is a regular backup. Pods can disappear, but persistent data must not. For stateful apps such as databases, going without backups is a big risk. Also, test cluster updates in a trial environment first.

• Keep YAML files in version control.
• Put test and live work in separate namespaces.
• Write requests and limits for every pod.
• Back up often and practice a restore.
• Test updates in a trial environment first.

How do you clean up and remove the cluster?

If your experiment is over, removing the cluster is good for memory and for security. A cluster left open is like a forgotten door. Cleanup on minikube is simple.

minikube stopminikube delete --all

On k3s, the install brings an uninstall script along. The official quick start mentions the name k3s-uninstall.sh. Before you run it on a server, make sure you have a backup of any data in the cluster.

sudo k3s-uninstall.sh

Also remember to close the ports you opened in the firewall. Remove the rule you opened for the NodePort and delete any kubeconfig copies. That way you leave no open door behind.

What should your next step be?

Setting up a cluster is only the start. As a next step, containerize your own app and run it with a Deployment. Then move on to topics such as environment variables, persistent disks and network rules.

If your app uses Node.js, first read our Node.js deployment guide for Linux. You will see whether the simple method is enough before you move to Kubernetes.

The real answer to how to install Kubernetes is to pick the goal first. If you want to learn, minikube is the right start. For a small always-on setup, k3s fits. For a critical system, a managed service is the better start.

Before you decide on infrastructure, make your goal clear. We help with websites, SEO and digital marketing, and for infrastructure we suggest you work with a trusted hosting provider. Follow the official docs, because these tools change fast.