public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-25 12:38:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'jtravee-docs/master' into patch-1

Browse Source
This commit is contained in:
Jennifer Travinski
2022-01-11 15:44:17 +00:00
parent 2de9a165cb 1ac1490202
commit 9c4033967e
1142 changed files with 18092 additions and 44369 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+7 -2
View File
@@ -5,7 +5,7 @@ Rancher Docs
We have transitioned to versioned documentation for Rancher (files within `content/rancher`).
New contributions should be made to the applicable versioned directories (e.g. `content/rancher/v2.5` and `content/rancher/v2.0-v2.4`).
New contributions should be made to the applicable versioned directories (e.g., `content/rancher/v2.5` and `content/rancher/v2.0-v2.4`).
Contents under the `content/rancher/v2.x` directory are no longer maintained after v2.5.6.
@@ -23,7 +23,12 @@ Windows
./scripts/dev-windows.ps1
```
and then navigate to http://localhost:9001/. You can customize the port by passing it as an argument:
and then navigate to http://localhost:9001/. Click the link on the card associated with a given Rancher version to
access the documentation. For example, clicking on the link of the Rancher v2.5 card will redirect to
http://localhost:9001/rancher/v2.5/en/. Note that due to the way the Rancher website is built, links in the top
navigation panel will not work.
You can customize the port by passing it as an argument:
Linux
```bash
config.toml
+1 -1
View File
@@ -209,4 +209,4 @@ pre = "<i class='material-icons'>keyboard_arrow_down</i>"
[[menu.main]]
name = "Partners"
url = "https://rancher.com/partners/"
parent = "about"
parent = "about"
content/_index.html
+88
View File
@@ -91,6 +91,31 @@
<div class="row max-sized cards-container">
<div class="col-12 cards-wrap">
<div class="row center-xs card-items-wrap">
<!--2.6-->
<div class="
col-xl-4
col-lg-4
col-md-4
col-sm-12
col-xs-12
col-12
card-item">
<div class="card-wrap">
<h3 class="title-label">
<span class="background">2.6</span>
Rancher 2.6
</h3>
<hr/>
<p class="description-label">Rancher manages all of your Kubernetes clusters everywhere, unifies them under centralized RBAC, monitors them and lets you easily deploy and manage workloads through an intuitive user interface.</p>
<div class="buttons-container">
<a href="{{<baseurl>}}/rancher/v2.6/en/">Rancher v2.6</a>
</div>
</div>
</div>
<!--2.5-->
<div class="
col-xl-4
col-lg-4
@@ -114,6 +139,7 @@
</div>
</div>
</div>
<!--2.0-->
<div class="
col-xl-4
col-lg-4
@@ -137,6 +163,7 @@
</div>
</div>
</div>
<!--1.6-->
<div class="
col-xl-4
col-lg-4
@@ -164,6 +191,7 @@
</div>
</div>
</div>
<!--rancher os-->
<div class="
col-xl-4
col-lg-4
@@ -191,6 +219,7 @@
</div>
</div>
</div>
<!--rke-->
<div class="
col-xl-4
col-lg-4
@@ -218,6 +247,7 @@
</div>
</div>
</div>
<!--k3s-->
<div class="
col-xl-4
col-lg-4
@@ -245,6 +275,64 @@
</div>
</div>
</div>
<!--rke2-->
<div class="
col-xl-4
col-lg-4
col-md-4
col-sm-12
col-xs-12
col-12
card-item">
<div class="card-wrap">
<h3 class="title-label">
<span class="background">RKE2</span>
RKE2
</h3>
<hr />
<p class="description-label">RKE2, also known as RKE Government, is Rancher's next-generation Kubernetes distribution.</p>
<div class="buttons-container">
<a href="https://docs.rke2.io/">
<button class="button text">
<span>Read the docs</span>
</button>
</a>
</div>
</div>
</div>
<!--longhorn-->
<div class="
col-xl-4
col-lg-4
col-md-4
col-sm-12
col-xs-12
col-12
card-item">
<div class="card-wrap">
<h3 class="title-label">
<span class="background">Longhorn</span>
Longhorn
</h3>
<hr />
<p class="description-label">Longhorn is a lightweight, reliable, and powerful distributed block storage system for Kubernetes.</p>
<div class="buttons-container">
<a href="https://longhorn.io/docs/">
<button class="button text">
<span>Read the docs</span>
</button>
</a>
</div>
</div>
</div>
</div>
</div>
</div>
content/k3s/latest/en/advanced/_index.md
+138 -60
View File
@@ -11,9 +11,9 @@ This section contains advanced information describing the different ways you can
- [Certificate rotation](#certificate-rotation)
- [Auto-deploying manifests](#auto-deploying-manifests)
- [Using Docker as the container runtime](#using-docker-as-the-container-runtime)
- [Using etcdctl](#using-etcdctl)
- [Configuring containerd](#configuring-containerd)
- [Secrets Encryption Config (Experimental)](#secrets-encryption-config-experimental)
- [Running K3s with RootlessKit (Experimental)](#running-k3s-with-rootlesskit-experimental)
- [Running K3s with Rootless mode (Experimental)](#running-k3s-with-rootless-mode-experimental)
- [Node labels and taints](#node-labels-and-taints)
- [Starting the server with the installation script](#starting-the-server-with-the-installation-script)
- [Additional preparation for Alpine Linux setup](#additional-preparation-for-alpine-linux-setup)
@@ -22,6 +22,9 @@ This section contains advanced information describing the different ways you can
- [Enabling cgroups for Raspbian Buster](#enabling-cgroups-for-raspbian-buster)
- [SELinux Support](#selinux-support)
- [Additional preparation for (Red Hat/CentOS) Enterprise Linux](#additional-preparation-for-red-hat-centos-enterprise-linux)
- [Enabling Lazy Pulling of eStargz (Experimental)](#enabling-lazy-pulling-of-estargz-experimental)
- [Additional Logging Sources](#additional-logging-sources)
- [Server and agent tokens](#server-and-agent-tokens)
# Certificate Rotation
@@ -31,7 +34,7 @@ If the certificates are expired or have fewer than 90 days remaining before they
# Auto-Deploying Manifests
Any file found in `/var/lib/rancher/k3s/server/manifests` will automatically be deployed to Kubernetes in a manner similar to `kubectl apply`.
Any file found in `/var/lib/rancher/k3s/server/manifests` will automatically be deployed to Kubernetes in a manner similar to `kubectl apply`, both on startup and when the file is changed on disk. Deleting files out of this directory will not delete the corresponding resources from the cluster.
For information about deploying Helm charts, refer to the section about [Helm.](../helm)
@@ -116,6 +119,24 @@ rancher/metrics-server v0.3.6 9dd718864ce61 39.9MB
rancher/pause 3.1 da86e6ba6ca19 742kB
```
# Using etcdctl
etcdctl provides a CLI for etcd.
If you would like to use etcdctl after installing K3s with embedded etcd, install etcdctl using the [official documentation.](https://etcd.io/docs/latest/install/)
```
$ VERSION="v3.5.0"
$ curl -L https://github.com/etcd-io/etcd/releases/download/${VERSION}/etcd-${VERSION}-linux-amd64.tar.gz --output etcdctl-linux-amd64.tar.gz
$ sudo tar -zxvf etcdctl-linux-amd64.tar.gz --strip-components=1 -C /usr/local/bin etcd-${VERSION}-linux-amd64/etcdctl
```
Then start using etcdctl commands with the appropriate K3s flags:
```
$ sudo etcdctl --cacert=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --cert=/var/lib/rancher/k3s/server/tls/etcd/client.crt --key=/var/lib/rancher/k3s/server/tls/etcd/client.key version
```
# Configuring containerd
K3s will generate config.toml for containerd in `/var/lib/rancher/k3s/agent/etc/containerd/config.toml`.
@@ -124,57 +145,16 @@ For advanced customization for this file you can create another file called `con
The `config.toml.tmpl` will be treated as a Go template file, and the `config.Node` structure is being passed to the template. [This template](https://github.com/rancher/k3s/blob/master/pkg/agent/templates/templates.go#L16-L32) example on how to use the structure to customize the configuration file.
# Secrets Encryption Config (Experimental)
As of v1.17.4+k3s1, K3s added the experimental feature of enabling secrets encryption at rest by passing the flag `--secrets-encryption` on a server, this flag will do the following automatically:
- Generate an AES-CBC key
- Generate an encryption config file with the generated key
```
{
"kind": "EncryptionConfiguration",
"apiVersion": "apiserver.config.k8s.io/v1",
"resources": [
{
"resources": [
"secrets"
],
"providers": [
{
"aescbc": {
"keys": [
{
"name": "aescbckey",
"secret": "xxxxxxxxxxxxxxxxxxx"
}
]
}
},
{
"identity": {}
}
]
}
]
}
```
- Pass the config to the KubeAPI as encryption-provider-config
Once enabled any created secret will be encrypted with this key. Note that if you disable encryption then any encrypted secrets will not be readable until you enable encryption again.
# Running K3s with RootlessKit (Experimental)
# Running K3s with Rootless mode (Experimental)
> **Warning:** This feature is experimental.
RootlessKit is a kind of Linux-native "fake root" utility, made for mainly [running Docker and Kubernetes as an unprivileged user,](https://github.com/rootless-containers/usernetes) so as to protect the real root on the host from potential container-breakout attacks.
Rootless mode allows running the entire k3s an unprivileged user, so as to protect the real root on the host from potential container-breakout attacks.
Initial rootless support has been added but there are a series of significant usability issues surrounding it.
See also https://rootlesscontaine.rs/ to learn about Rootless mode.
We are releasing the initial support for those interested in rootless and hopefully some people can help to improve the usability. First, ensure you have a proper setup and support for user namespaces. Refer to the [requirements section](https://github.com/rootless-containers/rootlesskit#setup) in RootlessKit for instructions.
In short, latest Ubuntu is your best bet for this to work.
### Known Issues with RootlessKit
### Known Issues with Rootless mode
* **Ports**
@@ -184,24 +164,41 @@ In short, latest Ubuntu is your best bet for this to work.
Currently, only `LoadBalancer` services are automatically bound.
* **Daemon lifecycle**
Once you kill K3s and then start a new instance of K3s it will create a new network namespace, but it doesn't kill the old pods. So you are left
with a fairly broken setup. This is the main issue at the moment, how to deal with the network namespace.
The issue is tracked in https://github.com/rootless-containers/rootlesskit/issues/65
* **Cgroups**
Cgroups are not supported.
Cgroup v1 is not supported. v2 is supported.
* **Multi-node cluster**
Multi-cluster installation is untested and undocumented.
### Running Servers and Agents with Rootless
* Enable cgroup v2 delegation, see https://rootlesscontaine.rs/getting-started/common/cgroup2/ .
This step is optional, but highly recommended for enabling CPU and memory resource limtitation.
Just add `--rootless` flag to either server or agent. So run `k3s server --rootless` and then look for the message `Wrote kubeconfig [SOME PATH]` for where your kubeconfig file is.
* Download `k3s-rootless.service` from [`https://github.com/k3s-io/k3s/blob/<VERSION>/k3s-rootless.service`](https://github.com/k3s-io/k3s/blob/master/k3s-rootless.service).
Make sure to use the same version of `k3s-rootless.service` and `k3s`.
For more information about setting up the kubeconfig file, refer to the [section about cluster access.](../cluster-access)
* Install `k3s-rootless.service` to `~/.config/systemd/user/k3s-rootless.service`.
Installing this file as a system-wide service (`/etc/systemd/...`) is not supported.
Depending on the path of `k3s` binary, you might need to modify the `ExecStart=/usr/local/bin/k3s ...` line of the file.
> Be careful, if you use `-o` to write the kubeconfig to a different directory it will probably not work. This is because the K3s instance in running in a different mount namespace.
* Run `systemctl --user daemon-reload`
* Run `systemctl --user enable --now k3s-rootless`
* Run `KUBECONFIG=~/.kube/k3s.yaml kubectl get pods -A`, and make sure the pods are running.
> **Note:** Don't try to run `k3s server --rootless` on a terminal, as it doesn't enable cgroup v2 delegation.
> If you really need to try it on a terminal, prepend `systemd-run --user -p Delegate=yes --tty` to create a systemd scope.
>
> i.e., `systemd-run --user -p Delegate=yes --tty k3s server --rootless`
### Troubleshooting
* Run `systemctl --user status k3s-rootless` to check the daemon status
* Run `journalctl --user -f -u k3s-rootless` to see the daemon log
* See also https://rootlesscontaine.rs/
# Node Labels and Taints
@@ -310,7 +307,7 @@ sudo reboot
Standard Raspbian Buster installations do not start with `cgroups` enabled. **K3S** needs `cgroups` to start the systemd service. `cgroups`can be enabled by appending `cgroup_memory=1 cgroup_enable=memory` to `/boot/cmdline.txt`.
## example of /boot/cmdline.txt
### example of /boot/cmdline.txt
```
console=serial0,115200 console=tty1 root=PARTUUID=58b06195-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait cgroup_memory=1 cgroup_enable=memory
```
@@ -374,3 +371,84 @@ It is recommended to turn off firewalld:
```
systemctl disable firewalld --now
```
If enabled, it is required to disable nm-cloud-setup and reboot the node:
```
systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
reboot
```
# Enabling Lazy Pulling of eStargz (Experimental)
### What's lazy pulling and eStargz?
Pulling images is known as one of the time-consuming steps in the container lifecycle.
According to [Harter, et al.](https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter),
> pulling packages accounts for 76% of container start time, but only 6.4% of that data is read
To address this issue, k3s experimentally supports *lazy pulling* of image contents.
This allows k3s to start a container before the entire image has been pulled.
Instead, the necessary chunks of contents (e.g. individual files) are fetched on-demand.
Especially for large images, this technique can shorten the container startup latency.
To enable lazy pulling, the target image needs to be formatted as [*eStargz*](https://github.com/containerd/stargz-snapshotter/blob/main/docs/stargz-estargz.md).
This is an OCI-alternative but 100% OCI-compatible image format for lazy pulling.
Because of the compatibility, eStargz can be pushed to standard container registries (e.g. ghcr.io) as well as this is *still runnable* even on eStargz-agnostic runtimes.
eStargz is developed based on the [stargz format proposed by Google CRFS project](https://github.com/google/crfs) but comes with practical features including content verification and performance optimization.
For more details about lazy pulling and eStargz, please refer to [Stargz Snapshotter project repository](https://github.com/containerd/stargz-snapshotter).
### Configure k3s for lazy pulling of eStargz
As shown in the following, `--snapshotter=stargz` option is needed for k3s server and agent.
```
k3s server --snapshotter=stargz
```
With this configuration, you can perform lazy pulling for eStargz-formatted images.
The following Pod manifest uses eStargz-formatted `node:13.13.0` image (`ghcr.io/stargz-containers/node:13.13.0-esgz`).
k3s performs lazy pulling for this image.
```
apiVersion: v1
kind: Pod
metadata:
name: nodejs
spec:
containers:
- name: nodejs-estargz
image: ghcr.io/stargz-containers/node:13.13.0-esgz
command: ["node"]
args:
- -e
- var http = require('http');
http.createServer(function(req, res) {
res.writeHead(200);
res.end('Hello World!\n');
}).listen(80);
ports:
- containerPort: 80
```
# Additional Logging Sources
[Rancher logging]({{<baseurl>}}//rancher/v2.6/en/logging/helm-chart-options/) for K3s can be installed without using Rancher. The following instructions should be executed to do so:
```
helm repo add rancher-charts https://charts.rancher.io
helm repo update
helm install --create-namespace -n cattle-logging-system rancher-logging-crd rancher-charts/rancher-logging-crd
helm install --create-namespace -n cattle-logging-system rancher-logging --set additionalLoggingSources.k3s.enabled=true rancher-charts/rancher-logging
```
# Server and agent tokens
In K3s, there are two types of tokens: K3S_TOKEN and K3S_AGENT_TOKEN.
K3S_TOKEN: Defines the key required by the server to offer the HTTP config resources. These resources are requested by the other servers before joining the K3s HA cluster. If the K3S_AGENT_TOKEN is not defined, the agents use this token as well to access the required HTTP resources to join the cluster. Note that this token is also used to generate the encryption key for important content in the database (e.g., bootstrap data).
K3S_AGENT_TOKEN: Optional. Defines the key required by the server to offer HTTP config resources to the agents. If not defined, agents will require K3S_TOKEN. Defining K3S_AGENT_TOKEN is encouraged to avoid agents having to know K3S_TOKEN, which is also used to encrypt data.
If no K3S_TOKEN is defined, the first K3s server will generate a random one. The result is part of the content in `/var/lib/rancher/k3s/server/token`. For example, `K1070878408e06a827960208f84ed18b65fa10f27864e71a57d9e053c4caff8504b::server:df54383b5659b9280aa1e73e60ef78fc`, where `df54383b5659b9280aa1e73e60ef78fc` is the K3S_TOKEN.
content/k3s/latest/en/backup-restore/_index.md
+43 -3
View File
@@ -18,7 +18,7 @@ For details on taking database snapshots and restoring your database from them,
- [Official MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/replication-snapshot-method.html)
- [Official PostgreSQL documentation](https://www.postgresql.org/docs/8.3/backup-dump.html)
- [Official etcd documentation](https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/recovery.md)
- [Official etcd documentation](https://etcd.io/docs/latest/op-guide/recovery/)
# Backup and Restore with Embedded etcd Datastore (Experimental)
@@ -26,17 +26,19 @@ _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.
>**Note on Single-Server with embedded SQLite:** Currently, backups of SQLite are not supported. Instead, make a copy of `/var/lib/rancher/k3s/server` and then delete K3s.
### Creating Snapshots
Snapshots are enabled by default.
The snapshot directory defaults to `/server/db/snapshots`.
The snapshot directory defaults to `${data-dir}/server/db/snapshots`. The data-dir value defaults to `/var/lib/rancher/k3s` and can be changed by setting the `--data-dir` flag.
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.
When K3s is restored from backup, the old data directory will be moved to `${data-dir}/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:
@@ -101,3 +103,41 @@ k3s server \
--etcd-s3-access-key=<S3-ACCESS-KEY> \
--etcd-s3-secret-key=<S3-SECRET-KEY>
```
### Etcd Snapshot and Restore Subcommands
k3s supports a set of subcommands for working with your etcd snapshots.
| Subcommand | Description |
| ----------- | --------------- |
| delete | Delete given snapshot(s) |
| ls, list, l | List snapshots |
| prune | Remove snapshots that exceed the configured retention count |
| save | Trigger an immediate etcd snapshot |
*note* The `save` subcommand is the same as `k3s etcd-snapshot`. The latter will eventually be deprecated in favor of the former.
These commands will perform as expected whether the etcd snapshots are stored locally or in an S3 compatible object store.
For additional information on the etcd snapshot subcommands, run `k3s etcd-snapshot`.
Delete a snapshot from S3.
```
k3s etcd-snapshot delete \
--s3 \
--s3-bucket=<S3-BUCKET-NAME> \
--s3-access-key=<S3-ACCESS-KEY> \
--s3-secret-key=<S3-SECRET-KEY> \
<SNAPSHOT-NAME>
```
Prune local snapshots with the default retention policy (5). The `prune` subcommand takes an additional flag `--snapshot-retention` that allows for overriding the default retention policy.
```
k3s etcd-snapshot prune
```
```
k3s etcd-snapshot prune --snapshot-retention 10
```
content/k3s/latest/en/helm/_index.md
+14
View File
@@ -66,6 +66,20 @@ spec:
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`.
**Note:** The `name` field should follow the Helm chart naming conventions. Refer [here](https://helm.sh/docs/chart_best_practices/conventions/#chart-names) to learn more.
>**Notice on File Naming Requirements:** `HelmChart` and `HelmChartConfig` manifest filenames should adhere to Kubernetes object [naming restrictions](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/). The Helm Controller uses filenames to create objects; therefore, the filename must also align with the restrictions. Any related errors can be observed in the rke2-server logs. The example below is an error generated from using underscores:
```
level=error msg="Failed to process config: failed to process
/var/lib/rancher/rke2/server/manifests/rke2_ingress_daemonset.yaml:
Addon.k3s.cattle.io \"rke2_ingress_daemonset\" is invalid: metadata.name:
Invalid value: \"rke2_ingress_daemonset\": a lowercase RFC 1123 subdomain
must consist of lower case alphanumeric characters, '-' or '.', and must
start and end with an alphanumeric character (e.g. 'example.com', regex
used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]
([-a-z0-9]*[a-z0-9])?)*')"
```
### 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.
content/k3s/latest/en/installation/airgap/_index.md
+11 -10
View File
@@ -3,7 +3,7 @@ title: "Air-Gap Install"
weight: 60
---
You can install K3s in an air-gapped environment using two different methods. You can either deploy a private registry and mirror docker.io or you can manually deploy images such as for small clusters.
You can install K3s in an air-gapped environment using two different methods. An air-gapped environment is any environment that is not directly connected to the Internet. You can either deploy a private registry and mirror docker.io, or you can manually deploy images such as for small clusters.
# Private Registry Method
@@ -39,22 +39,23 @@ Follow the steps in the next section to install K3s.
# Install K3s
Only after you have completed either the [Private Registry Method](#private-registry-method) or the [Manually Deploy Images Method](#manually-deploy-images-method) above should you install K3s.
### Prerequisites
Obtain the K3s binary from the [releases](https://github.com/rancher/k3s/releases) page, matching the same version used to get the airgap images.
Obtain the K3s install script at https://get.k3s.io
- Before installing K3s, complete the the [Private Registry Method](#private-registry-method) or the [Manually Deploy Images Method](#manually-deploy-images-method) above to prepopulate the images that K3s needs to install.
- Download the K3s binary from the [releases](https://github.com/rancher/k3s/releases) page, matching the same version used to get the airgap images. Place the binary in `/usr/local/bin` on each air-gapped node and ensure it is executable.
- Download the K3s install script at https://get.k3s.io. Place the install script anywhere on each air-gapped node, and name it `install.sh`.
Place the binary in `/usr/local/bin` on each node and ensure it is executable.
Place the install script anywhere on each node, and name it `install.sh`.
When running the K3s script with the `INSTALL_K3S_SKIP_DOWNLOAD` environment variable, K3s will use the local version of the script and binary.
### Install Options
### Installing K3s in an Air-Gapped Environment
You can install K3s on one or more servers as described below.
{{% tabs %}}
{{% tab "Single Server Configuration" %}}
To install K3s on a single server simply do the following on the server node.
To install K3s on a single server, simply do the following on the server node:
```
INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh
@@ -75,13 +76,13 @@ For example, step two of the High Availability with an External DB guide mention
```
curl -sfL https://get.k3s.io | sh -s - server \
--datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"
--datastore-endpoint='mysql://username:password@tcp(hostname:3306)/database-name'
```
Instead, you would modify such examples like below:
```
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_EXEC='server --datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"' ./install.sh
INSTALL_K3S_SKIP_DOWNLOAD=true INSTALL_K3S_EXEC='server' K3S_DATASTORE_ENDPOINT='mysql://username:password@tcp(hostname:3306)/database-name' ./install.sh
```
{{% /tab %}}
content/k3s/latest/en/installation/datastore/_index.md
+2 -2
View File
@@ -23,7 +23,7 @@ If you wish to use an external datastore such as PostgreSQL, MySQL, or etcd you
CLI Flag | Environment Variable | Description
------------|-------------|------------------
<span style="white-space: nowrap">`--datastore-endpoint`</span> | `K3S_DATASTORE_ENDPOINT` | Specify a PostgresSQL, MySQL, or etcd connection string. This is a string used to describe the connection to the datastore. The structure of this string is specific to each backend and is detailed below.
<span style="white-space: nowrap">`--datastore-endpoint`</span> | `K3S_DATASTORE_ENDPOINT` | Specify a PostgreSQL, MySQL, or etcd connection string. This is a string used to describe the connection to the datastore. The structure of this string is specific to each backend and is detailed below.
<span style="white-space: nowrap">`--datastore-cafile`</span> | `K3S_DATASTORE_CAFILE` | TLS Certificate Authority (CA) file used to help secure communication with the datastore. If your datastore serves requests over TLS using a certificate signed by a custom certificate authority, you can specify that CA using this parameter so that the K3s client can properly verify the certificate. |
| <span style="white-space: nowrap">`--datastore-certfile`</span> | `K3S_DATASTORE_CERTFILE` | TLS certificate file used for client certificate based authentication to your datastore. To use this feature, your datastore must be configured to support client certificate based authentication. If you specify this parameter, you must also specify the `datastore-keyfile` parameter. |
| <span style="white-space: nowrap">`--datastore-keyfile`</span> | `K3S_DATASTORE_KEYFILE` | TLS key file used for client certificate based authentication to your datastore. See the previous `datastore-certfile` parameter for more details. |
@@ -81,7 +81,7 @@ The above assumes a typical three node etcd cluster. The parameter can accept on
{{% /tab %}}
{{% /tabs %}}
<br/>Based on the above, the following example command could be used to launch a server instance that connects to a PostgresSQL database named k3s:
<br/>Based on the above, the following example command could be used to launch a server instance that connects to a PostgreSQL database named k3s:
```
K3S_DATASTORE_ENDPOINT='postgres://username:password@hostname:5432/k3s' k3s server
```
content/k3s/latest/en/installation/disable-flags/_index.md
+23 -8
View File
@@ -3,16 +3,16 @@ title: "Disable Components Flags"
weight: 60
---
When starting K3s server with --cluster-init it will run all control plane components that includes (api server, controller manager, scheduler, and etcd). However you can run server nodes with certain components and execlude others, the following sectiohs will explain how to do that.
When starting K3s server with --cluster-init it will run all control plane components that includes (api server, controller manager, scheduler, and etcd). However you can run server nodes with certain components and execlude others, the following sections will explain how to do that.
# ETCD Only Nodes
This document assumes you run K3s server with embedded etcd by passing `--cluster-init` flag to the server process.
To run a K3s server with only etcd components you can pass `--disable-api-server --disable-controller-manager --disable-scheduler` flags to k3s, this will result in running a server node with only etcd, for example to run K3s server with those flags:
To run a K3s server with only etcd components you can pass `--disable-apiserver --disable-controller-manager --disable-scheduler` flags to k3s, this will result in running a server node with only etcd, for example to run K3s server with those flags:
```
curl -fL https://get.k3s.io | sh -s - server --cluster-init --disable-api-server --disable-controller-manager --disable-scheduler
curl -fL https://get.k3s.io | sh -s - server --cluster-init --disable-apiserver --disable-controller-manager --disable-scheduler
```
You can join other nodes to the cluster normally after that.
@@ -34,12 +34,12 @@ ip-172-31-13-32 Ready etcd 5h39m v1.20.4+k3s1
ip-172-31-14-69 Ready control-plane,master 5h39m v1.20.4+k3s1
```
Note that you can run `kubectl` commands only on the k3s server that has the api running, and you cant run `kubectl` commands on etcd only nodes.
Note that you can run `kubectl` commands only on the k3s server that has the api running, and you can't run `kubectl` commands on etcd only nodes.
### Re-enabling control components
In both cases you can re-enable any component that you already disabled simply by removing the corresponding flag that disables them, so for example if you want to revert the etcd only node back to a full k3s server with all components you can just remove the following 3 flags `--disable-api-server --disable-controller-manager --disable-scheduler`, so in our example to revert back node `ip-172-31-13-32` to a full k3s server you can just re-run the curl command without the disable flags:
In both cases you can re-enable any component that you already disabled simply by removing the corresponding flag that disables them, so for example if you want to revert the etcd only node back to a full k3s server with all components you can just remove the following 3 flags `--disable-apiserver --disable-controller-manager --disable-scheduler`, so in our example to revert back node `ip-172-31-13-32` to a full k3s server you can just re-run the curl command without the disable flags:
```
curl -fL https://get.k3s.io | sh -s - server --cluster-init
```
@@ -57,11 +57,11 @@ Notice that role labels has been re-added to the node `ip-172-31-13-32` with the
# Add disable flags using the config file
In any of the previous situation you can use the config file instead of running the curl commands with the associated flags, for example to run an etcd only node you can add the following options to the `/etc/rancher/k3s/config.yaml` file:
In any of the previous situations you can use the config file instead of running the curl commands with the associated flags, for example to run an etcd only node you can add the following options to the `/etc/rancher/k3s/config.yaml` file:
```
---
disable-api-server: true
disable-apiserver: true
disable-controller-manager: true
disable-scheduler: true
cluster-init: true
@@ -70,4 +70,19 @@ and then start K3s using the curl command without any arguents:
```
curl -fL https://get.k3s.io | sh -
```
```
# Disable components using .skip files
For any yaml file under `/var/lib/rancher/k3s/server/manifests` (coredns, traefik, local-storeage, etc.) you can add a `.skip` file which will cause K3s to not apply the associated yaml file.
For example, adding `traefik.yaml.skip` in the manifests directory will cause K3s to skip `traefik.yaml`.
```
ls /var/lib/rancher/k3s/server/manifests
ccm.yaml local-storage.yaml rolebindings.yaml traefik.yaml.skip
coredns.yaml traefik.yaml
kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system local-path-provisioner-64ffb68fd-xx98j 1/1 Running 0 74s
kube-system metrics-server-5489f84d5d-7zwkt 1/1 Running 0 74s
kube-system coredns-85cb69466-vcq7j 1/1 Running 0 74s
```
content/k3s/latest/en/installation/ha-embedded/_index.md
+9
View File
@@ -7,6 +7,9 @@ weight: 40
K3s has added full support for embedded etcd as of release v1.19.5+k3s1. Versions v1.19.1 thru v1.19.4 provide only experimental support for embedded etcd.
Embedded etcd replaced experimental Dqlite in the K3s v1.19.1 release. This is a breaking change. Please note that upgrades from experimental Dqlite to embedded etcd are not supported. If you attempt an upgrade it will not succeed and data will be lost.
>**Warning:**
Embedded etcd (HA) may have performance issues on slower disks such as Raspberry Pis running with SD cards.
To run K3s in this mode, you must have an odd number of server nodes. We recommend starting with three nodes.
To get started, first launch a server node with the `cluster-init` flag to enable clustering and a token that will be used as a shared secret to join additional servers to the cluster.
@@ -20,3 +23,9 @@ 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.
There are a few config flags that must be the same in all server nodes:
* Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
* Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
* Feature related flags: `--secrets-encryption`
content/k3s/latest/en/installation/ha/_index.md
+31 -5
View File
@@ -33,12 +33,13 @@ You will first need to create an external datastore for the cluster. See the [Cl
### 2. Launch Server Nodes
K3s requires two or more server nodes for this HA configuration. See the [Installation Requirements]({{<baseurl>}}/k3s/latest/en/installation/installation-requirements/) guide for minimum machine requirements.
When running the `k3s server` command on these nodes, you must set the `datastore-endpoint` parameter so that K3s knows how to connect to the external datastore.
When running the `k3s server` command on these nodes, you must set the `datastore-endpoint` parameter so that K3s knows how to connect to the external datastore. The `token` parameter can also be used to set a deterministic token when adding nodes. When empty, this token will be generated automatically for further use.
For example, a command like the following could be used to install the K3s server with a MySQL database as the external datastore:
For example, a command like the following could be used to install the K3s server with a MySQL database as the external datastore and [set a token]({{<baseurl>}}/k3s/latest/en/installation/install-options/server-config/#cluster-options}}):
```
```bash
curl -sfL https://get.k3s.io | sh -s - server \
--token=SECRET \
--datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"
```
@@ -62,12 +63,37 @@ Agent nodes need a URL to register against. This can be the IP or hostname of an
This endpoint can also be used for accessing the Kubernetes API. So you can, for example, modify your [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file to point to it instead of a specific node. To avoid certificate errors in such a configuration, you should install the server with the `--tls-san YOUR_IP_OR_HOSTNAME_HERE` option. This option adds an additional hostname or IP as a Subject Alternative Name in the TLS cert, and it can be specified multiple times if you would like to access via both the IP and the hostname.
### 4. Optional: Join Agent Nodes
### 4. Optional: Join Additional Server Nodes
The same example command in Step 2 can be used to join additional server nodes, where the token from the first node needs to be used.
If the first server node was started without the `--token` CLI flag or `K3S_TOKEN` variable, the token value can be retrieved from any server already joined to the cluster:
```bash
cat /var/lib/rancher/k3s/server/token
```
Additional server nodes can then be added [using the token]({{<baseurl>}}/k3s/latest/en/installation/install-options/server-config/#cluster-options}}):
```bash
curl -sfL https://get.k3s.io | sh -s - server \
--token=SECRET \
--datastore-endpoint="mysql://username:password@tcp(hostname:3306)/database-name"
```
There are a few config flags that must be the same in all server nodes:
* Network related flags: `--cluster-dns`, `--cluster-domain`, `--cluster-cidr`, `--service-cidr`
* Flags controlling the deployment of certain components: `--disable-helm-controller`, `--disable-kube-proxy`, `--disable-network-policy` and any component passed to `--disable`
* Feature related flags: `--secrets-encryption`
> **Note:** Ensure that you retain a copy of this token as it is required when restoring from backup and adding nodes. Previously, K3s did not enforce the use of a token when using external SQL datastores.
### 5. Optional: Join Agent Nodes
Because K3s server nodes are schedulable by default, the minimum number of nodes for an HA K3s server cluster is two server nodes and zero agent nodes. To add nodes designated to run your apps and services, join agent nodes to your cluster.
Joining agent nodes in an HA cluster is the same as joining agent nodes in a single server cluster. You just need to specify the URL the agent should register to and the token it should use.
```
```bash
K3S_TOKEN=SECRET k3s agent --server https://fixed-registration-address:6443
```
content/k3s/latest/en/installation/install-options/_index.md
+6 -1
View File
@@ -46,6 +46,11 @@ When using this method to install K3s, the following environment variables can b
| `INSTALL_K3S_CHANNEL_URL` | Channel URL for fetching K3s download URL. Defaults to https://update.k3s.io/v1-release/channels. |
| `INSTALL_K3S_CHANNEL` | Channel to use for fetching K3s download URL. Defaults to "stable". Options include: `stable`, `latest`, `testing`. |
This example shows where to place aforementioned environment variables as options (after the pipe):
```
curl -sfL https://get.k3s.io | INSTALL_K3S_CHANNEL=latest sh -
```
Environment variables which begin with `K3S_` will be preserved for the systemd and openrc services to use.
@@ -53,7 +58,7 @@ Setting `K3S_URL` without explicitly setting an exec command will default the co
When running the agent `K3S_TOKEN` must also be set.
# Installing K3s from the Binary
### Options for installation from binary
As stated, the installation script is primarily concerned with configuring K3s to run as a service. If you choose to not use the script, you can run K3s simply by downloading the binary from our [release page](https://github.com/rancher/k3s/releases/latest), placing it on your path, and executing it. The K3s binary supports the following commands:
content/k3s/latest/en/installation/install-options/how-to-flags/_index.md
+21 -6
View File
@@ -27,9 +27,24 @@ If this command is not specified as a server or agent command, it will default t
The final systemd command resolves to a combination of this environment variable and script args. To illustrate this, the following commands result in the same behavior of registering a server without flannel:
```bash
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--no-flannel" sh -s -
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --no-flannel" sh -s -
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --no-flannel
curl -sfL https://get.k3s.io | sh -s - server --no-flannel
curl -sfL https://get.k3s.io | sh -s - --no-flannel
```
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--flannel-backend none" sh -s -
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --flannel-backend none" sh -s -
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --flannel-backend none
curl -sfL https://get.k3s.io | sh -s - server --flannel-backend none
curl -sfL https://get.k3s.io | sh -s - --flannel-backend none
```
### Example C: CONFIG FILE
Before installing k3s, you can create a file called `config.yaml` containing fields that match CLI flags. That file needs to be in the path: `/etc/rancher/k3s/config.yaml` for k3s to consume it.
The fields in the config file drop the starting `--` from the matching CLI flag. For example:
```
write-kubeconfig-mode: 644
token: "secret"
node-ip: 10.0.10.22,2a05:d012:c6f:4655:d73c:c825:a184:1b75
cluster-cidr: 10.42.0.0/16,2001:cafe:42:0::/56
service-cidr: 10.43.0.0/16,2001:cafe:42:1::/112
disable-network-policy: true
```
content/k3s/latest/en/installation/install-options/server-config/_index.md
+52 -1
View File
@@ -39,6 +39,21 @@ In this section, you'll learn how to configure the K3s server.
| `--datastore-cafile` value | `K3S_DATASTORE_CAFILE` | TLS Certificate Authority file used to secure datastore backend communication |
| `--datastore-certfile` value | `K3S_DATASTORE_CERTFILE` | TLS certification file used to secure datastore backend communication |
| `--datastore-keyfile` value | `K3S_DATASTORE_KEYFILE` | TLS key file used to secure datastore backend communication |
| `--etcd-expose-metrics` | N/A | Expose etcd metrics to client interface. (Default false) |
| `--etcd-disable-snapshots` | N/A | Disable automatic etcd snapshots |
| `--etcd-snapshot-name` value | N/A | Set the base name of etcd snapshots. Default: etcd-snapshot-<unix-timestamp> (default: "etcd-snapshot") |
| `--etcd-snapshot-schedule-cron` value | N/A | Snapshot interval time in cron spec. eg. every 5 hours '* */5 * * *' (default: "0 */12 * * *") |
| `--etcd-snapshot-retention` value | N/A | Number of snapshots to retain (Default: 5) |
| `--etcd-snapshot-dir` value | N/A | Directory to save db snapshots. (Default location: ${data-dir}/db/snapshots) |
| `--etcd-s3` | N/A | Enable backup to S3 |
| `--etcd-s3-endpoint` value | N/A | S3 endpoint url (default: "s3.amazonaws.com") |
| `--etcd-s3-endpoint-ca` value | N/A | S3 custom CA cert to connect to S3 endpoint |
| `--etcd-s3-skip-ssl-verify` | N/A | Disables S3 SSL certificate validation |
| `--etcd-s3-access-key` value | `AWS_ACCESS_KEY_ID` | S3 access key |
| `--etcd-s3-secret-key` value | `AWS_SECRET_ACCESS_KEY` | S3 secret key |
| `--etcd-s3-bucket` value | N/A | S3 bucket name |
| `--etcd-s3-region` value | N/A | S3 region / bucket location (optional) (default: "us-east-1") |
| `--etcd-s3-folder` value | N/A | S3 folder |
### Cluster Options
@@ -66,6 +81,10 @@ K3s agent options are available as server options because the server has the age
| `--with-node-id` | N/A | Append id to node name | (agent/node)
| `--node-label` value | N/A | Registering and starting kubelet with set of labels |
| `--node-taint` value | N/A | Registering kubelet with set of taints |
| `--image-credential-provider-bin-dir` value | N/A | The path to the directory where credential provider plugin binaries are located (default: "/var/lib/rancher/credentialprovider/bin") |
| `--image-credential-provider-config` value | N/A | The path to the credential provider plugin config file (default: "/var/lib/rancher/credentialprovider/config.yaml") |
| `--selinux` | `K3S_SELINUX` | Enable SELinux in containerd |
| `--lb-server-port` value | `K3S_LB_SERVER_PORT` | Local port for supervisor client load-balancer. If the supervisor and apiserver are not colocated an additional port 1 less than this port will also be used for the apiserver client load-balancer. (default: 6444) |
### Agent Runtime
@@ -74,6 +93,7 @@ K3s agent options are available as server options because the server has the age
| `--docker` | N/A | Use docker instead of containerd | (agent/runtime)
| `--container-runtime-endpoint` value | N/A | Disable embedded containerd and use alternative CRI implementation |
| `--pause-image` value | "docker.io/rancher/pause:3.1" | Customized pause image for containerd or Docker sandbox |
| `--snapshotter` value | N/A | Override default containerd snapshotter (default: "overlayfs") |
| `--private-registry` value | "/etc/rancher/k3s/registries.yaml" | Private registry configuration file |
### Agent Networking
@@ -94,6 +114,7 @@ the agent options are there because the server has the agent process embedded wi
| Flag | Default | Description |
|------|---------|-------------|
| `--debug` | N/A | Turn on debug logs |
| `-v` value | 0 | Number for the log level verbosity |
| `--vmodule` value | N/A | Comma-separated list of pattern=N settings for file-filtered logging |
| `--log value, -l` value | N/A | Log to file |
@@ -122,6 +143,7 @@ the agent options are there because the server has the agent process embedded wi
|------|---------|-------------|
| `--cluster-cidr` value | "10.42.0.0/16" | Network CIDR to use for pod IPs |
| `--service-cidr` value | "10.43.0.0/16" | Network CIDR to use for services IPs |
| `--service-node-port-range` value | "30000-32767" | Port range to reserve for services with NodePort visibility |
| `--cluster-dns` value | "10.43.0.10" | Cluster IP for coredns service. Should be in your service-cidr range |
| `--cluster-domain` value | "cluster.local" | Cluster Domain |
| `--flannel-backend` value | "vxlan" | One of 'none', 'vxlan', 'ipsec', 'host-gw', or 'wireguard' |
@@ -130,6 +152,7 @@ the agent options are there because the server has the agent process embedded wi
| Flag | Description |
|------|--------------|
| `--etcd-arg` value | Customized flag for etcd process |
| `--kube-apiserver-arg` value | Customized flag for kube-apiserver process |
| `--kube-scheduler-arg` value | Customized flag for kube-scheduler process |
| `--kube-controller-manager-arg` value | Customized flag for kube-controller-manager process |
@@ -148,6 +171,7 @@ the agent options are there because the server has the agent process embedded wi
| `--disable` value | Do not deploy packaged components and delete any deployed components (valid items: coredns, servicelb, traefik,local-storage, metrics-server) |
| `--disable-scheduler` | Disable Kubernetes default scheduler |
| `--disable-cloud-controller` | Disable k3s default cloud controller manager |
| `--disable-kube-proxy` | Disable running kube-proxy |
| `--disable-network-policy` | Disable k3s default network policy controller |
### Customized Flags for Kubernetes Processes
@@ -190,6 +214,7 @@ USAGE:
k3s server [OPTIONS]
OPTIONS:
--config FILE, -c FILE (config) Load configuration from FILE (default: "/etc/rancher/k3s/config.yaml") [$K3S_CONFIG_FILE] --debug (logging) Turn on debug logs [$K3S_DEBUG]
-v value (logging) Number for the log level verbosity (default: 0)
--vmodule value (logging) Comma-separated list of pattern=N settings for file-filtered logging
--log value, -l value (logging) Log to file
@@ -202,6 +227,7 @@ OPTIONS:
--data-dir value, -d value (data) Folder to hold state default /var/lib/rancher/k3s or ${HOME}/.rancher/k3s if not root
--cluster-cidr value (networking) Network CIDR to use for pod IPs (default: "10.42.0.0/16")
--service-cidr value (networking) Network CIDR to use for services IPs (default: "10.43.0.0/16")
--service-node-port-range value (networking) Port range to reserve for services with NodePort visibility (default: "30000-32767")
--cluster-dns value (networking) Cluster IP for coredns service. Should be in your service-cidr range (default: 10.43.0.10)
--cluster-domain value (networking) Cluster Domain (default: "cluster.local")
--flannel-backend value (networking) One of 'none', 'vxlan', 'ipsec', 'host-gw', or 'wireguard' (default: "vxlan")
@@ -209,6 +235,7 @@ OPTIONS:
--token-file value (cluster) File containing the cluster-secret/token [$K3S_TOKEN_FILE]
--write-kubeconfig value, -o value (client) Write kubeconfig for admin client to this file [$K3S_KUBECONFIG_OUTPUT]
--write-kubeconfig-mode value (client) Write kubeconfig with this mode [$K3S_KUBECONFIG_MODE]
--etcd-arg value (flags) Customized flag for etcd process
--kube-apiserver-arg value (flags) Customized flag for kube-apiserver process
--kube-scheduler-arg value (flags) Customized flag for kube-scheduler process
--kube-controller-manager-arg value (flags) Customized flag for kube-controller-manager process
@@ -217,18 +244,37 @@ OPTIONS:
--datastore-cafile value (db) TLS Certificate Authority file used to secure datastore backend communication [$K3S_DATASTORE_CAFILE]
--datastore-certfile value (db) TLS certification file used to secure datastore backend communication [$K3S_DATASTORE_CERTFILE]
--datastore-keyfile value (db) TLS key file used to secure datastore backend communication [$K3S_DATASTORE_KEYFILE]
--etcd-expose-metrics (db) Expose etcd metrics to client interface. (Default false)
--etcd-disable-snapshots (db) Disable automatic etcd snapshots
--etcd-snapshot-name value (db) Set the base name of etcd snapshots. Default: etcd-snapshot-<unix-timestamp> (default: "etcd-snapshot")
--etcd-snapshot-schedule-cron value (db) Snapshot interval time in cron spec. eg. every 5 hours '* */5 * * *' (default: "0 */12 * * *")
--etcd-snapshot-retention value (db) Number of snapshots to retain Default: 5 (default: 5)
--etcd-snapshot-dir value (db) Directory to save db snapshots. (Default location: ${data-dir}/db/snapshots)
--etcd-s3 (db) Enable backup to S3
--etcd-s3-endpoint value (db) S3 endpoint url (default: "s3.amazonaws.com")
--etcd-s3-endpoint-ca value (db) S3 custom CA cert to connect to S3 endpoint
--etcd-s3-skip-ssl-verify (db) Disables S3 SSL certificate validation
--etcd-s3-access-key value (db) S3 access key [$AWS_ACCESS_KEY_ID]
--etcd-s3-secret-key value (db) S3 secret key [$AWS_SECRET_ACCESS_KEY]
--etcd-s3-bucket value (db) S3 bucket name
--etcd-s3-region value (db) S3 region / bucket location (optional) (default: "us-east-1")
--etcd-s3-folder value (db) S3 folder
--default-local-storage-path value (storage) Default local storage path for local provisioner storage class
--disable value (components) Do not deploy packaged components and delete any deployed components (valid items: coredns, servicelb, traefik, local-storage, metrics-server)
--disable-scheduler (components) Disable Kubernetes default scheduler
--disable-cloud-controller (components) Disable k3s default cloud controller manager
--disable-kube-proxy (components) Disable running kube-proxy
--disable-network-policy (components) Disable k3s default network policy controller
--node-name value (agent/node) Node name [$K3S_NODE_NAME]
--with-node-id (agent/node) Append id to node name
--node-label value (agent/node) Registering and starting kubelet with set of labels
--node-taint value (agent/node) Registering kubelet with set of taints
--image-credential-provider-bin-dir value (agent/node) The path to the directory where credential provider plugin binaries are located (default: "/var/lib/rancher/credentialprovider/bin")
--image-credential-provider-config value (agent/node) The path to the credential provider plugin config file (default: "/var/lib/rancher/credentialprovider/config.yaml")
--docker (agent/runtime) Use docker instead of containerd
--container-runtime-endpoint value (agent/runtime) Disable embedded containerd and use alternative CRI implementation
--pause-image value (agent/runtime) Customized pause image for containerd or docker sandbox (default: "docker.io/rancher/pause:3.1")
--snapshotter value (agent/runtime) Override default containerd snapshotter (default: "overlayfs")
--private-registry value (agent/runtime) Private registry configuration file (default: "/etc/rancher/k3s/registries.yaml")
--node-ip value, -i value (agent/networking) IP address to advertise for node
--node-external-ip value (agent/networking) External IP address to advertise for node
@@ -237,14 +283,19 @@ OPTIONS:
--flannel-conf value (agent/networking) Override default flannel config file
--kubelet-arg value (agent/flags) Customized flag for kubelet process
--kube-proxy-arg value (agent/flags) Customized flag for kube-proxy process
--protect-kernel-defaults (agent/node) Kernel tuning behavior. If set, error if kernel tunables are different than kubelet defaults.
--rootless (experimental) Run rootless
--agent-token value (experimental/cluster) Shared secret used to join agents to the cluster, but not servers [$K3S_AGENT_TOKEN]
--agent-token-file value (experimental/cluster) File containing the agent secret [$K3S_AGENT_TOKEN_FILE]
--server value, -s value (experimental/cluster) Server to connect to, used to join a cluster [$K3S_URL]
--cluster-init (experimental/cluster) Initialize new cluster master [$K3S_CLUSTER_INIT]
--cluster-reset (experimental/cluster) Forget all peers and become a single cluster new cluster master [$K3S_CLUSTER_RESET]
--cluster-reset-restore-path value (db) Path to snapshot file to be restored
--secrets-encryption (experimental) Enable Secret encryption at rest
--system-default-registry value (image) Private registry to be used for all system images [$K3S_SYSTEM_DEFAULT_REGISTRY]
--selinux (agent/node) Enable SELinux in containerd [$K3S_SELINUX]
--lb-server-port value (agent/node) Local port for supervisor client load-balancer. If the supervisor and apiserver are not colocated an additional port 1 less than this port will also be used for the apiserver client load-balancer. (default: 6444) [$K3S_LB_SERVER_PORT]
--no-flannel (deprecated) use --flannel-backend=none
--no-deploy value (deprecated) Do not deploy packaged components (valid items: coredns, servicelb, traefik, local-storage, metrics-server)
--cluster-secret value (deprecated) use --token [$K3S_CLUSTER_SECRET]
```
```
content/k3s/latest/en/installation/installation-requirements/_index.md
+1
View File
@@ -51,6 +51,7 @@ If you wish to utilize the metrics server, you will need to open port 10250 on e
If you plan on achieving high availability with embedded etcd, server nodes must be accessible to each other on ports 2379 and 2380.
> **Important:** The VXLAN port on nodes should not be exposed to the world as it opens up your cluster network to be accessed by anyone. Run your nodes behind a firewall/security group that disables access to port 8472.
> **Warning:** Flannel relies on the [Bridge CNI plugin](https://www.cni.dev/plugins/current/main/bridge/) to create a L2 network that switches traffic. Rogue pods with NET_RAW capabilities can abuse that L2 network to launch attacks such as [ARP spoofing](https://static.sched.com/hosted_files/kccncna19/72/ARP%20DNS%20spoof.pdf). Therefore, as documented in the [kubernetes docs](https://kubernetes.io/docs/concepts/security/pod-security-standards/), please set a restricted profile that disables NET_RAW on non-trustable pods.
<figcaption>Inbound Rules for K3s Server Nodes</figcaption>
content/k3s/latest/en/installation/kube-dashboard/_index.md
+2
View File
@@ -86,4 +86,6 @@ sudo k3s kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard
```bash
sudo k3s kubectl delete ns kubernetes-dashboard
sudo k3s kubectl delete clusterrolebinding kubernetes-dashboard
sudo k3s kubectl delete clusterrole kubernetes-dashboard
```
content/k3s/latest/en/installation/network-options/_index.md
+17
View File
@@ -69,3 +69,20 @@ You should see that IP forwarding is set to true.
{{% /tab %}}
{{% /tabs %}}
### Dual-stack installation
Dual-stack networking must be configured when the cluster is first created. It cannot be enabled on an existing single-stack cluster.
To enable dual-stack in k3s, you must provide valid dual-stack `cluster-cidr` and `service-cidr`, and set `disable-network-policy` on all server nodes. Both servers and agents must provide valid dual-stack `node-ip` settings. Node address auto-detection and network policy enforcement are not supported on dual-stack clusters when using the default flannel CNI. Besides, only vxlan backend is supported at the moment. This is an example of a valid configuration:
```
node-ip: 10.0.10.7,2a05:d012:c6f:4611:5c2:5602:eed2:898c
cluster-cidr: 10.42.0.0/16,2001:cafe:42:0::/56
service-cidr: 10.43.0.0/16,2001:cafe:42:1::/112
disable-network-policy: true
```
Note that you can choose whatever `cluster-cidr` and `service-cidr` value, however the `node-ip` values must correspond to the ip addresses of your main interface. Remember to allow ipv6 traffic if you are deploying in a public cloud.
If you are using a custom cni plugin, i.e. a cni plugin different from flannel, the previous configuration might not be enough to enable dual-stack in the cni plugin. Please check how to enable dual-stack in its documentation and verify if network policies can be enabled.
content/k3s/latest/en/known-issues/_index.md
+2 -2
View File
@@ -12,6 +12,6 @@ If you plan to use K3s with docker, Docker installed via a snap package is not r
If you are running iptables in nftables mode instead of legacy you might encounter issues. We recommend utilizing newer iptables (such as 1.6.1+) to avoid issues.
**RootlessKit**
**Rootless Mode**
Running K3s with RootlessKit is experimental and has several [known issues.]({{<baseurl>}}/k3s/latest/en/advanced/#known-issues-with-rootlesskit)
Running K3s with Rootless mode is experimental and has several [known issues.]({{<baseurl>}}/k3s/latest/en/advanced/#known-issues-with-rootless-mode)
content/k3s/latest/en/networking/_index.md
+4 -4
View File
@@ -28,11 +28,11 @@ If you don't install CoreDNS, you will need to install a cluster DNS provider yo
[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.
Traefik is deployed by default when starting the server. For more information see [Auto Deploying Manifests]({{<baseurl>}}/k3s/latest/en/advanced/#auto-deploying-manifests). The default config file is found in `/var/lib/rancher/k3s/server/manifests/traefik.yaml` and any changes made to this file will automatically be deployed to Kubernetes in a manner similar to `kubectl apply`.
Traefik is deployed by default when starting the server. For more information see [Auto Deploying Manifests]({{<baseurl>}}/k3s/latest/en/advanced/#auto-deploying-manifests). The default config file is found in `/var/lib/rancher/k3s/server/manifests/traefik.yaml`.
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).
The Traefik ingress controller will use ports 80 and 443 on the host (i.e. these will not be usable for HostPort or NodePort).
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)
The `traefik.yaml` file should not be edited manually, because k3s would overwrite it again once it is restarted. Instead you can customize Traefik by creating an additional `HelmChartConfig` manifest in `/var/lib/rancher/k3s/server/manifests`. For more details and an example see [Customizing Packaged Components with HelmChartConfig]({{<baseurl>}}/k3s/latest/en/helm/#customizing-packaged-components-with-helmchartconfig). For more information on the possible configuration values, refer to the official [Traefik Helm Configuration Parameters.](https://github.com/traefik/traefik-helm-chart/tree/master/traefik).
To disable it, start each server with the `--disable traefik` option.
@@ -42,7 +42,7 @@ To migrate from an older Traefik v1 instance please refer to the [Traefik docume
# Service Load Balancer
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.
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/k3s-io/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.
content/k3s/latest/en/security/hardening_guide/_index.md
+62
View File
@@ -302,6 +302,68 @@ spec:
- Ingress
```
The metrics-server and Traefik ingress controller will be blocked by default if network policies are not created to allow access. Traefik v1 as packaged in K3s version 1.20 and below uses different labels than Traefik v2; ensure that you only use the sample yaml below that is associated with the version of Traefik present on your cluster.
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-metrics-server
namespace: kube-system
spec:
podSelector:
matchLabels:
k8s-app: metrics-server
ingress:
- {}
policyTypes:
- Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-svclbtraefik-ingress
namespace: kube-system
spec:
podSelector:
matchLabels:
app: svclb-traefik
ingress:
- {}
policyTypes:
- Ingress
---
# Below is for 1.20 ONLY -- remove if on 1.21 or above
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-traefik-v120-ingress
namespace: kube-system
spec:
podSelector:
matchLabels:
app: traefik
ingress:
- {}
policyTypes:
- Ingress
---
# Below is for 1.21 and above ONLY -- remove if on 1.20 or below
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-all-traefik-v121-ingress
namespace: kube-system
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: traefik
ingress:
- {}
policyTypes:
- Ingress
```
> **Note:** Operators must manage network policies as normal for additional namespaces that are created.
## Known Issues
content/k3s/latest/en/security/secrets_encryption/_index.md
+241
View File
@@ -0,0 +1,241 @@
---
title: Secrets Encryption
weight: 26
---
# Secrets Encryption Config
_Available as of v1.17.4+k3s1_
K3s supports enabling secrets encryption at rest by passing the flag `--secrets-encryption` on a server; this flag will do the following automatically:
- Generate an AES-CBC key
- Generate an encryption config file with the generated key
- Pass the config to the KubeAPI as encryption-provider-config
Example of the encryption config file:
```
{
"kind": "EncryptionConfiguration",
"apiVersion": "apiserver.config.k8s.io/v1",
"resources": [
{
"resources": [
"secrets"
],
"providers": [
{
"aescbc": {
"keys": [
{
"name": "aescbckey",
"secret": "xxxxxxxxxxxxxxxxxxx"
}
]
}
},
{
"identity": {}
}
]
}
]
}
```
## Secrets Encryption Tool
_Available as of v1.21.8+k3s1_
K3s contains a utility tool `secrets-encrypt`, which enables automatic control over the following:
- Disabling/Enabling secrets encryption
- Adding new encryption keys
- Rotating and deleting encryption keys
- Reencrypting secrets
>**Warning:** Failure to follow proper procedure for rotating encryption keys can leave your cluster permanently corrupted. Proceed with caution.
### Single-Server Encryption Key Rotation
To rotate secrets encryption keys on a single-node cluster:
- Start the K3s server with the flag `--secrets-encryption`
>**Note:** Starting K3s without encryption and enabling it at a later time is currently *not* supported.
1. Prepare
```
k3s secrets-encrypt prepare
```
2. Kill and restart the K3s server with same arguments
3. Rotate
```
k3s secrets-encrypt rotate
```
4. Kill and restart the K3s server with same arguments
5. Reencrypt
```
k3s secrets-encrypt reencrypt
```
### High-Availability Encryption Key Rotation
The steps are the same for both embedded DB and external DB clusters.
To rotate secrets encryption keys on HA setups:
>**Notes:**
>
> - Starting K3s without encryption and enabling it at a later time is currently *not* supported.
>
> - While not required, it is recommended that you pick one server node from which to run the `secrets-encrypt` commands.
- Start up all three K3s servers with the `--secrets-encryption` flag. For brevity, the servers will be referred to as S1, S2, S3.
1. Prepare on S1
```
k3s secrets-encrypt prepare
```
2. Kill and restart S1 with same arguments
3. Once S1 is up, kill and restart the S2 and S3
4. Rotate on S1
```
k3s secrets-encrypt rotate
```
5. Kill and restart S1 with same arguments
6. Once S1 is up, kill and restart the S2 and S3
7. Reencrypt on S1
```
k3s secrets-encrypt reencrypt
```
8. Kill and restart S1 with same arguments
9. Once S1 is up, kill and restart the S2 and S3
### Single-Server Secrets Encryption Disable/Enable
After launching a server with `--secrets-encryption` flag, secrets encryption can be disabled.
To disable secrets encryption on a single-node cluster:
1. Disable
```
k3s secrets-encrypt disable
```
2. Kill and restart the K3s server with same arguments
3. Reencrypt with flags
```
k3s secrets-encrypt reencrypt --force --skip
```
To re-enable secrets encryption on a single node cluster:
1. Enable
```
k3s secrets-encrypt enable
```
2. Kill and restart the K3s server with same arguments
3. Reencrypt with flags
```
k3s secrets-encrypt reencrypt --force --skip
```
### High-Availability Secrets Encryption Disable/Enable
After launching a HA cluster with `--secrets-encryption` flags, secrets encryption can be disabled.
>**Note:** While not required, it is recommended that you pick one server node from which to run the `secrets-encrypt` commands.
For brevity, the three servers used in this guide will be referred to as S1, S2, S3.
To disable secrets encryption on a HA cluster:
1. Disable on S1
```
k3s secrets-encrypt disable
```
2. Kill and restart S1 with same arguments
3. Once S1 is up, kill and restart the S2 and S3
4. Reencrypt with flags on S1
```
k3s secrets-encrypt reencrypt --force --skip
```
To re-enable secrets encryption on a HA cluster:
1. Enable on S1
```
k3s secrets-encrypt enable
```
2. Kill and restart S1 with same arguments
3. Once S1 is up, kill and restart the S2 and S3
4. Reencrypt with flags on S1
```
k3s secrets-encrypt reencrypt --force --skip
```
### Secrets Encryption Status
The secrets-encrypt tool includes a `status` command that displays information about the current status of secrets encryption on the node.
An example of the command on a single-server node:
```
$ k3s secrets-encrypt status
Encryption Status: Enabled
Current Rotation Stage: start
Server Encryption Hashes: All hashes match
Active Key Type Name
------ -------- ----
* AES-CBC aescbckey
```
Another example on HA cluster, after rotating the keys, but before restarting the servers:
```
$ k3s secrets-encrypt status
Encryption Status: Enabled
Current Rotation Stage: rotate
Server Encryption Hashes: hash does not match between node-1 and node-2
Active Key Type Name
------ -------- ----
* AES-CBC aescbckey-2021-12-10T22:54:38Z
AES-CBC aescbckey
```
Details on each section are as follows:
- __Encryption Status__: Displayed whether secrets encryption is disabled or enabled on the node
- __Current Rotation Stage__: Indicates the current rotation stage on the node.
Stages are: `start`, `prepare`, `rotate`, `reencrypt_request`, `reencrypt_active`, `reencrypt_finished`
- __Server Encryption Hashes__: Useful for HA clusters, this indicates whether all servers are on the same stage with their local files. This can be used to identify whether a restart of servers is required before proceeding to the next stage. In the HA example above, node-1 and node-2 have different hashes, indicating that they currently do not have the same encryption configuration. Restarting the servers will sync up their configuration.
- __Key Table__: Summarizes information about the secrets encryption keys found on the node.
* __Active__: The "*" indicates which, if any, of the keys are currently used for secrets encryption. An active key is used by Kubernetes to encrypt any new secrets.
* __Key Type__: All keys using this tool are `AES-CBC` type. See more info [here.](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers)
* __Name__: Name of the encryption key.
content/k3s/latest/en/security/self_assessment/_index.md
+1 -1
View File
@@ -2040,7 +2040,7 @@ Where access to the Kubernetes API from a pod is required, a specific service ac
The default service account should be configured such that it does not provide a service account token and does not have any explicit rights assignments.
</details>
**Result:** Fail. Currently requires operator intervention See the [Hardening Guide]({{<baseurl>}}/rancher/k3s/latest/en/security/hardening_guide) for details.
**Result:** Fail. Currently requires operator intervention See the [Hardening Guide]({{<baseurl>}}/k3s/latest/en/security/hardening_guide) for details.
**Audit:**
For each namespace in the cluster, review the rights assigned to the default service account and ensure that it has no roles or cluster roles bound to it apart from the defaults. Additionally ensure that the automountServiceAccountToken: false setting is in place for each default service account.
content/k3s/latest/en/upgrades/_index.md
+3 -1
View File
@@ -9,4 +9,6 @@ This section describes how to upgrade your K3s cluster.
[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.
> If Traefik is not disabled K3s versions 1.20 and earlier will have installed Traefik v1, while K3s versions 1.21 and later will install Traefik v2 if v1 is not already present. To upgrade Traefik, please refer to the [Traefik documentation](https://doc.traefik.io/traefik/migration/v1-to-v2/) and use the [migration tool](https://github.com/traefik/traefik-migration-tool) to migrate from the older Traefik v1 to Traefik v2.
> 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.
content/k3s/latest/en/upgrades/automated/_index.md
+9 -4
View File
@@ -24,16 +24,21 @@ For more details on the design and architecture of the system-upgrade-controller
- [system-upgrade-controller](https://github.com/rancher/system-upgrade-controller)
- [k3s-upgrade](https://github.com/rancher/k3s-upgrade)
To automate upgrades in this manner you must:
To automate upgrades in this manner, you must do the following:
1. Install the system-upgrade-controller into your cluster
1. Configure plans
>**Note:** Users can and should use Rancher to upgrade their K3s cluster if Rancher is managing it.
>
> * If you choose to use Rancher to upgrade, the following steps below are taken care of for you.
> * If you choose not to use Rancher to upgrade, you must use the following steps below to do so.
### Install the system-upgrade-controller
The system-upgrade-controller can be installed as a deployment into your cluster. The deployment requires a service-account, clusterRoleBinding, and a configmap. To install these components, run the following command:
The system-upgrade-controller can be installed as a deployment into your cluster. The deployment requires a service-account, clusterRoleBinding, and a configmap. To install these components, run the following command:
```
kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/download/v0.6.2/system-upgrade-controller.yaml
kubectl apply -f https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yaml
```
The controller can be configured and customized via the previously mentioned configmap, but the controller must be redeployed for the changes to be applied.
@@ -78,7 +83,7 @@ spec:
args:
- prepare
- server-plan
image: rancher/k3s-upgrade:v1.17.4-k3s1
image: rancher/k3s-upgrade
serviceAccountName: system-upgrade
upgrade:
image: rancher/k3s-upgrade
content/os/v1.x/en/_index.md
+1 -1
View File
@@ -5,7 +5,7 @@ description: RancherOS is a simplified Linux distribution built from containers,
weight: 1
---
> RancherOS 1.x is currently in a maintain-only-as-essential mode. It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see [this page.](https://support.rancher.com/hc/en-us/articles/360041771072#development-status-0-0)
> RancherOS 1.x is currently in a maintain-only-as-essential mode. It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see [this page.](https://rancher.com/docs/os/v1.x/en/support/)
RancherOS is the smallest, easiest way to run Docker in production. Every process in RancherOS is a container managed by Docker. This includes system services such as `udev` and `syslog`. Because it only includes the services necessary to run Docker, RancherOS is significantly smaller than most traditional operating systems. By removing unnecessary libraries and services, requirements for security patches and other maintenance are also reduced. This is possible because, with Docker, users typically package all necessary libraries into their containers.
content/os/v1.x/en/configuration/_index.md
+1 -1
View File
@@ -20,7 +20,7 @@ A Linux OS supporting cloud-config will invoke a cloud-init process during start
When you create a RancherOS instance on AWS, for example, you can optionally provide cloud-config passed in the `user-data` field. Inside the RancherOS instance, cloud-init process will retrieve the cloud-config content through its AWS cloud-config data source, which simply extracts the content of user-data received by the VM instance. If the file starts with "`#cloud-config`", cloud-init will interpret that file as a cloud-config file. If the file starts with `#!<interpreter>` (e.g., `#!/bin/sh`), cloud-init will simply execute that file. You can place any configuration commands in the file as scripts.
A cloud-config file uses the YAML format. YAML is easy to understand and easy to parse. For more information on YAML, please read more at the [YAML site](http://www.yaml.org/start.html). The most important formatting principle is indentation or whitespace. This indentation indicates relationships of the items to one another. If something is indented more than the previous line, it is a sub-item of the top item that is less indented.
A cloud-config file uses the YAML format. YAML is easy to understand and easy to parse. For more information on YAML, please read more at the [YAML site](http://www.yaml.org/). The most important formatting principle is indentation or whitespace. This indentation indicates relationships of the items to one another. If something is indented more than the previous line, it is a sub-item of the top item that is less indented.
Example: Notice how both are indented underneath `ssh_authorized_keys`.
content/os/v1.x/en/support/_index.md
+15
View File
@@ -0,0 +1,15 @@
---
title: Support
weight: 170
---
## Development and Maintenance Status
RancherOS 1.x is no longer being actively maintained. There are two significant reasons behind this product decision:
**1. Docker:** The current industry requirements for a container runtime are very much evolving. Container runtimes like containerd and CRIO are now being actively considered as the default choices. RancherOS 1.x, which was specifically designed around using Docker engine only, unfortunately does not lend itself, in its current design, to this new evolving requirement.
**2. ISV Support:** RancherOS was specifically designed as a minimalistic OS to support purpose-built containerized applications. It was not designed to be used as a general purpose OS (such as CentOS or Ubuntu). As such, most ISVs have not certified their software to run on RancherOS, nor does RancherOS even contain the necessary components for many of these applications to run.
We're working on a replacement. Stay tuned!
content/rancher/v2.0-v2.4/_index.md
+1 -1
View File
@@ -1,5 +1,5 @@
---
title: v2.0-v2.4.x
weight: 2
weight: 3
showBreadcrumb: false
---
content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md
+2
View File
@@ -29,6 +29,8 @@ Note that these URLs will not return valid data until the authentication configu
1. **Groups Field**: Make entries for managing group memberships (example: `memberOf`).
1. **Entity ID Field** (optional): The published, protocol-dependent, unique identifier of your partner. This ID defines your organization as the entity operating the server for SAML 2.0 transactions. This ID may have been obtained out-of-band or via a SAML metadata file.
1. **Rancher API Host**: Enter the URL for your Rancher Server.
1. **Private Key** and **Certificate**: This is a key-certificate pair to create a secure shell between Rancher and your IdP.
content/rancher/v2.0-v2.4/en/admin-settings/config-private-registry/_index.md
+1 -1
View File
@@ -4,7 +4,7 @@ weight: 400
aliases:
---
You might want to use a private Docker registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the Docker images that are used in your clusters.
You might want to use a private container registry to share your custom base images within your organization. With a private registry, you can keep a private, consistent, and centralized source of truth for the container images that are used in your clusters.
There are two main ways to set up private registries in Rancher: by setting up the global default registry through the **Settings** tab in the global view, and by setting up a private registry in the advanced options in the cluster-level settings. The global default registry is intended to be used for air-gapped setups, for registries that do not require credentials. The cluster-level private registry is intended to be used in all setups in which the private registry requires credentials.
content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md
+4
View File
@@ -84,6 +84,10 @@ _Project roles_ are roles that can be used to grant users access to a project. T
These users can manage project-scoped resources like namespaces and workloads, but cannot manage other project members.
>**Note:**
>
>By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
- **Read Only:**
These users can view everything in the project but cannot create, update, or delete anything.
content/rancher/v2.0-v2.4/en/backups/backup/_index.md
+2
View File
@@ -7,6 +7,8 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/backups
- /rancher/v2.0-v2.4/en/backups/legacy/backup
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/
---
This section contains information about how to create backups of your Rancher data and how to restore them in a disaster scenario.
content/rancher/v2.0-v2.4/en/backups/backup/docker-backups/_index.md
+1
View File
@@ -9,6 +9,7 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/legacy/backup/single-node-backups/
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/docker-backups
- /rancher/v2.0-v2.4/en/installation/backups-and-restoration/single-node-backup-and-restoration/
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/docker-backups/
---
content/rancher/v2.0-v2.4/en/backups/backup/k3s-backups/_index.md
+1
View File
@@ -9,6 +9,7 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/legacy/backups/k3s-backups
- /rancher/v2.0-v2.4/en/backups/legacy/backup/k3s-backups
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/k3s-backups
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/k3s-backups/
---
When Rancher is installed on a high-availability Kubernetes cluster, we recommend using an external database to store the cluster data.
content/rancher/v2.0-v2.4/en/backups/backup/rke-backups/_index.md
+1
View File
@@ -11,6 +11,7 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/legacy/backups/ha-backups
- /rancher/v2.0-v2.4/en/backups/legacy/backup/ha-backups
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/backup/rke-backups
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/backup/rke-backups/
---
This section describes how to create backups of your high-availability Rancher install.
content/rancher/v2.0-v2.4/en/backups/restore/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/restorations
- /rancher/v2.0-v2.4/en/backups/legacy/restore
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/
---
If you lose the data on your Rancher Server, you can restore it if you have backups stored in a safe location.
content/rancher/v2.0-v2.4/en/backups/restore/docker-restores/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/after-installation/single-node-backup-and-restoration/
- /rancher/v2.0-v2.4/en/backups/restorations/single-node-restoration
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/docker-restores
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/docker-restores/
---
If you encounter a disaster scenario, you can restore your Rancher Server to your most recent backup.
content/rancher/v2.0-v2.4/en/backups/restore/k3s-restore/_index.md
+1
View File
@@ -8,6 +8,7 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k8s-restore/k3s-restore/
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k3s-restore
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/k3s-restore
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/k3s-restore/
---
When Rancher is installed on a high-availability Kubernetes cluster, we recommend using an external database to store the cluster data.
content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/_index.md
+1
View File
@@ -9,6 +9,7 @@ aliases:
- /rancher/v2.0-v2.4/en/backups/legacy/restore/k8s-restore/rke-restore/
- /rancher/v2.0-v2.4/en/backups/legacy/restore/rke-restore
- /rancher/v2.0-v2.4/en/backups/v2.0.x-v2.4.x/restore/rke-restore
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/
---
This procedure describes how to use RKE to restore a snapshot of the Rancher Kubernetes cluster.
content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md
+3 -1
View File
@@ -1,6 +1,8 @@
---
title: "Rolling back to v2.0.0-v2.1.5"
weight: 1
aliases:
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/v2.0-v2.1/
---
> Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved here and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible.
@@ -26,7 +28,7 @@ Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.o
2. After executing the command a `tokens.json` file will be created. Important! Back up this file in a safe place.** You will need it to restore functionality to your clusters after rolling back Rancher. **If you lose this file, you may lose access to your clusters.**
3. Rollback Rancher following the [normal instructions]({{<baseurl>}}/rancher/v2.x/en/upgrades/rollbacks/).
3. Rollback Rancher following the [normal instructions]({{<baseurl>}}/rancher/v2.0-v2.4/en/upgrades/rollbacks/).
4. Once Rancher comes back up, every cluster managed by Rancher (except for Imported clusters) will be in an `Unavailable` state.
content/rancher/v2.0-v2.4/en/best-practices/_index.md
+2
View File
@@ -1,6 +1,8 @@
---
title: Best Practices Guide
weight: 4
aliases:
- /rancher/v2.x/en/best-practices/v2.0-v2.4/
---
The purpose of this section is to consolidate best practices for Rancher implementations. This also includes recommendations for related technologies, such as Kubernetes, Docker, containers, and more. The objective is to improve the outcome of a Rancher implementation using the operational experience of Rancher and its customers.
content/rancher/v2.0-v2.4/en/best-practices/containers/_index.md
+1
View File
@@ -4,6 +4,7 @@ weight: 100
aliases:
- /rancher/v2.0-v2.4/en/best-practices/containers
- /rancher/v2.0-v2.4/en/best-practices/v2.0-v2.4/containers
- /rancher/v2.x/en/best-practices/v2.0-v2.4/containers/
---
Running well-built containers can greatly impact the overall performance and security of your environment.
content/rancher/v2.0-v2.4/en/best-practices/deployment-strategies/_index.md
+1
View File
@@ -4,6 +4,7 @@ weight: 100
aliases:
- /rancher/v2.0-v2.4/en/best-practices/deployment-strategies
- /rancher/v2.0-v2.4/en/best-practices/v2.0-v2.4/deployment-strategies
- /rancher/v2.x/en/best-practices/v2.0-v2.4/deployment-strategies/
---
There are two recommended deployment strategies. Each one has its own pros and cons. Read more about which one would fit best for your use case:
content/rancher/v2.0-v2.4/en/best-practices/deployment-types/_index.md
+1
View File
@@ -4,6 +4,7 @@ weight: 100
aliases:
- /rancher/v2.0-v2.4/en/best-practices/deployment-types
- /rancher/v2.0-v2.4/en/best-practices/v2.0-v2.4/deployment-types
- /rancher/v2.x/en/best-practices/v2.0-v2.4/deployment-types/
---
A high-availability Kubernetes installation, defined as an installation of Rancher on a Kubernetes cluster with at least three nodes, should be used in any production installation of Rancher, as well as any installation deemed "important." Multiple Rancher instances running on multiple nodes ensure high availability that cannot be accomplished with a single node environment.
content/rancher/v2.0-v2.4/en/best-practices/management/_index.md
+4 -2
View File
@@ -4,6 +4,8 @@ weight: 101
aliases:
- /rancher/v2.0-v2.4/en/best-practices/management
- /rancher/v2.0-v2.4/en/best-practices/v2.0-v2.4/management
- /rancher/v2.x/en/best-practices/management/
- /rancher/v2.x/en/best-practices/v2.0-v2.4/management/
---
Rancher allows you to set up numerous combinations of configurations. Some configurations are more appropriate for development and testing, while there are other best practices for production environments for maximum availability and fault tolerance. The following best practices should be followed for production.
@@ -85,8 +87,8 @@ Run your etcd and control plane nodes on virtual machines where you can scale vC
### Use at Least Three etcd Nodes
Provision 3 or 5 etcd nodes. Etcd requires a quorum to determine a leader by the majority of nodes, therefore it is not recommended to have clusters of even numbers. Three etcd nodes is generally sufficient for smaller clusters and five etcd nodes for large clusters.
### Use at Least Two Control Plane Nodes
Provision two or more control plane nodes. Some control plane components, such as the `kube-apiserver`, run in [active-active](https://www.jscape.com/blog/active-active-vs-active-passive-high-availability-cluster) mode and will give you more scalability. Other components such as kube-scheduler and kube-controller run in active-passive mode (leader elect) and give you more fault tolerance.
### Use at Least Three Control Plane Nodes
Provision three or more control plane nodes. Some control plane components, such as the `kube-apiserver`, run in [active-active](https://www.jscape.com/blog/active-active-vs-active-passive-high-availability-cluster) mode and will give you more scalability. Other components such as kube-scheduler and kube-controller run in active-passive mode (leader elect) and give you more fault tolerance.
### Monitor Your Cluster
Closely monitor and scale your nodes as needed. You should [enable cluster monitoring]({{<baseurl>}}/rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/) and use the Prometheus metrics and Grafana visualization options as a starting point.
content/rancher/v2.0-v2.4/en/cli/_index.md
+3 -2
View File
@@ -6,6 +6,7 @@ metaDescription: "The Rancher CLI is a unified tool that you can use to interact
weight: 21
aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/cluster-access/cli
- /rancher/v2.x/en/cli/
---
The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
@@ -62,13 +63,13 @@ The following commands are available for use in Rancher CLI.
| `apps, [app]` | Performs operations on catalog applications (i.e. individual [Helm charts](https://docs.helm.sh/developing_charts/) or Rancher charts. |
| `catalog` | Performs operations on [catalogs]({{<baseurl>}}/rancher/v2.0-v2.4/en/catalog/). |
| `clusters, [cluster]` | Performs operations on your [clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/). |
| `context` | Switches between Rancher [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/). For an example, see [Project Selection](#project-selection). |
| `context` | Switches between Rancher [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/). For an example, see [Project Selection](#project-selection). |
| `inspect [OPTIONS] [RESOURCEID RESOURCENAME]` | Displays details about [Kubernetes resources](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#resource-types) or Rancher resources (i.e.: [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/) and [workloads]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads/)). Specify resources by name or ID. |
| `kubectl` |Runs [kubectl commands](https://kubernetes.io/docs/reference/kubectl/overview/#operations). |
| `login, [l]` | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication). |
| `namespaces, [namespace]` |Performs operations on namespaces. |
| `nodes, [node]` |Performs operations on nodes. |
| `projects, [project]` | Performs operations on [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/). |
| `projects, [project]` | Performs operations on [projects]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/). |
| `ps` | Displays [workloads]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/workloads) in a project. |
| `settings, [setting]` | Shows the current settings for your Rancher Server. |
| `ssh` | Connects to one of your cluster nodes using the SSH protocol. |
content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md
+3
View File
@@ -162,6 +162,9 @@ By default, your user is added as the project `Owner`.
>**Notes on Permissions:**
>
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
>
>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
>
>- Choose `Custom` to create a custom role on the fly: [Custom Project Roles]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles).
To add members:
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cis-scans/_index.md
+3 -2
View File
@@ -2,8 +2,9 @@
title: CIS Scans
weight: 18
aliases:
- /rancher/v2.0-v2.4/en/cis-scans/legacy
- /rancher/v2.0-v2.4/en/cis-scans
- /rancher/v2.0-v2.4/en/cis-scans/legacy
- /rancher/v2.0-v2.4/en/cis-scans
- /rancher/v2.x/en/cis-scans/v2.4/
---
_Available as of v2.4.0_
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cis-scans/skipped-tests/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cis-scans/legacy/skipped-tests
- /rancher/v2.0-v2.4/en/cis-scans/v2.4/skipped-tests
- /rancher/v2.0-v2.4/en/cis-scans/skipped-tests
- /rancher/v2.x/en/cis-scans/v2.4/skipped-tests/
---
This section lists the tests that are skipped in the permissive test profile for RKE.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-alerts/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/alerts
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/alerts/cluster-alerts
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-alerts
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-alerts/
---
To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-logging/_index.md
+2
View File
@@ -9,6 +9,8 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/logging
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/cluster-logging/
---
Logging is helpful because it allows you to:
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-logging/elasticsearch/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/logging/elasticsearch
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging/elasticsearch
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/elasticsearch
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/cluster-logging/elasticsearch/
---
If your organization uses [Elasticsearch](https://www.elastic.co/), either on premise or in the cloud, you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Elasticsearch deployment to view logs.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-logging/fluentd/_index.md
+4 -3
View File
@@ -2,9 +2,10 @@
title: Fluentd
weight: 600
aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/logging/fluentd
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging/fluentd
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/fluentd
- /rancher/v2.0-v2.4/en/cluster-admin/tools/logging/fluentd
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging/fluentd
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/fluentd
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/cluster-logging/fluentd/
---
If your organization uses [Fluentd](https://www.fluentd.org/), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Fluentd server to view logs.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-logging/kafka/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/logging/kafka
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging/kafka
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/kafka
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/cluster-logging/kafka/
---
If your organization uses [Kafka](https://kafka.apache.org/), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Kafka server to view logs.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-logging/splunk/_index.md
+2
View File
@@ -7,6 +7,8 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/logging/splunk
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging/splunk
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/splunk
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/cluster-logging/splunk/
- /rancher/v2.x/en/cluster-admin/tools/logging/splunk
---
If your organization uses [Splunk](https://www.splunk.com/), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Splunk server to view logs.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-logging/syslog/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/logging/syslog
- /rancher/v2.0-v2.4/en/logging/legacy/cluster-logging/syslog
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/syslog
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/cluster-logging/syslog/
---
If your organization uses [Syslog](https://tools.ietf.org/html/rfc5424), you can configure Rancher to send it Kubernetes logs. Afterwards, you can log into your Syslog server to view logs.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring/_index.md
+5 -1
View File
@@ -8,6 +8,8 @@ aliases:
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/monitoring/cluster-monitoring
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/
---
_Available as of v2.2.0_
@@ -53,7 +55,7 @@ Using Prometheus, you can monitor Rancher at both the cluster level and [project
As an [administrator]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/) or [cluster owner]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), you can configure Rancher to deploy Prometheus to monitor your Kubernetes cluster.
> **Prerequisite:** The following TCP ports need to be opened for metrics scraping:
> **Prerequisites:** The following TCP ports need to be opened for metrics scraping:
>
> | Port | Node type | Component |
> | --- | --- | --- |
@@ -64,6 +66,8 @@ As an [administrator]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/glo
> | 10252 | Controlplane | Kube controller manager |
> | 2379 | Etcd | Etcd server |
> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/migrating/)
1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring.
1. Select **Tools > Monitoring** in the navigation bar.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring/cluster-metrics/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/monitoring/cluster-metrics
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/cluster-metrics
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/cluster-metrics
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/cluster-metrics/
---
_Available as of v2.2.0_
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring/custom-metrics/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/custom-metrics
- /rancher/v2.0-v2.4/en/cluster-admin/tools/monitoring/custom-metrics/
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/custom-metrics
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/custom-metrics/
---
After you've enabled [cluster level monitoring]({{< baseurl >}}/rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/), You can view the metrics data from Rancher. You can also deploy the Prometheus custom metrics adapter then you can use the HPA with metrics stored in cluster monitoring.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring/expression/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/monitoring/expression
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/expression
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/expression
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/expression/
---
The PromQL expressions in this doc can be used to configure [alerts.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/alerts/)
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring/prometheus/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/monitoring/prometheus/
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/prometheus
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/prometheus
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/prometheus/
---
_Available as of v2.2.0_
content/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring/viewing-metrics/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/monitoring/viewing-metrics
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/monitoring/cluster-monitoring/viewing-metrics
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/viewing-metrics
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/viewing-metrics/
---
_Available as of v2.2.0_
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/_index.md
+1
View File
@@ -7,6 +7,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/
- /rancher/v2.0-v2.4/en/project-admin/istio
- /rancher/v2.0-v2.4/en/istio/legacy/cluster-istio
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/
---
_Available as of v2.3.0_
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/disabling-istio/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/disabling-istio
- /rancher/v2.0-v2.4/en/istio/legacy/disabling-istio
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/disabling-istio
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/disabling-istio/
---
This section describes how to disable Istio in a cluster, namespace, or workload.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/rbac/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/rbac
- /rancher/v2.0-v2.4/en/istio/legacy/rbac
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/rbac
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/rbac/
---
This section describes the permissions required to access Istio features and how to configure access to the Kiali and Jaeger visualizations.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/release-notes/_index.md
+1
View File
@@ -4,6 +4,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/release-notes
- /rancher/v2.0-v2.4/en/istio/legacy/release-notes
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/release-notes
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/release-notes/
---
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/resources/_index.md
+1
View File
@@ -7,6 +7,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/resources
- /rancher/v2.0-v2.4/en/istio/legacy/resources
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/resources
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/resources/
---
_Available as of v2.3.0_
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup
- /rancher/v2.0-v2.4/en/istio/legacy/setup
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/
---
This section describes how to enable Istio and start using it in your projects.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/deploy-workloads/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/deploy-workloads
- /rancher/v2.0-v2.4/en/istio/legacy/setup/deploy-workloads
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/deploy-workloads
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/deploy-workloads/
---
> **Prerequisite:** To enable Istio for a workload, the cluster and namespace must have Istio enabled.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster
- /rancher/v2.0-v2.4/en/istio/legacy/setup/enable-istio-in-cluster
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/enable-istio-in-cluster
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/enable-istio-in-cluster/
---
This cluster uses the default Nginx controller to allow traffic into the cluster.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster/enable-istio-with-psp/_index.md
+1
View File
@@ -4,6 +4,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/enable-istio-in-cluster/enable-istio-with-psp
- /rancher/v2.0-v2.4/en/istio/legacy/setup/enable-istio-in-cluster/enable-istio-with-psp
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/enable-istio-in-cluster/enable-istio-with-psp
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/enable-istio-in-cluster/enable-istio-with-psp/
---
>**Note:** The following guide is only for RKE provisioned clusters.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/enable-istio-in-namespace/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/enable-istio-in-namespace
- /rancher/v2.0-v2.4/en/istio/legacy/setup/enable-istio-in-namespace
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/enable-istio-in-namespace
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/enable-istio-in-namespace/
---
You will need to manually enable Istio in each namespace that you want to be tracked or controlled by Istio. When Istio is enabled in a namespace, the Envoy sidecar proxy will be automatically injected into all new workloads that are deployed in the namespace.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/gateway/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/gateway
- /rancher/v2.0-v2.4/en/istio/legacy/setup/gateway
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/gateway
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/gateway/
---
The gateway to each cluster can have its own port or load balancer, which is unrelated to a service mesh. By default, each Rancher-provisioned cluster has one NGINX ingress controller allowing traffic into the cluster.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/node-selectors/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/node-selectors
- /rancher/v2.0-v2.4/en/istio/legacy/setup/node-selectors
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/node-selectors
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/node-selectors/
---
> **Prerequisite:** Your cluster needs a worker node that can designated for Istio. The worker node should meet the [resource requirements.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/resources)
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/set-up-traffic-management/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/set-up-traffic-management
- /rancher/v2.0-v2.4/en/istio/legacy/setup/set-up-traffic-management
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/set-up-traffic-management
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/set-up-traffic-management/
---
A central advantage of traffic management in Istio is that it allows dynamic request routing. Some common applications for dynamic request routing include canary deployments and blue/green deployments. The two key resources in Istio traffic management are *virtual services* and *destination rules*.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/view-traffic/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/istio/setup/view-traffic
- /rancher/v2.0-v2.4/en/istio/legacy/setup/view-traffic
- /rancher/v2.0-v2.4/en/istio/v2.3.x-v2.4.x/setup/view-traffic
- /rancher/v2.x/en/istio/v2.3.x-v2.4.x/setup/view-traffic/
---
This section describes how to view the traffic that is being managed by Istio.
content/rancher/v2.0-v2.4/en/cluster-admin/tools/notifiers/_index.md
+2
View File
@@ -6,6 +6,8 @@ aliases:
- /rancher/v2.0-v2.4/en/cluster-admin/tools/notifiers
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/notifiers
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/notifiers/
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-alerts/default-alerts/
---
Notifiers are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action.
content/rancher/v2.0-v2.4/en/cluster-admin/upgrading-kubernetes/_index.md
+1 -1
View File
@@ -33,7 +33,7 @@ As of Rancher v2.4.0,
# Tested Kubernetes Versions
Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For example, Rancher v2.3.0 is was tested with Kubernetes v1.15.4, v1.14.7, and v1.13.11. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.3.0/)
Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.4.17/)
# How Upgrades Work
content/rancher/v2.0-v2.4/en/cluster-provisioning/cluster-capabilities-table/index.md
+2 -1
View File
@@ -16,7 +16,8 @@ headless: true
| [Ability to back up your Kubernetes Clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/backing-up-etcd/) | ✓ | | |
| [Ability to recover and restore etcd]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/restoring-etcd/) | ✓ | | |
| [Cleaning Kubernetes components when clusters are no longer reachable from Rancher]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/cleaning-cluster-nodes/) | ✓ | | |
| [Configuring Pod Security Policies]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/pod-security-policy/) | ✓ | | |
| [Configuring Pod Security Policies]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/pod-security-policy/) | ✓ | | |
| [Running Security Scans]({{<baseurl>}}/rancher/v2.0-v2.4/en/security/security-scan/) | ✓ | | |
| [Authorized Cluster Endpoint]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint) | ✓ | | |
\* Cluster configuration options can't be edited for imported clusters, except for K3s clusters.
content/rancher/v2.0-v2.4/en/cluster-provisioning/node-requirements/_index.md
+2 -2
View File
@@ -3,9 +3,9 @@ title: Node Requirements for Rancher Managed Clusters
weight: 1
---
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the cluster (or single node) running Rancher.
This page describes the requirements for the Rancher managed Kubernetes clusters where your apps and services will be installed. These downstream clusters should be separate from the three-node cluster running Rancher.
> If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/)
> If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/requirements/)
Make sure the nodes for the Rancher server fulfill the following requirements:
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md
+7
View File
@@ -12,6 +12,13 @@ First, you will set up your Azure cloud credentials in Rancher. Then you will us
Then you will create an Azure cluster in Rancher, and when configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
>**Warning:** When the Rancher RKE cluster is running in Azure and has an Azure load balancer in front, the outbound flow will fail. The workaround for this problem is as follows:
> - Terminate the SSL/TLS on the internal load balancer
> - Use the L7 load balancer
> For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations).
For more information on configuring the Kubernetes cluster that Rancher will install on the Azure nodes, refer to the [RKE cluster configuration reference.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options)
For more information on configuring Azure node templates, refer to the [Azure node template configuration reference.](./azure-node-template-config)
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4/_index.md
+2
View File
@@ -2,6 +2,8 @@
title: vSphere Node Template Configuration in Rancher before v2.0.4
shortTitle: Before v2.0.4
weight: 5
aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4/
---
- [Account access](#account-access)
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.0.4/_index.md
+2
View File
@@ -2,6 +2,8 @@
title: vSphere Node Template Configuration in Rancher v2.0.4
shortTitle: v2.0.4
weight: 4
aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.0.4/
---
- [Account access](#account-access)
- [Scheduling](#scheduling)
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.2.0/_index.md
+2
View File
@@ -2,6 +2,8 @@
title: vSphere Node Template Configuration in Rancher v2.2.0
shortTitle: v2.2.0
weight: 3
aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.2.0/
---
- [Account Access](#account-access)
- [Scheduling](#scheduling)
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.0/_index.md
+2
View File
@@ -2,6 +2,8 @@
title: vSphere Node Template Configuration in Rancher v2.3.0
shortTitle: v2.3.0
weight: 2
aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.0/
---
- [Account Access](#account-access)
- [Scheduling](#scheduling)
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.3/_index.md
+2
View File
@@ -2,6 +2,8 @@
title: vSphere Node Template Configuration in Rancher v2.3.3
shortTitle: v2.3.3
weight: 1
aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.3/
---
- [Account Access](#account-access)
- [Scheduling](#scheduling)
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/_index.md
+1 -1
View File
@@ -108,7 +108,7 @@ _Available as of v2.2.0_
Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
> The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE]({{<baseurl>}}/rancher/v2.0-v2.4/en/overview/architecture/#tools-for-provisioning-kubernetes-clusters) to provision the cluster. It is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
> The authorized cluster endpoint is available only in clusters that Rancher has provisioned [using RKE]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/#authorized-cluster-endpoint). It is not available for clusters in hosted Kubernetes providers, such as Amazon's EKS. Additionally, the authorized cluster endpoint cannot be enabled for RKE clusters that are imported into Rancher; it is available only on Rancher-launched Kubernetes clusters.
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
content/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/windows-clusters/docs-for-2.1-and-2.2/_index.md
+2
View File
@@ -1,6 +1,8 @@
---
title: v2.1.x and v2.2.x Windows Documentation (Experimental)
weight: 9100
aliases:
- /rancher/v2.x/en/cluster-provisioning/rke-clusters/windows-clusters/docs-for-2.1-and-2.2/
---
_Available from v2.1.0 to v2.1.9 and v2.2.0 to v2.2.3_
content/rancher/v2.0-v2.4/en/faq/upgrades-to-2x/_index.md
+2
View File
@@ -1,6 +1,8 @@
---
title: Questions about Upgrading to Rancher v2.x
weight: 1
aliases:
- /rancher/v2.x/en/faq/upgrades-to-2x/
---
This page contains frequently asked questions about the changes between Rancher v1.x and v2.x, and how to upgrade from Rancher v1.x to v2.x.
content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md
+12 -10
View File
@@ -45,18 +45,20 @@ Advantages of Rancher charts include:
# Chart Directory Structure
The following table demonstrates the directory structure for a chart, which can be found in a chart directory: `charts/<APPLICATION>/<APP_VERSION>/`. This information is helpful when customizing charts for a custom catalog. Files denoted with **Rancher Specific** are specific to Rancher charts, but are optional for chart customization.
The following table demonstrates the directory structure for a Rancher Chart. The `charts` directory is the top level directory under the repository base. Adding the repository to Rancher will expose all charts contained within it. This information is helpful when customizing charts for a custom catalog. The `questions.yaml`, `README.md`, and `requirements.yml` files are specific to Rancher charts, but are optional for chart customization.
```
charts/<APPLICATION>/<APP_VERSION>/
|--charts/ # Directory containing dependency charts.
|--templates/ # Directory containing templates that, when combined with values.yml, generates Kubernetes YAML.
|--app-readme.md # Text displayed in the charts header within the Rancher UI.*
|--Chart.yml # Required Helm chart information file.
|--questions.yml # Form questions displayed within the Rancher UI. Questions display in Configuration Options.*
|--README.md # Optional: Helm Readme file displayed within Rancher UI. This text displays in Detailed Descriptions.
|--requirements.yml # Optional: YAML file listing dependencies for the chart.
|--values.yml # Default configuration values for the chart.
<Repository-Base>/
│
├── charts/
│ ├── <Application Name>/ # This directory name will be surfaced in the Rancher UI as the chart name
│ │ ├── <App Version>/ # Each directory at this level provides different app versions that will be selectable within the chart in the Rancher UI
│ │ │ ├── Chart.yaml # Required Helm chart information file.
│ │ │ ├── questions.yaml # Form questions displayed within the Rancher UI. Questions display in Configuration Options.*
│ │ │ ├── README.md # Optional: Helm Readme file displayed within Rancher UI. This text displays in Detailed Descriptions.
│ │ │ ├── requirements.yml # Optional: YAML file listing dependencies for the chart.
│ │ │ ├── values.yml # Default configuration values for the chart.
│ │ │ ├── templates/ # Directory containing templates that, when combined with values.yml, generates Kubernetes YAML.
```
# Additional Files for Rancher Charts
content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/helm2/_index.md
+1
View File
@@ -7,6 +7,7 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/ha/helm2
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades/ha/helm2
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades/helm2
- /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/helm2/
---
> Helm 3 has been released. If you are using Helm 2, we recommend [migrating to Helm 3](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) because it is simpler to use and more secure than Helm 2.
content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/migrating-from-rke-add-on/_index.md
+1
View File
@@ -7,6 +7,7 @@ aliases:
- /rancher/v2.0-v2.4/en/upgrades/upgrades/migrating-from-rke-add-on
- /rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/migrating-from-rke-add-on
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades/migrating-from-rke-add-on
- /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/migrating-from-rke-add-on/
---
> **Important: RKE add-on install is only supported up to Rancher v2.0.8**
content/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades/namespace-migration/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/upgrades/upgrades/namespace-migration
- /rancher/v2.0-v2.4/en/installation/upgrades-rollbacks/upgrades/namespace-migration
- /rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/upgrades-rollbacks/upgrades/namespace-migration
- /rancher/v2.x/en/installation/install-rancher-on-k8s/upgrades/namespace-migration/
---
>This section applies only to Rancher upgrades from v2.0.6 or earlier to v2.0.7 or later. Upgrades from v2.0.7 to later version are unaffected.
content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md
+1 -1
View File
@@ -86,7 +86,7 @@ During upgrade, you create a copy of the data from your current Rancher containe
```
docker run --volumes-from rancher-data -v $PWD:/backup busybox tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz /var/lib/rancher
```
**Step Result:** When you enter this command, a series of commands should run.
content/rancher/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/_index.md
+1
View File
@@ -6,6 +6,7 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/
- /rancher/v2.0-v2.4/en/installation/air-gap-single-node/
- /rancher/v2.0-v2.4/en/installation/options/air-gap-helm2
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/
---
> After Helm 3 was released, the Rancher installation instructions were updated to use Helm 3.
content/rancher/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/_index.md
+1
View File
@@ -8,6 +8,7 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-single-node/install-rancher
- /rancher/v2.0-v2.4/en/installation/air-gap/install-rancher
- /rancher/v2.0-v2.4/en/installation/options/air-gap-helm2/install-rancher
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/install-rancher/
---
This section is about how to deploy Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
content/rancher/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/launch-kubernetes/_index.md
+1
View File
@@ -4,6 +4,7 @@ weight: 300
aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/install-kube
- /rancher/v2.0-v2.4/en/installation/options/air-gap-helm2/launch-kubernetes
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/launch-kubernetes/
---
This section is about how to prepare to launch a Kubernetes cluster which is used to deploy Rancher server for your air gapped environment.
content/rancher/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/_index.md
+1
View File
@@ -8,6 +8,7 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-single-node/config-rancher-for-private-reg/
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/config-rancher-for-private-reg/
- /rancher/v2.0-v2.4/en/installation/options/air-gap-helm2/populate-private-registry
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/
---
> **Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use.
content/rancher/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/prepare-nodes/_index.md
+1
View File
@@ -5,6 +5,7 @@ aliases:
- /rancher/v2.0-v2.4/en/installation/air-gap-high-availability/provision-hosts
- /rancher/v2.0-v2.4/en/installation/air-gap-single-node/provision-host
- /rancher/v2.0-v2.4/en/installation/options/air-gap-helm2/prepare-nodes
- /rancher/v2.x/en/installation/resources/advanced/air-gap-helm2/prepare-nodes/
---
This section is about how to prepare your node(s) to install Rancher for your air gapped environment. An air gapped environment could be where Rancher server will be installed offline, behind a firewall, or behind a proxy. There are _tabs_ for either a high availability (recommended) or a Docker installation.
content/rancher/v2.0-v2.4/en/installation/resources/advanced/arm64-platform/_index.md
+18 -2
View File
@@ -12,14 +12,30 @@ aliases:
The following options are available when using an ARM64 platform:
- Running Rancher on ARM64 based node(s)
- Only [Docker Install]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker)
- Only for Docker Install. Please note that the following installation command replaces the examples found in the [Docker Install]({{<baseurl>}}/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker) link:
```
# In the last line `rancher/rancher:vX.Y.Z`, be certain to replace "X.Y.Z" with a released version in which ARM64 builds exist. For example, if your matching version is v2.5.8, you would fill in this line with `rancher/rancher:v2.5.8`.
docker run -d --restart=unless-stopped \
-p 80:80 -p 443:443 \
--privileged \
rancher/rancher:vX.Y.Z
```
> **Note:** To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your
> version's release notes in the following two ways:
>
> - Manually find your version using https://github.com/rancher/rancher/releases.
> - Go directly to your version using the tag and the specific version number. If you plan to use v2.5.8, for example, you may
> navigate to https://github.com/rancher/rancher/releases/tag/v2.5.8.
- Create custom cluster and adding ARM64 based node(s)
- Kubernetes cluster version must be 1.12 or higher
- CNI Network Provider must be [Flannel]({{<baseurl>}}/rancher/v2.0-v2.4/en/faq/networking/cni-providers/#flannel)
- Importing clusters that contain ARM64 based nodes
- Kubernetes cluster version must be 1.12 or higher
Please see [Cluster Options]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/) how to configure the cluster options.
Please see [Cluster Options]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters/options/) for information on how to configure the cluster options.
The following features are not tested:

Some files were not shown because too many files have changed in this diff Show More