diff --git a/content/rancher/v2.x/en/admin-settings/authentication/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/_index.md index b6cc3cad3ae..c142d178945 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/_index.md @@ -10,8 +10,6 @@ One of the key features that Rancher adds to Kubernetes is centralized user auth This centralized user authentication is accomplished using the Rancher authentication proxy, which is installed along with the rest of Rancher. This proxy authenticates your users and forwards their requests to your Kubernetes clusters using a service account. - - ## External vs. Local Authentication The Rancher authentication proxy integrates with the following external authentication services. The following table lists the first version of Rancher each service debuted. diff --git a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md index 1e190eb3a7d..cdb24711323 100644 --- a/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md +++ b/content/rancher/v2.x/en/best-practices/v2.5/rancher-managed/monitoring/_index.md @@ -79,7 +79,7 @@ To get your own custom application metrics into Prometheus, you have to collect ### ServiceMonitors and PodMonitors -Once all your workloads expose metrics in a Prometheus format, you have to configure Prometheus to scrape it. Under the hood Rancher is using the [prometheus-operator](https://github.com/prometheus-operator/prometheus-operator). This makes it easy to add additional scraping targets with ServiceMonitors and PodMonitors. A lot of helm charts already include an option to create these monitors directly. You can also find more information in the [Rancher Documentation](TODO). +Once all your workloads expose metrics in a Prometheus format, you have to configure Prometheus to scrape it. Under the hood Rancher is using the [prometheus-operator](https://github.com/prometheus-operator/prometheus-operator). This makes it easy to add additional scraping targets with ServiceMonitors and PodMonitors. A lot of helm charts already include an option to create these monitors directly. You can also find more information in the Rancher documentation. ### Prometheus Push Gateway diff --git a/content/rancher/v2.x/en/cluster-provisioning/_index.md b/content/rancher/v2.x/en/cluster-provisioning/_index.md index 31129b3e6cb..9ec28ddf483 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/_index.md @@ -22,8 +22,9 @@ This section covers the following topics: - [Launching Kubernetes with Rancher](#launching-kubernetes-with-rancher) - [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) - - [Importing and Editing K3s Clusters](#importing-and-editing-k3s-clusters) + The following table summarizes the options and settings available for each cluster type: @@ -72,6 +73,8 @@ These nodes include on-premise bare metal servers, cloud-hosted virtual machines # Importing Existing Clusters +_Available from Rancher v2.0.x-v2.4.x_ + In this type of cluster, Rancher connects to a Kubernetes cluster that has already been set up. Therefore, Rancher does not provision Kubernetes, but only sets up the Rancher agents to communicate with the cluster. Note that Rancher does not automate the provisioning, scaling, or upgrade of imported clusters. Other Rancher features, including management of cluster, role-based access control, policy, and workloads, are available for imported clusters. @@ -94,3 +97,15 @@ When a K3s cluster is imported, Rancher will recognize it as K3s, and the Ranche - The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster. For more information, refer to the section on [imported K3s clusters.]({{}}/rancher/v2.x/en/cluster-provisioning/imported-clusters/#additional-features-of-imported-k3s-clusters) + +# Registering Existing Clusters + +_Available of of v2.5_ + +The cluster registration feature replaced the feature to import clusters. + +Registering EKS clusters now provides additional benefits. For the most part, registered EKS clusters and EKS clusters created in Rancher are treated the same way in the Rancher UI, except for deletion. + +When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher. + +For more information, see [this page.](./registered-clusters) \ No newline at end of file diff --git a/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md index c04cbfcf5eb..2c8f6e10e33 100644 --- a/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md +++ b/content/rancher/v2.x/en/cluster-provisioning/imported-clusters/_index.md @@ -8,6 +8,8 @@ aliases: - /rancher/v2.x/en/tasks/clusters/import-cluster/ --- +_Available as of v2.0.x-v2.4.x_ + When managing an imported cluster, Rancher connects to a Kubernetes cluster that has already been set up. Therefore, Rancher does not provision Kubernetes, but only sets up the Rancher agents to communicate with the cluster. Rancher features, including management of cluster, role-based access control, policy, and workloads, are available for imported clusters. Note that Rancher does not automate the provisioning or scaling of imported clusters. @@ -16,8 +18,6 @@ For all imported Kubernetes clusters except for K3s clusters, the configuration Rancher v2.4 added the capability to import a K3s cluster into Rancher, as well as the ability to upgrade Kubernetes by editing the cluster in the Rancher UI. -> Rancher v2.5 added the ability to [register clusters.](#changes-in-rancher-v2-5) This page will be updated to reflect the new functionality. - - [Changes in Rancher v2.5](#changes-in-rancher-v2-5) - [Features](#features) - [Prerequisites](#prerequisites) @@ -30,11 +30,11 @@ Rancher v2.4 added the capability to import a K3s cluster into Rancher, as well # Changes in Rancher v2.5 -In Rancher v2.5, the cluster registration feature replaced the feature to import clusters. Rancher has more capabilities to manage registered clusters compared to imported clusters, and registering a cluster allows Rancher to treat it as though it were created in Rancher. +In Rancher v2.5, the cluster registration feature replaced the feature to import clusters. -Amazon EKS clusters can now be registered in Rancher. For the most part, registered EKS clusters and EKS clusters created in Rancher are treated the same way in the Rancher UI, except for deletion. +Registering EKS clusters now provides additional benefits. For the most part, registered EKS clusters and EKS clusters created in Rancher are treated the same way in the Rancher UI, except for deletion. -When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher. +When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher. # Features @@ -78,7 +78,12 @@ By default, GKE users are not given this privilege, so you will need to run the 7. Copy the `kubectl` command to your clipboard and run it on a node where kubeconfig is configured to point to the cluster you want to import. If you are unsure it is configured correctly, run `kubectl get nodes` to verify before running the command shown in {{< product >}}. 8. If you are using self signed certificates, you will receive the message `certificate signed by unknown authority`. To work around this validation, copy the command starting with `curl` displayed in {{< product >}} to your clipboard. Then run the command on a node where kubeconfig is configured to point to the cluster you want to import. 9. When you finish running the command(s) on your node, click **Done**. - {{< result_import-cluster >}} + +**Result:** + +- Your cluster is registered and assigned a state of **Pending.** Rancher is deploying resources to manage your cluster. +- You can access your cluster after its state is updated to **Active.** +- **Active** clusters are assigned two Projects: `Default` (containing the namespace `default`) and `System` (containing the namespaces `cattle-system`, `ingress-nginx`, `kube-public` and `kube-system`, if present). > **Note:** > You can not re-import a cluster that is currently active in a Rancher setup. @@ -148,7 +153,7 @@ If the cluster becomes stuck in upgrading, restart the `system-upgrade-controlle To prevent issues when upgrading, the [Kubernetes upgrade best practices](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) should be followed. -### Annotating Imported Clusters +# Annotating Imported Clusters For all types of imported Kubernetes clusters except for K3s Kubernetes clusters, Rancher doesn't have any information about how the cluster is provisioned or configured. @@ -160,14 +165,19 @@ By annotating an imported cluster, it is possible to indicate to Rancher that a This example annotation indicates that a pod security policy is enabled: -```json +``` "capabilities.cattle.io/pspEnabled": "true" ``` The following annotation indicates Ingress capabilities. Note that that the values of non-primitive objects need to be JSON encoded, with quotations escaped. -```json -"capabilities.cattle.io/ingressCapabilities": "[{"customDefaultBackend":true,"ingressProvider":"asdf"}]" +``` +"capabilities.cattle.io/ingressCapabilities": "[ + { + "customDefaultBackend":true, + "ingressProvider":"asdf" + } +]" ``` These capabilities can be annotated for the cluster: diff --git a/content/rancher/v2.x/en/cluster-provisioning/registered-clusters/_index.md b/content/rancher/v2.x/en/cluster-provisioning/registered-clusters/_index.md new file mode 100644 index 00000000000..addf46510e2 --- /dev/null +++ b/content/rancher/v2.x/en/cluster-provisioning/registered-clusters/_index.md @@ -0,0 +1,200 @@ +--- +title: Registering Existing Clusters +weight: 6 +--- + +_Available of of v2.5_ + +The cluster registration feature replaced the feature to import clusters. + +The control that Rancher has to manage a registered cluster depends on the type of cluster. For details, see [Management Capabilities for Registered Clusters.](#management-capabilities-for-registered-clusters) + +Registering EKS clusters now provides additional benefits. + +- [Prerequisites](#prerequisites) +- [Registering a Cluster](#registering-a-cluster) +- [Management Capabilities for Registered Clusters](#management-capabilities-for-registered-clusters) + - [Features for All Registered Clusters](#features-for-all-registered-clusters) + - [Additional Features for Registered K3s Clusters](#additional-features-for-registered-k3s-clusters) + - [Additional Features for Registered EKS Clusters](#additional-features-for-registered-eks-clusters) +- [Configuring K3s Cluster Upgrades](#configuring-k3s-cluster-upgrades) +- [Debug Logging and Troubleshooting for Registered K3s Clusters](#debug-logging-and-troubleshooting=for-registered-k3s-clusters) +- [Annotating Registered Clusters](#annotating-registered-clusters) + +# Prerequisites + +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) + +# Registering a Cluster + +1. From the **Clusters** page, click **Add Cluster**. +2. Choose **Register**. +3. Enter a **Cluster Name**. +4. {{< step_create-cluster_member-roles >}} +5. Click **Create**. +6. The prerequisite for `cluster-admin` privileges is shown (see **Prerequisites** above), including an example command to fulfil the prerequisite. +7. Copy the `kubectl` command to your clipboard and run it on a node where kubeconfig is configured to point to the cluster you want to import. If you are unsure it is configured correctly, run `kubectl get nodes` to verify before running the command shown in Rancher. +8. If you are using self signed certificates, you will receive the message `certificate signed by unknown authority`. To work around this validation, copy the command starting with `curl` displayed in Rancher to your clipboard. Then run the command on a node where kubeconfig is configured to point to the cluster you want to import. +9. When you finish running the command(s) on your node, click **Done**. + +**Result:** + +- Your cluster is registered and assigned a state of **Pending.** Rancher is deploying resources to manage your cluster. +- You can access your cluster after its state is updated to **Active.** +- **Active** clusters are assigned two Projects: `Default` (containing the namespace `default`) and `System` (containing the namespaces `cattle-system`, `ingress-nginx`, `kube-public` and `kube-system`, if present). + + +> **Note:** +> You can not re-register a cluster that is currently active in a Rancher setup. + +### Configuring a K3s Cluster to Enable Registration in Rancher + +The K3s server needs to be configured to allow writing to the kubeconfig file. + +This can be accomplished by passing `--write-kubeconfig-mode 644` as a flag during installation: + +``` +$ curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644 +``` + +The option can also be specified using the environment variable `K3S_KUBECONFIG_MODE`: + +``` +$ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s - +``` + +# Management Capabilities for Registered Clusters + +The control that Rancher has to manage a registered cluster depends on the type of cluster. + +### Features for All Registered Clusters + +After registering a cluster, the cluster owner can: + +- [Manage cluster access]({{}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/) through role-based access control +- Enable [monitoring, alerts and notifiers]({{}}/rancher/v2.x/en/monitoring-alerting/v2.5/) +- Enable [logging]({{}}/rancher/v2.x/en/logging/v2.5/) +- Enable [Istio]({{}}/rancher/v2.x/en/istio/v2.5/) +- Use [pipelines]({{}}/rancher/v2.x/en/project-admin/pipelines/) +- Manage projects and workloads + +### Additional Features for Registered K3s Clusters + +[K3s]({{}}/k3s/latest/en/) is lightweight, fully compliant Kubernetes distribution. + +When a K3s cluster is registered in Rancher, Rancher will recognize it as K3s. The Rancher UI will expose the features for [all registered clusters,](#features-for-all-registered-clusters) in addition to the following features for editing and upgrading the cluster: + +- The ability to [upgrade the K3s version]({{}}/rancher/v2.x/en/cluster-admin/upgrading-kubernetes/) +- The ability to configure the maximum number of nodes that will be upgraded concurrently +- The ability to see a read-only version of the K3s cluster's configuration arguments and environment variables used to launch each node in the cluster + +### Additional Features for Registered EKS Clusters + +Registering an Amazon EKS cluster allows Rancher to treat it as though it were created in Rancher. + +Amazon EKS clusters can now be registered in Rancher. For the most part, registered EKS clusters and EKS clusters created in Rancher are treated the same way in the Rancher UI, except for deletion. + +When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher. + +The capabilities for registered EKS clusters are listed in the table on [this page.]({{}}/rancher/v2.x/en/cluster-provisioning/) + +# Configuring K3s Cluster Upgrades + +> It is a Kubernetes best practice to back up the cluster before upgrading. When upgrading a high-availability K3s cluster with an external database, back up the database in whichever way is recommended by the relational database provider. + +The **concurrency** is the maximum number of nodes that are permitted to be unavailable during an upgrade. If number of unavailable nodes is larger than the **concurrency,** the upgrade will fail. If an upgrade fails, you may need to repair or remove failed nodes before the upgrade can succeed. + +- **Controlplane concurrency:** The maximum number of server nodes to upgrade at a single time; also the maximum unavailable server nodes +- **Worker concurrency:** The maximum number worker nodes to upgrade at the same time; also the maximum unavailable worker nodes + +In the K3s documentation, controlplane nodes are called server nodes. These nodes run the Kubernetes master, which maintains the desired state of the cluster. In K3s, these controlplane nodes have the capability to have workloads scheduled to them by default. + +Also in the K3s documentation, nodes with the worker role are called agent nodes. Any workloads or pods that are deployed in the cluster can be scheduled to these nodes by default. + +# Debug Logging and Troubleshooting for Registered K3s Clusters + +Nodes are upgraded by the system upgrade controller running in the downstream cluster. Based on the cluster configuration, Rancher deploys two [plans](https://github.com/rancher/system-upgrade-controller#example-upgrade-plan) to upgrade K3s nodes: one for controlplane nodes and one for workers. The system upgrade controller follows the plans and upgrades the nodes. + +To enable debug logging on the system upgrade controller deployment, edit the [configmap](https://github.com/rancher/system-upgrade-controller/blob/50a4c8975543d75f1d76a8290001d87dc298bdb4/manifests/system-upgrade-controller.yaml#L32) to set the debug environment variable to true. Then restart the `system-upgrade-controller` pod. + +Logs created by the `system-upgrade-controller` can be viewed by running this command: + +``` +kubectl logs -n cattle-system system-upgrade-controller +``` + +The current status of the plans can be viewed with this command: + +``` +kubectl get plans -A -o yaml +``` + +If the cluster becomes stuck in upgrading, restart the `system-upgrade-controller`. + +To prevent issues when upgrading, the [Kubernetes upgrade best practices](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) should be followed. + + + + +# Annotating Registered Clusters + +For all types of registered Kubernetes clusters except for K3s Kubernetes clusters, Rancher doesn't have any information about how the cluster is provisioned or configured. + +Therefore, when Rancher registers a cluster, it assumes that several capabilities are disabled by default. Rancher assumes this in order to avoid exposing UI options to the user even when the capabilities are not enabled in the registered cluster. + +However, if the cluster has a certain capability, such as the ability to use a pod security policy, a user of that cluster might still want to select pod security policies for the cluster in the Rancher UI. In order to do that, the user will need to manually indicate to Rancher that pod security policies are enabled for the cluster. + +By annotating a registered cluster, it is possible to indicate to Rancher that a cluster was given a pod security policy, or another capability, outside of Rancher. + +This example annotation indicates that a pod security policy is enabled: + +``` +"capabilities.cattle.io/pspEnabled": "true" +``` + +The following annotation indicates Ingress capabilities. Note that that the values of non-primitive objects need to be JSON encoded, with quotations escaped. + +``` +"capabilities.cattle.io/ingressCapabilities": "[ + { + "customDefaultBackend":true, + "ingressProvider":"asdf" + } +]" +``` + +These capabilities can be annotated for the cluster: + +- `ingressCapabilities` +- `loadBalancerCapabilities` +- `nodePoolScalingSupported` +- `nodePortRange` +- `pspEnabled` +- `taintSupport` + +All the capabilities and their type definitions can be viewed in the Rancher API view, at `[Rancher Server URL]/v3/schemas/capabilities`. + +To annotate a registered cluster, + +1. Go to the cluster view in Rancher and select **⋮ > Edit.** +1. Expand the **Labels & Annotations** section. +1. Click **Add Annotation.** +1. Add an annotation to the cluster with the format `capabilities/: ` where `value` is the cluster capability that will be overridden by the annotation. In this scenario, Rancher is not aware of any capabilities of the cluster until you add the annotation. +1. Click **Save.** + +**Result:** The annotation does not give the capabilities to the cluster, but it does indicate to Rancher that the cluster has those capabilities. + diff --git a/content/rancher/v2.x/en/deploy-across-clusters/fleet/_index.md b/content/rancher/v2.x/en/deploy-across-clusters/fleet/_index.md index 5e474b26d5b..a794ffbe459 100644 --- a/content/rancher/v2.x/en/deploy-across-clusters/fleet/_index.md +++ b/content/rancher/v2.x/en/deploy-across-clusters/fleet/_index.md @@ -17,7 +17,7 @@ deploy everything in the cluster. This give a high degree of control, consistenc ### 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 > Fleet.** On this page, you can edit Kubernetes resources and cluster groups managed by Fleet. +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. ### GitHub Repository diff --git a/content/rancher/v2.x/en/installation/install-rancher-on-k8s/_index.md b/content/rancher/v2.x/en/installation/install-rancher-on-k8s/_index.md index 4e07a469d26..33096d9636d 100644 --- a/content/rancher/v2.x/en/installation/install-rancher-on-k8s/_index.md +++ b/content/rancher/v2.x/en/installation/install-rancher-on-k8s/_index.md @@ -17,6 +17,7 @@ Set up the Rancher server's local Kubernetes cluster. The cluster requirements depend on the Rancher version: - **As of Rancher v2.5,** Rancher can be installed on any Kubernetes cluster. This cluster can use upstream Kubernetes, or it can use one of Rancher's Kubernetes distributions, or it can be a managed Kubernetes cluster from a provider such as Amazon EKS. +> **Note:** To deploy Rancher v2.5 on a hosted Kubernetes cluster such as EKS, GKE, or AKS, you should deploy a compatible Ingress controller first to configure [SSL termination on Rancher.]({{}}/rancher/v2.x/en/installation/install-rancher-on-k8s/#4-choose-your-ssl-configuration). - **In Rancher v2.4.x,** Rancher needs to be installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster. - **In Rancher prior to v2.4,** Rancher needs to be installed on an RKE Kubernetes cluster. diff --git a/content/rancher/v2.x/en/installation/resources/advanced/helm2/rke-add-on/troubleshooting/_index.md b/content/rancher/v2.x/en/installation/resources/advanced/helm2/rke-add-on/troubleshooting/_index.md index c4a25094cdd..ed11a3c32b6 100644 --- a/content/rancher/v2.x/en/installation/resources/advanced/helm2/rke-add-on/troubleshooting/_index.md +++ b/content/rancher/v2.x/en/installation/resources/advanced/helm2/rke-add-on/troubleshooting/_index.md @@ -24,10 +24,10 @@ Choose from the following options: In this section, you can find errors related to SSH tunneling when you run the `rke` command to setup your nodes. -- [Failed to get job complete status](job-complete-status/) +- [Failed to get job complete status](./job-complete-status/) In this section, you can find errors related to deploying addons. -- [404 - default backend](404-default-backend/) +- [404 - default backend](./404-default-backend/) In this section, you can find errors related to the `404 - default backend` page that is shown when trying to access Rancher. diff --git a/content/rancher/v2.x/en/overview/architecture-recommendations/_index.md b/content/rancher/v2.x/en/overview/architecture-recommendations/_index.md index fd381be31e5..95fcd786f37 100644 --- a/content/rancher/v2.x/en/overview/architecture-recommendations/_index.md +++ b/content/rancher/v2.x/en/overview/architecture-recommendations/_index.md @@ -110,9 +110,9 @@ With that said, it is safe to use all three roles on three nodes when setting up Because no additional workloads will be deployed on the Rancher server cluster, in most cases it is not necessary to use the same architecture that we recommend for the scalability and reliability of downstream clusters. -For more best practices for downstream clusters, refer to the [production checklist]({{}}/rancher/v2.x/en/cluster-provisioning/production) or our [best practices guide.]({{}}/rancher/v2.x/en/best-practices/management/#tips-for-scaling-and-reliability) +For more best practices for downstream clusters, refer to the [production checklist]({{}}/rancher/v2.x/en/cluster-provisioning/production) or our [best practices guide.]({{}}/rancher/v2.x/en/best-practices/v2.5/) -# Architecture for an Authorized Cluster Endpoint +# Architecture for an Authorized Cluster Endpoint If you are using an [authorized cluster endpoint,]({{}}/rancher/v2.x/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. diff --git a/content/rancher/v2.x/en/security/_index.md b/content/rancher/v2.x/en/security/_index.md index 7107c1a8802..e1f9655dc3e 100644 --- a/content/rancher/v2.x/en/security/_index.md +++ b/content/rancher/v2.x/en/security/_index.md @@ -97,7 +97,3 @@ Results: ### Rancher CVEs and Resolutions Rancher is committed to informing the community of security issues in our products. For the list of CVEs (Common Vulnerabilities and Exposures) for issues we have resolved, refer to [this page.](./cve) - -### Security Tips and Best Practices - -Our [best practices guide]({{}}/rancher/v2.x/en/best-practices/management/#tips-for-security) includes basic tips for increasing security in Rancher. diff --git a/content/rke/latest/en/installation/_index.md b/content/rke/latest/en/installation/_index.md index 6a2531baf58..44adb3e9509 100644 --- a/content/rke/latest/en/installation/_index.md +++ b/content/rke/latest/en/installation/_index.md @@ -93,6 +93,8 @@ $ port upgrade rke The Kubernetes cluster components are launched using Docker on a Linux distro. You can use any Linux you want, as long as you can install Docker on it. +> For information on which Docker versions were tested with your version of RKE, refer to the [terms of service](https://rancher.com/support-maintenance-terms) for installing Rancher on RKE. + Review the [OS requirements]({{}}/rke/latest/en/installation/os/) and configure each node appropriately. ## Creating the Cluster Configuration File diff --git a/layouts/shortcodes/result_import-cluster.html b/layouts/shortcodes/result_import-cluster.html deleted file mode 100644 index 482b450bfb8..00000000000 --- a/layouts/shortcodes/result_import-cluster.html +++ /dev/null @@ -1,8 +0,0 @@ -
-

Result:

-
    -
  • Your cluster is created and assigned a state of Pending. Rancher is deploying resources to manage your cluster.
    • -
  • You can access your cluster after its state is updated to Active.
    • -
  • Active clusters are assigned two Projects Default (containing the namespace default) and System (containing the namespaces cattle-system,ingress-nginx,kube-public and kube-system, if present). -
-