diff --git a/content/_index.html b/content/_index.html index fe7f300004c..6eaf499e547 100644 --- a/content/_index.html +++ b/content/_index.html @@ -91,6 +91,7 @@
+
+
+
+
+
+

+ RKE2 + RKE2 +

+ +
+ +

RKE2, also known as RKE Government, is Rancher's next-generation Kubernetes distribution.

+ +
+ + + +
+
+
+ +
+
+

+ Longhorn + Longhorn +

+ +
+ +

Longhorn is a lightweight, reliable, and powerful distributed block storage system for Kubernetes.

+ +
+ + + +
+
+
+ + diff --git a/content/k3s/latest/en/advanced/_index.md b/content/k3s/latest/en/advanced/_index.md index 494650ebf82..c8effe5793e 100644 --- a/content/k3s/latest/en/advanced/_index.md +++ b/content/k3s/latest/en/advanced/_index.md @@ -13,7 +13,6 @@ This section contains advanced information describing the different ways you can - [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 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) @@ -127,8 +126,8 @@ If you would like to use etcdctl after installing K3s with embedded etcd, instal ``` $ VERSION="v3.5.0" -$ curl -L https://github.com/etcd-io/etcd/releases/download/${VERSION}/etcd-${VERSION}-linux-amd64.tar.gz --output etcdctl-${VERSION}-linux-amd64.tar.gz -$ sudo tar -zxvf etcdctl-${VERSION}-linux-amd64.tar.gz -C /usr/local/bin +$ 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: @@ -145,44 +144,6 @@ 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 Rootless mode (Experimental) diff --git a/content/k3s/latest/en/backup-restore/_index.md b/content/k3s/latest/en/backup-restore/_index.md index 447cabc14f2..27252dbb6fb 100644 --- a/content/k3s/latest/en/backup-restore/_index.md +++ b/content/k3s/latest/en/backup-restore/_index.md @@ -32,13 +32,13 @@ In this section, you'll learn how to create backups of the K3s cluster data and 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: diff --git a/content/k3s/latest/en/installation/airgap/_index.md b/content/k3s/latest/en/installation/airgap/_index.md index 91d37c00830..303cebab4b9 100644 --- a/content/k3s/latest/en/installation/airgap/_index.md +++ b/content/k3s/latest/en/installation/airgap/_index.md @@ -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 %}} diff --git a/content/k3s/latest/en/installation/datastore/_index.md b/content/k3s/latest/en/installation/datastore/_index.md index 059d73e16fe..b5476b42f35 100644 --- a/content/k3s/latest/en/installation/datastore/_index.md +++ b/content/k3s/latest/en/installation/datastore/_index.md @@ -23,7 +23,7 @@ If you wish to use an external datastore such as PostgreSQL, MySQL, or etcd you CLI Flag | Environment Variable | Description ------------|-------------|------------------ - `--datastore-endpoint` | `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. + `--datastore-endpoint` | `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. `--datastore-cafile` | `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. | | `--datastore-certfile` | `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. | | `--datastore-keyfile` | `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 %}} -
Based on the above, the following example command could be used to launch a server instance that connects to a PostgresSQL database named k3s: +
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 ``` diff --git a/content/k3s/latest/en/installation/ha-embedded/_index.md b/content/k3s/latest/en/installation/ha-embedded/_index.md index f8fe7d2ebea..9526a67c61e 100644 --- a/content/k3s/latest/en/installation/ha-embedded/_index.md +++ b/content/k3s/latest/en/installation/ha-embedded/_index.md @@ -23,3 +23,9 @@ K3S_TOKEN=SECRET k3s server --server https://: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` diff --git a/content/k3s/latest/en/installation/ha/_index.md b/content/k3s/latest/en/installation/ha/_index.md index 00c082d2ac5..a7bc5491eac 100644 --- a/content/k3s/latest/en/installation/ha/_index.md +++ b/content/k3s/latest/en/installation/ha/_index.md @@ -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]({{}}/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]({{}}/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]({{}}/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 ``` diff --git a/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md b/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md index 25aa9b43567..d7392feba23 100644 --- a/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md +++ b/content/k3s/latest/en/installation/install-options/how-to-flags/_index.md @@ -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 -``` \ No newline at end of file +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 +``` diff --git a/content/k3s/latest/en/installation/installation-requirements/_index.md b/content/k3s/latest/en/installation/installation-requirements/_index.md index 1b5d14825de..3daee8b3ccc 100644 --- a/content/k3s/latest/en/installation/installation-requirements/_index.md +++ b/content/k3s/latest/en/installation/installation-requirements/_index.md @@ -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.
Inbound Rules for K3s Server Nodes
diff --git a/content/k3s/latest/en/installation/kube-dashboard/_index.md b/content/k3s/latest/en/installation/kube-dashboard/_index.md index cb5c15bfc36..880a16c630d 100644 --- a/content/k3s/latest/en/installation/kube-dashboard/_index.md +++ b/content/k3s/latest/en/installation/kube-dashboard/_index.md @@ -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 ``` diff --git a/content/k3s/latest/en/installation/network-options/_index.md b/content/k3s/latest/en/installation/network-options/_index.md index 4b66327f51a..dcc65a03aea 100644 --- a/content/k3s/latest/en/installation/network-options/_index.md +++ b/content/k3s/latest/en/installation/network-options/_index.md @@ -72,6 +72,8 @@ You should see that IP forwarding is set to true. ### 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: ``` diff --git a/content/k3s/latest/en/networking/_index.md b/content/k3s/latest/en/networking/_index.md index 49ed55deb46..2dff22e927d 100644 --- a/content/k3s/latest/en/networking/_index.md +++ b/content/k3s/latest/en/networking/_index.md @@ -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. diff --git a/content/k3s/latest/en/security/hardening_guide/_index.md b/content/k3s/latest/en/security/hardening_guide/_index.md index 6a66acc02aa..90e888a8cd4 100644 --- a/content/k3s/latest/en/security/hardening_guide/_index.md +++ b/content/k3s/latest/en/security/hardening_guide/_index.md @@ -302,11 +302,25 @@ spec: - Ingress ``` -If you are using the default traefik ingress controller with k3s, it will also be blocked by default, so the following network policies must be added to allow traffic to both traefik pods and svclb pods in the kube-system namespace. For version 1.20 and below there is a different label `traefik` used than in 1.21 and above, so remove the one that is not associated with your Kubernetes version. +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 @@ -319,7 +333,7 @@ spec: policyTypes: - Ingress --- -# 1.20 +# Below is for 1.20 ONLY -- remove if on 1.21 or above apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: @@ -334,7 +348,7 @@ spec: policyTypes: - Ingress --- -# 1.21 +# Below is for 1.21 and above ONLY -- remove if on 1.20 or below apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: diff --git a/content/k3s/latest/en/security/secrets_encryption/_index.md b/content/k3s/latest/en/security/secrets_encryption/_index.md new file mode 100644 index 00000000000..b91bc4d081a --- /dev/null +++ b/content/k3s/latest/en/security/secrets_encryption/_index.md @@ -0,0 +1,237 @@ +--- +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: + +>**Note:** 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. \ No newline at end of file diff --git a/content/k3s/latest/en/upgrades/automated/_index.md b/content/k3s/latest/en/upgrades/automated/_index.md index 32264b4eeed..f95da7de0e5 100644 --- a/content/k3s/latest/en/upgrades/automated/_index.md +++ b/content/k3s/latest/en/upgrades/automated/_index.md @@ -38,7 +38,7 @@ To automate upgrades in this manner, you must do the following: ### 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: ``` -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. diff --git a/content/os/v1.x/en/configuration/_index.md b/content/os/v1.x/en/configuration/_index.md index 209b96ea3b4..15a11fcaaa2 100644 --- a/content/os/v1.x/en/configuration/_index.md +++ b/content/os/v1.x/en/configuration/_index.md @@ -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 `#!` (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`. diff --git a/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md index e9a43d062f2..987ab8e966a 100644 --- a/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md +++ b/content/rancher/v2.0-v2.4/en/admin-settings/authentication/ping-federate/_index.md @@ -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. diff --git a/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md index 6185daa0bee..6e155df7033 100644 --- a/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md +++ b/content/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/_index.md @@ -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. diff --git a/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md b/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md index b7026acc4a4..bfc20ae2b48 100644 --- a/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md +++ b/content/rancher/v2.0-v2.4/en/backups/restore/rke-restore/v2.0-v2.1/_index.md @@ -28,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]({{}}/rancher/v2.x/en/upgrades/rollbacks/). +3. Rollback Rancher following the [normal instructions]({{}}/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. diff --git a/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md b/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md index d85e5a22cbf..5e23755f729 100644 --- a/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md +++ b/content/rancher/v2.0-v2.4/en/best-practices/management/_index.md @@ -4,6 +4,7 @@ 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/ --- @@ -86,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]({{}}/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. diff --git a/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md index 9774a89c470..545de58bf84 100644 --- a/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.0-v2.4/en/cluster-admin/projects-and-namespaces/_index.md @@ -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]({{}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles). To add members: diff --git a/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md b/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md index a0928f9373a..73d1f6efe48 100644 --- a/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md +++ b/content/rancher/v2.0-v2.4/en/helm-charts/creating-apps/_index.md @@ -128,4 +128,4 @@ This reference contains variables that you can use in `questions.yml` nested und # Tutorial: Example Custom Chart Creation -For a tutorial on adding a custom Helm chart to a custom catalog, refer to [this page.]({{}}/rancher/v2.x/en/catalog/tutorial) +For a tutorial on adding a custom Helm chart to a custom catalog, refer to [this page.]({{}}/rancher/v2.0-v2.4/en/catalog/tutorial) diff --git a/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md b/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md index be69fcd235e..7e7e935097c 100644 --- a/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md +++ b/content/rancher/v2.0-v2.4/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md @@ -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--.tar.gz /var/lib/rancher + docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher ``` **Step Result:** When you enter this command, a series of commands should run. diff --git a/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md b/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md index 40f9c5294d2..3c32084c5e6 100644 --- a/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md +++ b/content/rancher/v2.0-v2.4/en/installation/resources/tls-secrets/_index.md @@ -35,4 +35,4 @@ kubectl -n cattle-system create secret generic tls-ca \ # Updating a Private CA Certificate -Follow the steps on [this page]({{}}/rancher/v2.x/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. \ No newline at end of file +Follow the steps on [this page]({{}}/rancher/v2.0-v2.4/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.0-v2.4/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. \ No newline at end of file diff --git a/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md b/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md index afac8412a3f..c637928995d 100644 --- a/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md +++ b/content/rancher/v2.0-v2.4/en/overview/concepts/_index.md @@ -52,7 +52,7 @@ Three etcd nodes is generally sufficient for smaller clusters and five etcd node ### Controlplane Nodes -Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles. +Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although three or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles. ### Worker Nodes @@ -69,4 +69,4 @@ For high-availability installations of Rancher, Helm is the tool used to install Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh). -For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) \ No newline at end of file +For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) diff --git a/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md b/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md index 47f4c7eddfe..a0a4a0922d7 100644 --- a/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md +++ b/content/rancher/v2.0-v2.4/en/project-admin/project-members/_index.md @@ -42,6 +42,8 @@ Following project creation, you can add users as project members so that they ca > >- 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. + > >- For `Custom` roles, you can modify the list of individual roles available for assignment. > > - To add roles to the list, [Add a Custom Role]({{}}/rancher/v2.0-v2.4/en/admin-settings/rbac/default-custom-roles). diff --git a/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md b/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md index 48a98a37919..169b5d84104 100644 --- a/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md +++ b/content/rancher/v2.0-v2.4/en/troubleshooting/dns/_index.md @@ -158,7 +158,7 @@ kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{ Enabling query logging can be done by enabling the [log plugin](https://coredns.io/plugins/log/) in the Corefile configuration in the configmap `coredns`. You can do so by using `kubectl -n kube-system edit configmap coredns` or use the command below to replace the configuration in place: ``` -kubectl get configmap -n kube-system coredns -o json | kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f - +kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f - ``` All queries will now be logged and can be checked using the command in [Check CoreDNS logging](#check-coredns-logging). diff --git a/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md index 87abce2b877..525717bb7b9 100644 --- a/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md +++ b/content/rancher/v2.5/en/admin-settings/authentication/ping-federate/_index.md @@ -30,6 +30,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. diff --git a/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md index 6c82e42e726..4996f82ab54 100644 --- a/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md +++ b/content/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/_index.md @@ -86,6 +86,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. @@ -94,7 +98,6 @@ _Project roles_ are roles that can be used to grant users access to a project. T > >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. - #### Custom Project Roles Rancher lets you assign _custom project roles_ to a standard user instead of the typical `Owner`, `Member`, or `Read Only` roles. These roles can be either a built-in custom project role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a standard user within a project. See the table below for a list of built-in custom project roles. diff --git a/content/rancher/v2.5/en/api/_index.md b/content/rancher/v2.5/en/api/_index.md index c6c3fdb63e3..a36f5f9fea2 100644 --- a/content/rancher/v2.5/en/api/_index.md +++ b/content/rancher/v2.5/en/api/_index.md @@ -52,3 +52,17 @@ Most collections can be sorted on the server-side by common fields using HTTP qu ## Pagination API responses are paginated with a limit of 100 resources per page by default. This can be changed with the `limit` query parameter, up to a maximum of 1000, e.g. `/v3/pods?limit=1000`. The `pagination` map in collection responses tells you whether or not you have the full result set and has a link to the next page if you do not. + +## Capturing Rancher API Calls + +You can use browser developer tools to capture how the Rancher API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning an RKE cluster: + +1. In the Rancher UI, go to **Cluster Management** and click **Create.** +1. Click one of the cluster types. This example uses Digital Ocean. +1. Fill out the form with a cluster name and node template, but don't click **Create**. +1. You will need to open the developer tools before the cluster creation to see the API call being recorded. To open the tools, right-click on the Rancher UI and click **Inspect.** +1. In the developer tools, click the **Network** tab. +1. On the **Network** tab, make sure **Fetch/XHR** is selected. +1. In the Rancher UI, click **Create**. In the developer tools, you should see a new network request with the name `cluster?_replace=true`. +1. Right-click `cluster?_replace=true` and click **Copy > Copy as cURL.** +1. Paste the result into any text editor. You will be able to see the POST request, including the URL it was sent to, all of the headers, and the full body of the request. This command can be used to create a cluster from the command line. Note: The request should be stored in a safe place because it contains credentials. \ No newline at end of file diff --git a/content/rancher/v2.5/en/backups/_index.md b/content/rancher/v2.5/en/backups/_index.md index 0f765d2d84d..01b07a0db84 100644 --- a/content/rancher/v2.5/en/backups/_index.md +++ b/content/rancher/v2.5/en/backups/_index.md @@ -63,6 +63,8 @@ The Backup and Restore custom resources can be created in the Rancher UI, or by The `rancher-backup` operator can be installed from the Rancher UI, or with the Helm CLI. In both cases, the `rancher-backup` Helm chart is installed on the Kubernetes cluster running the Rancher server. It is a cluster-admin only feature and available only for the **local** cluster. (*If you do not see `rancher-backup` in the Rancher UI, you may have selected the wrong cluster.*) +>**NOTE:** There are two known issues in Fleet that occur after performing a restoration using the backup-restore-operator: Fleet agents are inoperable and clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}rancher/v2.5/en/deploy-across-clusters/fleet/#troubleshooting) for workarounds. + ### Installing rancher-backup with the Rancher UI 1. In the Rancher UI's Cluster Manager, choose the cluster named **local** diff --git a/content/rancher/v2.5/en/backups/back-up-rancher/_index.md b/content/rancher/v2.5/en/backups/back-up-rancher/_index.md index 4da253421c4..47f57c96e26 100644 --- a/content/rancher/v2.5/en/backups/back-up-rancher/_index.md +++ b/content/rancher/v2.5/en/backups/back-up-rancher/_index.md @@ -7,7 +7,7 @@ aliases: - /rancher/v2.x/en/backups/v2.5/back-up-rancher/ --- -In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer the instructions for [single node backups]({{}}/rancher/v2.5/en/backups/v2.5/docker-installs/docker-backups) +In this section, you'll learn how to back up Rancher running on any Kubernetes cluster. To backup Rancher installed with Docker, refer to the instructions for [single node backups]({{}}/rancher/v2.5/en/backups/v2.5/docker-installs/docker-backups). The backup-restore operator needs to be installed in the local cluster, and only backs up the Rancher app. The backup and restore operations are performed only in the local Kubernetes cluster. @@ -30,6 +30,8 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio, 1. Click **Rancher Backups.** 1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config) +>**NOTE:** There are two known issues in Fleet that occur after performing a restoration using the backup-restore-operator: Fleet agents are inoperable and clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}/rancher/v2.5/en/deploy-across-clusters/fleet/#troubleshooting) for workarounds. + ### 2. Perform a Backup To perform a backup, a custom resource of type Backup must be created. diff --git a/content/rancher/v2.5/en/cis-scans/_index.md b/content/rancher/v2.5/en/cis-scans/_index.md index 39cbc411e56..6f72660c12c 100644 --- a/content/rancher/v2.5/en/cis-scans/_index.md +++ b/content/rancher/v2.5/en/cis-scans/_index.md @@ -108,7 +108,7 @@ From Rancher v2.5.4, the scan uses the CIS Benchmark v1.6 by default. In Rancher The Benchmark version is included in the generated report. -The Benchmark provides recommendations of two types: Scored and Not Scored. Recommendations marked as Not Scored in the Benchmark are not included in the generated report. +The Benchmark provides recommendations of two types: Automated and Manual. Recommendations marked as Manual in the Benchmark are not included in the generated report. Some tests are designated as "Not Applicable." These tests will not be run on any CIS scan because of the way that Rancher provisions RKE clusters. For information on how test results can be audited, and why some tests are designated to be not applicable, refer to Rancher's self-assessment guide for the corresponding Kubernetes version. diff --git a/content/rancher/v2.5/en/cis-scans/skipped-tests/_index.md b/content/rancher/v2.5/en/cis-scans/skipped-tests/_index.md index 8f43f3946e0..3312a9c3940 100644 --- a/content/rancher/v2.5/en/cis-scans/skipped-tests/_index.md +++ b/content/rancher/v2.5/en/cis-scans/skipped-tests/_index.md @@ -17,42 +17,42 @@ This section lists the tests that are skipped in the permissive test profile for | Number | Description | Reason for Skipping | | ---------- | ------------- | --------- | -| 1.1.12 | Ensure that the etcd data directory ownership is set to etcd:etcd (Scored) | A system service account is required for etcd data directory ownership. Refer to Rancher's hardening guide for more details on how to configure this ownership. | -| 1.2.6 | Ensure that the --kubelet-certificate-authority argument is set as appropriate (Scored) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | -| 1.2.16 | Ensure that the admission control plugin PodSecurityPolicy is set (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 1.2.33 | Ensure that the --encryption-provider-config argument is set as appropriate (Not Scored) | Enabling encryption changes how data can be recovered as data is encrypted. | -| 1.2.34 | Ensure that encryption providers are appropriately configured (Not Scored) | Enabling encryption changes how data can be recovered as data is encrypted. | -| 4.2.6 | Ensure that the --protect-kernel-defaults argument is set to true (Scored) | System level configurations are required before provisioning the cluster in order for this argument to be set to true. | -| 4.2.10 | Ensure that the--tls-cert-file and --tls-private-key-file arguments are set as appropriate (Scored) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | -| 5.1.5 | Ensure that default service accounts are not actively used. (Scored) | Kubernetes provides default service accounts to be used. | -| 5.2.2 | Minimize the admission of containers wishing to share the host process ID namespace (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.3 | Minimize the admission of containers wishing to share the host IPC namespace (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.4 | Minimize the admission of containers wishing to share the host network namespace (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.5 | Minimize the admission of containers with allowPrivilegeEscalation (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.3.2 | Ensure that all Namespaces have Network Policies defined (Scored) | Enabling Network Policies can prevent certain applications from communicating with each other. | -| 5.6.4 | The default namespace should not be used (Scored) | Kubernetes provides a default namespace. | +| 1.1.12 | Ensure that the etcd data directory ownership is set to etcd:etcd (Automated) | A system service account is required for etcd data directory ownership. Refer to Rancher's hardening guide for more details on how to configure this ownership. | +| 1.2.6 | Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | +| 1.2.16 | Ensure that the admission control plugin PodSecurityPolicy is set (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 1.2.33 | Ensure that the --encryption-provider-config argument is set as appropriate (Manual) | Enabling encryption changes how data can be recovered as data is encrypted. | +| 1.2.34 | Ensure that encryption providers are appropriately configured (Manual) | Enabling encryption changes how data can be recovered as data is encrypted. | +| 4.2.6 | Ensure that the --protect-kernel-defaults argument is set to true (Automated) | System level configurations are required before provisioning the cluster in order for this argument to be set to true. | +| 4.2.10 | Ensure that the--tls-cert-file and --tls-private-key-file arguments are set as appropriate (Automated) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | +| 5.1.5 | Ensure that default service accounts are not actively used. (Automated) | Kubernetes provides default service accounts to be used. | +| 5.2.2 | Minimize the admission of containers wishing to share the host process ID namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.2.3 | Minimize the admission of containers wishing to share the host IPC namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.2.4 | Minimize the admission of containers wishing to share the host network namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.2.5 | Minimize the admission of containers with allowPrivilegeEscalation (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.3.2 | Ensure that all Namespaces have Network Policies defined (Automated) | Enabling Network Policies can prevent certain applications from communicating with each other. | +| 5.6.4 | The default namespace should not be used (Automated) | Kubernetes provides a default namespace. | ### CIS Benchmark v1.5 Not Applicable Tests | Number | Description | Reason for being not applicable | | ---------- | ------------- | --------- | -| 1.1.1 | Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | -| 1.1.2 | Ensure that the API server pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | -| 1.1.3 | Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.4 | Ensure that the controller manager pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.5 | Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.6 | Ensure that the scheduler pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.7 | Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | -| 1.1.8 | Ensure that the etcd pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | -| 1.1.13 | Ensure that the admin.conf file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | -| 1.1.14 | Ensure that the admin.conf file ownership is set to root:root (Scored) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | -| 1.1.15 | Ensure that the scheduler.conf file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.16 | Ensure that the scheduler.conf file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.17 | Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.18 | Ensure that the controller-manager.conf file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.3.6 | Ensure that the RotateKubeletServerCertificate argument is set to true (Scored) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | -| 4.1.1 | Ensure that the kubelet service file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | -| 4.1.2 | Ensure that the kubelet service file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | -| 4.1.9 | Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | -| 4.1.10 | Ensure that the kubelet configuration file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | -| 4.2.12 | Ensure that the RotateKubeletServerCertificate argument is set to true (Scored) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | \ No newline at end of file +| 1.1.1 | Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | +| 1.1.2 | Ensure that the API server pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | +| 1.1.3 | Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.1.4 | Ensure that the controller manager pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.1.5 | Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.6 | Ensure that the scheduler pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.7 | Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | +| 1.1.8 | Ensure that the etcd pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | +| 1.1.13 | Ensure that the admin.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | +| 1.1.14 | Ensure that the admin.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | +| 1.1.15 | Ensure that the scheduler.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.16 | Ensure that the scheduler.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.17 | Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.1.18 | Ensure that the controller-manager.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.3.6 | Ensure that the RotateKubeletServerCertificate argument is set to true (Automated) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | +| 4.1.1 | Ensure that the kubelet service file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | +| 4.1.2 | Ensure that the kubelet service file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | +| 4.1.9 | Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | +| 4.1.10 | Ensure that the kubelet configuration file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | +| 4.2.12 | Ensure that the RotateKubeletServerCertificate argument is set to true (Automated) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | \ No newline at end of file diff --git a/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md b/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md index b3f52ad2d3f..37aa93ed56f 100644 --- a/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md +++ b/content/rancher/v2.5/en/cluster-admin/certificate-rotation/_index.md @@ -12,7 +12,8 @@ By default, Kubernetes clusters require certificates and Rancher launched Kubern Certificates can be rotated for the following services: - etcd -- kubelet +- kubelet (node certificate) +- kubelet (serving certificate, if [enabled]({{}}/rke/latest/en/config-options/services/#kubelet-options)) - kube-apiserver - kube-proxy - kube-scheduler diff --git a/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md b/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md index bb4e31086c1..0ea3ab8ad80 100644 --- a/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md +++ b/content/rancher/v2.5/en/cluster-admin/editing-clusters/eks-config-reference/_index.md @@ -16,7 +16,7 @@ Complete each drop-down and field using the information obtained for your IAM po | Setting | Description | | ---------- | -------------------------------------------------------------------------------------------------------------------- | | Region | From the drop-down choose the geographical region in which to build your cluster. | -| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.x/en/user-settings/cloud-credentials/) | +| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.5/en/user-settings/cloud-credentials/) | ### Service Role @@ -186,7 +186,7 @@ Complete each drop-down and field using the information obtained for your IAM po | Setting | Description | | ---------- | -------------------------------------------------------------------------------------------------------------------- | | Region | From the drop-down choose the geographical region in which to build your cluster. | -| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.x/en/user-settings/cloud-credentials/) | +| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.5/en/user-settings/cloud-credentials/) | ### Service Role diff --git a/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md b/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md index d66fdb087bd..9de7dbf3c1d 100644 --- a/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md +++ b/content/rancher/v2.5/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md @@ -25,7 +25,7 @@ If restricting outgoing internet access is not a concern for your organization, >**Note** >This scenario is not officially supported, but is described for cases in which using the Cloud NAT service is not sufficient. -If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.x/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it. +If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.5/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it. ### Private Control Plane Endpoint diff --git a/content/rancher/v2.5/en/cluster-admin/nodes/_index.md b/content/rancher/v2.5/en/cluster-admin/nodes/_index.md index 514ebc67a18..af48e6fa950 100644 --- a/content/rancher/v2.5/en/cluster-admin/nodes/_index.md +++ b/content/rancher/v2.5/en/cluster-admin/nodes/_index.md @@ -42,11 +42,11 @@ The following table lists which node options are available for each type of clus | [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | | Download SSH key in order to SSH into the node. | | [Node Scaling](#scaling-nodes) | ✓ | | | ✓ | | Scale the number of nodes in the node pool up or down. | -[1]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ -[2]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/ -[3]: {{}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ -[4]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/ -[5]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/ +[1]: {{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/node-pools/ +[2]: {{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/custom-nodes/ +[3]: {{}}/rancher/v2.5/en/cluster-provisioning/hosted-kubernetes-clusters/ +[4]: {{}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/ +[5]: {{}}/rancher/v2.5/en/cluster-provisioning/registered-clusters/ \* Delete option accessible via View API diff --git a/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md index 86c6574c224..493331bc93c 100644 --- a/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.5/en/cluster-admin/projects-and-namespaces/_index.md @@ -156,6 +156,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]({{}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles). To add members: diff --git a/content/rancher/v2.5/en/cluster-provisioning/_index.md b/content/rancher/v2.5/en/cluster-provisioning/_index.md index a46b43f5dc9..8fe1bc1c856 100644 --- a/content/rancher/v2.5/en/cluster-provisioning/_index.md +++ b/content/rancher/v2.5/en/cluster-provisioning/_index.md @@ -25,7 +25,6 @@ This section covers the following topics: - [Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider](#launching-kubernetes-and-provisioning-nodes-in-an-infrastructure-provider) - [Launching Kubernetes on Existing Custom Nodes](#launching-kubernetes-on-existing-custom-nodes) - [Registering Existing Clusters](#registering-existing-clusters) -- [Importing Existing Clusters](#importing-existing-clusters) diff --git a/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md b/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md index 8791b91df96..22995693f7a 100644 --- a/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md +++ b/content/rancher/v2.5/en/cluster-provisioning/registered-clusters/_index.md @@ -20,6 +20,17 @@ The control that Rancher has to manage a registered cluster depends on the type # Prerequisites +{{% tabs %}} +{{% tab "v2.5.9+" %}} + +## Kubernetes Node Roles + +Registered RKE Kubernetes clusters must have all three node roles - etcd, controlplane and worker. A cluster with only controlplane components cannot be registered in Rancher. + +For more information on RKE node roles, see the [best practices.]({{}}/rancher/v2.5/en/cluster-provisioning/production/#cluster-architecture) + +## Permissions + If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher. In order to apply the privilege, you need to run: @@ -36,6 +47,29 @@ By default, GKE users are not given this privilege, so you will need to run the If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher) +{{% /tab %}} +{{% tab "Rancher before v2.5.9" %}} + +## Permissions + +If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher. + +In order to apply the privilege, you need to run: + +```plain +kubectl create clusterrolebinding cluster-admin-binding \ + --clusterrole cluster-admin \ + --user [USER_ACCOUNT] +``` + +before running the `kubectl` command to register the cluster. + +By default, GKE users are not given this privilege, so you will need to run the command before registering GKE clusters. To learn more about role-based access control for GKE, please click [here](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control). + +If you are registering a K3s cluster, make sure the `cluster.yml` is readable. It is protected by default. For details, refer to [Configuring a K3s cluster to enable importation to Rancher.](#configuring-a-k3s-cluster-to-enable-registration-in-rancher) +{{% /tab %}} +{{% /tabs %}} + # Registering a Cluster 1. From the **Clusters** page, click **Add Cluster**. diff --git a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md index 662af99a33d..63b3bfddcbd 100644 --- a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md +++ b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/_index.md @@ -158,7 +158,7 @@ Option to enable or disable [recurring etcd snapshots]({{}}/rke/latest/ _Available as of v2.5.6_ -Option to set environment variables for [rancher agents]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables. +Option to set environment variables for [rancher agents]({{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables. # Cluster Config File diff --git a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md index 37ff393eded..16bf34656c1 100644 --- a/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md +++ b/content/rancher/v2.5/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md @@ -85,7 +85,7 @@ If you are configuring DHCP options sets for an AWS virtual private cloud, note > Some Linux operating systems accept multiple domain names separated by spaces. However, other Linux operating systems and Windows treat the value as a single domain, which results in unexpected behavior. If your DHCP options set is associated with a VPC that has instances with multiple operating systems, specify only one domain name. -#### Rancher on vSphere with ESXi 6.7u2 and above +### Rancher on vSphere with ESXi 6.7u2 and above If you are using Rancher on VMware vSphere with ESXi 6.7u2 or later with Red Hat Enterprise Linux 8.3, CentOS 8.3, or SUSE Enterprise Linux 15 SP2 or later, it is necessary to disable the `vmxnet3` virtual network adapter hardware offloading feature. Failure to do so will result in all network connections between pods on different cluster nodes to fail with timeout errors. All connections from Windows pods to critical services running on Linux nodes, such as CoreDNS, will fail as well. It is also possible that external connections may fail. This issue is the result of Linux distributions enabling the hardware offloading feature in `vmxnet3` and a bug in the `vmxnet3` hardware offloading feature that results in the discarding of packets for guest overlay traffic. To address this issue, it is necessary disable the `vmxnet3` hardware offloading feature. This setting does not survive reboot, so it is necessary to disable on every boot. The recommended course of action is to create a systemd unit file at `/etc/systemd/system/disable_hw_offloading.service`, which disables the `vmxnet3` hardware offloading feature on boot. A sample systemd unit file which disables the `vmxnet3` hardware offloading feature is as follows. Note that `` must be customized to the host `vmxnet3` network interface, e.g., `ens192`: diff --git a/content/rancher/v2.5/en/contributing/_index.md b/content/rancher/v2.5/en/contributing/_index.md index 3f27aced56a..f7db1880021 100644 --- a/content/rancher/v2.5/en/contributing/_index.md +++ b/content/rancher/v2.5/en/contributing/_index.md @@ -81,7 +81,7 @@ Please follow this checklist when filing an issue which will helps us investigat ``` - Kubernetes install using `kubectl` - > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` if Rancher is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. + > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if Rancher is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. ``` kubectl -n cattle-system \ @@ -98,7 +98,7 @@ Please follow this checklist when filing an issue which will helps us investigat ``` - Kubernetes Install with RKE Add-On - > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. + > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. ``` kubectl -n cattle-system \ diff --git a/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md b/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md index abea9bad31e..9774589340a 100644 --- a/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md +++ b/content/rancher/v2.5/en/deploy-across-clusters/fleet/_index.md @@ -16,6 +16,8 @@ Fleet is a separate project from Rancher, and can be installed on any Kubernetes - [Windows Support](#windows-support) - [GitHub Repository](#github-repository) - [Using Fleet Behind a Proxy](#using-fleet-behind-a-proxy) +- [Helm Chart Dependencies](#helm-chart-dependencies) +- [Troubleshooting](#troubleshooting) - [Documentation](#documentation) # Architecture @@ -24,7 +26,24 @@ For information about how Fleet works, see [this page.](./architecture) # Accessing Fleet in the Rancher UI -Fleet comes preinstalled in Rancher v2.5. To access it, go to the **Cluster Explorer** in the Rancher UI. In the top left dropdown menu, click **Cluster Explorer > Continuous Delivery.** On this page, you can edit Kubernetes resources and cluster groups managed by Fleet. +Fleet comes preinstalled in Rancher v2.5. Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/). + +Follow the steps below to access Continuous Delivery in the Rancher UI: + +1. Click **Cluster Explorer** in the Rancher UI. + +1. In the top left dropdown menu, click **Cluster Explorer > Continuous Delivery.** + +1. Select your namespace at the top of the menu, noting the following: + - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. + - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. + - You can then manage clusters by clicking on **Clusters** on the left navigation bar. + +1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. + +1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar. + +1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI. # Windows Support @@ -44,6 +63,31 @@ _Available as of v2.5.8_ For details on using Fleet behind a proxy, see [this page.](./proxy) +# Helm Chart Dependencies + +In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing. + +The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` OR run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters. + +# Troubleshooting +--- +* **Known Issue:** Fleet becomes inoperable after a restore using the [backup-restore-operator]({{}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place. + +* **Temporary Workaround:**
+ 1. Find the two service account tokens listed in the fleet-controller and the fleet-controller-bootstrap service accounts. These are under the fleet-system namespace of the local cluster.
+ 2. Remove the non-existent token secret. Doing so allows for only one entry to be present for the service account token secret that actually exists.
+ 3. Delete the fleet-controller Pod in the fleet-system namespace to reschedule.
+ 4. After the service account token issue is resolved, you can force redeployment of the fleet-agents. In the Rancher UI, go to **☰ > Cluster Management**, click on **Clusters** page, then click **Force Update**.
+ 5. If the fleet-agent bundles remain in a `Modified` state after Step 4, update the field `spec.forceSyncGeneration` for the fleet-agent bundle to force re-creation. + +--- +* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{}}/rancher/v2.5/en/backups/back-up-rancher/#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place. + +* **Temporary Workaround:**
+By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow). + +--- + # Documentation The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/) diff --git a/content/rancher/v2.5/en/faq/kubectl/_index.md b/content/rancher/v2.5/en/faq/kubectl/_index.md index 3414564db95..ad0c7764cbe 100644 --- a/content/rancher/v2.5/en/faq/kubectl/_index.md +++ b/content/rancher/v2.5/en/faq/kubectl/_index.md @@ -13,12 +13,12 @@ See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubect ### Configuration -When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_rancher-cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`. +When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`. -You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`. +You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`. ``` -export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml +export KUBECONFIG=$(pwd)/kube_config_cluster.yml ``` Test your connectivity with `kubectl` and see if you can get the list of nodes back. diff --git a/content/rancher/v2.5/en/faq/technical/_index.md b/content/rancher/v2.5/en/faq/technical/_index.md index 4aaecf857cb..9ea91ea6d92 100644 --- a/content/rancher/v2.5/en/faq/technical/_index.md +++ b/content/rancher/v2.5/en/faq/technical/_index.md @@ -16,7 +16,7 @@ New password for default administrator (user-xxxxx): Kubernetes install (Helm): ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- reset-password New password for default administrator (user-xxxxx): @@ -35,7 +35,7 @@ New password for default administrator (user-xxxxx): Kubernetes install (Helm): ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin New password for default administrator (user-xxxxx): @@ -173,3 +173,8 @@ In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. Se ### Can I use keyboard shortcuts in the UI? Yes, most parts of the UI can be reached using keyboard shortcuts. For an overview of the available shortcuts, press `?` anywhere in the UI. + + +### What does `Unknown schema for type:` errors followed by something like `catalog.cattle.io.operation` mean when trying to modify an App? + +This error occurs when Kubernetes can not find the CRD mentioned. The vast majority of the time these are a result of missing RBAC permissions. Try with an admin user and if this works, add permissions for the resource mentioned by the error (ie. `Get`, `List`, `Patch` as needed). diff --git a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md index 01d5ee5f778..94497592e86 100644 --- a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md +++ b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/_index.md @@ -190,6 +190,8 @@ deployment "rancher" successfully rolled out This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA. +>**Note:**: You need to have port 80 open as the HTTP-01 challenge can only be done on port 80. + In the following command, - Set `hostname` to the public DNS record that resolves to your load balancer. diff --git a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/rollbacks/_index.md b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/rollbacks/_index.md index 8f7a32d5b0b..185435db22c 100644 --- a/content/rancher/v2.5/en/installation/install-rancher-on-k8s/rollbacks/_index.md +++ b/content/rancher/v2.5/en/installation/install-rancher-on-k8s/rollbacks/_index.md @@ -17,7 +17,7 @@ aliases: # Rolling Back to Rancher v2.5.0+ -To roll back to Rancher v2.5.0+, use the `rancher-backup` application and restore Rancher from backup. +To roll back to Rancher v2.5.0+, use the **Rancher Backups** application and restore Rancher from backup. Rancher has to be started with the lower/previous version after a rollback. @@ -26,13 +26,13 @@ A restore is performed by creating a Restore custom resource. > **Important** > > * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{}}/rancher/v2.5/en/backups/migrating-rancher) -> * While restoring Rancher on the same setup, the Rancher deployment is manually scaled down before the restore starts, then the operator will scale it back up once the restore completes. So Rancher will be unavailable during the restore. +> * While restoring Rancher on the same setup, the Rancher deployment is manually scaled down before the restore starts, then the operator will scale it back up once the restore completes. As a result, Rancher and its UI will be unavailable until the restore is complete. While the UI is unavailable, use the original cluster kubeconfig with the restore YAML file: `kubectl create -f restore.yaml`. ### Scale the Rancher Deployment to 0 1. From the **Global** view, hover over the **local** cluster. 1. Under **Projects in local**, click on **System**. -1. From the **cattle-system** namespace section, find the `rancher-hook` deployment. +1. From the **cattle-system** namespace section, find the `rancher` deployment. 1. Select **⋮ > Edit**. 1. Change **Scalable deployment of _ pods** to `0`. 1. Scroll to the bottom and click **Save**. @@ -40,9 +40,10 @@ A restore is performed by creating a Restore custom resource. ### Create the Restore Custom Resource 1. In the **Cluster Explorer,** go to the dropdown menu in the upper left corner and click **Rancher Backups.** + * **Note:** If the Rancher Backups app is not visible in the dropdown, you will need to install it from the Charts page in **Apps & Marketplace**. Refer [here]({{}}/rancher/v2.5/en/helm-charts/#charts) for more information. 1. Click **Restore.** -1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference]({{}}/rancher/v2.5/en/backups/configuration/restore-config) and to the [examples.]({{}}/rancher/v2.5/en/backups/examples) -1. For using the YAML editor, we can click **Create > Create from YAML.** Enter the Restore YAML. +1. Create the Restore with the form or with YAML. For help creating the Restore resource using the online form, refer to the [configuration reference]({{}}/rancher/v2.5/en/backups/configuration/restore-config) and to the [examples.]({{}}/rancher/v2.5/en/backups/examples) +1. To use the YAML editor, you can click **Create > Create from YAML.** Enter the Restore YAML. The following is an example Restore custom resource: ```yaml apiVersion: resources.cattle.io/v1 @@ -61,8 +62,7 @@ A restore is performed by creating a Restore custom resource. region: us-west-2 endpoint: s3.us-west-2.amazonaws.com ``` - - For help configuring the Restore, refer to the [configuration reference]({{}}/rancher/v2.5/en/backups/v2.5/configuration/restore-config/) and to the [examples.]({{}}/rancher/v2.5/en/backups/v2.5/examples/) + For help configuring the Restore, refer to the [configuration reference]({{}}/rancher/v2.5/en/backups/configuration/restore-config) and to the [examples.]({{}}/rancher/v2.5/en/backups/examples) 1. Click **Create.** diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md index d97e2266801..78daa4f58a0 100644 --- a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md +++ b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/install-rancher/_index.md @@ -115,7 +115,8 @@ helm template cert-manager ./cert-manager-v1.5.1.tgz --output-dir . \ --namespace cert-manager \ --set image.repository=/quay.io/jetstack/cert-manager-controller \ --set webhook.image.repository=/quay.io/jetstack/cert-manager-webhook \ - --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector + --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector \ + --set startupapicheck.image.repository=/quay.io/jetstack/cert-manager-ctl ``` ### 4. Download the cert-manager CRD diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md index 53405d3762e..58578d7d8ff 100644 --- a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md +++ b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md @@ -209,7 +209,7 @@ rke up --config ./rancher-cluster.yml Save a copy of the following files in a secure location: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. +- `kube_config_cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. - `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.

_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._ {{% /tab %}} {{% /tabs %}} diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md index d42ee6f04e8..5c152feb541 100644 --- a/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md +++ b/content/rancher/v2.5/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md @@ -66,7 +66,7 @@ In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS helm repo add jetstack https://charts.jetstack.io helm repo update helm fetch jetstack/cert-manager --version v1.5.1 - helm template ./cert-manager-.tgz | grep -oP '(?<=image: ").*(?=")' >> ./rancher-images.txt + helm template ./cert-manager-.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt ``` 2. Sort and unique the images list to remove any overlap between the sources: @@ -237,7 +237,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are helm repo add jetstack https://charts.jetstack.io helm repo update helm fetch jetstack/cert-manager --version v0.12.0 - helm template ./cert-manager-.tgz | grep -oP '(?<=image: ").*(?=")' >> ./rancher-images.txt + helm template ./cert-manager-.tgz | | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt ``` 2. Sort and unique the images list to remove any overlap between the sources: diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md index fac08ab40c9..6e1de3f1ab6 100644 --- a/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md +++ b/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/install-rancher/_index.md @@ -60,14 +60,16 @@ Create a namespace: kubectl create namespace cattle-system ``` -And install Rancher with Helm. Rancher also needs a proxy configuration so that it can communicate with external application catalogs or retrieve Kubernetes version update metadata: +And install Rancher with Helm. Rancher also needs a proxy configuration so that it can communicate with external application catalogs or retrieve Kubernetes version update metadata. + +Note that `rancher.cattle-system` must be added to the noProxy list (as shown below) so that Fleet can communicate directly to Rancher with Kubernetes service DNS using service discovery. ``` helm upgrade --install rancher rancher-latest/rancher \ --namespace cattle-system \ --set hostname=rancher.example.com \ --set proxy=http://${proxy_host} - --set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local + --set noProxy=127.0.0.0/8\\,10.0.0.0/8\\,cattle-system.svc\\,172.16.0.0/12\\,192.168.0.0/16\\,.svc\\,.cluster.local,rancher.cattle-system ``` After waiting for the deployment to finish: diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md index d0b84f88830..e4326734a43 100644 --- a/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md +++ b/content/rancher/v2.5/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md @@ -114,12 +114,12 @@ After that, you can create the Kubernetes cluster by running: rke up --config rancher-cluster.yaml ``` -RKE creates a state file called `rancher-cluster.rkestate`, this is needed if you want to perform updates, modify your cluster configuration or restore it from a backup. It also creates a `kube_config_rancher-cluster.yaml` file, that you can use to connect to the remote Kubernetes cluster locally with tools like kubectl or Helm. Make sure to save all of these files in a secure location, for example by putting them into a version control system. +RKE creates a state file called `rancher-cluster.rkestate`, this is needed if you want to perform updates, modify your cluster configuration or restore it from a backup. It also creates a `kube_config_cluster.yaml` file, that you can use to connect to the remote Kubernetes cluster locally with tools like kubectl or Helm. Make sure to save all of these files in a secure location, for example by putting them into a version control system. To have a look at your cluster run: ``` -export KUBECONFIG=kube_config_rancher-cluster.yaml +export KUBECONFIG=kube_config_cluster.yaml kubectl cluster-info kubectl get pods --all-namespaces ``` @@ -141,7 +141,7 @@ default backend - 404 Save a copy of the following files in a secure location: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. +- `kube_config_cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. - `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates. > **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file. diff --git a/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md b/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md index ce5f6c3f6c2..6c55386d77d 100644 --- a/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md +++ b/content/rancher/v2.5/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md @@ -87,7 +87,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--.tar.gz /var/lib/rancher + docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher ``` **Step Result:** When you enter this command, a series of commands should run. diff --git a/content/rancher/v2.5/en/installation/requirements/_index.md b/content/rancher/v2.5/en/installation/requirements/_index.md index 887226232ff..5d4113fc217 100644 --- a/content/rancher/v2.5/en/installation/requirements/_index.md +++ b/content/rancher/v2.5/en/installation/requirements/_index.md @@ -62,6 +62,12 @@ If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).]({{ **Note:** If you have used a different file name from `rancher-cluster.yml`, then the kube config file will be named `kube_config_.yml`. -Move this file to `$HOME/.kube/config`, or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`: +Move this file to `$HOME/.kube/config`, or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`: ``` -export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml +export KUBECONFIG=$(pwd)/kube_config_cluster.yml ``` Test your connectivity with `kubectl` and see if all your nodes are in `Ready` state: @@ -156,7 +156,7 @@ This confirms that you have successfully installed a Kubernetes cluster that the Save a copy of the following files in a secure location: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. +- `kube_config_cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. - `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.

_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._ > **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file. diff --git a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md index 64d7472dbdd..788a80c1e4a 100644 --- a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md +++ b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/ha-rke2/_index.md @@ -8,7 +8,7 @@ aliases: --- _Tested on v2.5.6_ -This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) +This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.]({{}}/rancher/v2.5/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) # Prerequisites diff --git a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md index ac26cf28e2a..0f4d80d55c1 100644 --- a/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md +++ b/content/rancher/v2.5/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md @@ -19,9 +19,9 @@ To install the Rancher management server on a high-availability RKE2 cluster, we ### 1. Set up Linux Nodes -Make sure that your nodes fulfill the general installation requirements for [OS, container runtime, hardware, and networking.]({{}}/rancher/v2.x/en/installation/requirements/) +Make sure that your nodes fulfill the general installation requirements for [OS, container runtime, hardware, and networking.]({{}}/rancher/v2.5/en/installation/requirements/) -For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/rancher/v2.x/en/installation/options/ec2-node) for setting up nodes as instances in Amazon EC2. +For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/rancher/v2.5/en/installation/options/ec2-node) for setting up nodes as instances in Amazon EC2. ### 2. Set up the Load Balancer @@ -34,11 +34,11 @@ When Rancher is installed (also in a later step), the Rancher system creates an For your implementation, consider if you want or need to use a Layer-4 or Layer-7 load balancer: - **A layer-4 load balancer** is the simpler of the two choices, in which you are forwarding TCP traffic to your nodes. We recommend configuring your load balancer as a Layer 4 balancer, forwarding traffic to ports TCP/80 and TCP/443 to the Rancher management cluster nodes. The Ingress controller on the cluster will redirect HTTP traffic to HTTPS and terminate SSL/TLS on port TCP/443. The Ingress controller will forward traffic to port TCP/80 to the Ingress pod in the Rancher deployment. -- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.]({{}}/rancher/v2.x/en/installation/options/chart-options/#external-tls-termination) +- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.]({{}}/rancher/v2.5/en/installation/options/chart-options/#external-tls-termination) -For an example showing how to set up an NGINX load balancer, refer to [this page.]({{}}/rancher/v2.x/en/installation/options/nginx/) +For an example showing how to set up an NGINX load balancer, refer to [this page.]({{}}/rancher/v2.5/en/installation/options/nginx/) -For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{}}/rancher/v2.x/en/installation/options/nlb/) +For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{}}/rancher/v2.5/en/installation/options/nlb/) > **Important:** > Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications. diff --git a/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md b/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md index 850856ff865..9878109b8b6 100644 --- a/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md +++ b/content/rancher/v2.5/en/installation/resources/tls-secrets/_index.md @@ -38,4 +38,4 @@ kubectl -n cattle-system create secret generic tls-ca \ # Updating a Private CA Certificate -Follow the steps on [this page]({{}}/rancher/v2.x/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.5/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. \ No newline at end of file +Follow the steps on [this page]({{}}/rancher/v2.5/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.5/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. \ No newline at end of file diff --git a/content/rancher/v2.5/en/istio/release-notes/_index.md b/content/rancher/v2.5/en/istio/release-notes/_index.md deleted file mode 100644 index 5570eab1468..00000000000 --- a/content/rancher/v2.5/en/istio/release-notes/_index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Release Notes -aliases: - - /rancher/v2.5/en/istio/release-notes - - /rancher/v2.5/en/istio/v2.5/release-notes - - /rancher/v2.x/en/istio/v2.5/release-notes/ ---- - -# Istio 1.5.9 release notes - -**Bug fixes** - -* The Kiali traffic graph is now working [#28109](https://github.com/rancher/rancher/issues/28109) - -**Known Issues** - -* The Kiali traffic graph is offset in the UI [#28207](https://github.com/rancher/rancher/issues/28207) - - -# Istio 1.5.8 - -### Important note on 1.5.x versions - -When upgrading from any 1.4 version of Istio to any 1.5 version, the Rancher installer will delete several resources in order to complete the upgrade, at which point they will be immediately re-installed. This includes the `istio-reader-service-account`. If your Istio installation is using this service account be aware that any secrets tied to the service account will be deleted. Most notably this will **break specific [multi-cluster deployments](https://archive.istio.io/v1.4/docs/setup/install/multicluster/)**. Downgrades back to 1.4 are not possible. - -See the official upgrade notes for additional information on the 1.5 release and upgrading from 1.4: https://istio.io/latest/news/releases/1.5.x/announcing-1.5/upgrade-notes/ - -> **Note:** Rancher continues to use the Helm installation method, which produces a different architecture from an istioctl installation. - -### Known Issues - -* The Kiali traffic graph is currently not working [#24924](https://github.com/istio/istio/issues/24924) \ No newline at end of file diff --git a/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md b/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md index 4bc0e009c2a..3260cf8cf95 100644 --- a/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md +++ b/content/rancher/v2.5/en/monitoring-alerting/rbac/_index.md @@ -128,8 +128,8 @@ The relationship between the default roles deployed by Rancher Cluster Manager ( | --------- | --------- | --------- | --------- | | cluster-owner | cluster-admin | N/A | ClusterRoleBinding | | cluster-member | admin | monitoring-admin | ClusterRoleBinding | -| project-owner | edit | monitoring-admin | RoleBinding within Project namespace | -| project-member | view | monitoring-edit | RoleBinding within Project namespace | +| project-owner | admin | monitoring-admin | RoleBinding within Project namespace | +| project-member | edit | monitoring-edit | RoleBinding within Project namespace | In addition to these default Roles, the following additional Rancher project roles can be applied to members of your Cluster to provide additional access to Monitoring. These Rancher Roles will be tied to ClusterRoles deployed by the Monitoring chart: diff --git a/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md b/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md index a2aa6faf9f5..25029e83663 100644 --- a/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md +++ b/content/rancher/v2.5/en/overview/architecture-recommendations/_index.md @@ -34,7 +34,7 @@ We don't recommend installing Rancher in a single Docker container, because if t ### K3s Kubernetes Cluster Installations -One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s Rancher's CNCF certified Kubernetes distribution. It is easy to install, with half the memory of Kubernetes, all in a binary less than 100 MB. One main advantage of this K3s architecture is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral. +One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s is Rancher's CNCF certified Kubernetes distribution. It is easy to install and uses half the memory of Kubernetes, all in a binary of less than 100 MB. Another advantage of K3s is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server
![Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server]({{}}/img/rancher/k3s-server-storage.svg) @@ -110,4 +110,4 @@ For more best practices for downstream clusters, refer to the [production checkl If you are using an [authorized cluster endpoint,]({{}}/rancher/v2.5/en/overview/architecture/#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role. -If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files]({{}}/rancher/v2.5/en/k8s-in-rancher/kubeconfig/) and [API keys]({{}}/rancher/v2.5/en/user-settings/api-keys/#creating-an-api-key) for more information. \ No newline at end of file +If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files]({{}}/rancher/v2.5/en/k8s-in-rancher/kubeconfig/) and [API keys]({{}}/rancher/v2.5/en/user-settings/api-keys/#creating-an-api-key) for more information. diff --git a/content/rancher/v2.5/en/overview/architecture/_index.md b/content/rancher/v2.5/en/overview/architecture/_index.md index 9e145d0a665..b23c9d4f73b 100644 --- a/content/rancher/v2.5/en/overview/architecture/_index.md +++ b/content/rancher/v2.5/en/overview/architecture/_index.md @@ -77,7 +77,7 @@ The authentication proxy forwards all Kubernetes API calls to downstream cluster Rancher communicates with Kubernetes clusters using a [service account,](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) which provides an identity for processes that run in a pod. -By default, Rancher generates a [kubeconfig file]({{}}/rancher/v2.5/en/cluster-admin/cluster-access/kubectl/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster. +By default, Rancher generates a [kubeconfig file]({{}}/rancher/v2.5/en/cluster-admin/cluster-access/kubectl/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_cluster.yml`) contains full access to the cluster. ### 2. Cluster Controllers and Cluster Agents @@ -131,7 +131,7 @@ You will need to use a context defined in this kubeconfig file to access the clu The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down. +- `kube_config_cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down. - `rancher-cluster.rkestate`: The Kubernetes cluster state file. This file contains credentials for full access to the cluster. Note: This state file is only created when using RKE v0.2.0 or higher. > **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file. diff --git a/content/rancher/v2.5/en/overview/concepts/_index.md b/content/rancher/v2.5/en/overview/concepts/_index.md index 4e9d2d89e0d..30d5374875b 100644 --- a/content/rancher/v2.5/en/overview/concepts/_index.md +++ b/content/rancher/v2.5/en/overview/concepts/_index.md @@ -54,7 +54,7 @@ Three etcd nodes is generally sufficient for smaller clusters and five etcd node ### Controlplane Nodes -Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles. +Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although three or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles. ### Worker Nodes @@ -71,4 +71,4 @@ For high-availability installations of Rancher, Helm is the tool used to install Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh). -For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) \ No newline at end of file +For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) diff --git a/content/rancher/v2.5/en/pipelines/_index.md b/content/rancher/v2.5/en/pipelines/_index.md index a47fdaf7577..8c7ac545a87 100644 --- a/content/rancher/v2.5/en/pipelines/_index.md +++ b/content/rancher/v2.5/en/pipelines/_index.md @@ -6,7 +6,9 @@ aliases: - /rancher/v2.x/en/pipelines/ --- -> As of Rancher v2.5, Git-based deployment pipelines are now recommended to be handled with Rancher Continuous Delivery powered by [Fleet,]({{}}/rancher/v2.5/en/deploy-across-clusters/fleet) available in Cluster Explorer. +> As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{}}/rancher/v2.5/en/deploy-across-clusters/fleet), available in Cluster Explorer. +> +>**Notice:** Fleet does not replace Rancher pipelines; the distinction is that Rancher pipelines are now powered by Fleet. Rancher's pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds or scripts, publish Docker images or catalog applications, and deploy the updated software to users. diff --git a/content/rancher/v2.5/en/project-admin/project-members/_index.md b/content/rancher/v2.5/en/project-admin/project-members/_index.md index a8476db8ec8..45a149e90ea 100644 --- a/content/rancher/v2.5/en/project-admin/project-members/_index.md +++ b/content/rancher/v2.5/en/project-admin/project-members/_index.md @@ -43,6 +43,8 @@ Following project creation, you can add users as project members so that they ca > >- 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. + > >- For `Custom` roles, you can modify the list of individual roles available for assignment. > > - To add roles to the list, [Add a Custom Role]({{}}/rancher/v2.5/en/admin-settings/rbac/default-custom-roles). diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md index 770940ff92f..f14ab87f973 100644 --- a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md +++ b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-manual-setup/_index.md @@ -48,7 +48,7 @@ To install Rancher on your host, connect to it and then use a shell to install. 1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. -2. From your shell, enter the following command: +1. From your shell, enter the following command: ``` sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher @@ -60,13 +60,17 @@ To install Rancher on your host, connect to it and then use a shell to install. Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations. -1. Open a web browser and enter the IP address of your host: `https://`. +1. Open a web browser and enter the IP address of your host: `https://`. Replace `` with your host IP address. -2. When prompted, create a password for the default `admin` account there cowpoke! +1. When prompted, create a password for the default `admin` account there cowpoke! -3. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.

If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster. +1. Set the **Default View**. + - If `I want to create or manage multiple clusters` is selected, the Cluster Manager UI is used as the default view. + - If `I'm only going to use the cluster Rancher was installed on` is selected, the Cluster Explorer UI is used as the default view. + +1. Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.

If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
@@ -76,27 +80,29 @@ Welcome to Rancher! You are now able to create your first Kubernetes cluster. In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-prem VM, or bare-metal) to be used in a cluster. +1. If you chose `I'm only going to use the cluster Rancher was installed on` when setting the default view, click the **Cluster Manager** button in the upper-right of the UI to access the **Clusters** page. + 1. From the **Clusters** page, click **Add Cluster**. -2. Choose **Existing Nodes**. +1. Choose **Existing Nodes**. -3. Enter a **Cluster Name**. +1. Enter a **Cluster Name**. -4. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later. +1. Skip **Member Roles** and **Cluster Options**. We'll tell you about them later. -5. Click **Next**. +1. Click **Next**. -6. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**. +1. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**. -7. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section. +1. **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section. -8. Skip the **Labels** stuff. It's not important for now. +1. Skip the **Labels** stuff. It's not important for now. -9. Copy the command displayed on screen to your clipboard. +1. Copy the command displayed on screen to your clipboard. -10. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard. +1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard. -11. When you finish running the command on your Linux host, click **Done**. +1. When you finish running the command on your Linux host, click **Done**. **Result:** diff --git a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md index b175645408d..d959a0e5db0 100644 --- a/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md +++ b/content/rancher/v2.5/en/quick-start-guide/deployment/quickstart-vagrant/_index.md @@ -32,7 +32,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a 4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`. -5. Once provisioning finishes, go to `https://172.22.101.101` in the browser. The default user/password is `admin/admin`. +5. Once provisioning finishes, go to `https://192.168.56.101` in the browser. The default user/password is `admin/admin`. **Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox. diff --git a/content/rancher/v2.5/en/security/_index.md b/content/rancher/v2.5/en/security/_index.md index a6505193c90..531c7d2ca33 100644 --- a/content/rancher/v2.5/en/security/_index.md +++ b/content/rancher/v2.5/en/security/_index.md @@ -45,7 +45,7 @@ The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team. -The Benchmark provides recommendations of two types: Scored and Not Scored. We run tests related to only Scored recommendations. +The Benchmark provides recommendations of two types: Automated and Manual. We run tests related to only Automated recommendations. When Rancher runs a CIS security scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests. diff --git a/content/rancher/v2.5/en/troubleshooting/dns/_index.md b/content/rancher/v2.5/en/troubleshooting/dns/_index.md index 90892ee2644..3822399c32f 100644 --- a/content/rancher/v2.5/en/troubleshooting/dns/_index.md +++ b/content/rancher/v2.5/en/troubleshooting/dns/_index.md @@ -7,7 +7,7 @@ aliases: The commands/steps listed on this page can be used to check name resolution issues in your cluster. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. Before running the DNS checks, check the [default DNS provider]({{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/options/#default-dns-provider) for your cluster and make sure that [the overlay network is functioning correctly]({{}}/rancher/v2.5/en/troubleshooting/networking/#check-if-overlay-network-is-functioning-correctly) as this can also be the reason why DNS resolution (partly) fails. @@ -160,7 +160,7 @@ kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{ Enabling query logging can be done by enabling the [log plugin](https://coredns.io/plugins/log/) in the Corefile configuration in the configmap `coredns`. You can do so by using `kubectl -n kube-system edit configmap coredns` or use the command below to replace the configuration in place: ``` -kubectl get configmap -n kube-system coredns -o json | kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f - +kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f - ``` All queries will now be logged and can be checked using the command in [Check CoreDNS logging](#check-coredns-logging). diff --git a/content/rancher/v2.5/en/troubleshooting/kubernetes-resources/_index.md b/content/rancher/v2.5/en/troubleshooting/kubernetes-resources/_index.md index 1853ef0575b..0aac78e17b5 100644 --- a/content/rancher/v2.5/en/troubleshooting/kubernetes-resources/_index.md +++ b/content/rancher/v2.5/en/troubleshooting/kubernetes-resources/_index.md @@ -7,7 +7,7 @@ aliases: The commands/steps listed on this page can be used to check the most important Kubernetes resources and apply to [Rancher Launched Kubernetes]({{}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/) clusters. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. - [Nodes](#nodes) - [Get nodes](#get-nodes) diff --git a/content/rancher/v2.5/en/troubleshooting/logging/_index.md b/content/rancher/v2.5/en/troubleshooting/logging/_index.md index 630554ffff1..64326f15a15 100644 --- a/content/rancher/v2.5/en/troubleshooting/logging/_index.md +++ b/content/rancher/v2.5/en/troubleshooting/logging/_index.md @@ -18,7 +18,7 @@ The following log levels are used in Rancher: * Kubernetes install * Configure debug log level ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl -n cattle-system get pods -l app=rancher --no-headers -o custom-columns=name:.metadata.name | while read rancherpod; do kubectl -n cattle-system exec $rancherpod -c rancher -- loglevel --set debug; done OK OK @@ -28,7 +28,7 @@ $ kubectl -n cattle-system logs -l app=rancher -c rancher * Configure info log level ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl -n cattle-system get pods -l app=rancher --no-headers -o custom-columns=name:.metadata.name | while read rancherpod; do kubectl -n cattle-system exec $rancherpod -c rancher -- loglevel --set info; done OK OK diff --git a/content/rancher/v2.5/en/troubleshooting/networking/_index.md b/content/rancher/v2.5/en/troubleshooting/networking/_index.md index 1bdaa5c884f..771719bba79 100644 --- a/content/rancher/v2.5/en/troubleshooting/networking/_index.md +++ b/content/rancher/v2.5/en/troubleshooting/networking/_index.md @@ -7,7 +7,7 @@ aliases: The commands/steps listed on this page can be used to check networking related issues in your cluster. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. ### Double check if all the required ports are opened in your (host) firewall diff --git a/content/rancher/v2.5/en/troubleshooting/rancherha/_index.md b/content/rancher/v2.5/en/troubleshooting/rancherha/_index.md index 610a0b16c63..a7f74be3f5c 100644 --- a/content/rancher/v2.5/en/troubleshooting/rancherha/_index.md +++ b/content/rancher/v2.5/en/troubleshooting/rancherha/_index.md @@ -7,7 +7,7 @@ aliases: The commands/steps listed on this page can be used to check your Rancher Kubernetes Installation. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml`). +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`). ### Check Rancher pods diff --git a/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md b/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md index 5040d63561b..484b0a1610c 100644 --- a/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md +++ b/content/rancher/v2.6/en/admin-settings/authentication/ping-federate/_index.md @@ -27,6 +27,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. diff --git a/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md b/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md index c966d787383..022b08762ce 100644 --- a/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md +++ b/content/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/_index.md @@ -111,6 +111,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. @@ -119,7 +123,6 @@ _Project roles_ are roles that can be used to grant users access to a project. T > >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. - #### Custom Project Roles Rancher lets you assign _custom project roles_ to a standard user instead of the typical `Owner`, `Member`, or `Read Only` roles. These roles can be either a built-in custom project role or one defined by a Rancher administrator. They are convenient for defining narrow or specialized access for a standard user within a project. See the table below for a list of built-in custom project roles. diff --git a/content/rancher/v2.6/en/api/_index.md b/content/rancher/v2.6/en/api/_index.md index 60cf9320914..a69509ca17b 100644 --- a/content/rancher/v2.6/en/api/_index.md +++ b/content/rancher/v2.6/en/api/_index.md @@ -50,3 +50,17 @@ Most collections can be sorted on the server-side by common fields using HTTP qu ## Pagination API responses are paginated with a limit of 100 resources per page by default. This can be changed with the `limit` query parameter, up to a maximum of 1000, e.g. `/v3/pods?limit=1000`. The `pagination` map in collection responses tells you whether or not you have the full result set and has a link to the next page if you do not. + +## Capturing Rancher API Calls + +You can use browser developer tools to capture how the Rancher API is called. For example, you could follow these steps to use the Chrome developer tools to get the API call for provisioning an RKE cluster: + +1. In the Rancher UI, go to **Cluster Management** and click **Create.** +1. Click one of the cluster types. This example uses Digital Ocean. +1. Fill out the form with a cluster name and node template, but don't click **Create**. +1. You will need to open the developer tools before the cluster creation to see the API call being recorded. To open the tools, right-click on the Rancher UI and click **Inspect.** +1. In the developer tools, click the **Network** tab. +1. On the **Network** tab, make sure **Fetch/XHR** is selected. +1. In the Rancher UI, click **Create**. In the developer tools, you should see a new network request with the name `cluster?_replace=true`. +1. Right-click `cluster?_replace=true` and click **Copy > Copy as cURL.** +1. Paste the result into any text editor. You will be able to see the POST request, including the URL it was sent to, all of the headers, and the full body of the request. This command can be used to create a cluster from the command line. Note: The request should be stored in a safe place because it contains credentials. \ No newline at end of file diff --git a/content/rancher/v2.6/en/backups/_index.md b/content/rancher/v2.6/en/backups/_index.md index 3abd52d742e..d9e4dd96065 100644 --- a/content/rancher/v2.6/en/backups/_index.md +++ b/content/rancher/v2.6/en/backups/_index.md @@ -49,6 +49,8 @@ The Backup and Restore custom resources can be created in the Rancher UI, or by The `rancher-backup` operator can be installed from the Rancher UI, or with the Helm CLI. In both cases, the `rancher-backup` Helm chart is installed on the Kubernetes cluster running the Rancher server. It is a cluster-admin only feature and available only for the **local** cluster. (*If you do not see `rancher-backup` in the Rancher UI, you may have selected the wrong cluster.*) +>**NOTE:** There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround. + ### Installing rancher-backup with the Rancher UI 1. In the upper left corner, click **☰ > Cluster Management**. diff --git a/content/rancher/v2.6/en/backups/back-up-rancher/_index.md b/content/rancher/v2.6/en/backups/back-up-rancher/_index.md index ad495fa6874..629a7ad2c64 100644 --- a/content/rancher/v2.6/en/backups/back-up-rancher/_index.md +++ b/content/rancher/v2.6/en/backups/back-up-rancher/_index.md @@ -31,6 +31,8 @@ Backups are created as .tar.gz files. These files can be pushed to S3 or Minio, 1. Configure the default storage location. For help, refer to the [storage configuration section.](../configuration/storage-config) 1. Click **Install**. +>**NOTE:** There is a known issue in Fleet that occurs after performing a restoration using the backup-restore-operator: Secrets used for clientSecretName and helmSecretName are not included in Fleet gitrepos. Refer [here]({{}}rancher/v2.6/en/deploy-across-clusters/fleet/#troubleshooting) for a workaround. + ### 2. Perform a Backup To perform a backup, a custom resource of type Backup must be created. diff --git a/content/rancher/v2.6/en/backups/restoring-rancher/_index.md b/content/rancher/v2.6/en/backups/restoring-rancher/_index.md index 0d9925329a1..1f20f311720 100644 --- a/content/rancher/v2.6/en/backups/restoring-rancher/_index.md +++ b/content/rancher/v2.6/en/backups/restoring-rancher/_index.md @@ -9,6 +9,7 @@ A restore is performed by creating a Restore custom resource. > > * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{}}/rancher/v2.6/en/backups/migrating-rancher) > * While restoring rancher on the same setup, the operator will scale down the rancher deployment when restore starts, and it will scale back up the deployment once restore completes. So Rancher will be unavailable during the restore. +> * If you need to restore Rancher to a previous version after an upgrade, see the [rollback documentation.]({{}}/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/) ### Create the Restore Custom Resource diff --git a/content/rancher/v2.6/en/cis-scans/_index.md b/content/rancher/v2.6/en/cis-scans/_index.md index a9a1c897886..17aa5a5a3b1 100644 --- a/content/rancher/v2.6/en/cis-scans/_index.md +++ b/content/rancher/v2.6/en/cis-scans/_index.md @@ -42,7 +42,7 @@ By default, the CIS Benchmark v1.6 is used. The Benchmark version is included in the generated report. -The Benchmark provides recommendations of two types: Scored and Not Scored. Recommendations marked as Not Scored in the Benchmark are not included in the generated report. +The Benchmark provides recommendations of two types: Automated and Manual. Recommendations marked as Manual in the Benchmark are not included in the generated report. Some tests are designated as "Not Applicable." These tests will not be run on any CIS scan because of the way that Rancher provisions RKE clusters. For information on how test results can be audited, and why some tests are designated to be not applicable, refer to Rancher's self-assessment guide for the corresponding Kubernetes version. diff --git a/content/rancher/v2.6/en/cis-scans/skipped-tests/_index.md b/content/rancher/v2.6/en/cis-scans/skipped-tests/_index.md index c1ece507024..f2b125c0262 100644 --- a/content/rancher/v2.6/en/cis-scans/skipped-tests/_index.md +++ b/content/rancher/v2.6/en/cis-scans/skipped-tests/_index.md @@ -13,42 +13,42 @@ This section lists the tests that are skipped in the permissive test profile for | Number | Description | Reason for Skipping | | ---------- | ------------- | --------- | -| 1.1.12 | Ensure that the etcd data directory ownership is set to etcd:etcd (Scored) | A system service account is required for etcd data directory ownership. Refer to Rancher's hardening guide for more details on how to configure this ownership. | -| 1.2.6 | Ensure that the --kubelet-certificate-authority argument is set as appropriate (Scored) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | -| 1.2.16 | Ensure that the admission control plugin PodSecurityPolicy is set (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 1.2.33 | Ensure that the --encryption-provider-config argument is set as appropriate (Not Scored) | Enabling encryption changes how data can be recovered as data is encrypted. | -| 1.2.34 | Ensure that encryption providers are appropriately configured (Not Scored) | Enabling encryption changes how data can be recovered as data is encrypted. | -| 4.2.6 | Ensure that the --protect-kernel-defaults argument is set to true (Scored) | System level configurations are required before provisioning the cluster in order for this argument to be set to true. | -| 4.2.10 | Ensure that the--tls-cert-file and --tls-private-key-file arguments are set as appropriate (Scored) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | -| 5.1.5 | Ensure that default service accounts are not actively used. (Scored) | Kubernetes provides default service accounts to be used. | -| 5.2.2 | Minimize the admission of containers wishing to share the host process ID namespace (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.3 | Minimize the admission of containers wishing to share the host IPC namespace (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.4 | Minimize the admission of containers wishing to share the host network namespace (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.2.5 | Minimize the admission of containers with allowPrivilegeEscalation (Scored) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | -| 5.3.2 | Ensure that all Namespaces have Network Policies defined (Scored) | Enabling Network Policies can prevent certain applications from communicating with each other. | -| 5.6.4 | The default namespace should not be used (Scored) | Kubernetes provides a default namespace. | +| 1.1.12 | Ensure that the etcd data directory ownership is set to etcd:etcd (Automated) | A system service account is required for etcd data directory ownership. Refer to Rancher's hardening guide for more details on how to configure this ownership. | +| 1.2.6 | Ensure that the --kubelet-certificate-authority argument is set as appropriate (Automated) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | +| 1.2.16 | Ensure that the admission control plugin PodSecurityPolicy is set (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 1.2.33 | Ensure that the --encryption-provider-config argument is set as appropriate (Manual) | Enabling encryption changes how data can be recovered as data is encrypted. | +| 1.2.34 | Ensure that encryption providers are appropriately configured (Manual) | Enabling encryption changes how data can be recovered as data is encrypted. | +| 4.2.6 | Ensure that the --protect-kernel-defaults argument is set to true (Automated) | System level configurations are required before provisioning the cluster in order for this argument to be set to true. | +| 4.2.10 | Ensure that the--tls-cert-file and --tls-private-key-file arguments are set as appropriate (Automated) | When generating serving certificates, functionality could break in conjunction with hostname overrides which are required for certain cloud providers. | +| 5.1.5 | Ensure that default service accounts are not actively used. (Automated) | Kubernetes provides default service accounts to be used. | +| 5.2.2 | Minimize the admission of containers wishing to share the host process ID namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.2.3 | Minimize the admission of containers wishing to share the host IPC namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.2.4 | Minimize the admission of containers wishing to share the host network namespace (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.2.5 | Minimize the admission of containers with allowPrivilegeEscalation (Automated) | Enabling Pod Security Policy can cause applications to unexpectedly fail. | +| 5.3.2 | Ensure that all Namespaces have Network Policies defined (Automated) | Enabling Network Policies can prevent certain applications from communicating with each other. | +| 5.6.4 | The default namespace should not be used (Automated) | Kubernetes provides a default namespace. | ### CIS Benchmark v1.5 Not Applicable Tests | Number | Description | Reason for being not applicable | | ---------- | ------------- | --------- | -| 1.1.1 | Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | -| 1.1.2 | Ensure that the API server pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | -| 1.1.3 | Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.4 | Ensure that the controller manager pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.5 | Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.6 | Ensure that the scheduler pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.7 | Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | -| 1.1.8 | Ensure that the etcd pod specification file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | -| 1.1.13 | Ensure that the admin.conf file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | -| 1.1.14 | Ensure that the admin.conf file ownership is set to root:root (Scored) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | -| 1.1.15 | Ensure that the scheduler.conf file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.16 | Ensure that the scheduler.conf file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | -| 1.1.17 | Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.1.18 | Ensure that the controller-manager.conf file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | -| 1.3.6 | Ensure that the RotateKubeletServerCertificate argument is set to true (Scored) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | -| 4.1.1 | Ensure that the kubelet service file permissions are set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | -| 4.1.2 | Ensure that the kubelet service file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | -| 4.1.9 | Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | -| 4.1.10 | Ensure that the kubelet configuration file ownership is set to root:root (Scored) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | -| 4.2.12 | Ensure that the RotateKubeletServerCertificate argument is set to true (Scored) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | \ No newline at end of file +| 1.1.1 | Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | +| 1.1.2 | Ensure that the API server pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for kube-apiserver. All configuration is passed in as arguments at container run time. | +| 1.1.3 | Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.1.4 | Ensure that the controller manager pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.1.5 | Ensure that the scheduler pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.6 | Ensure that the scheduler pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.7 | Ensure that the etcd pod specification file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | +| 1.1.8 | Ensure that the etcd pod specification file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for etcd. All configuration is passed in as arguments at container run time. | +| 1.1.13 | Ensure that the admin.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | +| 1.1.14 | Ensure that the admin.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE does not store the kubernetes default kubeconfig credentials file on the nodes. | +| 1.1.15 | Ensure that the scheduler.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.16 | Ensure that the scheduler.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for scheduler. All configuration is passed in as arguments at container run time. | +| 1.1.17 | Ensure that the controller-manager.conf file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.1.18 | Ensure that the controller-manager.conf file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn't require or maintain a configuration file for controller-manager. All configuration is passed in as arguments at container run time. | +| 1.3.6 | Ensure that the RotateKubeletServerCertificate argument is set to true (Automated) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | +| 4.1.1 | Ensure that the kubelet service file permissions are set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | +| 4.1.2 | Ensure that the kubelet service file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet service. All configuration is passed in as arguments at container run time. | +| 4.1.9 | Ensure that the kubelet configuration file has permissions set to 644 or more restrictive (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | +| 4.1.10 | Ensure that the kubelet configuration file ownership is set to root:root (Automated) | Clusters provisioned by RKE doesn’t require or maintain a configuration file for the kubelet. All configuration is passed in as arguments at container run time. | +| 4.2.12 | Ensure that the RotateKubeletServerCertificate argument is set to true (Automated) | Clusters provisioned by RKE handles certificate rotation directly through RKE. | \ No newline at end of file diff --git a/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md b/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md index 38eb69b8cb1..8a70bfd34b6 100644 --- a/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/certificate-rotation/_index.md @@ -10,7 +10,8 @@ By default, Kubernetes clusters require certificates and Rancher launched Kubern Certificates can be rotated for the following services: - etcd -- kubelet +- kubelet (node certificate) +- kubelet (serving certificate, if [enabled]({{}}/rke/latest/en/config-options/services/#kubelet-options)) - kube-apiserver - kube-proxy - kube-scheduler diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md index 67d3e46d94f..4eec75f21f7 100644 --- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/eks-config-reference/_index.md @@ -11,7 +11,7 @@ Complete each drop-down and field using the information obtained for your IAM po | Setting | Description | | ---------- | -------------------------------------------------------------------------------------------------------------------- | | Region | From the drop-down choose the geographical region in which to build your cluster. | -| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.x/en/user-settings/cloud-credentials/) | +| Cloud Credentials | Select the cloud credentials that you created for your IAM policy. For more information on creating cloud credentials in Rancher, refer to [this page.]({{}}/rancher/v2.6/en/user-settings/cloud-credentials/) | ### Service Role diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md index cf3b3963f05..95d9bd39bcc 100644 --- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/gke-config-reference/private-clusters/_index.md @@ -21,7 +21,7 @@ If restricting outgoing internet access is not a concern for your organization, >**Note** >This scenario is not officially supported, but is described for cases in which using the Cloud NAT service is not sufficient. -If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.x/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it. +If restricting both incoming and outgoing traffic to nodes is a requirement, follow the air-gapped installation instructions to set up a private container image [registry](https://rancher.com/docs/rancher/v2.6/en/installation/other-installation-methods/air-gap/) on the VPC where the cluster is going to be, allowing the cluster nodes to access and download the images they need to run the cluster agent. If the control plane endpoint is also private, Rancher will need [direct access](#direct-access) to it. ### Private Control Plane Endpoint diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md index 2b530a8db5e..0f0c03d67f2 100644 --- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/rke-config-reference/_index.md @@ -189,7 +189,7 @@ Option to enable or disable [recurring etcd snapshots]({{}}/rke/latest/ ### Agent Environment Variables -Option to set environment variables for [rancher agents]({{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables. +Option to set environment variables for [rancher agents]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/rancher-agents/). The environment variables can be set using key value pairs. If rancher agent requires use of proxy to communicate with Rancher server, `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` environment variables can be set using agent environment variables. ### Updating ingress-nginx diff --git a/content/rancher/v2.6/en/cluster-admin/nodes/_index.md b/content/rancher/v2.6/en/cluster-admin/nodes/_index.md index a60fb2d562a..9f2243cceab 100644 --- a/content/rancher/v2.6/en/cluster-admin/nodes/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/nodes/_index.md @@ -40,11 +40,11 @@ The following table lists which node options are available for each type of clus | [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | | Download SSH key in order to SSH into the node. | | [Node Scaling](#scaling-nodes) | ✓ | | | ✓ | | Scale the number of nodes in the node pool up or down. | -[1]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/ -[2]: {{}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/ -[3]: {{}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/ -[4]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/ -[5]: {{}}/rancher/v2.x/en/cluster-provisioning/registered-clusters/ +[1]: {{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/ +[2]: {{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/custom-nodes/ +[3]: {{}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/ +[4]: {{}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/ +[5]: {{}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/ \* Delete option accessible via View API diff --git a/content/rancher/v2.6/en/cluster-admin/projects-and-namespaces/_index.md b/content/rancher/v2.6/en/cluster-admin/projects-and-namespaces/_index.md index 71820214033..d1ae03863b4 100644 --- a/content/rancher/v2.6/en/cluster-admin/projects-and-namespaces/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/projects-and-namespaces/_index.md @@ -8,6 +8,8 @@ A namespace is a Kubernetes concept that allows a virtual cluster within a clust A project is a group of namespaces, and it is a concept introduced by Rancher. Projects allow you to manage multiple namespaces as a group and perform Kubernetes operations in them. You can use projects to support multi-tenancy, so that a team can access a project within a cluster without having access to other projects in the same cluster. +>**Note:** As of Rancher v2.6, projects are de-emphasized on the UI because it is no longer required to create any Kubernetes resources within a project scope. However, resources such as [Secrets]({{}}/rancher/v2.6/en/k8s-in-rancher/secrets/#creating-secrets-in-projects) can still be created in a project scope if the legacy feature flag is enabled. + This section describes how projects and namespaces work with Rancher. It covers the following topics: - [About namespaces](#about-namespaces) @@ -150,6 +152,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]({{}}/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/#custom-project-roles). To add members: diff --git a/content/rancher/v2.6/en/cluster-provisioning/_index.md b/content/rancher/v2.6/en/cluster-provisioning/_index.md index 7f9b266fc86..5a33cad88f8 100644 --- a/content/rancher/v2.6/en/cluster-provisioning/_index.md +++ b/content/rancher/v2.6/en/cluster-provisioning/_index.md @@ -20,7 +20,6 @@ This section covers the following topics: - [Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider](#launching-kubernetes-and-provisioning-nodes-in-an-infrastructure-provider) - [Launching Kubernetes on Existing Custom Nodes](#launching-kubernetes-on-existing-custom-nodes) - [Registering Existing Clusters](#registering-existing-clusters) -- [Importing Existing Clusters](#importing-existing-clusters) diff --git a/content/rancher/v2.6/en/cluster-provisioning/registered-clusters/_index.md b/content/rancher/v2.6/en/cluster-provisioning/registered-clusters/_index.md index 54fee0662cd..0891f46df79 100644 --- a/content/rancher/v2.6/en/cluster-provisioning/registered-clusters/_index.md +++ b/content/rancher/v2.6/en/cluster-provisioning/registered-clusters/_index.md @@ -17,6 +17,14 @@ The control that Rancher has to manage a registered cluster depends on the type # Prerequisites +## Kubernetes Node Roles + +Registered RKE Kubernetes clusters must have all three node roles - etcd, controlplane and worker. A cluster with only controlplane components cannot be registered in Rancher. + +For more information on RKE node roles, see the [best practices.]({{}}/rancher/v2.6/en/cluster-provisioning/production/#cluster-architecture) + +## Permissions + If your existing Kubernetes cluster already has a `cluster-admin` role defined, you must have this `cluster-admin` privilege to register the cluster in Rancher. In order to apply the privilege, you need to run: diff --git a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md index 1d5b9d4b072..0e4f17f8abc 100644 --- a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md +++ b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/_index.md @@ -85,6 +85,32 @@ If you are configuring DHCP options sets for an AWS virtual private cloud, note > Some Linux operating systems accept multiple domain names separated by spaces. However, other Linux operating systems and Windows treat the value as a single domain, which results in unexpected behavior. If your DHCP options set is associated with a VPC that has instances with multiple operating systems, specify only one domain name. +### Rancher on vSphere with ESXi 6.7u2 and above + +If you are using Rancher on VMware vSphere with ESXi 6.7u2 or later with Red Hat Enterprise Linux 8.3, CentOS 8.3, or SUSE Enterprise Linux 15 SP2 or later, it is necessary to disable the `vmxnet3` virtual network adapter hardware offloading feature. Failure to do so will result in all network connections between pods on different cluster nodes to fail with timeout errors. All connections from Windows pods to critical services running on Linux nodes, such as CoreDNS, will fail as well. It is also possible that external connections may fail. This issue is the result of Linux distributions enabling the hardware offloading feature in `vmxnet3` and a bug in the `vmxnet3` hardware offloading feature that results in the discarding of packets for guest overlay traffic. To address this issue, it is necessary disable the `vmxnet3` hardware offloading feature. This setting does not survive reboot, so it is necessary to disable on every boot. The recommended course of action is to create a systemd unit file at `/etc/systemd/system/disable_hw_offloading.service`, which disables the `vmxnet3` hardware offloading feature on boot. A sample systemd unit file which disables the `vmxnet3` hardware offloading feature is as follows. Note that `` must be customized to the host `vmxnet3` network interface, e.g., `ens192`: + +``` +[Unit] +Description=Disable vmxnet3 hardware offloading feature + +[Service] +Type=oneshot +ExecStart=ethtool -K tx-udp_tnl-segmentation off +ExecStart=ethtool -K tx-udp_tnl-csum-segmentation off +StandardOutput=journal + +[Install] +WantedBy=multi-user.target +``` +Then set the appropriate permissions on the systemd unit file: +``` +chmod 0644 /etc/systemd/system/disable_hw_offloading.service +``` +Finally, enable the systemd service: +``` +systemctl enable disable_hw_offloading.service +``` + ### Architecture Requirements The Kubernetes cluster management nodes (`etcd` and `controlplane`) must be run on Linux nodes. diff --git a/content/rancher/v2.6/en/contributing/_index.md b/content/rancher/v2.6/en/contributing/_index.md index 5f0daf20015..3900cabb57f 100644 --- a/content/rancher/v2.6/en/contributing/_index.md +++ b/content/rancher/v2.6/en/contributing/_index.md @@ -78,7 +78,7 @@ Please follow this checklist when filing an issue which will helps us investigat ``` - Kubernetes install using `kubectl` - > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` if Rancher is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. + > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if Rancher is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. ``` kubectl -n cattle-system \ @@ -95,7 +95,7 @@ Please follow this checklist when filing an issue which will helps us investigat ``` - Kubernetes Install with RKE Add-On - > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. + > **Note:** Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` if the Rancher server is installed on a Kubernetes cluster) or are using the embedded kubectl via the UI. ``` kubectl -n cattle-system \ diff --git a/content/rancher/v2.6/en/deploy-across-clusters/fleet/_index.md b/content/rancher/v2.6/en/deploy-across-clusters/fleet/_index.md index f9ef3cc818c..1b129ee97f0 100644 --- a/content/rancher/v2.6/en/deploy-across-clusters/fleet/_index.md +++ b/content/rancher/v2.6/en/deploy-across-clusters/fleet/_index.md @@ -12,6 +12,8 @@ Fleet is a separate project from Rancher, and can be installed on any Kubernetes - [Windows Support](#windows-support) - [GitHub Repository](#github-repository) - [Using Fleet Behind a Proxy](#using-fleet-behind-a-proxy) +- [Helm Chart Dependencies](#helm-chart-dependencies) +- [Troubleshooting](#troubleshooting) - [Documentation](#documentation) # Architecture @@ -20,7 +22,24 @@ For information about how Fleet works, see [this page.](./architecture) # Accessing Fleet in the Rancher UI -Fleet comes preinstalled in Rancher. To access it, click **☰ > Continuous Delivery**. +Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/). + +Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice. + +Follow the steps below to access Continuous Delivery in the Rancher UI: + +1. Click **☰ > Continuous Delivery**. + +1. Select your namespace at the top of the menu, noting the following: + - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. + - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. + - You can then manage clusters by clicking on **Clusters** on the left navigation bar. + +1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. + +1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar. + +1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI. # Windows Support @@ -36,6 +55,22 @@ The Fleet Helm charts are available [here.](https://github.com/rancher/fleet/rel For details on using Fleet behind a proxy, see [this page.](./proxy) +# Helm Chart Dependencies + +In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing. + +The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` OR run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters. + +# Troubleshooting + +--- +* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. + +* **Temporary Workaround:**
+By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow). + +--- + # Documentation The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/) diff --git a/content/rancher/v2.6/en/faq/kubectl/_index.md b/content/rancher/v2.6/en/faq/kubectl/_index.md index b4172ab0a40..ffd8eee6789 100644 --- a/content/rancher/v2.6/en/faq/kubectl/_index.md +++ b/content/rancher/v2.6/en/faq/kubectl/_index.md @@ -11,12 +11,12 @@ See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubect ### Configuration -When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_rancher-cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`. +When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`. -You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`. +You can copy this file to `$HOME/.kube/config` or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`. ``` -export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml +export KUBECONFIG=$(pwd)/kube_config_cluster.yml ``` Test your connectivity with `kubectl` and see if you can get the list of nodes back. diff --git a/content/rancher/v2.6/en/faq/technical/_index.md b/content/rancher/v2.6/en/faq/technical/_index.md index 11f25ca0a35..ed4d3ec3f02 100644 --- a/content/rancher/v2.6/en/faq/technical/_index.md +++ b/content/rancher/v2.6/en/faq/technical/_index.md @@ -14,7 +14,7 @@ New password for default administrator (user-xxxxx): Kubernetes install (Helm): ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password New password for default administrator (user-xxxxx): @@ -33,7 +33,7 @@ New password for default administrator (user-xxxxx): Kubernetes install (Helm): ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin New password for default administrator (user-xxxxx): diff --git a/content/rancher/v2.6/en/helm-charts/creating-apps/_index.md b/content/rancher/v2.6/en/helm-charts/creating-apps/_index.md new file mode 100644 index 00000000000..b4376f81ef7 --- /dev/null +++ b/content/rancher/v2.6/en/helm-charts/creating-apps/_index.md @@ -0,0 +1,128 @@ +--- +title: Creating Apps +weight: 400 +--- + +Rancher's App Marketplace is based on Helm Repositories and Helm Charts. You can add HTTP based standard Helm Repositories as well as any Git Repository which contains charts. + +> For a complete walkthrough of developing charts, see the [Chart Template Developer's Guide](https://helm.sh/docs/chart_template_guide/) in the official Helm documentation. + +- [Chart types](#chart-types) + - [Helm charts](#helm-charts) + - [Rancher charts](#rancher-charts) +- [Chart directory structure](#chart-directory-structure) +- [Additional Files for Rancher Charts](#additional-files-for-rancher-charts) + - [questions.yml](#questions-yml) + - [Min/Max Rancher versions](#min-max-rancher-versions) + - [Question variable reference](#question-variable-reference) +- [Tutorial: Example Custom Chart Creation](#tutorial-example-custom-chart-creation) + +# Chart Types + +Rancher supports two different types of charts: Helm charts and Rancher charts. + +### Helm Charts + +Native Helm charts include an application along with other software required to run it. When deploying native Helm charts, you' can provide the chart's parameter values in a YAML editor. + +### Rancher Charts + +Rancher charts are native helm charts with two files that enhance user experience: `app-readme.md` and `questions.yaml`. Read more about them in [Additional Files for Rancher Charts.](#additional-files-for-rancher-charts) + +Rancher charts add simplified chart descriptions and configuration forms to make the application deployment easy. Rancher users do not need to read through the entire list of Helm variables to understand how to launch an application. + +# Chart Directory Structure + +You can provide Helm Charts in a standard, HTTP based Helm Repository. For more information see the [Chart Repository Guide](https://helm.sh/docs/topics/chart_repository) in the official Helm documentation. + +Alternatively you can organize your charts in a Git Repository and directly add this to the App Marketplace. + +The following table demonstrates the directory structure for a Git repository. The `charts` directory is the top level directory under the repository base. Adding the repository to Rancher will expose all charts contained within it. The `questions.yaml`, `README.md`, and `requirements.yml` files are specific to Rancher charts, but are optional for chart customization. + +``` +/ + │ + ├── charts/ + │ ├── / # This directory name will be surfaced in the Rancher UI as the chart name + │ │ ├── / # 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 + +Before you create your own custom catalog, you should have a basic understanding about how a Rancher chart differs from a native Helm chart. Rancher charts differ slightly from Helm charts in their directory structures. Rancher charts include two files that Helm charts do not. + +- `app-readme.md` + + A file that provides descriptive text in the chart's UI header. + +- `questions.yml` + + A file that contains questions for a form. These form questions simplify deployment of a chart. Without it, you must configure the deployment using a values YAML config, which is more difficult. The following image displays the difference between a Rancher chart (which includes `questions.yml`) and a native Helm chart (which does not). + + +
Rancher Chart with questions.yml (top) vs. Helm Chart without (bottom)
+ + ![questions.yml]({{}}/img/rancher/rancher-app-2.6.png) + ![values.yaml]({{}}/img/rancher/helm-app-2.6.png) + + +### Chart.yaml annotations + +Rancher supports additional annotations that you can add to the `Chart.yaml` file. These annotations allow you to define application dependencies or configure additional UI defaults: + +| Annotation | Description | Example | +| --------------------------------- | ----------- | ------- | +| catalog.cattle.io/auto-install | If set, will install the specified chart in the specified version before installing this chart | other-chart-name=1.0.0 | +| catalog.cattle.io/display-name | A display name that should be displayed in the App Marketplace instead of the chart name | Display Name of Chart | +| catalog.cattle.io/namespace | A fixed namespace where the chart should be deployed in. If set, this can't be changed by the user | fixed-namespace | +| catalog.cattle.io/release-name | A fixed release name for the Helm installation. If set, this can't be changed by the user | fixed-release-name | +| catalog.cattle.io/requests-cpu | Total amount of CPU that should be unreserverd in the cluster. If less CPU is available, a warning will be shown | 2000m | +| catalog.cattle.io/requests-memory | Total amount of memory that should be unreserverd in the cluster. If less memory is available, a warning will be shown | 2Gi | +| catalog.cattle.io/os | Restricts the OS where this chart can be installed. Possible values: `linux`, `windows`. Default: no restriction | linux | + +### questions.yml + +Inside the `questions.yml`, most of the content will be around the questions to ask the end user, but there are some additional fields that can be set in this file. + +### Min/Max Rancher versions + +For each chart, you can add the minimum and/or maximum Rancher version, which determines whether or not this chart is available to be deployed from Rancher. + +> **Note:** Even though Rancher release versions are prefixed with a `v`, there is *no* prefix for the release version when using this option. + +``` +rancher_min_version: 2.3.0 +rancher_max_version: 2.3.99 +``` + +### Question Variable Reference + +This reference contains variables that you can use in `questions.yml` nested under `questions:`. + +| Variable | Type | Required | Description | +| ------------- | ------------- | --- |------------- | +| variable | string | true | Define the variable name specified in the `values.yml` file, using `foo.bar` for nested objects. | +| label | string | true | Define the UI label. | +| description | string | false | Specify the description of the variable.| +| type | string | false | Default to `string` if not specified (current supported types are string, multiline, boolean, int, enum, password, storageclass, hostname, pvc, and secret).| +| required | bool | false | Define if the variable is required or not (true \| false)| +| default | string | false | Specify the default value. | +| group | string | false | Group questions by input value. | +| min_length | int | false | Min character length.| +| max_length | int | false | Max character length.| +| min | int | false | Min integer length. | +| max | int | false | Max integer length. | +| options | []string | false | Specify the options when the variable type is `enum`, for example: options:
- "ClusterIP"
- "NodePort"
- "LoadBalancer"| +| valid_chars | string | false | Regular expression for input chars validation. | +| invalid_chars | string | false | Regular expression for invalid input chars validation.| +| subquestions | []subquestion | false| Add an array of subquestions.| +| show_if | string | false | Show current variable if conditional variable is true. For example `show_if: "serviceType=Nodeport"` | +| show\_subquestion_if | string | false | Show subquestions if is true or equal to one of the options. for example `show_subquestion_if: "true"`| + +>**Note:** `subquestions[]` cannot contain `subquestions` or `show_subquestions_if` keys, but all other keys in the above table are supported. diff --git a/content/rancher/v2.6/en/installation/install-rancher-on-k8s/_index.md b/content/rancher/v2.6/en/installation/install-rancher-on-k8s/_index.md index dfb0df08af7..11b5f6c2def 100644 --- a/content/rancher/v2.6/en/installation/install-rancher-on-k8s/_index.md +++ b/content/rancher/v2.6/en/installation/install-rancher-on-k8s/_index.md @@ -181,6 +181,8 @@ deployment "rancher" successfully rolled out This option uses `cert-manager` to automatically request and renew [Let's Encrypt](https://letsencrypt.org/) certificates. This is a free service that provides you with a valid certificate as Let's Encrypt is a trusted CA. +>**Note:**: You need to have port 80 open as the HTTP-01 challenge can only be done on port 80. + In the following command, - `hostname` is set to the public DNS record, diff --git a/content/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/_index.md b/content/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/_index.md index 652e9057515..fd46576cf20 100644 --- a/content/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/_index.md +++ b/content/rancher/v2.6/en/installation/install-rancher-on-k8s/rollbacks/_index.md @@ -18,7 +18,7 @@ A restore is performed by creating a Restore custom resource. > **Important** > > * Follow the instructions from this page for restoring rancher on the same cluster where it was backed up from. In order to migrate rancher to a new cluster, follow the steps to [migrate rancher.]({{}}/rancher/v2.6/en/backups/migrating-rancher) -> * While restoring Rancher on the same setup, the Rancher deployment is manually scaled down before the restore starts, then the operator will scale it back up once the restore completes. So Rancher will be unavailable during the restore. +> * While restoring Rancher on the same setup, the Rancher deployment is manually scaled down before the restore starts, then the operator will scale it back up once the restore completes. As a result, Rancher and its UI will be unavailable until the restore is complete. While the UI is unavailable, use the original cluster kubeconfig with the restore YAML file: `kubectl create -f restore.yaml`. ### Scale the Rancher Deployment to 0 @@ -32,11 +32,13 @@ A restore is performed by creating a Restore custom resource. ### Create the Restore Custom Resource -1. Click **☰ > Cluster Management**. -1. Go to the cluster that you created and click **Explore**. +1. Click **☰ > Cluster Management**. +1. Go to the local cluster and click **Explore**. 1. In the left navigation bar, click **Rancher Backups > Restore**. + * **Note:** If the Rancher Backups app is not visible, you will need to install it from the Charts page in **Apps & Marketplace**. Refer [here]({{}}/rancher/v2.6/en/helm-charts/#charts) for more information. 1. Click **Create**. -1. Create the Restore with the form, or with YAML. For creating the Restore resource using form, refer to the [configuration reference]({{}}/rancher/v2.6/en/backups/configuration/restore-config) and to the [examples.]({{}}/rancher/v2.6/en/backups/examples) The following is an example Restore custom resource: +1. Create the Restore with the form or with YAML. For help creating the Restore resource using the online form, refer to the [configuration reference]({{}}/rancher/v2.6/en/backups/configuration/restore-config) and to the [examples.]({{}}/rancher/v2.6/en/backups/examples) +1. To use the YAML editor, you can click **Create > Create from YAML.** Enter the Restore YAML. The following is an example Restore custom resource: ```yaml apiVersion: resources.cattle.io/v1 @@ -55,8 +57,7 @@ A restore is performed by creating a Restore custom resource. region: us-west-2 endpoint: s3.us-west-2.amazonaws.com ``` - - For help configuring the Restore, refer to the [configuration reference]({{}}/rancher/v2.6/en/backups/configuration/restore-config/) and to the [examples.]({{}}/rancher/v2.6/en/backups/examples/) + For help configuring the Restore, refer to the [configuration reference]({{}}/rancher/v2.6/en/backups/configuration/restore-config) and to the [examples.]({{}}/rancher/v2.6/en/backups/examples) 1. Click **Create**. diff --git a/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/_index.md b/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/_index.md index d2be9a4a1ef..8f15d855e8e 100644 --- a/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/_index.md +++ b/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/_index.md @@ -107,7 +107,8 @@ helm template cert-manager ./cert-manager-v1.5.1.tgz --output-dir . \ --namespace cert-manager \ --set image.repository=/quay.io/jetstack/cert-manager-controller \ --set webhook.image.repository=/quay.io/jetstack/cert-manager-webhook \ - --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector + --set cainjector.image.repository=/quay.io/jetstack/cert-manager-cainjector \ + --set startupapicheck.image.repository=/quay.io/jetstack/cert-manager-ctl ``` ### 4. Download the cert-manager CRD diff --git a/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md b/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md index f58ef372b27..5245f52e95d 100644 --- a/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md +++ b/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/launch-kubernetes/_index.md @@ -206,7 +206,7 @@ rke up --config ./rancher-cluster.yml Save a copy of the following files in a secure location: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. +- `kube_config_cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. - `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates.

_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._ {{% /tab %}} {{% /tabs %}} diff --git a/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md b/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md index 2c27c28bb2c..05b260b3aa5 100644 --- a/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md +++ b/content/rancher/v2.6/en/installation/other-installation-methods/air-gap/populate-private-registry/_index.md @@ -59,7 +59,7 @@ In a Kubernetes Install, if you elect to use the Rancher default self-signed TLS helm repo add jetstack https://charts.jetstack.io helm repo update helm fetch jetstack/cert-manager --version v1.5.1 - helm template ./cert-manager-.tgz | grep -oP '(?<=image: ").*(?=")' >> ./rancher-images.txt + helm template ./cert-manager-.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt ``` 2. Sort and unique the images list to remove any overlap between the sources: @@ -230,7 +230,7 @@ The workstation must have Docker 18.02+ in order to support manifests, which are helm repo add jetstack https://charts.jetstack.io helm repo update helm fetch jetstack/cert-manager --version v0.12.0 - helm template ./cert-manager-.tgz | grep -oP '(?<=image: ").*(?=")' >> ./rancher-images.txt + helm template ./cert-manager-.tgz | awk '$1 ~ /image:/ {print $2}' | sed s/\"//g >> ./rancher-images.txt ``` 2. Sort and unique the images list to remove any overlap between the sources: diff --git a/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md b/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md index 574e881c4c8..b47128310e9 100644 --- a/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md +++ b/content/rancher/v2.6/en/installation/other-installation-methods/behind-proxy/launch-kubernetes/_index.md @@ -112,12 +112,12 @@ After that, you can create the Kubernetes cluster by running: rke up --config rancher-cluster.yaml ``` -RKE creates a state file called `rancher-cluster.rkestate`, this is needed if you want to perform updates, modify your cluster configuration or restore it from a backup. It also creates a `kube_config_rancher-cluster.yaml` file, that you can use to connect to the remote Kubernetes cluster locally with tools like kubectl or Helm. Make sure to save all of these files in a secure location, for example by putting them into a version control system. +RKE creates a state file called `rancher-cluster.rkestate`, this is needed if you want to perform updates, modify your cluster configuration or restore it from a backup. It also creates a `kube_config_cluster.yaml` file, that you can use to connect to the remote Kubernetes cluster locally with tools like kubectl or Helm. Make sure to save all of these files in a secure location, for example by putting them into a version control system. To have a look at your cluster run: ``` -export KUBECONFIG=kube_config_rancher-cluster.yaml +export KUBECONFIG=kube_config_cluster.yaml kubectl cluster-info kubectl get pods --all-namespaces ``` @@ -139,7 +139,7 @@ default backend - 404 Save a copy of the following files in a secure location: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. +- `kube_config_cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. - `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains the current state of the cluster including the RKE configuration and the certificates. > **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file. diff --git a/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/_index.md b/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/_index.md index c047052f024..26ba9770630 100644 --- a/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/_index.md +++ b/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/_index.md @@ -44,14 +44,13 @@ Choose from the following options: - [Option B: Bring Your Own Certificate, Self-signed](#option-b-bring-your-own-certificate-self-signed) - [Option C: Bring Your Own Certificate, Signed by a Recognized CA](#option-c-bring-your-own-certificate-signed-by-a-recognized-ca) - [Option D: Let's Encrypt Certificate](#option-d-let-s-encrypt-certificate) +- [Option E: Localhost tunneling, no Certificate](#option-e-localhost-tunneling-no-certificate) ### Option A: Default Rancher-generated Self-signed Certificate If you are installing Rancher in a development or testing environment where identity verification isn't a concern, install Rancher using the self-signed certificate that it generates. This installation option omits the hassle of generating a certificate yourself. -Log into your Linux host, and then run the minimum installation command below. - -Privileged access is [required.](#privileged-access-for-rancher) +Log into your host, and run the command below: ```bash docker run -d --restart=unless-stopped \ @@ -78,7 +77,7 @@ After creating your certificate, run the Docker command below to install Rancher | `` | The path to the private key for your certificate. | | `` | The path to the certificate authority's certificate. | -Privileged access is [required.](#privileged-access-for-rancher) +Log into your host, and run the command below: ```bash docker run -d --restart=unless-stopped \ @@ -110,7 +109,7 @@ After obtaining your certificate, run the Docker command below. | `` | The path to your full certificate chain. | | `` | The path to the private key for your certificate. | -Privileged access is [required.](#privileged-access-for-rancher) +Log into your host, and run the command below: ```bash docker run -d --restart=unless-stopped \ @@ -140,7 +139,7 @@ After you fulfill the prerequisites, you can install Rancher using a Let's Encry | ----------------- | ------------------- | | `` | Your domain address | -Privileged access is [required.](#privileged-access-for-rancher) +Log into your host, and run the command below: ``` docker run -d --restart=unless-stopped \ @@ -150,6 +149,22 @@ docker run -d --restart=unless-stopped \ --acme-domain ``` +### Option E: Localhost tunneling, no Certificate + +If you are installing Rancher in a development or testing environment where you have a localhost tunneling solution running, such as [ngrok](https://ngrok.com/), avoid generating a certificate. This installation option doesn't require a certificate. + +- You will use `--no-cacerts` in the argument to disable the default CA certificate generated by Rancher. + +Log into your host, and run the command below: + +```bash +docker run -d --restart=unless-stopped \ + -p 80:80 -p 443:443 \ + --privileged \ + rancher/rancher:latest \ + --no-cacerts +``` + ## Advanced Options When installing Rancher on a single node with Docker, there are several advanced options that can be enabled: diff --git a/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md b/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md index 7ee1d1f9328..42a5504789d 100644 --- a/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md +++ b/content/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/single-node-upgrades/_index.md @@ -80,7 +80,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--.tar.gz /var/lib/rancher + docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher ``` **Step Result:** When you enter this command, a series of commands should run. diff --git a/content/rancher/v2.6/en/installation/requirements/_index.md b/content/rancher/v2.6/en/installation/requirements/_index.md index 6ca43607b08..0fd9eaa5669 100644 --- a/content/rancher/v2.6/en/installation/requirements/_index.md +++ b/content/rancher/v2.6/en/installation/requirements/_index.md @@ -58,6 +58,12 @@ If you plan to run Rancher on ARM64, see [Running on ARM64 (Experimental).]({{ **Note:** If you have used a different file name from `rancher-cluster.yml`, then the kube config file will be named `kube_config_.yml`. -Move this file to `$HOME/.kube/config`, or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_rancher-cluster.yml`: +Move this file to `$HOME/.kube/config`, or if you are working with multiple Kubernetes clusters, set the `KUBECONFIG` environmental variable to the path of `kube_config_cluster.yml`: ``` -export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml +export KUBECONFIG=$(pwd)/kube_config_cluster.yml ``` Test your connectivity with `kubectl` and see if all your nodes are in `Ready` state: @@ -153,7 +153,7 @@ This confirms that you have successfully installed a Kubernetes cluster that the Save a copy of the following files in a secure location: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. +- `kube_config_cluster.yml`: The [Kubeconfig file]({{}}/rke/latest/en/kubeconfig/) for the cluster, this file contains credentials for full access to the cluster. - `rancher-cluster.rkestate`: The [Kubernetes Cluster State file]({{}}/rke/latest/en/installation/#kubernetes-cluster-state), this file contains credentials for full access to the cluster.

_The Kubernetes Cluster State file is only created when using RKE v0.2.0 or higher._ > **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file. diff --git a/content/rancher/v2.6/en/installation/resources/k8s-tutorials/ha-rke2/_index.md b/content/rancher/v2.6/en/installation/resources/k8s-tutorials/ha-rke2/_index.md index 6c72adfaf09..f1a1c52bab1 100644 --- a/content/rancher/v2.6/en/installation/resources/k8s-tutorials/ha-rke2/_index.md +++ b/content/rancher/v2.6/en/installation/resources/k8s-tutorials/ha-rke2/_index.md @@ -5,7 +5,7 @@ weight: 2 --- _Tested on v2.5.6_ -This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.]({{}}/rancher/v2.x/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) +This section describes how to install a Kubernetes cluster according to the [best practices for the Rancher server environment.]({{}}/rancher/v2.6/en/overview/architecture-recommendations/#environment-for-kubernetes-installations) # Prerequisites diff --git a/content/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md b/content/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md index 82eb68522f7..e03f8ccc868 100644 --- a/content/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md +++ b/content/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/infra-for-rke2-ha/_index.md @@ -17,9 +17,9 @@ To install the Rancher management server on a high-availability RKE2 cluster, we ### 1. Set up Linux Nodes -Make sure that your nodes fulfill the general installation requirements for [OS, container runtime, hardware, and networking.]({{}}/rancher/v2.x/en/installation/requirements/) +Make sure that your nodes fulfill the general installation requirements for [OS, container runtime, hardware, and networking.]({{}}/rancher/v2.6/en/installation/requirements/) -For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/rancher/v2.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/ec2-node) for setting up nodes as instances in Amazon EC2. +For an example of one way to set up Linux nodes, refer to this [tutorial]({{}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/ec2-node) for setting up nodes as instances in Amazon EC2. ### 2. Set up the Load Balancer @@ -32,11 +32,11 @@ When Rancher is installed (also in a later step), the Rancher system creates an For your implementation, consider if you want or need to use a Layer-4 or Layer-7 load balancer: - **A layer-4 load balancer** is the simpler of the two choices, in which you are forwarding TCP traffic to your nodes. We recommend configuring your load balancer as a Layer 4 balancer, forwarding traffic to ports TCP/80 and TCP/443 to the Rancher management cluster nodes. The Ingress controller on the cluster will redirect HTTP traffic to HTTPS and terminate SSL/TLS on port TCP/443. The Ingress controller will forward traffic to port TCP/80 to the Ingress pod in the Rancher deployment. -- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.]({{}}/rancher/v2.x/en/installation/resources/chart-options/#external-tls-termination) +- **A layer-7 load balancer** is a bit more complicated but can offer features that you may want. For instance, a layer-7 load balancer is capable of handling TLS termination at the load balancer, as opposed to Rancher doing TLS termination itself. This can be beneficial if you want to centralize your TLS termination in your infrastructure. Layer-7 load balancing also offers the capability for your load balancer to make decisions based on HTTP attributes such as cookies, etc. that a layer-4 load balancer is not able to concern itself with. If you decide to terminate the SSL/TLS traffic on a layer-7 load balancer, you will need to use the `--set tls=external` option when installing Rancher in a later step. For more information, refer to the [Rancher Helm chart options.]({{}}/rancher/v2.6/en/installation/resources/chart-options/#external-tls-termination) For an example showing how to set up an NGINX load balancer, refer to [this page.]({{}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/nginx/) -For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{}}/rancher/v2.x/en/installation/resources/k8s-tutorials/infrastructure-tutorials/nlb/) +For a how-to guide for setting up an Amazon ELB Network Load Balancer, refer to [this page.]({{}}/rancher/v2.6/en/installation/resources/k8s-tutorials/infrastructure-tutorials/nlb/) > **Important:** > Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance applications other than Rancher following installation. Sharing this Ingress with other applications may result in websocket errors to Rancher following Ingress configuration reloads for other apps. We recommend dedicating the `local` cluster to Rancher and no other applications. diff --git a/content/rancher/v2.6/en/installation/resources/tls-secrets/_index.md b/content/rancher/v2.6/en/installation/resources/tls-secrets/_index.md index e977c983669..cd11f1e9684 100644 --- a/content/rancher/v2.6/en/installation/resources/tls-secrets/_index.md +++ b/content/rancher/v2.6/en/installation/resources/tls-secrets/_index.md @@ -35,4 +35,4 @@ kubectl -n cattle-system create secret generic tls-ca \ # Updating a Private CA Certificate -Follow the steps on [this page]({{}}/rancher/v2.x/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.6/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. \ No newline at end of file +Follow the steps on [this page]({{}}/rancher/v2.6/en/installation/resources/update-ca-cert) to update the SSL certificate of the ingress in a Rancher [high availability Kubernetes installation]({{}}/rancher/v2.6/en/installation/install-rancher-on-k8s/) or to switch from the default self-signed certificate to a custom certificate. \ No newline at end of file diff --git a/content/rancher/v2.6/en/istio/release-notes/_index.md b/content/rancher/v2.6/en/istio/release-notes/_index.md deleted file mode 100644 index 9f02fa9b30e..00000000000 --- a/content/rancher/v2.6/en/istio/release-notes/_index.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Release Notes -weight: 100 ---- - -# Istio 1.5.9 release notes - -**Bug fixes** - -* The Kiali traffic graph is now working [#28109](https://github.com/rancher/rancher/issues/28109) - -**Known Issues** - -* The Kiali traffic graph is offset in the UI [#28207](https://github.com/rancher/rancher/issues/28207) - - -# Istio 1.5.8 - -### Important note on 1.5.x versions - -When upgrading from any 1.4 version of Istio to any 1.5 version, the Rancher installer will delete several resources in order to complete the upgrade, at which point they will be immediately re-installed. This includes the `istio-reader-service-account`. If your Istio installation is using this service account be aware that any secrets tied to the service account will be deleted. Most notably this will **break specific [multi-cluster deployments](https://archive.istio.io/v1.4/docs/setup/install/multicluster/)**. Downgrades back to 1.4 are not possible. - -See the official upgrade notes for additional information on the 1.5 release and upgrading from 1.4: https://istio.io/latest/news/releases/1.5.x/announcing-1.5/upgrade-notes/ - -> **Note:** Rancher continues to use the Helm installation method, which produces a different architecture from an istioctl installation. - -### Known Issues - -* The Kiali traffic graph is currently not working [#24924](https://github.com/istio/istio/issues/24924) \ No newline at end of file diff --git a/content/rancher/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md b/content/rancher/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md index 3ca7dc768d4..bb69c198262 100644 --- a/content/rancher/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md +++ b/content/rancher/v2.6/en/k8s-in-rancher/load-balancers-and-ingress/ingress/_index.md @@ -14,6 +14,7 @@ Ingresses can be added for workloads to provide load balancing, SSL termination 1. Enter a **Name** for the ingress. 1. Create ingress forwarding **Rules**. For help configuring the rules, refer to [this section.](#ingress-rule-configuration) If any of your ingress rules handle requests for encrypted ports, add a certificate to encrypt/decrypt communications. 1. **Optional:** click **Add Rule** to create additional ingress rules. For example, after you create ingress rules to direct requests for your hostname, you'll likely want to create a default backend to handle 404s. +1. Click **Create** at the bottom right. **Result:** Your ingress is added to the project. The ingress begins enforcing your ingress rules. diff --git a/content/rancher/v2.6/en/k8s-in-rancher/registries/_index.md b/content/rancher/v2.6/en/k8s-in-rancher/registries/_index.md index 38a88542576..0b075b620d0 100644 --- a/content/rancher/v2.6/en/k8s-in-rancher/registries/_index.md +++ b/content/rancher/v2.6/en/k8s-in-rancher/registries/_index.md @@ -14,13 +14,13 @@ Deployments use the Kubernetes registry secret to authenticate with a private Do Currently, deployments pull the private registry credentials automatically only if the workload is created in the Rancher UI and not when it is created via kubectl. -# Creating a Registry +# Creating a Registry in Namespaces >**Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use. 1. In the upper left corner, click **☰ > Cluster Management**. 1. Go to the cluster where you want to add a registry and click **Explore**. -1. In the left navigation lick **More Resources > Core > Secrets**. +1. In the left navigation, click either **Storage > Secrets** or **More Resources > Core > Secrets**. 1. Click **Create**. 1. Click **Registry**. 1. Enter a **Name** for the registry. @@ -28,17 +28,46 @@ Currently, deployments pull the private registry credentials automatically only >**Note:** Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace. 1. Select a namespace for the registry. - 1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password. - 1. Click **Save**. **Result:** -- Your secret is added to the project or namespace, depending on the scope you chose. -- You can view the secret in the Rancher UI from the **Resources > Registries** view. +- Your secret is added to the namespace you chose. +- You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**. - Any workload that you create in the Rancher UI will have the credentials to access the registry if the workload is within the registry's scope. +# Creating a Registry in Projects + +>**Prerequisites:** You must have a [private registry](https://docs.docker.com/registry/deploying/) available to use. + +Before v2.6, secrets were required to be in a project scope. Projects are no longer required, and you may use the namespace scope instead. As a result, the Rancher UI was updated to reflect this new functionality. However, you may still create a project-scoped registry if desired. Use the following steps to do so: + +1. In the upper left corner, click **☰ > Global Settings** in the dropdown. +1. Click **Feature Flags**. +1. Go to the `legacy` feature flag and click **Activate**. +1. In the upper left corner, click **☰ > Cluster Management**. +1. Go to the cluster where you want to add a registry and click **Explore**. +1. In the left navigation, click either **Storage > Secrets** or **More Resources > Core > Secrets**. +1. Click **Create**. +1. Click **Registry**. +1. In the top navigation bar, filter to see only one project. +1. Enter a **Name** for the registry. + + >**Note:** Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your registry must have a unique name among all secrets within your workspace. + +1. Select a namespace for the registry. +1. Select the website that hosts your private registry. Then enter credentials that authenticate with the registry. For example, if you use DockerHub, provide your DockerHub username and password. +1. Click **Save**. + +**Result:** + +- Your secret is added to the individual project you chose. +- You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**. +- Any workload that you create in the Rancher UI will have the credentials to access the registry if the workload is within the registry's scope. + +>**Note:** Project-scoped registries on the local cluster are only visible when a single project is selected. + # Using a Private Registry You can deploy a workload with an image from a private registry through the Rancher UI, or with `kubectl`. diff --git a/content/rancher/v2.6/en/k8s-in-rancher/secrets/_index.md b/content/rancher/v2.6/en/k8s-in-rancher/secrets/_index.md index 0663d4f1bc3..9c7f74220ea 100644 --- a/content/rancher/v2.6/en/k8s-in-rancher/secrets/_index.md +++ b/content/rancher/v2.6/en/k8s-in-rancher/secrets/_index.md @@ -11,17 +11,17 @@ When configuring a workload, you'll be able to choose which secrets to include. Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically) -# Creating Secrets +# Creating Secrets in Namespaces 1. In the upper left corner, click **☰ > Cluster Management**. 1. Go to the cluster where you want to add a secret and click **Explore**. -1. Click **More Resources > Core > Secrets**. +1. To navigate to secrets, you may click either **Storage > Secrets** or **More Resources > Core > Secrets**. 1. Click **Create**. 1. Select the type of secret you want to create. 1. Select a **Namespace** for the secret. 1. Enter a **Name** for the secret. - >**Note:** Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a project or namespace can have duplicate names. Therefore, to prevent conflicts, your secret must have a unique name among all secrets within your workspace. + >**Note:** Kubernetes classifies secrets, certificates, and registries all as [secrets](https://kubernetes.io/docs/concepts/configuration/secret/), and no two secrets in a namespace can have duplicate names. Therefore, to prevent conflicts, your secret must have a unique name among all secrets within your workspace. 1. From **Data**, click **Add** to add a key-value pair. Add as many values as you need. @@ -31,12 +31,31 @@ Mounted secrets will be updated automatically unless they are mounted as subpath 1. Click **Save**. -**Result:** Your secret is added to the project or namespace, depending on the scope you chose. You can view the secret in the Rancher UI from the **Resources > Secrets** view. +**Result:** Your secret is added to the namespace you chose. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**. Mounted secrets will be updated automatically unless they are mounted as subpath volumes. For details on how updated secrets are propagated, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/configuration/secret/#mounted-secrets-are-updated-automatically) + +# Creating Secrets in Projects + +Before v2.6, secrets were required to be in a project scope. Projects are no longer required, and you may use the namespace scope instead. As a result, the Rancher UI was updated to reflect this new functionality. However, you may still create project-scoped secrets if desired. Note that you have to first enable the `legacy` feature flag and look at a single project to do so. Use the following steps to set up your project-level secret: + +1. In the upper left corner, click **☰ > Global Settings** in the dropdown. +1. Click **Feature Flags**. +1. Go to the `legacy` feature flag and click **Activate**. +1. In the upper left corner, click **☰ > Cluster Management** in the dropdown. +1. Go to the cluster that you created and click **Explore.** +1. Click **Legacy > Projects**. +1. In the top navigation bar, filter to see only one project. +1. In the left navigation bar, click **Secrets**. +1. Click **Add Secret**. + +**Result:** Your secret is added to the individual project you chose. You can view the secret in the Rancher UI by clicking either **Storage > Secrets** or **More Resources > Core > Secrets**. + +>**Note:** Project-scoped secrets on the local cluster are only visible when a single project is selected. + # What's Next? -Now that you have a secret added to the project or namespace, you can add it to a workload that you deploy. +Now that you have a secret added to a namespace, you can add it to a workload that you deploy. For more information on adding secret to a workload, see [Deploying Workloads]({{}}/rancher/v2.6/en/k8s-in-rancher/workloads/deploy-workloads/). diff --git a/content/rancher/v2.6/en/monitoring-alerting/guides/enable-monitoring/_index.md b/content/rancher/v2.6/en/monitoring-alerting/guides/enable-monitoring/_index.md index cf84b6cbf65..29c21812eb9 100644 --- a/content/rancher/v2.6/en/monitoring-alerting/guides/enable-monitoring/_index.md +++ b/content/rancher/v2.6/en/monitoring-alerting/guides/enable-monitoring/_index.md @@ -29,11 +29,9 @@ For more information about the default limits, see [this page.]({{}}/ra 1. Click **☰ > Cluster Management**. 1. Go to the cluster that you created and click **Explore**. -1. Click **Apps & Marketplace**. -1. Click **Charts**. -1. Click the **Monitoring** app. -1. Optional: Click **Chart Options** and configure alerting, Prometheus and Grafana. For help, refer to the [configuration reference.]({{}}/rancher/v2.6/en/monitoring-alerting/configuration/helm-chart-options/) -1. Scroll to the bottom of the Helm chart README and click **Install**. +1. Click **Cluster Tools** (bottom left corner). +1. Click **Install** by Monitoring. +1. Optional: Customize requests, limits and more for Alerting, Prometheus, and Grafana in the Values step. For help, refer to the [configuration reference.]({{}}/rancher/v2.6/en/monitoring-alerting/configuration/helm-chart-options/) **Result:** The monitoring app is deployed in the `cattle-monitoring-system` namespace. @@ -63,4 +61,4 @@ cert.pem=`base64-content` key.pfx=`base64-content` ``` -Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`. \ No newline at end of file +Then **Cert File Path** would be set to `/etc/alertmanager/secrets/cert.pem`. diff --git a/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md b/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md index ba487525225..e025b733e64 100644 --- a/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md +++ b/content/rancher/v2.6/en/monitoring-alerting/rbac/_index.md @@ -124,8 +124,8 @@ The relationship between the default roles deployed by Rancher (i.e. cluster-own | --------- | --------- | --------- | --------- | | cluster-owner | cluster-admin | N/A | ClusterRoleBinding | | cluster-member | admin | monitoring-admin | ClusterRoleBinding | -| project-owner | edit | monitoring-admin | RoleBinding within Project namespace | -| project-member | view | monitoring-edit | RoleBinding within Project namespace | +| project-owner | admin | monitoring-admin | RoleBinding within Project namespace | +| project-member | edit | monitoring-edit | RoleBinding within Project namespace | In addition to these default Roles, the following additional Rancher project roles can be applied to members of your Cluster to provide additional access to Monitoring. These Rancher Roles will be tied to ClusterRoles deployed by the Monitoring chart: diff --git a/content/rancher/v2.6/en/overview/architecture-recommendations/_index.md b/content/rancher/v2.6/en/overview/architecture-recommendations/_index.md index e476540c0b4..179346f74aa 100644 --- a/content/rancher/v2.6/en/overview/architecture-recommendations/_index.md +++ b/content/rancher/v2.6/en/overview/architecture-recommendations/_index.md @@ -32,7 +32,7 @@ We don't recommend installing Rancher in a single Docker container, because if t ### K3s Kubernetes Cluster Installations -One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s Rancher's CNCF certified Kubernetes distribution. It is easy to install, with half the memory of Kubernetes, all in a binary less than 100 MB. One main advantage of this K3s architecture is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral. +One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s is Rancher's CNCF certified Kubernetes distribution. It is easy to install and uses half the memory of Kubernetes, all in a binary of less than 100 MB. Another advantage of K3s is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server
![Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server]({{}}/img/rancher/k3s-server-storage.svg) diff --git a/content/rancher/v2.6/en/overview/architecture/_index.md b/content/rancher/v2.6/en/overview/architecture/_index.md index 3fb4384308e..a42fe9a2015 100644 --- a/content/rancher/v2.6/en/overview/architecture/_index.md +++ b/content/rancher/v2.6/en/overview/architecture/_index.md @@ -75,7 +75,7 @@ The authentication proxy forwards all Kubernetes API calls to downstream cluster Rancher communicates with Kubernetes clusters using a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/), which provides an identity for processes that run in a pod. -By default, Rancher generates a [kubeconfig file]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_rancher-cluster.yml`) contains full access to the cluster. +By default, Rancher generates a [kubeconfig file]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_cluster.yml`) contains full access to the cluster. ### 2. Cluster Controllers and Cluster Agents @@ -131,7 +131,7 @@ You will need to use a context defined in this kubeconfig file to access the clu The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster: - `rancher-cluster.yml`: The RKE cluster configuration file. -- `kube_config_rancher-cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down. +- `kube_config_cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down. - `rancher-cluster.rkestate`: The Kubernetes cluster state file. This file contains credentials for full access to the cluster. Note: This state file is only created when using RKE v0.2.0 or higher. > **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file. diff --git a/content/rancher/v2.6/en/overview/concepts/_index.md b/content/rancher/v2.6/en/overview/concepts/_index.md index 2736a842f2d..5cd01b9460c 100644 --- a/content/rancher/v2.6/en/overview/concepts/_index.md +++ b/content/rancher/v2.6/en/overview/concepts/_index.md @@ -52,7 +52,7 @@ Three etcd nodes is generally sufficient for smaller clusters and five etcd node ### Controlplane Nodes -Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although two or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles. +Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although three or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles. ### Worker Nodes diff --git a/content/rancher/v2.6/en/pipelines/_index.md b/content/rancher/v2.6/en/pipelines/_index.md index ebf82d30aaf..5c9a2e868d7 100644 --- a/content/rancher/v2.6/en/pipelines/_index.md +++ b/content/rancher/v2.6/en/pipelines/_index.md @@ -3,7 +3,12 @@ title: Pipelines weight: 10 --- -> As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet.](https://fleet.rancher.io/) To get to Fleet in Rancher, click ☰ > Continuous Delivery. Note that pipelines in Kubernetes 1.21+ are no longer supported. +> As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{}}/rancher/v2.6/en/deploy-across-clusters/fleet). To get to Fleet in Rancher, click ☰ > Continuous Delivery. +> +>**Notice:** +> +> - Pipelines in Kubernetes 1.21+ are no longer supported. +> - Fleet does not replace Rancher pipelines; the distinction is that Rancher pipelines are now powered by Fleet. Rancher's pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds or scripts, publish Docker images or catalog applications, and deploy the updated software to users. diff --git a/content/rancher/v2.6/en/project-admin/project-members/_index.md b/content/rancher/v2.6/en/project-admin/project-members/_index.md index c84e655974f..32708445e60 100644 --- a/content/rancher/v2.6/en/project-admin/project-members/_index.md +++ b/content/rancher/v2.6/en/project-admin/project-members/_index.md @@ -38,7 +38,9 @@ Following project creation, you can add users as project members so that they ca >**Notes:** > - >- 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. + >- 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 or delete 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. > >- For `Custom` roles, you can modify the list of individual roles available for assignment. > diff --git a/content/rancher/v2.6/en/quick-start-guide/deployment/_index.md b/content/rancher/v2.6/en/quick-start-guide/deployment/_index.md index f7d4da476aa..b3169225fe4 100644 --- a/content/rancher/v2.6/en/quick-start-guide/deployment/_index.md +++ b/content/rancher/v2.6/en/quick-start-guide/deployment/_index.md @@ -9,8 +9,10 @@ Use one of the following guides to deploy and provision Rancher and a Kubernetes - [AWS](./amazon-aws-qs) (uses Terraform) - [Azure](./microsoft-azure-qs) (uses Terraform) - [GCP](./google-gcp-qs) (uses Terraform) +- [Hetzner Cloud](./hetzner-cloud-qs) (uses Terraform) - [Vagrant](./quickstart-vagrant) + If you prefer, the following guide will take you through the same process in individual steps. Use this if you want to run Rancher in a different provider, on prem, or if you would just like to see how easy it is. - [Manual Install](./quickstart-manual-setup) diff --git a/content/rancher/v2.6/en/quick-start-guide/deployment/equinix-metal-qs.md b/content/rancher/v2.6/en/quick-start-guide/deployment/equinix-metal-qs/_index.md similarity index 100% rename from content/rancher/v2.6/en/quick-start-guide/deployment/equinix-metal-qs.md rename to content/rancher/v2.6/en/quick-start-guide/deployment/equinix-metal-qs/_index.md diff --git a/content/rancher/v2.6/en/quick-start-guide/deployment/hetzner-cloud-qs/_index.md b/content/rancher/v2.6/en/quick-start-guide/deployment/hetzner-cloud-qs/_index.md new file mode 100644 index 00000000000..f0fc2c964a3 --- /dev/null +++ b/content/rancher/v2.6/en/quick-start-guide/deployment/hetzner-cloud-qs/_index.md @@ -0,0 +1,65 @@ +--- +title: Rancher Hetzner Cloud Quick Start Guide +description: Read this step by step Rancher Hetzner Cloud guide to quickly deploy a Rancher Server with a single node cluster attached. +weight: 100 +--- +The following steps will quickly deploy a Rancher Server on Hetzner Cloud with a single node cluster attached. + +## Prerequisites + +>**Note** +>Deploying to Hetzner Cloud will incur charges. + +- [Hetzner Cloud Account](https://www.hetzner.com): You will require an account on Hetzner as this is where the server and cluster will run. +- [Hetzner API Access Key](https://docs.hetzner.cloud/#getting-started): Use these instructions to create a Hetzner Cloud API Key if you don't have one. +- [Terraform](https://www.terraform.io/downloads.html): Used to provision the server and cluster to Hetzner. + + +## Getting Started + +1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`. + +1. Go into the Hetzner folder containing the terraform files by executing `cd quickstart/hcloud`. + +1. Rename the `terraform.tfvars.example` file to `terraform.tfvars`. + +1. Edit `terraform.tfvars` and customize the following variables: + - `hcloud_token` - Hetzner API access key + - `rancher_server_admin_password` - Admin password for created Rancher server + +1. **Optional:** Modify optional variables within `terraform.tfvars`. +See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Hetzner Quickstart Readme](https://github.com/rancher/quickstart/tree/master/hcloud) for more information. +Suggestions include: + - `prefix` - Prefix for all created resources + - `instance_type` - Instance type, minimum required is `cx21` + - `ssh_key_file_name` - Use a specific SSH key instead of `~/.ssh/id_rsa` (public key is assumed to be `${ssh_key_file_name}.pub`) + +1. Run `terraform init`. + +2. To initiate the creation of the environment, run `terraform apply --auto-approve`. Then wait for output similar to the following: + + ``` + Apply complete! Resources: 15 added, 0 changed, 0 destroyed. + + Outputs: + + rancher_node_ip = xx.xx.xx.xx + rancher_server_url = https://rancher.xx.xx.xx.xx.xip.io + workload_node_ip = yy.yy.yy.yy + ``` + +3. Paste the `rancher_server_url` from the output above into the browser. Log in when prompted (default username is `admin`, use the password set in `rancher_server_admin_password`). + +#### Result + +Two Kubernetes clusters are deployed into your Hetzner account, one running Rancher Server and the other ready for experimentation deployments. + +### What's Next? + +Use Rancher to create a deployment. For more information, see [Creating Deployments]({{}}/rancher/v2.6/en/quick-start-guide/workload). + +## Destroying the Environment + +1. From the `quickstart/hcloud` folder, execute `terraform destroy --auto-approve`. + +2. Wait for confirmation that all resources have been destroyed. diff --git a/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-vagrant/_index.md b/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-vagrant/_index.md index 3f22066b26a..0eb0d0ef169 100644 --- a/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-vagrant/_index.md +++ b/content/rancher/v2.6/en/quick-start-guide/deployment/quickstart-vagrant/_index.md @@ -30,7 +30,7 @@ The following steps quickly deploy a Rancher Server with a single node cluster a 4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`. -5. Once provisioning finishes, go to `https://172.22.101.101` in the browser. The default user/password is `admin/admin`. +5. Once provisioning finishes, go to `https://192.168.56.101` in the browser. The default user/password is `admin/admin`. **Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox. diff --git a/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md b/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md index fb4ac811514..5be4b866fb9 100644 --- a/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md +++ b/content/rancher/v2.6/en/quick-start-guide/workload/quickstart-deploy-workload-ingress/_index.md @@ -13,13 +13,14 @@ You're ready to create your first Kubernetes [workload](https://kubernetes.io/do For this workload, you'll be deploying the application Rancher Hello-World. -1. Click **☰ > Cluster Management**. +1. Click **☰ > Cluster Management**. 1. Go to the cluster that you created and click **Explore**. 1. Click **Workload**. 1. Click **Create**. 1. Click **Deployment**. 1. Enter a **Name** for your workload. 1. From the **Docker Image** field, enter `rancher/hello-world`. This field is case-sensitive. +1. Click **Add Port** and enter `80` in the **Private Container Port** field. Adding a port enables access to the application inside and outside of the cluster. For more information, see [Services]({{}}/rancher/v2.6/en/k8s-in-rancher/workloads/#services). 1. Click **Create**. **Result:** @@ -30,32 +31,32 @@ For this workload, you'll be deploying the application Rancher Hello-World.
### 2. Expose The Application Via An Ingress -Now that the application is up and running it needs to be exposed so that other services can connect. +Now that the application is up and running, it needs to be exposed so that other services can connect. 1. Click **☰ > Cluster Management**. -1. Go to the cluster that you created and click **Explore**. +1. Go to the cluster that you created and click **Explore**. -2. From the main menu of the **Dashboard**, select **Projects**. +1. Click **Service Discovery > Ingresses**. -3. Open the **Default** project. +1. Click **Create.** -4. Click **Resources > Workloads > Load Balancing**. Click on the **Load Balancing** tab. +1. When choosing **Namespace**, ensure it is the same as the one used when you created your deployment. Otherwise, your deployment will not be available when you attempt to select **Target Service**, as in Step 8 below. -5. Click **Add Ingress**. +1. Enter a **Name**, such as **hello**. -6. Enter a name i.e. **hello**. +1. Specify your **Path**, such as `/hello`. -7. In the **Target** field, drop down the list and choose the name that you set for your service. +1. In the **Target Service** field, drop down the list and choose the name that you set for your service. -8. Enter `80` in the **Port** field. +1. In the **Port** field, drop down the list and select `80`. -9. Leave everything else as default and click **Save**. +1. Click **Create** at the bottom right. -**Result:** The application is assigned a `xip.io` address and exposed. It may take a minute or two to populate. +**Result:** The application is assigned a `sslip.io` address and exposed. It may take a minute or two to populate. ### View Your Application -From the **Load Balancing** page, click the target link, which will look something like `hello.default.xxx.xxx.xxx.xxx.xip.io > hello-world`. +From the **Deployments** page, find the **Endpoints** column for your deployment and click on an endpoint. The endpoints available will depend on how you configured the port you added to your deployment. For endpoints where you do not see a randomly assigned port, append the path you specified when creating the ingress to the IP address. For example, if your endpoint looks like `xxx.xxx.xxx.xxx` or `https://xxx.xxx.xxx.xxx` change it to `xxx.xxx.xxx.xxx/hello` or `https://xxx.xxx.xxx.xxx/hello`. Your application will open in a separate window. diff --git a/content/rancher/v2.6/en/security/_index.md b/content/rancher/v2.6/en/security/_index.md index e2b641dd4d7..871203d2102 100644 --- a/content/rancher/v2.6/en/security/_index.md +++ b/content/rancher/v2.6/en/security/_index.md @@ -42,7 +42,7 @@ The Center for Internet Security (CIS) is a 501(c\)(3) non-profit organization, CIS Benchmarks are best practices for the secure configuration of a target system. CIS Benchmarks are developed through the generous volunteer efforts of subject matter experts, technology vendors, public and private community members, and the CIS Benchmark Development team. -The Benchmark provides recommendations of two types: Scored and Not Scored. We run tests related to only Scored recommendations. +The Benchmark provides recommendations of two types: Automated and Manual. We run tests related to only Automated recommendations. When Rancher runs a CIS security scan on a cluster, it generates a report showing the results of each test, including a summary with the number of passed, skipped and failed tests. The report also includes remediation steps for any failed tests. diff --git a/content/rancher/v2.6/en/troubleshooting/dns/_index.md b/content/rancher/v2.6/en/troubleshooting/dns/_index.md index 47be0497c40..a1292df3e32 100644 --- a/content/rancher/v2.6/en/troubleshooting/dns/_index.md +++ b/content/rancher/v2.6/en/troubleshooting/dns/_index.md @@ -5,7 +5,7 @@ weight: 103 The commands/steps listed on this page can be used to check name resolution issues in your cluster. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. Before running the DNS checks, check the [default DNS provider]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/options/#default-dns-provider) for your cluster and make sure that [the overlay network is functioning correctly]({{}}/rancher/v2.6/en/troubleshooting/networking/#check-if-overlay-network-is-functioning-correctly) as this can also be the reason why DNS resolution (partly) fails. @@ -158,7 +158,7 @@ kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{ Enabling query logging can be done by enabling the [log plugin](https://coredns.io/plugins/log/) in the Corefile configuration in the configmap `coredns`. You can do so by using `kubectl -n kube-system edit configmap coredns` or use the command below to replace the configuration in place: ``` -kubectl get configmap -n kube-system coredns -o json | kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f - +kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log\\n loadbalance_g' | kubectl apply -f - ``` All queries will now be logged and can be checked using the command in [Check CoreDNS logging](#check-coredns-logging). diff --git a/content/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/_index.md b/content/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/_index.md index 99979410992..59a7bfbcc1f 100644 --- a/content/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/_index.md +++ b/content/rancher/v2.6/en/troubleshooting/expired-webhook-certificates/_index.md @@ -10,6 +10,7 @@ Rancher will advise the community once there is a permanent solution in place fo ##### 1. Users with cluster access, run the following commands: ``` kubectl delete secret -n cattle-system cattle-webhook-tls +kubectl delete mutatingwebhookconfigurations.admissionregistration.k8s.io --ignore-not-found=true rancher.cattle.io kubectl delete pod -n cattle-system -l app=rancher-webhook ``` @@ -17,6 +18,8 @@ kubectl delete pod -n cattle-system -l app=rancher-webhook 1. Delete the `cattle-webhook-tls` secret in the `cattle-system` namespace in the local cluster. -1. Delete the `rancher-webhook` pod in the `cattle-system` namespace in the local cluster. +2. Delete the `rancher.cattle.io` mutating webhook -**Note:** The webhook certificate expiration issue is not specific to `cattle-webhook-tls` as listed in the examples. You will fill in your expired certificate secret accordingly. \ No newline at end of file +3. Delete the `rancher-webhook` pod in the `cattle-system` namespace in the local cluster. + +**Note:** The webhook certificate expiration issue is not specific to `cattle-webhook-tls` as listed in the examples. You will fill in your expired certificate secret accordingly. diff --git a/content/rancher/v2.6/en/troubleshooting/kubernetes-components/controlplane/_index.md b/content/rancher/v2.6/en/troubleshooting/kubernetes-components/controlplane/_index.md index 201c6e30aaf..e27339cb8b5 100644 --- a/content/rancher/v2.6/en/troubleshooting/kubernetes-components/controlplane/_index.md +++ b/content/rancher/v2.6/en/troubleshooting/kubernetes-components/controlplane/_index.md @@ -37,4 +37,12 @@ The logging of the containers can contain information on what the problem could docker logs kube-apiserver docker logs kube-controller-manager docker logs kube-scheduler +``` + +# RKE2 Server Logging + +If Rancher provisions an RKE2 cluster that can't communicate with Rancher, you can run this command on a server node in the downstream cluster to get the RKE2 server logs: + +``` +journalctl -u rke2-server -f ``` \ No newline at end of file diff --git a/content/rancher/v2.6/en/troubleshooting/kubernetes-resources/_index.md b/content/rancher/v2.6/en/troubleshooting/kubernetes-resources/_index.md index c45b092bbde..450f02f85df 100644 --- a/content/rancher/v2.6/en/troubleshooting/kubernetes-resources/_index.md +++ b/content/rancher/v2.6/en/troubleshooting/kubernetes-resources/_index.md @@ -5,7 +5,7 @@ weight: 101 The commands/steps listed on this page can be used to check the most important Kubernetes resources and apply to [Rancher Launched Kubernetes]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) clusters. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. - [Nodes](#nodes) - [Get nodes](#get-nodes) diff --git a/content/rancher/v2.6/en/troubleshooting/logging/_index.md b/content/rancher/v2.6/en/troubleshooting/logging/_index.md index 0c038f81ec4..13a7a752bac 100644 --- a/content/rancher/v2.6/en/troubleshooting/logging/_index.md +++ b/content/rancher/v2.6/en/troubleshooting/logging/_index.md @@ -16,7 +16,7 @@ The following log levels are used in Rancher: * Kubernetes install * Configure debug log level ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl -n cattle-system get pods -l app=rancher --no-headers -o custom-columns=name:.metadata.name | while read rancherpod; do kubectl -n cattle-system exec $rancherpod -c rancher -- loglevel --set debug; done OK OK @@ -26,7 +26,7 @@ $ kubectl -n cattle-system logs -l app=rancher -c rancher * Configure info log level ``` -$ KUBECONFIG=./kube_config_rancher-cluster.yml +$ KUBECONFIG=./kube_config_cluster.yml $ kubectl -n cattle-system get pods -l app=rancher --no-headers -o custom-columns=name:.metadata.name | while read rancherpod; do kubectl -n cattle-system exec $rancherpod -c rancher -- loglevel --set info; done OK OK diff --git a/content/rancher/v2.6/en/troubleshooting/networking/_index.md b/content/rancher/v2.6/en/troubleshooting/networking/_index.md index 5960cdf0735..a184369afe3 100644 --- a/content/rancher/v2.6/en/troubleshooting/networking/_index.md +++ b/content/rancher/v2.6/en/troubleshooting/networking/_index.md @@ -5,7 +5,7 @@ weight: 102 The commands/steps listed on this page can be used to check networking related issues in your cluster. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml` for Rancher HA) or are using the embedded kubectl via the UI. ### Double check if all the required ports are opened in your (host) firewall diff --git a/content/rancher/v2.6/en/troubleshooting/rancherha/_index.md b/content/rancher/v2.6/en/troubleshooting/rancherha/_index.md index a30b664c9e2..d724c778cdb 100644 --- a/content/rancher/v2.6/en/troubleshooting/rancherha/_index.md +++ b/content/rancher/v2.6/en/troubleshooting/rancherha/_index.md @@ -5,7 +5,7 @@ weight: 104 The commands/steps listed on this page can be used to check your Rancher Kubernetes Installation. -Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_rancher-cluster.yml`). +Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG=$PWD/kube_config_cluster.yml`). ### Check Rancher pods diff --git a/content/rke/latest/en/config-options/secrets-encryption/_index.md b/content/rke/latest/en/config-options/secrets-encryption/_index.md index 5801592df0a..81e24ff9bf9 100644 --- a/content/rke/latest/en/config-options/secrets-encryption/_index.md +++ b/content/rke/latest/en/config-options/secrets-encryption/_index.md @@ -56,7 +56,7 @@ services: ``` Once enabled, RKE will perform the following [actions](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#encrypting-your-data) to enable at-rest data encryption: -- Generate a new random 32-bit encryption key +- Generate a new random 32-byte encryption key - Generate an encryption provider configuration file using the new key The default [provider](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers) used is `aescbc` - Deploy the provider configuration file to all nodes with `controlplane` role - Update the `kube-apiserver` container arguments to point to the provider configuration file. @@ -105,7 +105,7 @@ OPTIONS: ``` This command will perform the following actions: -- Generate a new random 32-bit encryption key +- Generate a new random 32-byte encryption key - Generate a new provider configuration with the new key as the first provider and the second key as the second provider. When the secrets are rewritten, the first key will be used to encrypt the data on the write operation, while the second key (the old key) will be used to decrypt the stored data during the the read operation - Deploy the new provider configuration to all `controlplane` nodes and restart the `kube-apiserver` - Rewrite all secrets. This process will re-encrypt all the secrets with the new key. @@ -126,7 +126,7 @@ With custom encryption configuration, RKE allows the user to provide their own c The following describes the steps required to configure custom encryption with a user provided 32-byte random key. -Step 1: Generate a 32 byte random key and base64 encode it. If you're on Linux or macOS, run the following command: +Step 1: Generate a 32-byte random key and base64 encode it. If you're on Linux or macOS, run the following command: ``` head -c 32 /dev/urandom | base64 diff --git a/content/rke/latest/en/os/_index.md b/content/rke/latest/en/os/_index.md index d60aa9c39ed..c1e1dc79db8 100644 --- a/content/rke/latest/en/os/_index.md +++ b/content/rke/latest/en/os/_index.md @@ -27,6 +27,10 @@ weight: 5 - [Docker](#docker) - [Installing Docker](#installing-docker) - [Checking the Installed Docker Version](#checking-the-installed-docker-version) +- [Hardware](#hardware) + - [Worker Role](#worker-role) + - [Large Kubernetes Clusters](#large-kubernetes-clusters) + - [Etcd clusters](#etcd-clusters) - [Ports](#ports) - [Opening port TCP/6443 using `iptables`](#opening-port-tcp-6443-using-iptables) - [Opening port TCP/6443 using `firewalld`](#opening-port-tcp-6443-using-firewalld) @@ -274,6 +278,24 @@ Refer to [Installing Docker]({{}}/rancher/v2.5/en/installation/requirem Confirm that a Kubernetes supported version of Docker is installed on your machine, by running `docker version --format '{{.Server.Version}}'`. +## Hardware + +This section describes the hardware requirements for the worker role, large Kubernetes clusters, and etcd clusters. + +### Worker Role + +The hardware requirements for nodes with the `worker` role mostly depend on your workloads. The minimum to run the Kubernetes node components is 1 CPU (core) and 1GB of memory. + +Regarding CPU and memory, it is recommended that the different planes of Kubernetes clusters (etcd, controlplane, and workers) should be hosted on different nodes so that they can scale separately from each other. + +### Large Kubernetes Clusters + +For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters](https://kubernetes.io/docs/setup/best-practices/cluster-large/). + +### Etcd Clusters + +For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation](https://etcd.io/docs/v3.5/op-guide/hardware/). + ## Ports {{< ports-rke-nodes >}} {{< requirements_ports_rke >}} diff --git a/layouts/_default/list.html b/layouts/_default/list.html index e370b7cb515..7da558dd82a 100644 --- a/layouts/_default/list.html +++ b/layouts/_default/list.html @@ -30,11 +30,6 @@ We are transitioning to versioned documentation. The v2.x docs will no longer be maintained. Rancher v2.6 docs • Rancher v2.5 docs • Rancher v2.0-2.4 docs {{end}} - {{ if in .Dir "/pipelines" }} -
- As of Rancher v2.5, Git-based deployment pipelines are now recommended to be handled with Rancher Continuous Delivery powered by Fleet, available in the Rancher UI by clicking ☰ > Continuous Delivery. -
- {{end}} {{ if in .Dir "/multi-cluster-apps" }}
As of Rancher v2.5, multi-cluster apps are deprecated. We now recommend using Fleet for deploying apps across clusters. It is available in the Rancher UI by clicking ☰ > Continuous Delivery. diff --git a/static/img/rancher/helm-app-2.6.png b/static/img/rancher/helm-app-2.6.png new file mode 100644 index 00000000000..b1f43d77f81 Binary files /dev/null and b/static/img/rancher/helm-app-2.6.png differ diff --git a/static/img/rancher/rancher-app-2.6.png b/static/img/rancher/rancher-app-2.6.png new file mode 100644 index 00000000000..07b64f2e9e0 Binary files /dev/null and b/static/img/rancher/rancher-app-2.6.png differ