K3s A lightweight Kubernetes distribution is ideal for development use. It is now part of the Cloud Native Computing Foundation (CNCF), but was originally developed by Rancher.

K3s ships as a binary with a file size of less than 50MB. Despite its diminutive presence, K3s includes everything you need to run a production-ready Kubernetes cluster. The project focuses on resource-constrained hardware where reliability and ease of maintenance are major concerns. While the K3s is now commonly found on edge on IoT devices, these qualities also make it a good contender for local use by developers.

K3s. start with

Running the K3s binary will start the Kubernetes cluster on the host machine. The core K3s process starts and manages all components of Kubernetes, including the control plane’s API server, the Kubelet worker instance, and containerd container runtime,

In practice you will usually want K3s to start automatically as a service. It is recommended that you use official installation script To get K3s running on your system quickly. This will download the binary, move it to your path, and register a systemd or openrc service as appropriate for your system. K3s will be configured to restart automatically after its process crashes or your host reboots.

$ curl -sfL https://get.k3s.io | sh -

Confirm the installation was successful by checking the status of k3s Service:

$ sudo service k3s status

You are ready to start using your cluster if active (running) is displayed in green.

interact with your cluster

K3s Bundle kubectly If you install it using the script provided. it is nested under k3s command:

$ k3s kubectl get pods
No resources found in default namespace.

You may receive an error that looks like this:

$ k3s kubectl get pods
WARN[0000] Unable to read /etc/rancher/k3s/k3s.yaml, please start server with --write-kubeconfig-mode to modify kube config permissions 
error: error loading config file "/etc/rancher/k3s/k3s.yaml": open /etc/rancher/k3s/k3s.yaml: permission denied

You can fix this by adjusting the file permissions of the referenced path:

$ sudo chmod 644 /etc/rancher/k3s/k3s.yaml

Now you should be able to run the Kubectl command without using sudo,

You can continue to use a standalone Kubectl installation if you don’t want to rely on the integrated version of K3s. Use KUBECONFIG environment variable or --kubeconfig Flag your K3s configuration file to be referenced when running bare kubectl command:

$ export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
$ kubectl get pods
No resources found in default namespace.

an example assignment

You can test your cluster by adding a simple deployment:

$ k3s kubectl create deployment nginx --image=nginx:latest
deployment.apps/nginx created
$ k3s kubectl expose deployment nginx --type=LoadBalancer --port=80
service/nginx exposed

Use Kubectl to find the IP address of the created service:

$ k3s kubectl get services
NAME         TYPE           CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP      10.43.0.1     <none>        443/TCP        35m
nginx        LoadBalancer   10.43.49.20   <pending>     80:30968/TCP   17s

In this example, the NGINX service is available at 10.43.49.20, Visit this URL in your web browser to view the default NGINX landing page.

setting kubernetes options

When you run K3s, you can set custom logic for individual Kubernetes components. Values ​​must be given as command-line flags to the K3s binary. Environment variables are also supported but conversion from flag to variable name not always compatible,

Here are some commonly used flags to configure your installation:

several other options K3s and your Kubernetes are available to customize the operation of the cluster. These include features to disable bundled components such as traffic ingress controllers (--disable traefik) so that you can replace them with alternative implementations.

Apart from flags and variables, K3s also supports a YAML configuration file which is pretty much maintainable. submit it here /etc/rancher/k3s/config.yaml To use it automatically every time the K3s is started. Field names must be CLI arguments stripped of them -- prefix.

node-name: first-worker
bind-address: 1.2.3.4

multi-node cluster

K3s has full support for multi-node clusters. You can add nodes to your cluster by setting K3S_URL And K3S_TOKEN Environment variables before running the installation script.

$ curl -sfL https://get.k3s.io | K3S_URL=https://192.168.0.1:6443 K3S_TOKEN=token sh -

This script will install K3s and configure it as a worker node that connects by IP address 192.168.0.1, To find your token, copy the value of /var/lib/rancher/k3s/server/node-token file from the machine that is running your K3s server.

Using images in private registries

K3s has good integrated support for images in private registries. You can provide a special configuration file to inject registry credentials into your cluster. These credentials will be read when the K3s server starts. It will automatically share them with your worker nodes.

make /etc/rancher/k3s/registries.yaml File with the following content:

mirrors:
  example-registry.com:
    endpoint:
      - "https://example-registry.com:5000"

This will let your cluster draw images like example-registry.com/example-image:latest from server example-registry.com:5000, You can specify multiple URLs under endpoint Farm; They will be used as a fallback in the written order until a successful pull occurs.

Provide user credentials for your registries using the following syntax:

mirrors:
  example-registry.com:
    endpoint:
      - "https://example-registry.com:5000"
configs:
  "example-registry.com:5000":
    auth:
      username: <username>
      password: <password>

Credentials are defined on a per-endpoint basis. Requires separate entries in defined registries with multiple endpoints config area for each.

The endpoint that uses SSL also needs to be assigned a TLS configuration:

configs:
  "example-registry.com:5000":
    auth:
      username: <username>
      password: <password
    tls:
      cert_file: /tls/cert
      key_file: /tls/key
      ca_file: /tls/ca

Well cert_file, key_fileAnd ca_file Fields to reference the correct certificate files for your registry.

upgrade your cluster

You can upgrade to the new K3s release by running the latest version of the installation script. It will automatically detect your existing cluster and migrate it to the new version.

$ curl -sfL https://get.k3s.io | sh -

If you have customized your cluster by setting installer environment variables, repeat them when you run the upgrade command:

$ curl -sfL https://get.k3s.io | INSTALL_K3S_BIN_DIR=/usr/bin sh -

Multi-node clusters are upgraded using the same process. After running the new release of the server, you should upgrade each worker node separately.

You can install a specific Kubernetes version by setting INSTALL_K3S_VERSION Variables before running script:

$ curl -sFL https://get.k3s.io | INSTALL_K3S_VERSION=v1.23.0 sh -

INSTALL_K3S_CHANNEL Versioning can select unstable versions and pre-release builds:

$ curl -sFL https://get.k3s.io | INSTALL_K3S_CHANNEL=latest sh -

K3s will default to running the latest stable Kubernetes release when these variables are not set.

Uninstalling K3s

Since K3s is packaged as a self-contained binary, it’s easy to clean up if you want to stop using it. The install process provides an uninstall script that will remove system services, remove binaries, and clear all data created by your cluster.

$ /usr/local/bin/k3s-uninstall.sh

you should use script /usr/local/bin/k3s-agent-uninstall.sh Instead when you are shutting down the K3s worker node.

conclusion

K3s is a single-binary Kubernetes distribution that is light on system resources and easy to maintain. It doesn’t come at the cost of capabilities: K3s is billed as production-ready and has full support for Kubernetes API objects, persistent storageAnd load balanced networking,

K3s is a good alternative to other developer-oriented Kubernetes flavors like minicube And MicroK8S, You don’t need to run virtual machines, install other software, or do any advanced configuration to set up your cluster. This is especially suitable if you’re already running K3s in production, allowing you to smooth out disparities between your environments.