mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-27 05:28:22 +00:00
Fix merge conflicts pulling master into staging
This commit is contained in:
Catherine Luse
@@ -314,6 +314,29 @@ rpm -i https://rpm.rancher.io/k3s-selinux-0.1.1-rc1.el7.noarch.rpm
|
||||
|
||||
To force the install script to log a warning rather than fail, you can set the following environment variable: `INSTALL_K3S_SELINUX_WARN=true`.
|
||||
|
||||
The way that SELinux enforcement is enabled or disabled depends on the K3s version. Prior to v1.19.x, SELinux enablement for the builtin containerd was automatic but could be disabled by passing `--disable-selinux`. With v1.19.x and beyond, enabling SELinux must be affirmatively configured via the `--selinux` flag or config file entry. Servers and agents that specify both the `--selinux` and (deprecated) `--disable-selinux` flags will fail to start.
|
||||
|
||||
Using a custom `--data-dir` under SELinux is not supported. To customize it, you would most likely need to write your own custom policy. For guidance, you could refer to the [containers/container-selinux](https://github.com/containers/container-selinux) repository, which contains the SELinux policy files for Container Runtimes, and the [rancher/k3s-selinux](https://github.com/rancher/k3s-selinux) repository, which contains the SELinux policy for K3s .
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "K3s v1.19.1+k3s1" %}}
|
||||
|
||||
To leverage experimental SELinux, specify the `--selinux` flag when starting K3s servers and agents.
|
||||
|
||||
This option can also be specified in the K3s [configuration file:]({{<baseurl>}}/k3s/latest/en/installation/install-options/#configuration-file)
|
||||
|
||||
```
|
||||
selinux: true
|
||||
```
|
||||
|
||||
The `--disable-selinux` option should not be used. It is deprecated and will be either ignored or will be unrecognized, resulting in an error, in future minor releases.
|
||||
|
||||
{{%/tab%}}
|
||||
{{% tab "K3s prior to v1.19.1+k3s1" %}}
|
||||
|
||||
You can turn off SELinux enforcement in the embedded containerd by launching K3s with the `--disable-selinux` flag.
|
||||
|
||||
{{%/tab%}}
|
||||
{{% /tabs %}}
|
||||
|
||||
Note that support for SELinux in containerd is still under development. Progress can be tracked in [this pull request](https://github.com/containerd/cri/pull/1246).
|
||||
|
||||
@@ -56,4 +56,4 @@ A unique node ID can be appended to the hostname by launching K3s servers or age
|
||||
|
||||
# Automatically Deployed Manifests
|
||||
|
||||
The [manifests](https://github.com/rancher/k3s/tree/master/manifests) located at the directory path `/var/lib/rancher/k3s/server/manifests` are bundled into the K3s binary at build time.
|
||||
The [manifests](https://github.com/rancher/k3s/tree/master/manifests) located at the directory path `/var/lib/rancher/k3s/server/manifests` are bundled into the K3s binary at build time. These will be installed at runtime by the [rancher/helm-controller.](https://github.com/rancher/helm-controller#helm-controller)
|
||||
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: Backup and Restore Embedded etcd Datastore (Experimental)
|
||||
shortTitle: Backup and Restore
|
||||
weight: 26
|
||||
---
|
||||
|
||||
_Available as of v1.19.1+k3s1_
|
||||
|
||||
In this section, you'll learn how to create backups of the K3s cluster data and to restore the cluster from backup.
|
||||
|
||||
> This is an experimental feature available for K3s clusters with an embedded etcd datastore. If you installed K3s with an external datastore, refer to the upstream documentation for the database for information on backing up the cluster data.
|
||||
|
||||
### Creating Snapshots
|
||||
|
||||
Snapshots are enabled by default.
|
||||
|
||||
The snapshot directory defaults to `/server/db/snapshots`.
|
||||
|
||||
To configure the snapshot interval or the number of retained snapshots, refer to the [options.](#options)
|
||||
|
||||
### Restoring a Cluster from a Snapshot
|
||||
|
||||
When K3s is restored from backup, the old data directory will be moved to `/server/db/etcd-old/`. Then K3s will attempt to restore the snapshot by creating a new data directory, then starting etcd with a new K3s cluster with one etcd member.
|
||||
|
||||
To restore the cluster from backup, run K3s with the `--cluster-reset` option, with the `--cluster-reset-restore-path` also given:
|
||||
|
||||
```
|
||||
./k3s server \
|
||||
--cluster-reset \
|
||||
--cluster-reset-restore-path=<PATH-TO-SNAPSHOT>
|
||||
```
|
||||
|
||||
**Result:** A message in the logs says that K3s can be restarted without the flags. Start k3s again and should run successfully and be restored from the specified snapshot.
|
||||
|
||||
### Options
|
||||
|
||||
These options can be passed in with the command line, or in the [configuration file,]({{<baseurl>}}/k3s/latest/en/installation/install-options/#configuration-file ) which may be easier to use.
|
||||
|
||||
| Options | Description |
|
||||
| ----------- | --------------- |
|
||||
| `--etcd-disable-snapshots` | Disable automatic etcd snapshots |
|
||||
| `--etcd-snapshot-schedule-cron` value | Snapshot interval time in cron spec. eg. every 5 hours `* */5 * * *`(default: `0 */12 * * *`) |
|
||||
| `--etcd-snapshot-retention` value | Number of snapshots to retain (default: 5) |
|
||||
| `--etcd-snapshot-dir` value | Directory to save db snapshots. (Default location: `${data-dir}/db/snapshots`) |
|
||||
| `--cluster-reset` | Forget all peers and become sole member of a new cluster. This can also be set with the environment variable `[$K3S_CLUSTER_RESET]`.
|
||||
| `--cluster-reset-restore-path` value | Path to snapshot file to be restored
|
||||
@@ -3,48 +3,28 @@ title: Helm
|
||||
weight: 42
|
||||
---
|
||||
|
||||
K3s release _v1.17.0+k3s.1_ added support for Helm 3. You can access the Helm 3 documentation [here](https://helm.sh/docs/intro/quickstart/).
|
||||
Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/docs/intro/quickstart/](https://helm.sh/docs/intro/quickstart/).
|
||||
|
||||
Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at https://helm.sh/.
|
||||
|
||||
K3s does not require any special configuration to start using Helm 3. Just be sure you have properly set up your kubeconfig as per the section about [cluster access.](../cluster-access)
|
||||
K3s does not require any special configuration to use with Helm command-line tools. Just be sure you have properly set up your kubeconfig as per the section about [cluster access](../cluster-access). K3s does include some extra functionality to make deploying both traditional Kubernetes resource manifests and Helm Charts even easier with the [rancher/helm-release CRD.](#using-the-helm-crd)
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [Upgrading Helm](#upgrading-helm)
|
||||
- [Deploying manifests and Helm charts](#deploying-manifests-and-helm-charts)
|
||||
- [Automatically Deploying Manifests and Helm Charts](#automatically-deploying-manifests-and-helm-charts)
|
||||
- [Using the Helm CRD](#using-the-helm-crd)
|
||||
- [Customizing Packaged Components with HelmChartConfig](#customizing-packaged-components-with-helmchartconfig)
|
||||
- [Upgrading from Helm v2](#upgrading-from-helm-v2)
|
||||
|
||||
### Upgrading Helm
|
||||
### Automatically Deploying Manifests and Helm Charts
|
||||
|
||||
If you were using Helm v2 in previous versions of K3s, you may upgrade to v1.17.0+k3s.1 or newer and Helm 2 will still function. If you wish to migrate to Helm 3, [this](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) blog post by Helm explains how to use a plugin to successfully migrate. Refer to the official Helm 3 documentation [here](https://helm.sh/docs/) for more information. K3s will handle either Helm v2 or Helm v3 as of v1.17.0+k3s.1. Just be sure you have properly set your kubeconfig as per the examples in the section about [cluster access.](../cluster-access)
|
||||
Any Kubernetes manifests found in `/var/lib/rancher/k3s/server/manifests` will automatically be deployed to K3s in a manner similar to `kubectl apply`. Manifests deployed in this manner are managed as AddOn custom resources, and can be viewed by running `kubectl get addon -A`. You will find AddOns for packaged components such as CoreDNS, Local-Storage, Traefik, etc. AddOns are created automatically by the deploy controller, and are named based on their filename in the manifests directory.
|
||||
|
||||
Note that Helm 3 no longer requires Tiller and the `helm init` command. Refer to the official documentation for details.
|
||||
It is also possible to deploy Helm charts as AddOns. K3s includes a [Helm Controller](https://github.com/rancher/helm-controller/) that manages Helm charts using a HelmChart Custom Resource Definition (CRD).
|
||||
|
||||
### Deploying Manifests and Helm Charts
|
||||
### Using the Helm CRD
|
||||
|
||||
Any file found in `/var/lib/rancher/k3s/server/manifests` will automatically be deployed to Kubernetes in a manner similar to `kubectl apply`.
|
||||
> **Note:** K3s versions through v0.5.0 used `k3s.cattle.io/v1` as the apiVersion for HelmCharts. This has been changed to `helm.cattle.io/v1` for later versions.
|
||||
|
||||
It is also possible to deploy Helm charts. K3s supports a CRD controller for installing charts. A YAML file specification can look as following (example taken from `/var/lib/rancher/k3s/server/manifests/traefik.yaml`):
|
||||
|
||||
```yaml
|
||||
apiVersion: helm.cattle.io/v1
|
||||
kind: HelmChart
|
||||
metadata:
|
||||
name: traefik
|
||||
namespace: kube-system
|
||||
spec:
|
||||
chart: stable/traefik
|
||||
set:
|
||||
rbac.enabled: "true"
|
||||
ssl.enabled: "true"
|
||||
```
|
||||
|
||||
Keep in mind that `namespace` in your HelmChart resource metadata section should always be `kube-system`, because the K3s deploy controller is configured to watch this namespace for new HelmChart resources. If you want to specify the namespace for the actual Helm release, you can do that using `targetNamespace` key under the `spec` directive, as shown in the configuration example below.
|
||||
|
||||
> **Note:** In order for the Helm Controller to know which version of Helm to use to Auto-Deploy a helm app, please specify the `helmVersion` in the spec of your YAML file.
|
||||
|
||||
Also note that besides `set`, you can use `valuesContent` under the `spec` directive. And it's okay to use both of them:
|
||||
The [HelmChart resource definition](https://github.com/rancher/helm-controller#helm-controller) captures most of the options you would normally pass to the `helm` command-line tool. Here's an example of how you might deploy Grafana from the default chart repository, overriding some of the default chart values. Note that the HelmChart resource itself is in the `kube-system` namespace, but the chart's resources will be deployed to the `monitoring` namespace.
|
||||
|
||||
```yaml
|
||||
apiVersion: helm.cattle.io/v1
|
||||
@@ -68,34 +48,58 @@ spec:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
K3s versions `<= v0.5.0` used `k3s.cattle.io` for the API group of HelmCharts. This has been changed to `helm.cattle.io` for later versions.
|
||||
#### HelmChart Field Definitions
|
||||
|
||||
### Using the Helm CRD
|
||||
| Field | Default | Description | Helm Argument / Flag Equivalent |
|
||||
|-------|---------|-------------|-------------------------------|
|
||||
| name | | Helm Chart name | NAME |
|
||||
| spec.chart | | Helm Chart name in repository, or complete HTTPS URL to chart archive (.tgz) | CHART |
|
||||
| spec.targetNamespace | default | Helm Chart target namespace | `--namespace` |
|
||||
| spec.version | | Helm Chart version (when installing from repository) | `--version` |
|
||||
| spec.repo | | Helm Chart repository URL | `--repo` |
|
||||
| spec.helmVersion | v3 | Helm version to use (`v2` or `v3`) | |
|
||||
| spec.bootstrap | False | Set to True if this chart is needed to bootstrap the cluster (Cloud Controller Manager, etc) | |
|
||||
| spec.set | | Override simple default Chart values. These take precedence over options set via valuesContent. | `--set` / `--set-string` |
|
||||
| spec.valuesContent | | Override complex default Chart values via YAML file content | `--values` |
|
||||
| spec.chartContent | | Base64-encoded chart archive .tgz - overrides spec.chart | CHART |
|
||||
|
||||
You can deploy a third-party Helm chart using an example like this:
|
||||
Content placed in `/var/lib/rancher/k3s/server/static/` can be accessed anonymously via the Kubernetes APIServer from within the cluster. This URL can be templated using the special variable `%{KUBERNETES_API}%` in the `spec.chart` field. For example, the packaged Traefik component loads its chart from `https://%{KUBERNETES_API}%/static/charts/traefik-1.81.0.tgz`.
|
||||
|
||||
### Customizing Packaged Components with HelmChartConfig
|
||||
|
||||
To allow overriding values for packaged components that are deployed as HelmCharts (such as Traefik), K3s versions starting with v1.19.0+k3s1 support customizing deployments via a HelmChartConfig resources. The HelmChartConfig resource must match the name and namespace of its corresponding HelmChart, and supports providing additional `valuesContent`, which is passed to the `helm` command as an additional value file.
|
||||
|
||||
> **Note:** HelmChart `spec.set` values override HelmChart and HelmChartConfig `spec.valuesContent` settings.
|
||||
|
||||
For example, to customize the packaged Traefik ingress configuration, you can create a file named `/var/lib/rancher/k3s/server/manifests/traefik-config.yaml` and populate it with the following content:
|
||||
|
||||
```yaml
|
||||
apiVersion: helm.cattle.io/v1
|
||||
kind: HelmChart
|
||||
kind: HelmChartConfig
|
||||
metadata:
|
||||
name: nginx
|
||||
name: traefik
|
||||
namespace: kube-system
|
||||
spec:
|
||||
chart: nginx
|
||||
repo: https://charts.bitnami.com/bitnami
|
||||
targetNamespace: default
|
||||
valuesContent: |-
|
||||
image: traefik
|
||||
imageTag: v1.7.26-alpine
|
||||
proxyProtocol:
|
||||
enabled: true
|
||||
trustedIPs:
|
||||
- 10.0.0.0/8
|
||||
forwardedHeaders:
|
||||
enabled: true
|
||||
trustedIPs:
|
||||
- 10.0.0.0/8
|
||||
ssl:
|
||||
enabled: true
|
||||
permanentRedirect: false
|
||||
```
|
||||
|
||||
You can install a specific version of a Helm chart using an example like this:
|
||||
### Upgrading from Helm v2
|
||||
|
||||
```yaml
|
||||
apiVersion: helm.cattle.io/v1
|
||||
kind: HelmChart
|
||||
metadata:
|
||||
name: stable/nginx-ingress
|
||||
namespace: kube-system
|
||||
spec:
|
||||
chart: nginx-ingress
|
||||
version: 1.24.4
|
||||
targetNamespace: default
|
||||
```
|
||||
> **Note:** K3s versions starting with v1.17.0+k3s.1 support Helm v3, and will use it by default. Helm v2 charts can be used by setting `helmVersion: v2` in the spec.
|
||||
|
||||
If you were using Helm v2 in previous versions of K3s, you may upgrade to v1.17.0+k3s.1 or newer and Helm 2 will still function. If you wish to migrate to Helm 3, [this](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) blog post by Helm explains how to use a plugin to successfully migrate. Refer to the official Helm 3 documentation [here](https://helm.sh/docs/) for more information. K3s will handle either Helm v2 or Helm v3 as of v1.17.0+k3s.1. Just be sure you have properly set your kubeconfig as per the examples in the section about [cluster access.](../cluster-access)
|
||||
|
||||
Note that Helm 3 no longer requires Tiller and the `helm init` command. Refer to the official documentation for details.
|
||||
|
||||
@@ -7,7 +7,7 @@ The ability to run Kubernetes using a datastore other than etcd sets K3s apart f
|
||||
|
||||
* If your team doesn't have expertise in operating etcd, you can choose an enterprise-grade SQL database like MySQL or PostgreSQL
|
||||
* If you need to run a simple, short-lived cluster in your CI/CD environment, you can use the embedded SQLite database
|
||||
* If you wish to deploy Kubernetes on the edge and require a highly available solution but can't afford the operational overhead of managing a database at the edge, you can use K3s's embedded HA datastore built on top of DQLite (currently experimental)
|
||||
* If you wish to deploy Kubernetes on the edge and require a highly available solution but can't afford the operational overhead of managing a database at the edge, you can use K3s's embedded HA datastore built on top of embedded etcd (currently experimental)
|
||||
|
||||
K3s supports the following datastore options:
|
||||
|
||||
@@ -16,7 +16,7 @@ K3s supports the following datastore options:
|
||||
* [MySQL](https://www.mysql.com/) (certified against version 5.7)
|
||||
* [MariaDB](https://mariadb.org/) (certified against version 10.3.20)
|
||||
* [etcd](https://etcd.io/) (certified against version 3.3.15)
|
||||
* Embedded [DQLite](https://dqlite.io/) for High Availability (experimental)
|
||||
* Embedded etcd for High Availability (experimental)
|
||||
|
||||
### External Datastore Configuration Parameters
|
||||
If you wish to use an external datastore such as PostgreSQL, MySQL, or etcd you must set the `datastore-endpoint` parameter so that K3s knows how to connect to it. You may also specify parameters to configure the authentication and encryption of the connection. The below table summarizes these parameters, which can be passed as either CLI flags or environment variables.
|
||||
@@ -94,5 +94,6 @@ K3S_DATASTORE_KEYFILE='/path/to/client.key' \
|
||||
k3s server
|
||||
```
|
||||
|
||||
### Embedded DQLite for HA (Experimental)
|
||||
K3s's use of DQLite is similar to its use of SQLite. It is simple to set up and manage. As such, there is no external configuration or additional steps to take in order to use this option. Please see [High Availability with Embedded DB (Experimental)]({{<baseurl>}}/k3s/latest/en/installation/ha-embedded/) for instructions on how to run with this option.
|
||||
### Embedded etcd for HA (Experimental)
|
||||
|
||||
Please see [High Availability with Embedded DB (Experimental)]({{<baseurl>}}/k3s/latest/en/installation/ha-embedded/) for instructions on how to run with this option.
|
||||
|
||||
@@ -3,9 +3,15 @@ title: "High Availability with Embedded DB (Experimental)"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
As of v1.0.0, K3s is previewing support for running a highly available control plane without the need for an external database. This means there is no need to manage an external etcd or SQL datastore in order to run a reliable production-grade setup. While this feature is currently experimental, we expect it to be the primary architecture for running HA K3s clusters in the future.
|
||||
K3s is previewing support for running a highly available control plane without the need for an external database. This means there is no need to manage an external etcd or SQL datastore.
|
||||
|
||||
This architecture is achieved by embedding a dqlite database within the K3s server process. DQLite is short for "distributed SQLite." According to https://dqlite.io, it is "*a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices.*" This makes it a natural fit for K3s.
|
||||
In K3s 1.0.0, Dqlite was used as the experimental embedded database. In K3s v1.19.1+, embedded etcd is used.
|
||||
|
||||
Please note that upgrades from experimental Dqlite to experimental embedded etcd are not supported. If you attempt an upgrade it will not succeed and data will be lost.
|
||||
|
||||
### Embedded etcd (Experimental)
|
||||
|
||||
_Available as of K3s v1.19.1_
|
||||
|
||||
To run K3s in this mode, you must have an odd number of server nodes. We recommend starting with three nodes.
|
||||
|
||||
@@ -20,3 +26,13 @@ K3S_TOKEN=SECRET k3s server --server https://<ip or hostname of server1>:6443
|
||||
```
|
||||
|
||||
Now you have a highly available control plane. Joining additional worker nodes to the cluster follows the same procedure as a single server cluster.
|
||||
|
||||
### Embedded Dqlite (Deprecated)
|
||||
|
||||
> **Warning:** Experimental etcd replaced experimental Dqlite in the K3s v1.19.1 release. This is a breaking change. Please note that upgrades from experimental Dqlite to experimental embedded etcd are not supported. If you attempt an upgrade it will not succeed and data will be lost.
|
||||
|
||||
As of v1.0.0, K3s previewed support for running a highly available control plane without the need for an external database.
|
||||
|
||||
This architecture is achieved by embedding a Dqlite database within the K3s server process. DQLite is short for "distributed SQLite." According to https://dqlite.io, it is "*a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices.*"
|
||||
|
||||
To run K3s with the embedded Dqlite database, follow the same steps as the [embedded etcd database](#embedded-etcd-experimental) using a K3s release between v1.0.0 and v1.19.1.
|
||||
@@ -48,7 +48,7 @@ To configure TLS certificates when launching server nodes, refer to the [datasto
|
||||
|
||||
> **Note:** The same installation options available to single-server installs are also available for high-availability installs. For more details, see the [Installation and Configuration Options]({{<baseurl>}}/k3s/latest/en/installation/install-options/) documentation.
|
||||
|
||||
By default, server nodes will be schedulable and thus your workloads can get launched on them. If you wish to have a dedicated control plane where no user workloads will run, you can use taints. The <span style='white-space: nowrap'>`node-taint`</span> parameter will allow you to configure nodes with taints, for example <span style='white-space: nowrap'>`--node-taint k3s-controlplane=true:NoExecute`</span>.
|
||||
By default, server nodes will be schedulable and thus your workloads can get launched on them. If you wish to have a dedicated control plane where no user workloads will run, you can use taints. The <span style='white-space: nowrap'>`node-taint`</span> parameter will allow you to configure nodes with taints, for example <span style='white-space: nowrap'>`--node-taint CriticalAddonsOnly=true:NoExecute`</span>.
|
||||
|
||||
Once you've launched the `k3s server` process on all server nodes, ensure that the cluster has come up properly with `k3s kubectl get nodes`. You should see your server nodes in the Ready state.
|
||||
|
||||
|
||||
@@ -9,6 +9,9 @@ This page focuses on the options that can be used when you set up K3s for the fi
|
||||
- [Options for installation from binary](#options-for-installation-from-binary)
|
||||
- [Registration options for the K3s server](#registration-options-for-the-k3s-server)
|
||||
- [Registration options for the K3s agent](#registration-options-for-the-k3s-agent)
|
||||
- [Configuration File](#configuration-file)
|
||||
|
||||
In addition to configuring K3s with environment variables and CLI arguments, K3s can also use a [config file.](#configuration-file)
|
||||
|
||||
For more advanced options, refer to [this page.]({{<baseurl>}}/k3s/latest/en/advanced)
|
||||
|
||||
@@ -71,3 +74,36 @@ For details on configuring the K3s server, refer to the [server configuration re
|
||||
### Registration Options for the K3s Agent
|
||||
|
||||
For details on configuring the K3s agent, refer to the [agent configuration reference.]({{<baseurl>}}/k3s/latest/en/installation/install-options/agent-config)
|
||||
|
||||
### Configuration File
|
||||
|
||||
In addition to configuring K3s with environment variables and CLI arguments, K3s can also use a config file.
|
||||
|
||||
By default, values present in a YAML file located at `/etc/rancher/k3s/config.yaml` will be used on install.
|
||||
|
||||
An example of a basic `server` config file is below:
|
||||
|
||||
```yaml
|
||||
write-kubeconfig-mode: "0644"
|
||||
tls-san:
|
||||
- "foo.local"
|
||||
node-label:
|
||||
- "foo=bar"
|
||||
- "something=amazing"
|
||||
```
|
||||
|
||||
In general, CLI arguments map to their respective YAML key, with repeatable CLI arguments being represented as YAML lists.
|
||||
|
||||
An identical configuration using solely CLI arguments is shown below to demonstrate this:
|
||||
|
||||
```bash
|
||||
k3s server \
|
||||
--write-kubeconfig-mode "0644" \
|
||||
--tls-san "foo.local" \
|
||||
--node-label "foo=bar" \
|
||||
--node-label "something=amazing"
|
||||
```
|
||||
|
||||
It is also possible to use both a configuration file and CLI arguments. In these situations, values will be loaded from both sources, but CLI arguments will take precedence. For repeatable arguments such as `--node-label`, the CLI arguments will overwrite all values in the list.
|
||||
|
||||
Finally, the location of the config file can be changed either through the cli argument `--config FILE, -c FILE`, or the environment variable `$K3S_CONFIG_FILE`.
|
||||
|
||||
@@ -33,7 +33,7 @@ If you are using **Alpine Linux**, follow [these steps]({{<baseurl>}}/k3s/latest
|
||||
|
||||
Hardware requirements scale based on the size of your deployments. Minimum recommendations are outlined here.
|
||||
|
||||
* RAM: 512MB Minimum
|
||||
* RAM: 512MB Minimum (we recommend at least 1GB)
|
||||
* CPU: 1 Minimum
|
||||
|
||||
#### Disks
|
||||
|
||||
@@ -25,7 +25,7 @@ Mirrors is a directive that defines the names and endpoints of the private regis
|
||||
|
||||
```
|
||||
mirrors:
|
||||
docker.io:
|
||||
mycustomreg.com:
|
||||
endpoint:
|
||||
- "https://mycustomreg.com:5000"
|
||||
```
|
||||
@@ -41,6 +41,7 @@ Directive | Description
|
||||
`cert_file` | The client certificate path that will be used to authenticate with the registry
|
||||
`key_file` | The client key path that will be used to authenticate with the registry
|
||||
`ca_file` | Defines the CA certificate path to be used to verify the registry's server cert file
|
||||
`insecure_skip_verify` | Boolean that defines if TLS verification should be skipped for the registry
|
||||
|
||||
The credentials consist of either username/password or authentication token:
|
||||
|
||||
|
||||
@@ -3,21 +3,27 @@ title: "Networking"
|
||||
weight: 35
|
||||
---
|
||||
|
||||
>**Note:** CNI options are covered in detail on the [Installation Network Options]({{<baseurl>}}/k3s/latest/en/installation/network-options/) page. Please reference that page for details on Flannel and the various flannel backend options or how to set up your own CNI.
|
||||
This page explains how CoreDNS, the Traefik Ingress controller, and Klipper service load balancer work within K3s.
|
||||
|
||||
Open Ports
|
||||
----------
|
||||
Please reference the [Installation Requirements]({{<baseurl>}}/k3s/latest/en/installation/installation-requirements/#networking) page for port information.
|
||||
Refer to the [Installation Network Options]({{<baseurl>}}/k3s/latest/en/installation/network-options/) page for details on Flannel configuration options and backend selection, or how to set up your own CNI.
|
||||
|
||||
CoreDNS
|
||||
-------
|
||||
For information on which ports need to be opened for K3s, refer to the [Installation Requirements.]({{<baseurl>}}/k3s/latest/en/installation/installation-requirements/#networking)
|
||||
|
||||
- [CoreDNS](#coredns)
|
||||
- [Traefik Ingress Controller](#traefik-ingress-controller)
|
||||
- [Service Load Balancer](#service-load-balancer)
|
||||
- [How the Service LB Works](#how-the-service-lb-works)
|
||||
- [Usage](#usage)
|
||||
- [Excluding the Service LB from Nodes](#excluding-the-service-lb-from-nodes)
|
||||
- [Disabling the Service LB](#disabling-the-service-lb)
|
||||
|
||||
# CoreDNS
|
||||
|
||||
CoreDNS is deployed on start of the agent. To disable, run each server with the `--disable coredns` option.
|
||||
|
||||
If you don't install CoreDNS, you will need to install a cluster DNS provider yourself.
|
||||
|
||||
Traefik Ingress Controller
|
||||
--------------------------
|
||||
# Traefik Ingress Controller
|
||||
|
||||
[Traefik](https://traefik.io/) is a modern HTTP reverse proxy and load balancer made to deploy microservices with ease. It simplifies networking complexity while designing, deploying, and running applications.
|
||||
|
||||
@@ -25,15 +31,59 @@ Traefik is deployed by default when starting the server. For more information se
|
||||
|
||||
The Traefik ingress controller will use ports 80, 443, and 8080 on the host (i.e. these will not be usable for HostPort or NodePort).
|
||||
|
||||
You can tweak traefik to meet your needs by setting options in the traefik.yaml file. Refer to the official [Traefik for Helm Configuration Parameters](https://github.com/helm/charts/tree/master/stable/traefik#configuration) readme for more information.
|
||||
Traefik can be configured by editing the `traefik.yaml` file. To prevent k3s from using or overwriting the modified version, deploy k3s with `--no-deploy traefik` and store the modified copy in the `k3s/server/manifests` directory. For more information, refer to the official [Traefik for Helm Configuration Parameters.](https://github.com/helm/charts/tree/master/stable/traefik#configuration)
|
||||
|
||||
To disable it, start each server with the `--disable traefik` option.
|
||||
|
||||
Service Load Balancer
|
||||
---------------------
|
||||
# Service Load Balancer
|
||||
|
||||
K3s includes a basic service load balancer that uses available host ports. If you try to create a load balancer that listens on port 80, for example, it will try to find a free host in the cluster for port 80. If no port is available, the load balancer will stay in Pending.
|
||||
Any service load balancer (LB) can be leveraged in your Kubernetes cluster. K3s provides a load balancer known as [Klipper Load Balancer](https://github.com/rancher/klipper-lb) that uses available host ports.
|
||||
|
||||
Upstream Kubernetes allows a Service of type LoadBalancer to be created, but doesn't include the implementation of the LB. Some LB services require a cloud provider such as Amazon EC2 or Microsoft Azure. By contrast, the K3s service LB makes it possible to use an LB service without a cloud provider.
|
||||
|
||||
### How the Service LB Works
|
||||
|
||||
K3s creates a controller that creates a Pod for the service load balancer, which is a Kubernetes object of kind [Service.](https://kubernetes.io/docs/concepts/services-networking/service/)
|
||||
|
||||
For each service load balancer, a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) is created. The DaemonSet creates a pod with the `svc` prefix on each node.
|
||||
|
||||
The Service LB controller listens for other Kubernetes Services. After it finds a Service, it creates a proxy Pod for the service using a DaemonSet on all of the nodes. This Pod becomes a proxy to the other Service, so that for example, requests coming to port 8000 on a node could be routed to your workload on port 8888.
|
||||
|
||||
If the Service LB runs on a node that has an external IP, it uses the external IP.
|
||||
|
||||
If multiple Services are created, a separate DaemonSet is created for each Service.
|
||||
|
||||
It is possible to run multiple Services on the same node, as long as they use different ports.
|
||||
|
||||
If you try to create a Service LB that listens on port 80, the Service LB will try to find a free host in the cluster for port 80. If no host with that port is available, the LB will stay in Pending.
|
||||
|
||||
### Usage
|
||||
|
||||
Create a [Service of type LoadBalancer](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer) in K3s.
|
||||
|
||||
### Excluding the Service LB from Nodes
|
||||
|
||||
To exclude nodes from using the Service LB, add the following label to the nodes that should not be excluded:
|
||||
|
||||
```
|
||||
svccontroller.k3s.cattle.io/enablelb
|
||||
```
|
||||
|
||||
If the label is used, the service load balancer only runs on the labeled nodes.
|
||||
|
||||
### Disabling the Service LB
|
||||
|
||||
<<<<<<< HEAD
|
||||
To disable it, start each server with the `--disable traefik` option.
|
||||
=======
|
||||
To disable the embedded LB, run the server with the `--disable servicelb` option.
|
||||
>>>>>>> 6d1d47358a30f3687e515ee9a5b4ce1c3afd9a33
|
||||
|
||||
This is necessary if you wish to run a different LB, such as MetalLB.
|
||||
|
||||
# Nodes Without a Hostname
|
||||
|
||||
<<<<<<< HEAD
|
||||
To disable the embedded load balancer, run the server with the `--disable servicelb` option. This is necessary if you wish to run a different load balancer, such as MetalLB.
|
||||
|
||||
Nodes Without a Hostname
|
||||
@@ -41,3 +91,6 @@ Nodes Without a Hostname
|
||||
|
||||
Some cloud providers, such as Linode, will create machines with "localhost" as the hostname and others may not have a hostname set at all. This can cause problems with domain name resolution. You can run K3s with the `--node-name` flag or `K3S_NODE_NAME` environment variable and this will pass the node name to resolve this issue.
|
||||
|
||||
=======
|
||||
Some cloud providers, such as Linode, will create machines with "localhost" as the hostname and others may not have a hostname set at all. This can cause problems with domain name resolution. You can run K3s with the `--node-name` flag or `K3S_NODE_NAME` environment variable and this will pass the node name to resolve this issue.
|
||||
>>>>>>> 6d1d47358a30f3687e515ee9a5b4ce1c3afd9a33
|
||||
|
||||
@@ -8,3 +8,5 @@ This section describes how to upgrade your K3s cluster.
|
||||
[Upgrade basics]({{< baseurl >}}/k3s/latest/en/upgrades/basic/) describes several techniques for upgrading your cluster manually. It can also be used as a basis for upgrading through third-party Infrastructure-as-Code tools like [Terraform](https://www.terraform.io/).
|
||||
|
||||
[Automated upgrades]({{< baseurl >}}/k3s/latest/en/upgrades/automated/) describes how to perform Kubernetes-native automated upgrades using Rancher's [system-upgrade-controller](https://github.com/rancher/system-upgrade-controller).
|
||||
|
||||
> The experimental embedded Dqlite data store was deprecated in K3s v1.19.1. Please note that upgrades from experimental Dqlite to experimental embedded etcd are not supported. If you attempt an upgrade it will not succeed and data will be lost.
|
||||
Reference in New Issue
Block a user