From 5fdfa523865e29a1eae4f32d921572f972ca02ad Mon Sep 17 00:00:00 2001 From: Catherine Luse Date: Fri, 9 Sep 2022 17:06:29 -0700 Subject: [PATCH] Fix tables of contents, headers and formatting --- docs/contribute-to-rancher.md | 8 +- .../cis-scans/custom-benchmark.md | 5 -- .../cis-scans/rbac-for-cis-scans.md | 4 +- .../skipped-and-not-applicable-tests.md | 2 +- .../use-fleet-behind-a-proxy.md | 4 +- .../selectors-and-scrape-configurations.md | 4 - .../istio/cpu-and-memory-allocations.md | 2 +- .../istio/disable-istio.md | 6 +- .../flows-and-clusterflows.md | 16 +--- .../outputs-and-clusteroutputs.md | 18 +---- .../logging/logging-helm-chart-options.md | 6 -- .../migrate-to-rancher-v2.5+-logging.md | 29 ++----- .../integrations-in-rancher/longhorn.md | 1 + .../built-in-dashboards.md | 10 +-- .../how-monitoring-works.md | 15 ++-- .../promql-expressions.md | 78 ++----------------- .../rbac-for-monitoring.md | 20 ++--- .../windows-support.md | 7 +- .../integrations-in-rancher/opa-gatekeeper.md | 14 ++-- docs/faq/rancher-is-no-longer-needed.md | 5 -- .../configure-layer-7-nginx-load-balancer.md | 7 -- .../open-ports-with-firewalld.md | 4 +- .../istio-traffic-management-features.md | 2 +- .../rancher-on-arm64.md | 3 +- .../rancher-on-aks.md | 18 ++--- .../rancher-on-amazon-eks.md | 6 +- .../rancher-on-gke.md | 22 +++--- .../rollbacks.md | 9 +-- .../upgrades.md | 24 ++---- .../install-kubernetes.md | 4 +- .../install-rancher-ha.md | 68 +++++++--------- .../publish-images.md | 2 +- .../install-kubernetes.md | 4 +- .../upgrade-docker-installed-rancher.md | 50 +++++------- .../resources/choose-a-rancher-version.md | 1 + .../upgrade-and-roll-back-kubernetes.md | 28 ++----- .../introduction/what-are-divio-docs.md | 14 ---- .../deploy-rancher-manager/aws.md | 15 ++-- .../deploy-rancher-manager/azure.md | 13 ++-- .../deploy-rancher-manager/digitalocean.md | 9 +-- .../deploy-rancher-manager/equinix-metal.md | 12 --- .../deploy-rancher-manager/gcp.md | 8 +- .../deploy-rancher-manager/hetzner-cloud.md | 7 +- .../deploy-workloads/nodeports.md | 2 +- .../deploy-workloads/workload-ingress.md | 1 - .../configure-azure-ad.md | 9 --- .../about-rke1-templates/apply-templates.md | 5 -- .../about-rke1-templates/enforce-templates.md | 4 +- .../about-rke1-templates/example-use-cases.md | 8 +- .../about-rke1-templates/infrastructure.md | 8 +- .../manage-rke1-templates.md | 14 ---- .../create-pod-security-policies.md | 17 +--- .../custom-branding.md | 14 +--- .../global-default-private-registry.md | 4 +- .../manage-cluster-templates.md | 25 ++---- .../cluster-and-project-roles.md | 12 +-- .../custom-roles.md | 22 ++---- .../global-permissions.md | 21 +---- .../use-kubectl-and-kubeconfig.md | 8 +- .../assign-pod-security-policies.md | 2 +- .../about-persistent-storage.md | 13 +--- .../use-external-ceph-driver.md | 40 +++------- .../vsphere-storage.md | 5 -- .../use-aws-ec2-auto-scaling-groups.md | 12 +-- .../manage-clusters/nodes-and-node-pools.md | 36 +++------ .../projects-and-namespaces.md | 21 ++--- .../manage-clusters/rotate-encryption-key.md | 2 +- .../migrate-to-rancher-v2.5+-monitoring.md | 16 +--- .../enable-prometheus-federator.md | 12 ++- .../set-up-workloads.md | 3 - .../set-up-monitoring-for-workloads.md | 2 - .../advanced-configuration/alertmanager.md | 2 +- ...up-rancher-launched-kubernetes-clusters.md | 14 ---- ...aunched-kubernetes-clusters-from-backup.md | 7 -- .../deploy-apps-across-clusters/fleet.md | 24 ++---- .../multi-cluster-apps.md | 29 ++----- .../helm-charts-in-rancher/create-apps.md | 10 +-- .../amazon-elb-load-balancer.md | 19 ++--- .../ha-rke2-kubernetes-cluster.md | 2 +- .../nginx-load-balancer.md | 1 + .../recommended-cluster-architecture.md | 6 +- .../roles-for-nodes-in-kubernetes.md | 8 +- .../google-compute-engine.md | 4 +- .../vsphere/create-a-vm-template.md | 28 +++---- ...rovision-kubernetes-clusters-in-vsphere.md | 4 +- .../azure-storageclass-configuration.md | 45 +++++------ .../workload-migration-guidance.md | 17 ---- ...quirements-for-rancher-managed-clusters.md | 15 +--- .../register-existing-clusters.md | 75 +++++++++--------- .../aks.md | 26 ++----- .../alibaba.md | 6 +- .../gke.md | 21 ++--- .../huawei.md | 12 +-- .../tencent.md | 6 +- .../kubernetes-and-docker-registries.md | 2 +- .../ingress-configuration.md | 6 -- .../workloads-and-pods/deploy-workloads.md | 16 ++-- .../about-rke1-templates.md | 14 ++-- .../amazon-eks-permissions.md | 36 +++------ .../backup-restore-and-disaster-recovery.md | 24 ++---- docs/pages-for-subheaders/cis-scans.md | 21 ++--- .../configuration-options.md | 8 -- .../configure-shibboleth-saml.md | 10 --- .../fleet-gitops-at-scale.md | 24 ++---- .../gke-cluster-configuration.md | 6 +- ...install-upgrade-on-a-kubernetes-cluster.md | 2 - .../pages-for-subheaders/istio-setup-guide.md | 4 +- docs/pages-for-subheaders/istio.md | 27 +++---- .../kubernetes-clusters-in-rancher-setup.md | 20 +---- .../load-balancer-and-ingress-controller.md | 5 +- docs/pages-for-subheaders/logging.md | 28 ++----- .../monitoring-and-alerting.md | 7 -- docs/pages-for-subheaders/pipelines.md | 27 ++----- .../rancher-on-a-single-node-with-docker.md | 8 +- docs/pages-for-subheaders/rancher-security.md | 12 +-- .../rancher-v2.6-hardening-guides.md | 12 +-- .../use-existing-nodes.md | 7 -- .../use-new-nodes-in-an-infra-provider.md | 18 +---- .../use-windows-clusters.md | 36 +++------ docs/pages-for-subheaders/vsphere.md | 13 +--- .../backup-configuration.md | 17 +--- .../backup-restore-configuration/examples.md | 22 +----- .../restore-configuration.md | 15 +--- .../storage-configuration.md | 11 +-- .../logging-best-practices.md | 10 +-- .../monitoring-best-practices.md | 22 ++---- .../on-premises-rancher-in-vsphere.md | 15 ++-- .../rancher-deployment-strategy.md | 4 +- .../cli-with-rancher/kubectl-utility.md | 4 - .../cli-with-rancher/rancher-cli.md | 9 --- .../node-template-configuration/nutanix.md | 18 ++--- .../node-template-configuration/vsphere.md | 18 ++--- .../aks-cluster-configuration.md | 16 ++-- .../k3s-cluster-configuration.md | 6 +- .../rke1-cluster-configuration.md | 42 ++-------- .../rke2-cluster-configuration.md | 8 +- .../openldap-config-reference.md | 5 -- .../helm-chart-options.md | 15 +--- docs/reference-guides/kubernetes-concepts.md | 21 ++--- .../helm-chart-options.md | 15 +--- .../monitoring-v2-configuration/receivers.md | 42 ++++------ .../monitoring-v2-configuration/routes.md | 10 +-- .../pipelines/configure-persistent-data.md | 56 ++++++------- .../pipelines/pipeline-configuration.md | 51 ++++-------- .../reference-guides/rancher-cluster-tools.md | 22 ++---- .../architecture-recommendations.md | 9 --- .../reference-guides/rancher-project-tools.md | 10 +-- ...hardening-guide-with-cis-v1.6-benchmark.md | 8 -- ...hardening-guide-with-cis-v1.6-benchmark.md | 8 -- .../selinux-rpm/about-rancher-selinux.md | 4 +- .../rke1-template-example-yaml.md | 2 +- .../advanced-options.md | 8 -- .../troubleshooting-etcd-nodes.md | 33 ++------ .../kubernetes-resources.md | 33 ++------ .../version-2.0-2.4/contribute-to-rancher.md | 8 +- .../skipped-and-not-applicable-tests.md | 6 +- .../cluster-monitoring/expression.md | 62 --------------- .../cluster-monitoring/project-monitoring.md | 7 -- .../istio/cpu-and-memory-allocations.md | 2 +- .../integrations-in-rancher/notifiers.md | 7 -- .../integrations-in-rancher/opa-gatekeeper.md | 14 ++-- .../faq/rancher-is-no-longer-needed.md | 5 -- .../configure-layer-7-nginx-load-balancer.md | 7 -- .../rke-add-on/layer-4-lb.md | 16 ---- .../rke-add-on/layer-7-lb.md | 17 ---- .../install-kubernetes.md | 2 +- .../upgrade-and-roll-back-kubernetes.md | 14 ---- .../deploy-rancher-manager/helm-cli.md | 12 --- .../configure-azure-ad.md | 10 --- .../about-rke1-templates/apply-templates.md | 6 -- .../about-rke1-templates/enforce-templates.md | 4 +- .../about-rke1-templates/example-use-cases.md | 8 +- .../about-rke1-templates/infrastructure.md | 8 +- .../manage-rke1-templates.md | 15 ---- .../create-pod-security-policies.md | 16 +--- .../global-default-private-registry.md | 4 +- .../custom-roles.md | 7 -- .../global-permissions.md | 11 --- .../use-kubectl-and-kubeconfig.md | 8 +- .../manage-clusters/backing-up-etcd.md | 13 ---- .../about-persistent-storage.md | 13 +--- .../vsphere-storage.md | 5 -- .../use-aws-ec2-auto-scaling-groups.md | 12 +-- .../manage-clusters/nodes-and-node-pools.md | 18 ----- .../projects-and-namespaces.md | 20 ++--- .../manage-clusters/restoring-etcd.md | 8 +- ...aunched-kubernetes-clusters-from-backup.md | 10 --- .../helm-charts-in-rancher/creating-apps.md | 9 --- .../recommended-cluster-architecture.md | 6 +- .../google-compute-engine.md | 4 +- ...rovision-kubernetes-clusters-in-vsphere.md | 4 +- .../use-windows-clusters/v2.1-v2.2.md | 11 --- ...quirements-for-rancher-managed-clusters.md | 15 +--- .../huawei.md | 4 +- .../kubernetes-and-docker-registries.md | 2 +- .../discover-services.md | 11 --- .../migrate-from-v1.6-v2.x/expose-services.md | 12 --- .../install-and-configure-rancher.md | 12 --- .../migrate-from-v1.6-v2.x/load-balancing.md | 12 --- .../migrate-services.md | 13 ---- .../migrate-from-v1.6-v2.x/monitor-apps.md | 9 --- .../schedule-services.md | 13 ---- .../about-rke1-templates.md | 14 ++-- .../pages-for-subheaders/cluster-alerts.md | 16 ---- .../pages-for-subheaders/cluster-logging.md | 6 -- .../cluster-monitoring.md | 9 --- .../configure-shibboleth-saml.md | 10 --- .../helm-charts-in-rancher.md | 38 +++------ .../helm2-rke-add-on-layer-4-lb.md | 21 ----- .../helm2-rke-add-on-layer-7-lb.md | 21 ----- .../kubernetes-clusters-in-rancher-setup.md | 12 --- .../pages-for-subheaders/pipelines.md | 27 ++----- .../pages-for-subheaders/project-tools.md | 10 +-- .../use-existing-nodes.md | 7 -- .../use-new-nodes-in-an-infra-provider.md | 13 ---- .../use-windows-clusters.md | 15 ---- .../pages-for-subheaders/vsphere.md | 13 +--- .../cli-with-rancher/kubectl-utility.md | 4 - .../cli-with-rancher/rancher-cli.md | 9 --- .../vsphere/prior-to-v2.0.4.md | 18 ++--- .../vsphere/v2.0.4.md | 16 ++-- .../vsphere/v2.2.0.md | 16 ++-- .../vsphere/v2.3.0.md | 15 ++-- .../vsphere/v2.3.3.md | 19 ++--- .../rke1-cluster-configuration.md | 26 +------ .../amazon-eks-permissions.md | 32 +++----- .../helm-chart-options.md | 14 +--- .../reference-guides/kubernetes-concepts.md | 20 ++--- .../pipelines/configure-persistent-data.md | 56 ++++++------- .../pipelines/pipeline-configuration.md | 54 ++++--------- .../reference-guides/rancher-cluster-tools.md | 14 +--- .../architecture-recommendations.md | 9 --- ...unicating-with-downstream-user-clusters.md | 6 +- .../rancher-project-tools/project-alerts.md | 30 +++---- .../rke1-template-example-yaml.md | 2 +- .../troubleshooting-etcd-nodes.md | 33 ++------ .../kubernetes-resources.md | 34 ++------ .../rke-clusters/options/options.md | 29 +------ .../cis-scans/custom-benchmark.md | 5 -- .../cis-scans/rbac-for-cis-scans.md | 4 +- .../skipped-and-not-applicable-tests.md | 2 +- .../use-fleet-behind-a-proxy.md | 6 +- .../selectors-and-scrape-configurations.md | 5 -- .../istio/disable-istio.md | 6 +- .../flows-and-clusterflows.md | 14 ++-- .../outputs-and-clusteroutputs.md | 16 ++-- .../logging/logging-helm-chart-options.md | 6 -- .../migrate-to-rancher-v2.5+-logging.md | 26 ++----- .../integrations-in-rancher/longhorn.md | 1 + .../built-in-dashboards.md | 11 +-- .../how-monitoring-works.md | 15 ++-- .../promql-expressions.md | 78 ++----------------- .../rbac-for-monitoring.md | 21 ++--- .../windows-support.md | 4 +- .../integrations-in-rancher/opa-gatekeeper.md | 14 ++-- .../faq/rancher-is-no-longer-needed.md | 5 -- .../configure-layer-7-nginx-load-balancer.md | 9 --- .../upgrade-and-roll-back-kubernetes.md | 26 ++----- .../deploy-rancher-manager/helm-cli.md | 16 ---- .../configure-azure-ad.md | 9 --- .../about-rke1-templates/apply-templates.md | 6 -- .../about-rke1-templates/enforce-templates.md | 4 +- .../about-rke1-templates/example-use-cases.md | 8 +- .../about-rke1-templates/infrastructure.md | 8 +- .../manage-rke1-templates.md | 15 ---- .../create-pod-security-policies.md | 16 +--- .../global-default-private-registry.md | 4 +- .../custom-roles.md | 20 ++--- .../global-permissions.md | 13 ---- .../use-kubectl-and-kubeconfig.md | 9 +-- .../about-persistent-storage.md | 13 +--- .../use-external-ceph-driver.md | 44 ++++------- .../vsphere-storage.md | 5 -- .../use-aws-ec2-auto-scaling-groups.md | 12 +-- .../manage-clusters/nodes-and-node-pools.md | 18 ----- .../projects-and-namespaces.md | 23 ++---- .../migrate-to-rancher-v2.5+-monitoring.md | 17 +--- .../set-up-monitoring-for-workloads.md | 3 - .../advanced-configuration/alertmanager.md | 2 +- ...up-rancher-launched-kubernetes-clusters.md | 14 ---- ...aunched-kubernetes-clusters-from-backup.md | 7 -- .../deploy-apps-across-clusters/fleet.md | 24 ++---- .../multi-cluster-apps.md | 29 ++----- .../recommended-cluster-architecture.md | 6 +- .../google-compute-engine.md | 4 +- .../create-a-digitalocean-cluster.md | 2 +- ...rovision-kubernetes-clusters-in-vsphere.md | 6 +- ...quirements-for-rancher-managed-clusters.md | 26 +++---- .../register-existing-clusters.md | 18 ++--- .../gke.md | 22 ++---- .../huawei.md | 4 +- .../kubernetes-and-docker-registries.md | 2 +- .../about-rke1-templates.md | 14 ++-- .../amazon-eks-permissions.md | 33 +++----- .../backup-restore-and-disaster-recovery.md | 27 ++----- .../pages-for-subheaders/cis-scans.md | 25 ++---- .../configuration-options.md | 8 -- .../configure-shibboleth-saml.md | 10 --- .../fleet-gitops-at-scale.md | 24 ++---- ...install-upgrade-on-a-kubernetes-cluster.md | 3 - .../version-2.5/pages-for-subheaders/istio.md | 27 +++---- .../kubernetes-clusters-in-rancher-setup.md | 19 +---- .../pages-for-subheaders/logging.md | 28 ++----- .../monitoring-and-alerting.md | 7 -- .../pages-for-subheaders/pipelines.md | 13 ---- .../pages-for-subheaders/rancher-security.md | 11 +-- .../rancher-v2.5-hardening-guides.md | 13 +--- .../use-existing-nodes.md | 7 -- .../use-new-nodes-in-an-infra-provider.md | 13 ---- .../use-windows-clusters.md | 15 ---- .../pages-for-subheaders/vsphere.md | 6 +- .../backup-configuration.md | 18 +---- .../backup-restore-configuration/examples.md | 22 +----- .../restore-configuration.md | 15 +--- .../storage-configuration.md | 11 +-- .../logging-best-practices.md | 12 +-- .../monitoring-best-practices.md | 21 ++--- .../on-premises-rancher-in-vsphere.md | 15 ++-- .../rancher-deployment-strategy.md | 4 +- .../cli-with-rancher/kubectl-utility.md | 4 - .../cli-with-rancher/rancher-cli.md | 9 --- .../node-template-configuration/vsphere.md | 16 ++-- .../helm-chart-options.md | 14 +--- .../reference-guides/kubernetes-concepts.md | 20 ++--- .../helm-chart-options.md | 15 +--- .../monitoring-v2-configuration/receivers.md | 46 ++++------- .../monitoring-v2-configuration/routes.md | 10 +-- .../pipelines/configure-persistent-data.md | 62 ++++++++------- .../pipelines/pipeline-configuration.md | 54 ++++--------- .../reference-guides/rancher-cluster-tools.md | 12 +-- .../architecture-recommendations.md | 9 --- .../reference-guides/rancher-project-tools.md | 9 +-- .../selinux-rpm/about-rancher-selinux.md | 4 +- .../rke1-template-example-yaml.md | 2 +- .../troubleshooting-etcd-nodes.md | 33 ++------ .../kubernetes-resources.md | 31 +------- 336 files changed, 1249 insertions(+), 3710 deletions(-) diff --git a/docs/contribute-to-rancher.md b/docs/contribute-to-rancher.md index ee2664adae1..08c8ab24a44 100644 --- a/docs/contribute-to-rancher.md +++ b/docs/contribute-to-rancher.md @@ -15,7 +15,7 @@ For more detailed information on how to contribute to the development of Rancher On the Rancher Users Slack, the channel for developers is **#developer**. -# Repositories +## Repositories All of repositories are located within our main GitHub organization. There are many repositories used for Rancher, but we'll provide descriptions of some of the main ones used in Rancher. @@ -39,13 +39,13 @@ To see all libraries/projects used in Rancher, see the [`go.mod` file](https://g ![Rancher diagram](/img/ranchercomponentsdiagram-2.6.svg)
Rancher components used for provisioning/managing Kubernetes clusters. -# Building +## Building Every repository should have a Makefile and can be built using the `make` command. The `make` targets are based on the scripts in the `/scripts` directory in the repository, and each target will use [Dapper](https://github.com/rancher/dapper) to run the target in an isolated environment. The `Dockerfile.dapper` will be used for this process, and includes all the necessary build tooling needed. The default target is `ci`, and will run `./scripts/validate`, `./scripts/build`, `./scripts/test` and `./scripts/package`. The resulting binaries of the build will be in `./build/bin` and are usually also packaged in a Docker image. -# Bugs, Issues or Questions +## Bugs, Issues or Questions If you find any bugs or are having any trouble, please search the [reported issue](https://github.com/rancher/rancher/issues) as someone may have experienced the same issue or we are actively working on a solution. @@ -128,7 +128,7 @@ Please remove any sensitive data as it will be publicly viewable. - `/var/log/docker.log` - **Metrics:** If you are experiencing performance issues, please provide as much of data (files or screenshots) of metrics which can help determining what is going on. If you have an issue related to a machine, it helps to supply output of `top`, `free -m`, `df` which shows processes/memory/disk usage. -# Docs +## Docs If you have any updates to our documentation, please make any pull request to our docs repo. diff --git a/docs/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md b/docs/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md index 36f70ccaa55..66582cab1c2 100644 --- a/docs/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md +++ b/docs/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md @@ -14,11 +14,6 @@ When a cluster scan is run, you need to select a Profile which points to a speci Follow all the steps below to add a custom Benchmark Version and run a scan using it. -1. [Prepare the Custom Benchmark Version ConfigMap](#1-prepare-the-custom-benchmark-version-configmap) -2. [Add a Custom Benchmark Version to a Cluster](#2-add-a-custom-benchmark-version-to-a-cluster) -3. [Create a New Profile for the Custom Benchmark Version](#3-create-a-new-profile-for-the-custom-benchmark-version) -4. [Run a Scan Using the Custom Benchmark Version](#4-run-a-scan-using-the-custom-benchmark-version) - ### 1. Prepare the Custom Benchmark Version ConfigMap To create a custom benchmark version, first you need to create a ConfigMap containing the benchmark version's config files and upload it to your Kubernetes cluster where you want to run the scan. diff --git a/docs/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md b/docs/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md index ad2b47bff2c..0eaaaccd2ce 100644 --- a/docs/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md +++ b/docs/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md @@ -19,7 +19,7 @@ Note: If you were using the `cis-edit` role added in Rancher v2.5 setup, it has Rancher v2.5.2 because it essentially is same as `cis-admin`. If you happen to create any clusterrolebindings for `cis-edit`, please update them to use `cis-admin` ClusterRole instead. -# Cluster-Admin Access +## Cluster-Admin Access Rancher CIS Scans is a cluster-admin only feature by default. This means only the Rancher global admins, and the cluster’s cluster-owner can: @@ -32,7 +32,7 @@ This means only the Rancher global admins, and the cluster’s cluster-owner can - View and Download the ClusterScanReport created after the ClusterScan is complete -# Summary of Default Permissions for Kubernetes Default Roles +## Summary of Default Permissions for Kubernetes Default Roles The rancher-cis-benchmark creates three `ClusterRoles` and adds the CIS Benchmark CRD access to the following default K8s `ClusterRoles`: diff --git a/docs/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md b/docs/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md index f2b125c0262..4aae02fa330 100644 --- a/docs/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md +++ b/docs/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md @@ -7,7 +7,7 @@ This section lists the tests that are skipped in the permissive test profile for > All the tests that are skipped and not applicable on this page will be counted as Not Applicable in the v2.5 generated report. The skipped test count will only mention the user-defined skipped tests. This allows user-skipped tests to be distinguished from the tests that are skipped by default in the RKE permissive test profile. -# CIS Benchmark v1.5 +## CIS Benchmark v1.5 ### CIS Benchmark v1.5 Skipped Tests diff --git a/docs/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md b/docs/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md index 4e41e1115f9..5710c1564ab 100644 --- a/docs/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md +++ b/docs/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md @@ -25,7 +25,7 @@ When adding Fleet agent environment variables for the proxy, replace | `HTTPS_PROXY` | http://:8888 | `NO_PROXY` | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local | -# Setting Environment Variables in the Rancher UI +## Setting Environment Variables in the Rancher UI To add the environment variable to an existing cluster, @@ -38,7 +38,7 @@ To add the environment variable to an existing cluster, **Result:** The Fleet agent works behind a proxy. -# Setting Environment Variables on Private Nodes +## Setting Environment Variables on Private Nodes For private nodes and private clusters, the proxy environment variables need to be set on the nodes themselves, as well as configured from the Rancher UI. diff --git a/docs/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md b/docs/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md index da12c344c6b..3545da226ad 100644 --- a/docs/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md +++ b/docs/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md @@ -9,10 +9,6 @@ This ensures you can view traffic, metrics and graphs for resources deployed in If you would like to limit Prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources. -- [Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True](#limiting-monitoring-to-specific-namespaces-by-setting-ignorenamespaceselectors-to-true) -- [Enabling Prometheus to Detect Resources in Other Namespaces](#enabling-prometheus-to-detect-resources-in-other-namespaces) -- [Monitoring Specific Namespaces: Create a Service Monitor or Pod Monitor](#monitoring-specific-namespaces-create-a-service-monitor-or-pod-monitor) -- [Monitoring Across Namespaces: Set ignoreNamespaceSelectors to False](#monitoring-across-namespaces-set-ignorenamespaceselectors-to-false) ### Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True diff --git a/docs/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md b/docs/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md index 469dc529f6f..ac90240960a 100644 --- a/docs/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md +++ b/docs/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md @@ -27,7 +27,7 @@ In Kubernetes, the resource request indicates that the workload will not deploye | proxy | 10m | 10mi | 2000m | 1024mi | | **Totals:** | **710m** | **2314Mi** | **6000m** | **3072Mi** | -# Configuring Resource Allocations +## Configuring Resource Allocations You can individually configure the resource allocation for each type of Istio component. This section includes the default resource allocations for each component. diff --git a/docs/explanations/integrations-in-rancher/istio/disable-istio.md b/docs/explanations/integrations-in-rancher/istio/disable-istio.md index c7956f35c70..d063c938a2b 100644 --- a/docs/explanations/integrations-in-rancher/istio/disable-istio.md +++ b/docs/explanations/integrations-in-rancher/istio/disable-istio.md @@ -5,7 +5,7 @@ weight: 4 This section describes how to uninstall Istio in a cluster or disable a namespace, or workload. -# Uninstall Istio in a Cluster +## Uninstall Istio in a Cluster To uninstall Istio, @@ -29,7 +29,7 @@ You can no longer disable and re-enable your Istio installation. If you would li This could mean a few things. You either selected all the apps in the `istio-system` namespace and deleted them at the same time, or you deleted `rancher-istio` chart dependencies prior to deleting the `rancher-istio` chart. Since the uninstall did not complete properly, you will have resources remaining in the `istio-system` namespace that you will need to manually clean up. Another option to avoid manual clean up is to install `rancher-istio` again, then uninstall it in the correct order. -# Disable Istio in a Namespace +## Disable Istio in a Namespace 1. Click **☰ > Cluster Management**. 1. Go to the cluster that you created and click **Explore**. @@ -38,6 +38,6 @@ This could mean a few things. You either selected all the apps in the `istio-sys **Result:** When workloads are deployed in this namespace, they will not have the Istio sidecar. -# Remove the Istio Sidecar from a Workload +## Remove the Istio Sidecar from a Workload Disable Istio in the namespace, then redeploy the workloads with in it. They will be deployed without the Istio sidecar. diff --git a/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md b/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md index 2ad4991dc8f..bdce1655d8d 100644 --- a/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md +++ b/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md @@ -5,18 +5,8 @@ weight: 1 For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/flow/) -- [Configuration](#configuration) -- [YAML Example](#yaml-example) -# Configuration - -- [Flows](#flows) - - [Matches](#matches) - - [Filters](#filters) - - [Outputs](#outputs) -- [ClusterFlows](#clusterflows) - -# Flows +## Flows A `Flow` defines which logs to collect and filter and which output to send the logs to. @@ -50,7 +40,7 @@ This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespa `Outputs` can be referenced when filling out the `Flow` or `ClusterFlow` forms in the Rancher UI. -# ClusterFlows +## ClusterFlows Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces. @@ -58,7 +48,7 @@ Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way After `ClusterFlow` selects logs from all namespaces in the cluster, logs from the cluster will be collected and logged to the selected `ClusterOutput`. -# YAML Example +## YAML Example The following example `Flow` transforms the log messages from the default namespace and sends them to an S3 `Output`: diff --git a/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md b/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md index 93cf01c067a..36c6c451e8d 100644 --- a/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md +++ b/docs/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md @@ -5,19 +5,7 @@ weight: 2 For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/) -- [Configuration](#configuration) -- [YAML Examples](#yaml-examples) - - [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch) - - [Output to Splunk](#output-to-splunk) - - [Output to Syslog](#output-to-syslog) - - [Unsupported Outputs](#unsupported-outputs) - -# Configuration - -- [Outputs](#outputs) -- [ClusterOutputs](#clusteroutputs) - -# Outputs +## Outputs The `Output` resource defines where your `Flows` can send the log messages. `Outputs` are the final stage for a logging `Flow`. @@ -53,7 +41,7 @@ The Rancher UI provides forms for configuring the `Output` type, target, and acc For example configuration for each logging plugin supported by the logging operator, see the [logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/plugins/outputs/) -# ClusterOutputs +## ClusterOutputs `ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator. @@ -61,7 +49,7 @@ For example configuration for each logging plugin supported by the logging opera For the details of the `ClusterOutput` custom resource, see [ClusterOutput.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/crds/v1beta1/clusteroutput_types/) -# YAML Examples +## YAML Examples Once logging is installed, you can use these examples to help craft your own logging pipeline. diff --git a/docs/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md b/docs/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md index ae4edcb6520..2ccea6a311a 100644 --- a/docs/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md +++ b/docs/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md @@ -4,12 +4,6 @@ shortTitle: Helm Chart Options weight: 4 --- -- [Enable/Disable Windows Node Logging](#enable-disable-windows-node-logging) -- [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory) -- [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints) -- [Enabling the Logging Application to Work with SELinux](#enabling-the-logging-application-to-work-with-selinux) -- [Additional Logging Sources](#additional-logging-sources) -- [Systemd Configuration](#systemd-configuration) ### Enable/Disable Windows Node Logging diff --git a/docs/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md b/docs/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md index 498569ea50b..770a0586d4f 100644 --- a/docs/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md +++ b/docs/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md @@ -6,20 +6,7 @@ Starting in v2.5, the logging feature available within Rancher has been complete Among the many features and changes in the new logging functionality is the removal of project-specific logging configurations. Instead, one now configures logging at the namespace level. Cluster-level logging remains available, but configuration options differ. -- [Installation](#installation) - - [Terminology](#terminology) -- [Cluster Logging](#cluster-logging) -- [Project Logging](#project-logging) -- [Output Configuration](#output-configuration) - - [Elasticsearch](#elasticsearch) - - [Splunk](#splunk) - - [Kafka](#kafka) - - [Fluentd](#fluentd) - - [Syslog](#syslog) -- [Custom Log Fields](#custom-log-fields) -- [System Logging](#system-logging) - -# Installation +## Installation To install logging in Rancher v2.5+, refer to the [installation instructions](../../../pages-for-subheaders/logging.md#enabling-logging). @@ -51,7 +38,7 @@ There are four key concepts to understand for v2.5+ logging: `ClusterFlows` serve the same function as `Flows`, but at the cluster level. They are used to configure log collection for an entire cluster, instead of on a per-namespace level. `ClusterFlows` are also where mutations and filters are defined, same as `Flows` (in functionality). -# Cluster Logging +## Cluster Logging To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs. @@ -71,7 +58,7 @@ In legacy logging, in order to collect logs from across the entire cluster, one This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`. -# Project Logging +## Project Logging Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces. @@ -91,7 +78,7 @@ To collect logs from a project, repeat the above steps for every namespace withi ::: -# Output Configuration +## Output Configuration In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+. @@ -110,7 +97,7 @@ In legacy logging, there are five logging destinations to choose from: Elasticse In legacy logging, indices were automatically created according to the format in the "Index Patterns" section. In v2.5 logging, default behavior has been changed to logging to a single index. You can still configure index pattern functionality on the `Output` object by editing as YAML and inputting the following values: -``` +```yaml ... spec: elasticsearch: @@ -179,11 +166,11 @@ _(1) These values are to be specified as paths to files. Those files must be mou As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging. -# Custom Log Fields +## Custom Log Fields In order to add custom log fields, you will need to add the following YAML to your `Flow` configuration: -``` +```yaml ... spec: filters: @@ -194,7 +181,7 @@ spec: (replace `foo: "bar"` with custom log fields you wish to add) -# System Logging +## System Logging In legacy logging, collecting logs from system components was accomplished by checking a box labeled "Include System Log" when setting up cluster logging. In v2.5+ logging, system logs are gathered in one of two ways: diff --git a/docs/explanations/integrations-in-rancher/longhorn.md b/docs/explanations/integrations-in-rancher/longhorn.md index ce7f6f77f4f..5632c8a00bc 100644 --- a/docs/explanations/integrations-in-rancher/longhorn.md +++ b/docs/explanations/integrations-in-rancher/longhorn.md @@ -20,6 +20,7 @@ With Longhorn, you can: - Upgrade Longhorn without disrupting persistent volumes
Longhorn Dashboard
+ ![Longhorn Dashboard](/img/longhorn-screenshot.png) ### Installing Longhorn with Rancher diff --git a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md index 544fe729567..aaf44ee698b 100644 --- a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md +++ b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md @@ -3,11 +3,8 @@ title: Built-in Dashboards weight: 3 --- -- [Grafana UI](#grafana-ui) -- [Alertmanager UI](#alertmanager-ui) -- [Prometheus UI](#prometheus-ui) -# Grafana UI +## Grafana UI [Grafana](https://grafana.com/grafana/) allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture. @@ -26,7 +23,7 @@ To create a persistent Grafana dashboard, see [this page.](../../../how-to-guide For information about role-based access control for Grafana, see [this section.](rbac-for-monitoring.md#role-based-access-control-for-grafana) -# Alertmanager UI +## Alertmanager UI When `rancher-monitoring` is installed, the Prometheus Alertmanager UI is deployed, allowing you to view your alerts and the current Alertmanager configuration. @@ -66,7 +63,7 @@ For more information on configuring Alertmanager in Rancher, see [this page.](.. To see alerts that are fired by default, go to the Alertmanager UI and click **Expand all groups**. -# Prometheus UI +## Prometheus UI By default, the [kube-state-metrics service](https://github.com/kubernetes/kube-state-metrics) provides a wealth of information about CPU and memory utilization to the monitoring application. These metrics cover Kubernetes resources across namespaces. This means that in order to see resource metrics for a service, you don't need to create a new ServiceMonitor for it. Because the data is already in the time series database, you can go to the Prometheus UI and run a PromQL query to get the information. The same query can be used to configure a Grafana dashboard to show a graph of those metrics over time. @@ -78,6 +75,7 @@ To see the Prometheus UI, install `rancher-monitoring`. Then: 1. Click **Prometheus Graph**.
Prometheus Graph UI
+ ![Prometheus Graph UI](/img/prometheus-graph-ui.png) ### Viewing the Prometheus Targets diff --git a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md index d2937abac79..5f9cd11cf73 100644 --- a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md +++ b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md @@ -3,13 +3,8 @@ title: How Monitoring Works weight: 1 --- -1. [Architecture Overview](#1-architecture-overview) -2. [How Prometheus Works](#2-how-prometheus-works) -3. [How Alertmanager Works](#3-how-alertmanager-works) -4. [Monitoring V2 Specific Components](#4-monitoring-v2-specific-components) -5. [Scraping and Exposing Metrics](#5-scraping-and-exposing-metrics) -# 1. Architecture Overview +## 1. Architecture Overview _**The following sections describe how data flows through the Monitoring V2 application:**_ @@ -67,7 +62,7 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
How data flows through the monitoring application:
-# 2. How Prometheus Works +## 2. How Prometheus Works ### Storing Time Series Data @@ -111,7 +106,7 @@ The Rule file adds labels and annotations to alerts before firing them, dependin - Annotations denote information that doesn't affect where an alert is routed, for example, a runbook or an error message. -# 3. How Alertmanager Works +## 3. How Alertmanager Works The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of the following tasks: @@ -139,7 +134,7 @@ By editing the forms in the Rancher UI, you can set up a Receiver resource with By editing custom YAML in the Alertmanager or Receiver configuration, you can also send alerts to multiple notification systems. For more information, see the section on configuring [Receivers.](../../../reference-guides/monitoring-v2-configuration/receivers.md#configuring-multiple-receivers) -# 4. Monitoring V2 Specific Components +## 4. Monitoring V2 Specific Components Prometheus Operator introduces a set of [Custom Resource Definitions](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions) that allow users to deploy and manage Prometheus and Alertmanager instances by creating and modifying those custom resources on a cluster. @@ -185,7 +180,7 @@ Since the metrics for Kubernetes components are generally exposed on the host ne Refer to [Scraping Metrics with PushProx](#scraping-metrics-with-pushprox) for more. -# 5. Scraping and Exposing Metrics +## 5. Scraping and Exposing Metrics ### Defining what Metrics are Scraped diff --git a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md index d0201d1f934..5b9fd3a3449 100644 --- a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md +++ b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md @@ -7,70 +7,8 @@ The PromQL expressions in this doc can be used to configure alerts. For more information about querying the Prometheus time series database, refer to the official [Prometheus documentation.](https://prometheus.io/docs/prometheus/latest/querying/basics/) - -- [Cluster Metrics](#cluster-metrics) - - [Cluster CPU Utilization](#cluster-cpu-utilization) - - [Cluster Load Average](#cluster-load-average) - - [Cluster Memory Utilization](#cluster-memory-utilization) - - [Cluster Disk Utilization](#cluster-disk-utilization) - - [Cluster Disk I/O](#cluster-disk-i-o) - - [Cluster Network Packets](#cluster-network-packets) - - [Cluster Network I/O](#cluster-network-i-o) -- [Node Metrics](#node-metrics) - - [Node CPU Utilization](#node-cpu-utilization) - - [Node Load Average](#node-load-average) - - [Node Memory Utilization](#node-memory-utilization) - - [Node Disk Utilization](#node-disk-utilization) - - [Node Disk I/O](#node-disk-i-o) - - [Node Network Packets](#node-network-packets) - - [Node Network I/O](#node-network-i-o) -- [Etcd Metrics](#etcd-metrics) - - [Etcd Has a Leader](#etcd-has-a-leader) - - [Number of Times the Leader Changes](#number-of-times-the-leader-changes) - - [Number of Failed Proposals](#number-of-failed-proposals) - - [GRPC Client Traffic](#grpc-client-traffic) - - [Peer Traffic](#peer-traffic) - - [DB Size](#db-size) - - [Active Streams](#active-streams) - - [Raft Proposals](#raft-proposals) - - [RPC Rate](#rpc-rate) - - [Disk Operations](#disk-operations) - - [Disk Sync Duration](#disk-sync-duration) -- [Kubernetes Components Metrics](#kubernetes-components-metrics) - - [API Server Request Latency](#api-server-request-latency) - - [API Server Request Rate](#api-server-request-rate) - - [Scheduling Failed Pods](#scheduling-failed-pods) - - [Controller Manager Queue Depth](#controller-manager-queue-depth) - - [Scheduler E2E Scheduling Latency](#scheduler-e2e-scheduling-latency) - - [Scheduler Preemption Attempts](#scheduler-preemption-attempts) - - [Ingress Controller Connections](#ingress-controller-connections) - - [Ingress Controller Request Process Time](#ingress-controller-request-process-time) -- [Rancher Logging Metrics](#rancher-logging-metrics) - - [Fluentd Buffer Queue Rate](#fluentd-buffer-queue-rate) - - [Fluentd Input Rate](#fluentd-input-rate) - - [Fluentd Output Errors Rate](#fluentd-output-errors-rate) - - [Fluentd Output Rate](#fluentd-output-rate) -- [Workload Metrics](#workload-metrics) - - [Workload CPU Utilization](#workload-cpu-utilization) - - [Workload Memory Utilization](#workload-memory-utilization) - - [Workload Network Packets](#workload-network-packets) - - [Workload Network I/O](#workload-network-i-o) - - [Workload Disk I/O](#workload-disk-i-o) -- [Pod Metrics](#pod-metrics) - - [Pod CPU Utilization](#pod-cpu-utilization) - - [Pod Memory Utilization](#pod-memory-utilization) - - [Pod Network Packets](#pod-network-packets) - - [Pod Network I/O](#pod-network-i-o) - - [Pod Disk I/O](#pod-disk-i-o) -- [Container Metrics](#container-metrics) - - [Container CPU Utilization](#container-cpu-utilization) - - [Container Memory Utilization](#container-memory-utilization) - - [Container Disk I/O](#container-disk-i-o) - - - -# Cluster Metrics +## Cluster Metrics ### Cluster CPU Utilization @@ -121,7 +59,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)
| | Summary |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))
| -# Node Metrics +## Node Metrics ### Node CPU Utilization @@ -172,7 +110,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)
| | Summary |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))
| -# Etcd Metrics +## Etcd Metrics ### Etcd Has a Leader @@ -242,7 +180,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
wal`histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le))`
db`histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le))`
| | Summary |
wal`sum(histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le)))`
db`sum(histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le)))`
| -# Kubernetes Components Metrics +## Kubernetes Components Metrics ### API Server Request Latency @@ -300,7 +238,7 @@ For more information about querying the Prometheus time series database, refer t | Detail | `topk(10, histogram_quantile(0.95,sum by (le, host, path)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` | | Summary | `topk(10, histogram_quantile(0.95,sum by (le, host)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` | -# Rancher Logging Metrics +## Rancher Logging Metrics ### Fluentd Buffer Queue Rate @@ -331,7 +269,7 @@ For more information about querying the Prometheus time series database, refer t | Detail | `sum(rate(fluentd_output_status_num_records_total[5m])) by (instance)` | | Summary | `sum(rate(fluentd_output_status_num_records_total[5m]))` | -# Workload Metrics +## Workload Metrics ### Workload CPU Utilization @@ -368,7 +306,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`
| | Summary |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`
| -# Pod Metrics +## Pod Metrics ### Pod CPU Utilization @@ -405,7 +343,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`
| | Summary |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`
| -# Container Metrics +## Container Metrics ### Container CPU Utilization diff --git a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md index 418d42d95fe..f634a38c156 100644 --- a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md +++ b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md @@ -5,18 +5,8 @@ weight: 2 --- This section describes the expectations for RBAC for Rancher Monitoring. -- [Cluster Admins](#cluster-admins) -- [Users with Kubernetes ClusterRole-based Permissions](#users-with-kubernetes-clusterrole-based-permissions) - - [Users with Kubernetes Admin/Edit Permissions](#users-with-kubernetes-admin-edit-permissions) - - [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions) - - [Additional Monitoring Roles](#additional-monitoring-roles) - - [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles) -- [Users with Rancher Based Permissions](#users-with-rancher-based-permissions) - - [Differences in 2.5.x](#differences-in-2-5-x) - - [Assigning Additional Access](#assigning-additional-access) -- [Role-based Access Control for Grafana](#role-based-access-control-for-grafana) -# Cluster Admins +## Cluster Admins By default, only those with the cluster-admin `ClusterRole` should be able to: @@ -27,7 +17,7 @@ By default, only those with the cluster-admin `ClusterRole` should be able to: - Persist new Grafana dashboards or datasources via creating ConfigMaps in the appropriate namespace - Expose certain Prometheus metrics to the k8s Custom Metrics API for HPA via a Secret in the `cattle-monitoring-system` namespace -# Users with Kubernetes ClusterRole-based Permissions +## Users with Kubernetes ClusterRole-based Permissions The `rancher-monitoring` chart installs the following three `ClusterRoles`. By default, they aggregate into the corresponding k8s `ClusterRoles`: @@ -92,7 +82,7 @@ An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a * **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes. You will need to fill in the name below, and name is case-sensitive. -``` +```yaml # monitoring-config-view-role-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding @@ -114,7 +104,7 @@ subjects: * **`kubectl apply -f monitoring-config-view-role-binding.yaml` -# Users with Rancher Based Permissions +## Users with Rancher Based Permissions The relationship between the default roles deployed by Rancher (i.e. cluster-owner, cluster-member, project-owner, project-member), the default Kubernetes roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below: @@ -161,7 +151,7 @@ If cluster-admins would like to provide additional admin/edit access to users ou -# Role-based Access Control for Grafana +## Role-based Access Control for Grafana Rancher allows any users who are authenticated by Kubernetes and have access the Grafana service deployed by the Rancher Monitoring chart to access Grafana via the Rancher Dashboard UI. By default, all users who are able to access Grafana are given the [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) role, which allows them to view any of the default dashboards deployed by Rancher. diff --git a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md index 593dc3e74b0..eed7a3f7c4f 100644 --- a/docs/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md +++ b/docs/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md @@ -8,17 +8,14 @@ _Available as of v2.5.8_ Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitoring V2 can now be deployed on a Windows cluster and will scrape metrics from Windows nodes using [prometheus-community/windows_exporter](https://github.com/prometheus-community/windows_exporter) (previously named `wmi_exporter`). -- [Comparison to Monitoring V1](#comparison-to-monitoring-v1) -- [Cluster Requirements](#cluster-requirements) - - [Upgrading Existing Clusters to wins v0.1.0](#upgrading-existing-clusters-to-wins-v0-1-0) -# Comparison to Monitoring V1 +## Comparison to Monitoring V1 Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`. In addition, Monitoring V2 for Windows will no longer require users to keep port 9796 open on Windows hosts since the host metrics will published directly onto a port exposed on the windows-exporter Pod. This feature was powered by recent changes made by `wins` v0.1.0 to support publishing ports exposed on the hostNetwork on Pods that use wins to run a privileged Windows binary as a host process. -# Cluster Requirements +## Cluster Requirements Monitoring V2 for Windows can only scrape metrics from Windows hosts that have a minimum `wins` version of v0.1.0. To be able to fully deploy Monitoring V2 for Windows, all of your hosts must meet this requirement. diff --git a/docs/explanations/integrations-in-rancher/opa-gatekeeper.md b/docs/explanations/integrations-in-rancher/opa-gatekeeper.md index d8a23354324..4ae2e407bab 100644 --- a/docs/explanations/integrations-in-rancher/opa-gatekeeper.md +++ b/docs/explanations/integrations-in-rancher/opa-gatekeeper.md @@ -16,13 +16,13 @@ OPA provides a high-level declarative language that lets you specify policy as c To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/) -# How the OPA Gatekeeper Integration Works +## How the OPA Gatekeeper Integration Works Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies. OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.` -# Enabling OPA Gatekeeper in a Cluster +## Enabling OPA Gatekeeper in a Cluster :::note @@ -48,7 +48,7 @@ The OPA Gatekeeper Helm chart can be installed from **Apps & Marketplace**. **Result:** OPA Gatekeeper is deployed in your Kubernetes cluster. -# Constraint Templates +## Constraint Templates [Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/) @@ -58,7 +58,7 @@ To list the constraint templates installed in the cluster, go to the left side m Rancher also provides the ability to create your own constraint templates by importing YAML definitions. -# Creating and Configuring Constraints +## Creating and Configuring Constraints [Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together. @@ -84,7 +84,7 @@ To limit the scope of the constraint only to user namespaces, always specify the Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints. -# Enforcing Constraints in your Cluster +## Enforcing Constraints in your Cluster When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny**. @@ -92,7 +92,7 @@ When the **Enforcement Action** is **Dryrun,** then any resources that violate t To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny**. -# Audit and Violations in your Cluster +## Audit and Violations in your Cluster OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper. @@ -102,7 +102,7 @@ Also under **Constraints,** the number of violations of the constraint can be fo The detail view of each constraint lists information about the resource that violated the constraint. -# Disabling Gatekeeper +## Disabling Gatekeeper 1. Navigate to the cluster's Dashboard view 1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper**. diff --git a/docs/faq/rancher-is-no-longer-needed.md b/docs/faq/rancher-is-no-longer-needed.md index ac895b26f31..7e59ee8e3d6 100644 --- a/docs/faq/rancher-is-no-longer-needed.md +++ b/docs/faq/rancher-is-no-longer-needed.md @@ -5,11 +5,6 @@ weight: 8010 This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted. -- [If the Rancher server is deleted, what happens to the workloads in my downstream clusters?](#if-the-rancher-server-is-deleted-what-happens-to-the-workloads-in-my-downstream-clusters) -- [If the Rancher server is deleted, how do I access my downstream clusters?](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters) -- [What if I don't want Rancher anymore?](#what-if-i-don-t-want-rancher-anymore) -- [What if I don't want my registered cluster managed by Rancher?](#what-if-i-don-t-want-my-registered-cluster-managed-by-rancher) -- [What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?](#what-if-i-don-t-want-my-rke-cluster-or-hosted-kubernetes-cluster-managed-by-rancher) ### If the Rancher server is deleted, what happens to the workloads in my downstream clusters? diff --git a/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md b/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md index 43f2f6144c5..c978f08243c 100644 --- a/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md +++ b/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md @@ -15,13 +15,6 @@ Make sure that your node fulfills the general [installation requirements.](../.. ## Installation Outline - - -- [1. Provision Linux Host](#1-provision-linux-host) -- [2. Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher) -- [3. Configure Load Balancer](#3-configure-load-balancer) - - ## 1. Provision Linux Host diff --git a/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/open-ports-with-firewalld.md b/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/open-ports-with-firewalld.md index 78b4313e145..689b0a2809d 100644 --- a/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/open-ports-with-firewalld.md +++ b/docs/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/open-ports-with-firewalld.md @@ -34,7 +34,7 @@ sudo iptables --list This section describes how to use `firewalld` to apply the [firewall port rules](../../installation-requirements/port-requirements.md) for nodes in a high-availability Rancher server cluster. -# Prerequisite +## Prerequisite Install v7.x or later ofv`firewalld`: @@ -44,7 +44,7 @@ systemctl start firewalld systemctl enable firewalld ``` -# Applying Firewall Port Rules +## Applying Firewall Port Rules In the Rancher high-availability installation instructions, the Rancher server is set up on three nodes that have all three Kubernetes roles: etcd, controlplane, and worker. If your Rancher server nodes have all three roles, run the following commands on each node: diff --git a/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/istio-traffic-management-features.md b/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/istio-traffic-management-features.md index 19a38981b1b..e4fdcb01252 100644 --- a/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/istio-traffic-management-features.md +++ b/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/istio-traffic-management-features.md @@ -14,7 +14,7 @@ Environment Variable Key | Default Value | Status | Available as of `istio-virtual-service-ui` |`false` | Experimental | v2.3.0 `istio-virtual-service-ui` | `true` | GA | v2.3.2 -# About this Feature +## About this Feature A central advantage of Istio's traffic management features is that they allow dynamic request routing, which is useful for canary deployments, blue/green deployments, or A/B testing. diff --git a/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/rancher-on-arm64.md b/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/rancher-on-arm64.md index 4a96161f4e2..c7d99a8eb38 100644 --- a/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/rancher-on-arm64.md +++ b/docs/getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/rancher-on-arm64.md @@ -3,7 +3,7 @@ title: "Running on ARM64 (Experimental)" weight: 3 --- -:::caution: +:::caution Running on an ARM64 platform is currently an experimental feature and is not yet officially supported in Rancher. Therefore, we do not recommend using ARM64 based nodes in a production environment. @@ -21,6 +21,7 @@ The following options are available when using an ARM64 platform: --privileged \ rancher/rancher:vX.Y.Z ``` + :::note To check if your specific released version is compatible with the ARM64 architecture, you may navigate to your diff --git a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md index 7bfcd7fc77d..f7ee72a2bf9 100644 --- a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md +++ b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-aks.md @@ -10,7 +10,7 @@ The guide uses command line tools to provision an AKS cluster with an ingress. I If you already have an AKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) -# Prerequisites +## Prerequisites :::caution @@ -24,7 +24,7 @@ Deploying to Microsoft Azure will incur charges. - Your subscription has sufficient quota for at least 2 vCPUs. For details on Rancher server resource requirements, refer to [this section](../../../pages-for-subheaders/installation-requirements.md#rke-and-hosted-kubernetes) - When installing Rancher with Helm in Azure, use the L7 load balancer to avoid networking issues. For more information, refer to the documentation on [Azure load balancer limitations](https://docs.microsoft.com/en-us/azure/load-balancer/components#limitations). -# 1. Prepare your Workstation +## 1. Prepare your Workstation Install the following command line tools on your workstation: @@ -32,7 +32,7 @@ Install the following command line tools on your workstation: - **kubectl:** For help, refer to these [installation steps.](https://kubernetes.io/docs/tasks/tools/#kubectl) - **helm:** For help, refer to these [installation steps.](https://helm.sh/docs/intro/install/) -# 2. Create a Resource Group +## 2. Create a Resource Group After installing the CLI, you will need to log in with your Azure account. @@ -46,7 +46,7 @@ Create a [resource group](https://docs.microsoft.com/en-us/azure/azure-resource- az group create --name rancher-rg --location eastus ``` -# 3. Create the AKS Cluster +## 3. Create the AKS Cluster To create an AKS cluster, run the following command. Use a VM size that applies to your use case. Refer to [this article](https://docs.microsoft.com/en-us/azure/virtual-machines/sizes) for available sizes and options. When choosing a Kubernetes version, be sure to first consult the [support matrix](https://rancher.com/support-matrix/) to find the highest version of Kubernetes that has been validated for your Rancher version. @@ -67,7 +67,7 @@ az aks create \ The cluster will take some time to be deployed. -# 4. Get Access Credentials +## 4. Get Access Credentials After the cluster is deployed, get the access credentials. @@ -77,7 +77,7 @@ az aks get-credentials --resource-group rancher-rg --name rancher-server This command merges your cluster's credentials into the existing kubeconfig and allows `kubectl` to interact with the cluster. -# 5. Install an Ingress +## 5. Install an Ingress The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. Installing an Ingress requires allocating a public IP address. Ensure you have sufficient quota, otherwise it will fail to assign the IP address. Limits for public IP addresses are applicable at a regional level per subscription. @@ -94,7 +94,7 @@ helm upgrade --install \ --create-namespace ``` -# 6. Get Load Balancer IP +## 6. Get Load Balancer IP To get the address of the load balancer, run: @@ -113,7 +113,7 @@ ingress-nginx-controller LoadBalancer 10.0.116.18 40.31.180.83 80:31229 Save the `EXTERNAL-IP`. -# 7. Set up DNS +## 7. Set up DNS External traffic to the Rancher server will need to be directed at the load balancer you created. @@ -121,7 +121,7 @@ Set up a DNS to point at the `EXTERNAL-IP` that you saved. This DNS will be used There are many valid ways to set up the DNS. For help, refer to the [Azure DNS documentation](https://docs.microsoft.com/en-us/azure/dns/) -# 8. Install the Rancher Helm Chart +## 8. Install the Rancher Helm Chart Next, install the Rancher Helm chart by following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution. diff --git a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md index c2c95fc15bb..00fcbcba5af 100644 --- a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md +++ b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md @@ -12,10 +12,8 @@ The second is a guide for installing an EKS cluster with an ingress by using com If you already have an EKS Kubernetes cluster, skip to the step about [installing an ingress.](#5-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) -- [Automated Quickstart using AWS Best Practices](#automated-quickstart-using-aws-best-practices) -- [Creating an EKS Cluster for the Rancher Server](#creating-an-eks-cluster-for-the-rancher-server) -# Automated Quickstart using AWS Best Practices +## Automated Quickstart using AWS Best Practices Rancher and Amazon Web Services collaborated on a quick start guide for deploying Rancher on an EKS cluster following AWS best practices. The deployment guide is [here.](https://aws-quickstart.github.io/quickstart-eks-rancher/) @@ -41,7 +39,7 @@ Deploying this Quick Start for a new virtual private cloud (VPC) and new Amazon \* The CloudFormation template that deploys the Quick Start into an existing Amazon EKS cluster skips the components marked by asterisks and prompts you for your existing VPC configuration. -# Creating an EKS Cluster for the Rancher Server +## Creating an EKS Cluster for the Rancher Server In this section, you'll install an EKS cluster with an ingress by using command line tools. This guide may be useful if you want to use fewer resources while trying out Rancher on EKS. diff --git a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md index 80ad9b92097..fd5c861472d 100644 --- a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md +++ b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-gke.md @@ -11,13 +11,13 @@ In this section, you'll learn how to install Rancher using Google Kubernetes Eng If you already have a GKE Kubernetes cluster, skip to the step about [installing an ingress.](#7-install-an-ingress) Then install the Rancher Helm chart following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) -# Prerequisites +## Prerequisites - You will need a Google account. - You will need a Google Cloud billing account. You can manage your Cloud Billing accounts using the Google Cloud Console. For more information about the Cloud Console, visit [General guide to the console.](https://support.google.com/cloud/answer/3465889?hl=en&ref_topic=3340599) - You will need a cloud quota for at least one in-use IP address and at least 2 CPUs. For more details about hardware requirements for the Rancher server, refer to [this section.](../../../pages-for-subheaders/installation-requirements.md#rke-and-hosted-kubernetes) -# 1. Enable the Kubernetes Engine API +## 1. Enable the Kubernetes Engine API Take the following steps to enable the Kubernetes Engine API: @@ -26,7 +26,7 @@ Take the following steps to enable the Kubernetes Engine API: 1. Open the project and enable the Kubernetes Engine API for the project. Wait for the API and related services to be enabled. This can take several minutes. 1. Make sure that billing is enabled for your Cloud project. For information on how to enable billing for your project, refer to the [Google Cloud documentation.](https://cloud.google.com/billing/docs/how-to/modify-project#enable_billing_for_a_project) -# 2. Open the Cloud Shell +## 2. Open the Cloud Shell Cloud Shell is a shell environment for managing resources hosted on Google Cloud. Cloud Shell comes preinstalled with the `gcloud` command-line tool and kubectl command-line tool. The `gcloud` tool provides the primary command-line interface for Google Cloud, and `kubectl` provides the primary command-line interface for running commands against Kubernetes clusters. @@ -65,7 +65,7 @@ To install `gcloud` and `kubectl`, perform the following steps: -# 3. Configure the gcloud CLI +## 3. Configure the gcloud CLI Set up default gcloud settings using one of the following methods: @@ -93,7 +93,7 @@ To install `gcloud` and `kubectl`, perform the following steps: -# 4. Confirm that gcloud is configured correctly +## 4. Confirm that gcloud is configured correctly Run: @@ -115,7 +115,7 @@ project = Your active configuration is: [default] ``` -# 5. Create a GKE Cluster +## 5. Create a GKE Cluster The following command creates a three-node cluster. @@ -129,7 +129,7 @@ When choosing a Kubernetes version, be sure to first consult the [support matrix gcloud container clusters create cluster-name --num-nodes=3 --cluster-version= ``` -# 6. Get Authentication Credentials +## 6. Get Authentication Credentials After creating your cluster, you need to get authentication credentials to interact with the cluster: @@ -139,7 +139,7 @@ gcloud container clusters get-credentials cluster-name This command configures `kubectl` to use the cluster you created. -# 7. Install an Ingress +## 7. Install an Ingress The cluster needs an Ingress so that Rancher can be accessed from outside the cluster. @@ -156,7 +156,7 @@ helm upgrade --install \ --create-namespace ``` -# 8. Get the Load Balancer IP +## 8. Get the Load Balancer IP To get the address of the load balancer, run: @@ -173,7 +173,7 @@ ingress-nginx-controller LoadBalancer 10.3.244.156 35.233.206.34 80:3187 Save the `EXTERNAL-IP`. -# 9. Set up DNS +## 9. Set up DNS External traffic to the Rancher server will need to be directed at the load balancer you created. @@ -181,7 +181,7 @@ Set up a DNS to point at the external IP that you saved. This DNS will be used a There are many valid ways to set up the DNS. For help, refer to the Google Cloud documentation about [managing DNS records.](https://cloud.google.com/dns/docs/records) -# 10. Install the Rancher Helm chart +## 10. Install the Rancher Helm chart Next, install the Rancher Helm chart by following the instructions on [this page.](../../../pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md#install-the-rancher-helm-chart) The Helm instructions are the same for installing Rancher on any Kubernetes distribution. diff --git a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md index 0373499ee01..0c97a8c27c8 100644 --- a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md +++ b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md @@ -3,11 +3,8 @@ title: Rollbacks weight: 3 --- -- [Rolling Back to Rancher v2.5.0+](#rolling-back-to-rancher-v2-5-0) -- [Rolling Back to Rancher v2.2-v2.4+](#rolling-back-to-rancher-v2-2-v2-4) -- [Rolling Back to Rancher v2.0-v2.1](#rolling-back-to-rancher-v2-0-v2-1) -# Rolling Back to Rancher v2.5.0+ +## Rolling Back to Rancher v2.5.0+ To roll back to Rancher v2.5.0+, use the **Rancher Backups** application and restore Rancher from backup. @@ -102,7 +99,7 @@ When the target revision is determined, perform the rollback. This example will helm rollback rancher 3 -n cattle-system ``` -# Rolling Back to Rancher v2.2-v2.4+ +## Rolling Back to Rancher v2.2-v2.4+ To roll back to Rancher before v2.5, follow the procedure detailed here: [Restoring Backups — Kubernetes installs](../../../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md) Restoring a snapshot of the Rancher server cluster will revert Rancher to the version and state at the time of the snapshot. @@ -114,6 +111,6 @@ Managed clusters are authoritative for their state. This means restoring the Ran ::: -# Rolling Back to Rancher v2.0-v2.1 +## Rolling Back to Rancher v2.0-v2.1 Rolling back to Rancher v2.0-v2.1 is no longer supported. The instructions for rolling back to these versions are preserved [here](../../../../versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup/roll-back-to-v2.0-v2.1.md) and are intended to be used only in cases where upgrading to Rancher v2.2+ is not feasible. diff --git a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md index e7b45d3612f..06a320b3b26 100644 --- a/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md +++ b/docs/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md @@ -8,12 +8,8 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine. -- [Prerequisites](#prerequisites) -- [Upgrade Outline](#upgrade-outline) -- [Known Upgrade Issues](#known-upgrade-issues) -- [RKE Add-on Installs](#rke-add-on-installs) -# Prerequisites +## Prerequisites ### Access to kubeconfig @@ -47,22 +43,18 @@ If you are upgrading to Rancher v2.5 from a Rancher server that was started with [Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../resources/upgrade-cert-manager.md) -# Upgrade Outline +## Upgrade Outline Follow the steps to upgrade Rancher server: -- [1. Back up your Kubernetes cluster that is running Rancher server](#1-back-up-your-kubernetes-cluster-that-is-running-rancher-server) -- [2. Update the Helm chart repository](#2-update-the-helm-chart-repository) -- [3. Upgrade Rancher](#3-upgrade-rancher) -- [4. Verify the Upgrade](#4-verify-the-upgrade) -# 1. Back up Your Kubernetes Cluster that is Running Rancher Server +### 1. Back up Your Kubernetes Cluster that is Running Rancher Server Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher. You'll use the backup as a restore point if something goes wrong during upgrade. -# 2. Update the Helm chart repository +### 2. Update the Helm chart repository 1. Update your local helm repo cache. @@ -115,7 +107,7 @@ You'll use the backup as a restore point if something goes wrong during upgrade. helm fetch rancher-/rancher --version=v2.4.11 ``` -# 3. Upgrade Rancher +### 3. Upgrade Rancher This section describes how to upgrade normal (Internet-connected) or air-gapped installations of Rancher with Helm. @@ -143,7 +135,7 @@ There will be more values that are listed with this command. This is just an exa If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-1-5-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below. -### Steps to Upgrade Rancher +#### Steps to Upgrade Rancher Upgrade Rancher to the latest version with all your settings. @@ -172,7 +164,7 @@ helm upgrade rancher rancher-/rancher \ --version=2.4.5 ``` -# 4. Verify the Upgrade +### 4. Verify the Upgrade Log into Rancher to confirm that the upgrade succeeded. @@ -184,6 +176,6 @@ See [Restoring Cluster Networking](../../../../versioned_docs/version-2.0-2.4/ge ::: -# Known Upgrade Issues +## Known Upgrade Issues A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12) diff --git a/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md b/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md index 9100a3441af..80767ac9618 100644 --- a/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md +++ b/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md @@ -45,7 +45,7 @@ Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will The registries.yaml file should look like this before plugging in the necessary information: -``` +```yaml --- mirrors: customreg: @@ -109,7 +109,7 @@ To use this `kubeconfig` file, 2. Copy the file at `/etc/rancher/k3s/k3s.yaml` and save it to the directory `~/.kube/config` on your local machine. 3. In the kubeconfig file, the `server` directive is defined as localhost. Configure the server as the DNS of your load balancer, referring to port 6443. (The Kubernetes API server will be reached at port 6443, while the Rancher server will be reached at ports 80 and 443.) Here is an example `k3s.yaml`: -``` +```yaml apiVersion: v1 clusters: - cluster: diff --git a/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md b/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md index 968baad0764..41769a7df24 100644 --- a/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md +++ b/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md @@ -9,22 +9,15 @@ This section is about how to deploy Rancher for your air gapped environment in a When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option. -# Docker Instructions +## Docker Instructions If you want to continue the air gapped installation using Docker commands, skip the rest of this page and follow the instructions on [this page.](docker-install-commands.md) -# Kubernetes Instructions +## Kubernetes Instructions Rancher recommends installing Rancher on a Kubernetes cluster. A highly available Kubernetes install is comprised of three nodes running the Rancher server components on a Kubernetes cluster. The persistence layer (etcd) is also replicated on these three nodes, providing redundancy and data duplication in case one of the nodes fails. -This section describes installing Rancher: - -- [1. Add the Helm Chart Repository](#1-add-the-helm-chart-repository) -- [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration) -- [3. Render the Rancher Helm Template](#3-render-the-rancher-helm-template) -- [4. Install Rancher](#4-install-rancher) - -# 1. Add the Helm Chart Repository +### 1. Add the Helm Chart Repository From a system that has access to the internet, fetch the latest Helm chart and copy the resulting manifests to a system that has access to the Rancher server cluster. @@ -55,7 +48,7 @@ From a system that has access to the internet, fetch the latest Helm chart and c helm fetch rancher-stable/rancher --version=v2.4.8 ``` -# 2. Choose your SSL Configuration +### 2. Choose your SSL Configuration Rancher Server is designed to be secure by default and requires SSL/TLS configuration. @@ -72,7 +65,7 @@ If you want terminate SSL/TLS externally, see [TLS termination on an External Lo | Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)
This is the **default** and does not need to be added when rendering the Helm template. | yes | | Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s).
This option must be passed when rendering the Rancher Helm template. | no | -# Helm Chart Options for Air Gap Installations +### Helm Chart Options for Air Gap Installations When setting up the Rancher Helm template, there are several options in the Helm chart that are designed specifically for air gap installations. @@ -82,11 +75,11 @@ When setting up the Rancher Helm template, there are several options in the Helm | `systemDefaultRegistry` | `` | Configure Rancher server to always pull from your private registry when provisioning clusters. | | `useBundledSystemChart` | `true` | Configure Rancher server to use the packaged copy of Helm system charts. The [system charts](https://github.com/rancher/system-charts) repository contains all the catalog items required for features such as monitoring, logging, alerting and global DNS. These [Helm charts](https://github.com/rancher/system-charts) are located in GitHub, but since you are in an air gapped environment, using the charts that are bundled within Rancher is much easier than setting up a Git mirror. | -# 3. Render the Rancher Helm Template +### 3. Render the Rancher Helm Template Based on the choice your made in [2. Choose your SSL Configuration](#2-choose-your-ssl-configuration), complete one of the procedures below. -# Option A: Default Self-Signed Certificate +#### Option A: Default Self-Signed Certificate By default, Rancher generates a CA and uses cert-manager to issue the certificate for access to the Rancher server interface. @@ -97,7 +90,7 @@ Recent changes to cert-manager require an upgrade. If you are upgrading Rancher ::: -### 1. Add the cert-manager repo +##### 1. Add the cert-manager repo From a system connected to the internet, add the cert-manager repo to Helm: @@ -106,7 +99,7 @@ helm repo add jetstack https://charts.jetstack.io helm repo update ``` -### 2. Fetch the cert-manager chart +##### 2. Fetch the cert-manager chart Fetch the latest cert-manager chart available from the [Helm chart repository](https://artifacthub.io/packages/helm/cert-manager/cert-manager). @@ -120,7 +113,7 @@ New in v2.6.4, cert-manager versions 1.6.2 and 1.7.1 are compatible. We recommen helm fetch jetstack/cert-manager --version v1.7.1 ``` -### 3. Render the cert-manager template +##### 3. Render the cert-manager template Render the cert-manager template with the options you would like to use to install the chart. Remember to set the `image.repository` option to pull the image from your private registry. This will create a `cert-manager` directory with the Kubernetes manifest files. @@ -133,14 +126,14 @@ helm template cert-manager ./cert-manager-v1.7.1.tgz --output-dir . \ --set startupapicheck.image.repository=/quay.io/jetstack/cert-manager-ctl ``` -### 4. Download the cert-manager CRD +##### 4. Download the cert-manager CRD Download the required CRD file for cert-manager: ```plain curl -L -o cert-manager/cert-manager-crd.yaml https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml ``` -### 5. Render the Rancher template +##### 5. Render the Rancher template Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools. @@ -165,14 +158,14 @@ helm template rancher ./rancher-.tgz --output-dir . \ **Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8` -# Option B: Certificates From Files using Kubernetes Secrets +#### Option B: Certificates From Files using Kubernetes Secrets -### 1. Create secrets +##### 1. Create secrets Create Kubernetes secrets from your own certificates for Rancher to use. The common name for the cert will need to match the `hostname` option in the command below, or the ingress controller will fail to provision the site for Rancher. -### 2. Render the Rancher template +##### 2. Render the Rancher template Render the Rancher template, declaring your chosen options. Use the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools. @@ -211,7 +204,7 @@ If you are using a Private CA signed cert, add `--set privateCA=true` following Then refer to [Adding TLS Secrets](../../resources/add-tls-secrets.md) to publish the certificate files so Rancher and the ingress controller can use them. -# 4. Install Rancher +### 4. Install Rancher Copy the rendered manifest directories to a system that has access to the Rancher server cluster to complete installation. @@ -219,7 +212,7 @@ Use `kubectl` to create namespaces and apply the rendered manifests. If you choose to use self-signed certificates in [B. Choose your SSL Configuration](#b-choose-your-ssl-configuration), install cert-manager. -### For Self-Signed Certificate Installs, Install Cert-manager +#### For Self-Signed Certificate Installs, Install Cert-manager
Click to expand @@ -227,14 +220,13 @@ If you choose to use self-signed certificates in [B. Choose your SSL Configurati If you are using self-signed certificates, install cert-manager: 1. Create the namespace for cert-manager. -```plain -kubectl create namespace cert-manager -``` - -1. Create the cert-manager CustomResourceDefinitions (CRDs). -```plain -kubectl apply -f cert-manager/cert-manager-crd.yaml -``` + ```plain + kubectl create namespace cert-manager + ``` +2. Create the cert-manager CustomResourceDefinitions (CRDs). + ```plain + kubectl apply -f cert-manager/cert-manager-crd.yaml + ``` :::note @@ -242,14 +234,14 @@ kubectl apply -f cert-manager/cert-manager-crd.yaml ::: -1. Launch cert-manager. -```plain -kubectl apply -R -f ./cert-manager -``` +3. Launch cert-manager. + ```plain + kubectl apply -R -f ./cert-manager + ```
-### Install Rancher with kubectl +#### Install Rancher with kubectl ```plain kubectl create namespace cattle-system @@ -263,7 +255,7 @@ If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/ ::: -# Additional Resources +## Additional Resources These resources could be helpful when installing Rancher: diff --git a/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md b/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md index c79cddeecec..6418c531eb0 100644 --- a/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md +++ b/docs/getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md @@ -178,7 +178,7 @@ Your registry must support manifests. As of April 2020, Amazon Elastic Container Append your private registry address to the `allow-nondistributable-artifacts` config field in the Docker daemon (`C:\ProgramData\Docker\config\daemon.json`). Since the base image of Windows images are maintained by the `mcr.microsoft.com` registry, this step is required as the layers in the Microsoft registry are missing from Docker Hub and need to be pulled into the private registry. - ``` + ```json { ... "allow-nondistributable-artifacts": [ diff --git a/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md b/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md index c15262f51fb..284d4fb2dd0 100644 --- a/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md +++ b/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md @@ -5,8 +5,6 @@ weight: 200 Once the infrastructure is ready, you can continue with setting up an RKE cluster to install Rancher in. -### Installing Docker - First, you have to install Docker and setup the HTTP proxy on all three Linux nodes. For this perform the following steps on all three nodes. For convenience, export the IP address and port of your proxy into an environment variable and set up the HTTP_PROXY variables for your current shell: @@ -105,7 +103,7 @@ sudo ./get_helm.sh Next, create a YAML file that describes the RKE cluster. Ensure that the IP addresses of the nodes and the SSH username are correct. For more information on the cluster YAML, have a look at the [RKE documentation](https://rancher.com/docs/rke/latest/en/example-yamls/). -``` +```yml nodes: - address: 10.0.1.200 user: ubuntu diff --git a/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md b/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md index 94d8cf5d784..0b6806ada7c 100644 --- a/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md +++ b/docs/getting-started/installation-and-upgrade/other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md @@ -14,12 +14,12 @@ The following instructions will guide you through upgrading a Rancher server tha ::: -# Prerequisites +## Prerequisites - **Review the [known upgrade issues](../../install-upgrade-on-a-kubernetes-cluster/upgrades.md#known-upgrade-issues)** section in the Rancher documentation for the most noteworthy issues to consider when upgrading Rancher. A more complete list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums](https://forums.rancher.com/c/announcements/12). Note that upgrades to or from any chart in the [rancher-alpha repository](../../../../reference-guides/installation-references/helm-chart-options.md#helm-chart-repositories/) aren’t supported. - **For [air gap installs only,](../../../../pages-for-subheaders/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version**. Follow the guide to [populate your private registry](../air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to. -# Placeholder Review +## Placeholder Review During upgrade, you'll enter a series of commands, filling placeholders with data from your environment. These placeholders are denoted with angled brackets and all capital letters (``). @@ -31,7 +31,7 @@ docker stop In this command, `` is the name of your Rancher container. -# Get Data for Upgrade Commands +## Get Data for Upgrade Commands To obtain the data to replace the placeholders, run: @@ -55,18 +55,10 @@ Write down or copy this information before starting the upgrade. You can obtain `` and `` by logging into your Rancher server by remote connection and entering the command to view the containers that are running: `docker ps`. You can also view containers that are stopped using a different command: `docker ps -a`. Use these commands for help anytime during while creating backups. -# Upgrade Outline +## Upgrade -During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data. Follow the steps to upgrade Rancher server: - -- [1. Create a copy of the data from your Rancher server container](#1-create-a-copy-of-the-data-from-your-rancher-server-container) -- [2. Create a backup tarball](#2-create-a-backup-tarball) -- [3. Pull the new Docker image](#3-pull-the-new-docker-image) -- [4. Start the new Rancher server container](#4-start-the-new-rancher-server-container) -- [5. Verify the Upgrade](#5-verify-the-upgrade) -- [6. Clean up your old Rancher server container](#6-clean-up-your-old-rancher-server-container) - -# 1. Create a copy of the data from your Rancher server container +During upgrade, you create a copy of the data from your current Rancher container and a backup in case something goes wrong. Then you deploy the new version of Rancher in a new container using your existing data. +### 1. Create a copy of the data from your Rancher server container 1. Using a remote Terminal connection, log into the node running your Rancher server. @@ -82,13 +74,11 @@ During upgrade, you create a copy of the data from your current Rancher containe docker create --volumes-from --name rancher-data rancher/rancher: ``` -# 2. Create a backup tarball +### 2. Create a backup tarball 1. From the data container that you just created (rancher-data), create a backup tarball (rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz). This tarball will serve as a rollback point if something goes wrong during upgrade. Use the following command, replacing each placeholder. - - ``` docker run --volumes-from rancher-data -v "$PWD:/backup" --rm busybox tar zcvf /backup/rancher-data-backup--.tar.gz /var/lib/rancher ``` @@ -104,7 +94,7 @@ During upgrade, you create a copy of the data from your current Rancher containe 1. Move your backup tarball to a safe location external from your Rancher server. -# 3. Pull the New Docker Image +### 3. Pull the New Docker Image Pull the image of the Rancher version that you want to upgrade to. @@ -116,7 +106,7 @@ Placeholder | Description docker pull rancher/rancher: ``` -# 4. Start the New Rancher Server Container +### 4. Start the New Rancher Server Container Start a new Rancher server container using the data from the `rancher-data` container. Remember to pass in all the environment variables that you had used when you started the original container. @@ -142,7 +132,7 @@ To see the command to use when starting the new Rancher server container, choose Select which option you had installed Rancher server -### Option A: Default Self-Signed Certificate +#### Option A: Default Self-Signed Certificate
Click to expand @@ -165,10 +155,10 @@ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s
-### Option B: Bring Your Own Certificate: Self-Signed +#### Option B: Bring Your Own Certificate: Self-Signed
- Click to expand +Click to expand If you have selected to bring your own self-signed certificate, you add the `--volumes-from rancher-data` to the command that you had started your original Rancher server container and need to have access to the same certificate that you had originally installed with. @@ -201,7 +191,7 @@ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s
-### Option C: Bring Your Own Certificate: Signed by Recognized CA +#### Option C: Bring Your Own Certificate: Signed by Recognized CA
Click to expand @@ -235,7 +225,7 @@ docker run -d --volumes-from rancher-data \ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
-### Option D: Let's Encrypt Certificate +#### Option D: Let's Encrypt Certificate
Click to expand @@ -280,7 +270,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher When starting the new Rancher server container, choose from the following options: -### Option A: Default Self-Signed Certificate +#### Option A: Default Self-Signed Certificate
Click to expand @@ -305,7 +295,7 @@ Placeholder | Description Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
-### Option B: Bring Your Own Certificate: Self-Signed +#### Option B: Bring Your Own Certificate: Self-Signed
Click to expand @@ -341,7 +331,7 @@ docker run -d --restart=unless-stopped \ Privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md#privileged-access-for-rancher)
-### Option C: Bring Your Own Certificate: Signed by Recognized CA +#### Option C: Bring Your Own Certificate: Signed by Recognized CA
Click to expand @@ -388,7 +378,7 @@ privileged access is [required.](../../../../pages-for-subheaders/rancher-on-a-s **Result:** You have upgraded Rancher. Data from your upgraded server is now saved to the `rancher-data` container for use in future upgrades. -# 5. Verify the Upgrade +### 5. Verify the Upgrade Log into Rancher. Confirm that the upgrade succeeded by checking the version displayed in the bottom-left corner of the browser window. @@ -398,10 +388,10 @@ See [Restoring Cluster Networking](../../../../../versioned_docs/version-2.0-2.4 ::: -# 6. Clean up Your Old Rancher Server Container +### 6. Clean up Your Old Rancher Server Container Remove the previous Rancher server container. If you only stop the previous Rancher server container (and don't remove it), the container may restart after the next server reboot. -# Rolling Back +## Rolling Back If your upgrade does not complete successfully, you can roll back Rancher server and its data back to its last healthy state. For more information, see [Docker Rollback](roll-back-docker-installed-rancher.md). diff --git a/docs/getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md b/docs/getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md index 1895eaab17e..d6413420827 100644 --- a/docs/getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md +++ b/docs/getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md @@ -99,6 +99,7 @@ Because the rancher-alpha repository contains only alpha charts, switching betwe + When performing [Docker installs](../../../pages-for-subheaders/rancher-on-a-single-node-with-docker.md), upgrades, or rollbacks, you can use _tags_ to install a specific version of Rancher. ### Server Tags diff --git a/docs/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md b/docs/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md index 44cc5c72866..61413064f3f 100644 --- a/docs/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md +++ b/docs/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md @@ -7,33 +7,19 @@ Following an upgrade to the latest version of Rancher, downstream Kubernetes clu Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/). -This section covers the following topics: -- [New Features](#new-features) -- [Tested Kubernetes Versions](#tested-kubernetes-versions) -- [How Upgrades Work](#how-upgrades-work) -- [Recommended Best Practice for Upgrades](#recommended-best-practice-for-upgrades) -- [Upgrading the Kubernetes Version](#upgrading-the-kubernetes-version) -- [Rolling Back](#rolling-back) -- [Configuring the Upgrade Strategy](#configuring-the-upgrade-strategy) - - [Configuring the Maximum Unavailable Worker Nodes in the Rancher UI](#configuring-the-maximum-unavailable-worker-nodes-in-the-rancher-ui) - - [Enabling Draining Nodes During Upgrades from the Rancher UI](#enabling-draining-nodes-during-upgrades-from-the-rancher-ui) - - [Maintaining Availability for Applications During Upgrades](#maintaining-availability-for-applications-during-upgrades) - - [Configuring the Upgrade Strategy in the cluster.yml](#configuring-the-upgrade-strategy-in-the-cluster-yml) -- [Troubleshooting](#troubleshooting) - -# Tested Kubernetes Versions +## Tested Kubernetes Versions Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) -# How Upgrades Work +## How Upgrades Work RKE v1.1.0 changed the way that clusters are upgraded. In this section of the [RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work) you'll learn what happens when you edit or upgrade your RKE Kubernetes cluster. -# Recommended Best Practice for Upgrades +## Recommended Best Practice for Upgrades When upgrading the Kubernetes version of a cluster, we recommend that you: @@ -43,7 +29,7 @@ When upgrading the Kubernetes version of a cluster, we recommend that you: The restore operation will work on a cluster that is not in a healthy or active state. -# Upgrading the Kubernetes Version +## Upgrading the Kubernetes Version :::note Prerequisites: @@ -59,14 +45,14 @@ The restore operation will work on a cluster that is not in a healthy or active **Result:** Kubernetes begins upgrading for the cluster. -# Rolling Back +## Rolling Back A cluster can be restored to a backup in which the previous Kubernetes version was used. For more information, refer to the following sections: - [Backing up a cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#how-snapshots-work) - [Restoring a cluster from backup](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md#restoring-a-cluster-from-a-snapshot) -# Configuring the Upgrade Strategy +## Configuring the Upgrade Strategy As of RKE v1.1.0, additional upgrade options became available to give you more granular control over the upgrade process. These options can be used to maintain availability of your applications during a cluster upgrade if certain [conditions and requirements](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability) are met. @@ -122,7 +108,7 @@ More advanced upgrade strategy configuration options are available by editing th For details, refer to [Configuring the Upgrade Strategy](https://rancher.com/docs/rke/latest/en/upgrades/configuring-strategy) in the RKE documentation. The section also includes an example `cluster.yml` for configuring the upgrade strategy. -# Troubleshooting +## Troubleshooting If a node doesn't come up after an upgrade, the `rke up` command errors out. diff --git a/docs/getting-started/introduction/what-are-divio-docs.md b/docs/getting-started/introduction/what-are-divio-docs.md index cd9adf930af..c1e44cbf29d 100644 --- a/docs/getting-started/introduction/what-are-divio-docs.md +++ b/docs/getting-started/introduction/what-are-divio-docs.md @@ -6,20 +6,6 @@ The [Divio documentation system](https://documentation.divio.com/) is a software In our docs, we have used this guideline to craft a unique set of docs which include [getting started](../../getting-started.md), [how-to guides](../../how-to-guides.md) (including [new](../../pages-for-subheaders/new-user-guides.md) and [advanced user guides](../../pages-for-subheaders/advanced-user-guides.md)), [reference guides](../../reference-guides.md), [explanations](../../explanations.md), an [FAQ section](../../faq.md), [troubleshooting tips](../../troubleshooting.md), and the ability to [contribute to Rancher](../../contribute-to-rancher.md). -- [Getting Started](#getting-started) -- [How-to Guides](#how-to-guides) - - [New User Guides](#new-user-guides) - - [Advanced User Guides](#advanced-user-guides) -- [Reference Guides](#reference-guides) -- [Explanations](#explanations) - - [Integrations in Rancher](#integrations-in-rancher) -- [Other Docs Categories](#other-docs-categories) - - [FAQ](#faq) - - [Troubleshooting](#troubleshooting) - - [Contribute to Rancher](#contribute-to-rancher) -- [Overlapping of Categories](#overlapping-of-categories) -- [New Structure Goals](#new-structure-goals) - ## Getting Started diff --git a/docs/getting-started/quick-start-guides/deploy-rancher-manager/aws.md b/docs/getting-started/quick-start-guides/deploy-rancher-manager/aws.md index d382b354b2c..9ef522c64fd 100644 --- a/docs/getting-started/quick-start-guides/deploy-rancher-manager/aws.md +++ b/docs/getting-started/quick-start-guides/deploy-rancher-manager/aws.md @@ -28,7 +28,7 @@ Deploying to Amazon AWS will incur charges. The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 instance. A simple policy would be: -``` +```json { "Version": "2012-10-17", "Statement": [ @@ -50,17 +50,18 @@ The AWS module just creates an EC2 KeyPair, an EC2 SecurityGroup and an EC2 inst 3. Rename the `terraform.tfvars.example` file to `terraform.tfvars`. 4. Edit `terraform.tfvars` and customize the following variables: + - `aws_access_key` - Amazon AWS Access Key - `aws_secret_key` - Amazon AWS Secret Key - `rancher_server_admin_password` - Admin password for created Rancher server -5. **Optional:** Modify optional variables within `terraform.tfvars`. -See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information. +5. **Optional:** Modify optional variables within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [AWS Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/aws) for more information. Suggestions include: - - `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`) - - `prefix` - Prefix for all created resources - - `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget - - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster + + - `aws_region` - Amazon AWS region, choose the closest instead of the default (`us-east-1`) + - `prefix` - Prefix for all created resources + - `instance_type` - EC2 instance size used, minimum is `t3a.medium` but `t3a.large` or `t3a.xlarge` could be used if within budget + - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster 6. Run `terraform init`. diff --git a/docs/getting-started/quick-start-guides/deploy-rancher-manager/azure.md b/docs/getting-started/quick-start-guides/deploy-rancher-manager/azure.md index 39b77c8aaa1..925bbeb56e4 100644 --- a/docs/getting-started/quick-start-guides/deploy-rancher-manager/azure.md +++ b/docs/getting-started/quick-start-guides/deploy-rancher-manager/azure.md @@ -43,13 +43,12 @@ Deploying to Microsoft Azure will incur charges. - `rancher_server_admin_password` - Admin password for created Rancher server 5. **Optional:** Modify optional variables within `terraform.tfvars`. -See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. -Suggestions include: - - `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`) - - `prefix` - Prefix for all created resources - - `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget - - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster - - `windows_admin_password` - The admin password of the windows worker node +See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [Azure Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/azure) for more information. Suggestions include: + - `azure_location` - Microsoft Azure region, choose the closest instead of the default (`East US`) + - `prefix` - Prefix for all created resources + - `instance_type` - Compute instance size used, minimum is `Standard_DS2_v2` but `Standard_DS2_v3` or `Standard_DS3_v2` could be used if within budget + - `add_windows_node` - If true, an additional Windows worker node is added to the workload cluster + - `windows_admin_password` - The admin password of the windows worker node 6. Run `terraform init`. diff --git a/docs/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md b/docs/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md index ac8d7c156a2..68a40ca475b 100644 --- a/docs/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md +++ b/docs/getting-started/quick-start-guides/deploy-rancher-manager/digitalocean.md @@ -37,11 +37,10 @@ Deploying to DigitalOcean will incur charges. - `rancher_server_admin_password` - Admin password for created Rancher server 5. **Optional:** Modify optional variables within `terraform.tfvars`. -See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. -Suggestions include: - - `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`) - - `prefix` - Prefix for all created resources - - `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget +See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [DO Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/do) for more information. Suggestions include: + - `do_region` - DigitalOcean region, choose the closest instead of the default (`nyc1`) + - `prefix` - Prefix for all created resources + - `droplet_size` - Droplet size used, minimum is `s-2vcpu-4gb` but `s-4vcpu-8gb` could be used if within budget 6. Run `terraform init`. diff --git a/docs/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal.md b/docs/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal.md index b16a455c2bd..011fae0deb6 100644 --- a/docs/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal.md +++ b/docs/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal.md @@ -20,18 +20,6 @@ The intent of these guides is to quickly launch a sandbox that you can use to ev This Quick Start Guide is divided into different tasks for easier consumption. - - - -1. [Provision a Equinix Metal Host](#1-provision-a-equinix-metal-host) - -1. [Install Rancher](#2-install-rancher) - -1. [Log In](#3-log-in) - -1. [Create the Cluster](#4-create-the-cluster) - -
## Prerequisites diff --git a/docs/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md b/docs/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md index aed01fd3284..78dd49ff065 100644 --- a/docs/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md +++ b/docs/getting-started/quick-start-guides/deploy-rancher-manager/gcp.md @@ -40,10 +40,10 @@ Deploying to Google GCP will incur charges. 5. **Optional:** Modify optional variables within `terraform.tfvars`. See the [Quickstart Readme](https://github.com/rancher/quickstart) and the [GCP Quickstart Readme](https://github.com/rancher/quickstart/tree/master/rancher/gcp) for more information. Suggestions include: - - `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`) - - `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`) - - `prefix` - Prefix for all created resources - - `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget + - `gcp_region` - Google GCP region, choose the closest instead of the default (`us-east4`) + - `gcp_zone` - Google GCP zone, choose the closest instead of the default (`us-east4-a`) + - `prefix` - Prefix for all created resources + - `machine_type` - Compute instance size used, minimum is `n1-standard-1` but `n1-standard-2` or `n1-standard-4` could be used if within budget 6. Run `terraform init`. diff --git a/docs/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md b/docs/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md index 8347bcecfab..2bfa4133ad2 100644 --- a/docs/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md +++ b/docs/getting-started/quick-start-guides/deploy-rancher-manager/hetzner-cloud.md @@ -39,9 +39,10 @@ Deploying to Hetzner Cloud will incur charges. 5. **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/rancher/hcloud) for more information. Suggestions include: - - `prefix` - Prefix for all created resources - - `instance_type` - Instance type, minimum required is `cx21` - - `hcloud_location` - Hetzner Cloud location, choose the closest instead of the default (`fsn1`) + + - `prefix` - Prefix for all created resources + - `instance_type` - Instance type, minimum required is `cx21` + - `hcloud_location` - Hetzner Cloud location, choose the closest instead of the default (`fsn1`) 6. Run `terraform init`. diff --git a/docs/getting-started/quick-start-guides/deploy-workloads/nodeports.md b/docs/getting-started/quick-start-guides/deploy-workloads/nodeports.md index 154f51e5ef1..389ca9881d8 100644 --- a/docs/getting-started/quick-start-guides/deploy-workloads/nodeports.md +++ b/docs/getting-started/quick-start-guides/deploy-workloads/nodeports.md @@ -45,7 +45,7 @@ From the **Workloads** page, click the link underneath your workload. If your de When using a cloud-hosted virtual machine, you may not have access to the port running the container. In this event, you can test Nginx in an ssh session on the local machine using `Execute Shell`. Use the port number after the `:` in the link under your workload if available, which is `31568` in this example. -```sh +```html gettingstarted@rancher:~$ curl http://localhost:31568 diff --git a/docs/getting-started/quick-start-guides/deploy-workloads/workload-ingress.md b/docs/getting-started/quick-start-guides/deploy-workloads/workload-ingress.md index 1f4de821d40..d7d368c830f 100644 --- a/docs/getting-started/quick-start-guides/deploy-workloads/workload-ingress.md +++ b/docs/getting-started/quick-start-guides/deploy-workloads/workload-ingress.md @@ -28,7 +28,6 @@ For this workload, you'll be deploying the application Rancher Hello-World. * Your workload is deployed. This process might take a few minutes to complete. * When your workload completes deployment, it's assigned a state of **Active**. You can view this status from the project's **Workloads** page. -
### 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. diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md index 851c92941b1..c4339690dc3 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md @@ -34,15 +34,6 @@ Before you start, we recommend creating an empty text file. You can use this fil ::: - - -- [1. Register Rancher with Azure](#1-register-rancher-with-azure) -- [2. Create a new client secret](#2-create-a-new-client-secret) -- [3. Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher) -- [4. Copy Azure Application Data](#5-copy-azure-application-data) -- [5. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher) - - #### 1. Register Rancher with Azure diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md index ff81feee708..1e292ea4f9d 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md @@ -11,11 +11,6 @@ You can [save the configuration of an existing cluster as an RKE template.](#con You can't change a cluster to use a different RKE template. You can only update the cluster to a new revision of the same template. -This section covers the following topics: - -- [Creating a cluster from an RKE template](#creating-a-cluster-from-an-rke-template) -- [Updating a cluster created with an RKE template](#updating-a-cluster-created-with-an-rke-template) -- [Converting an existing cluster to use an RKE template](#converting-an-existing-cluster-to-use-an-rke-template) ### Creating a Cluster from an RKE Template diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md index c4b1d9e7e95..ac1a2f21597 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md @@ -15,7 +15,7 @@ Users can only create new templates if the administrator [gives them permission. After a cluster is created with an RKE template, the cluster creator cannot edit settings that are defined in the template. The only way to change those settings after the cluster is created is to [upgrade the cluster to a new revision](apply-templates.md#updating-a-cluster-created-with-an-rke-template) of the same template. If cluster creators want to change template-defined settings, they would need to contact the template owner to get a new revision of the template. For details on how template revisions work, refer to the [documentation on revising templates.](manage-rke1-templates.md#updating-a-template) -# Requiring New Clusters to Use an RKE Template +## Requiring New Clusters to Use an RKE Template You might want to require new clusters to use a template to ensure that any cluster launched by a [standard user](../manage-role-based-access-control-rbac/global-permissions.md) will use the Kubernetes and/or Rancher settings that are vetted by administrators. @@ -33,7 +33,7 @@ To require new clusters to use an RKE template, administrators can turn on RKE t **Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator. -# Disabling RKE Template Enforcement +## Disabling RKE Template Enforcement To allow new clusters to be created without an RKE template, administrators can turn off RKE template enforcement with the following steps: diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md index bf7bf15bec1..81b8015dc6c 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md @@ -11,7 +11,7 @@ These example scenarios describe how an organization could use templates to stan - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to delegate ownership of the template, this scenario describes how [template ownership can be shared.](#allowing-other-users-to-control-and-share-a-template) -# Enforcing a Template Setting for Everyone +## Enforcing a Template Setting for Everyone Let's say there is an organization in which the administrators decide that all new clusters should be created with Kubernetes version 1.14. @@ -27,7 +27,7 @@ Let's say there is an organization in which the administrators decide that all n In this way, the administrators enforce the Kubernetes version across the organization, while still allowing end users to configure everything else. -# Templates for Basic and Advanced Users +## Templates for Basic and Advanced Users Let's say an organization has both basic and advanced users. Administrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want. @@ -42,7 +42,7 @@ Let's say an organization has both basic and advanced users. Administrators want **Result:** All Rancher users, except for administrators, are required to use a template when creating a cluster. Everyone has access to the restrictive template, but only advanced users have permission to use the more permissive template. The basic users are more restricted, while advanced users have more freedom when configuring their Kubernetes clusters. -# Updating Templates and Clusters Created with Them +## Updating Templates and Clusters Created with Them Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the administrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes. @@ -54,7 +54,7 @@ The template owner has several options for allowing the cluster creators to upgr - **Allow any Kubernetes version on the template:** When creating a template revision, the template owner can also mark the the Kubernetes version as **Allow User Override** using the switch near that setting on the Rancher UI. This will allow clusters that upgrade to this template revision to use any version of Kubernetes. - **Allow the latest minor Kubernetes version on the template:** The template owner can also create a template revision in which the Kubernetes version is defined as **Latest v1.14 (Allows patch version upgrades)**. This means clusters that use that revision will be able to get patch version upgrades, but major version upgrades will not be allowed. -# Allowing Other Users to Control and Share a Template +## Allowing Other Users to Control and Share a Template Let's say Alice is a Rancher administrator. She owns an RKE template that reflects her organization's agreed-upon best practices for creating a cluster. diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md index 38524924ff6..749f2173717 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md @@ -29,7 +29,7 @@ Terraform allows you to: - Incorporate infrastructure changes into standard development practices - Prevent configuration drift, in which some servers become configured differently than others -# How Does Terraform Work? +## How Does Terraform Work? Terraform is written in files with the extension `.tf`. It is written in HashiCorp Configuration Language, which is a declarative language that lets you define the infrastructure you want in your cluster, the cloud provider you are using, and your credentials for the provider. Then Terraform makes API calls to the provider in order to efficiently create that infrastructure. @@ -39,7 +39,7 @@ Then Terraform calls the Rancher API to provision your infrastructure, and Ranch When you need to make changes to your infrastructure, instead of manually updating the servers, you can make changes in the Terraform configuration files. Then those files can be committed to version control, validated, and reviewed as necessary. Then when you run `terraform apply`, the changes would be deployed. -# Tips for Working with Terraform +## Tips for Working with Terraform - There are examples of how to provide most aspects of a cluster in the [documentation for the Rancher 2 provider.](https://www.terraform.io/docs/providers/rancher2/) @@ -51,7 +51,7 @@ When you need to make changes to your infrastructure, instead of manually updati - If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware. -# Tip for Creating CIS Benchmark Compliant Clusters +## Tip for Creating CIS Benchmark Compliant Clusters This section describes one way that you can make security and compliance-related config files standard in your clusters. @@ -63,7 +63,7 @@ Then you would make sure that the `kube-api-server` flag in your RKE template us In this way, you can create flags that comply with the CIS benchmark. -# Resources +## Resources - [Terraform documentation](https://www.terraform.io/docs/) - [Rancher2 Terraform provider documentation](https://www.terraform.io/docs/providers/rancher2/) diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md index 33e05445657..0edcf638c63 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md @@ -11,20 +11,6 @@ Template revisions can be used in two ways: to create a new cluster, or to upgra The template owner has full control over template revisions, and can create new revisions to update the template, delete or disable revisions that should not be used to create clusters, and choose which template revision is the default. -This section covers the following topics: - -- [Prerequisites](#prerequisites) -- [Creating a template](#creating-a-template) -- [Updating a template](#updating-a-template) -- [Deleting a template](#deleting-a-template) -- [Creating a revision based on the default revision](#creating-a-revision-based-on-the-default-revision) -- [Creating a revision based on a cloned revision](#creating-a-revision-based-on-a-cloned-revision) -- [Disabling a template revision](#disabling-a-template-revision) -- [Re-enabling a disabled template revision](#re-enabling-a-disabled-template-revision) -- [Setting a template revision as default](#setting-a-template-revision-as-default) -- [Deleting a template revision](#deleting-a-template-revision) -- [Upgrading a cluster to use a new template revision](#upgrading-a-cluster-to-use-a-new-template-revision) -- [Exporting a running cluster to a new RKE template and revision](#exporting-a-running-cluster-to-a-new-rke-template-and-revision) ### Prerequisites diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md index 043c7686b26..2e0f61a571d 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md @@ -7,17 +7,8 @@ _Pod Security Policies_ (or PSPs) are objects that control security-sensitive as If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod is forbidden: unable to validate...`. -- [How PSPs Work](#how-psps-work) -- [Default PSPs](#default-psps) - - [Restricted-NoRoot](#restricted-noroot) - - [Restricted](#restricted) - - [Unrestricted](#unrestricted) -- [Creating PSPs](#creating-psps) - - [Requirements](#requirements) - - [Creating PSPs in the Rancher UI](#creating-psps-in-the-rancher-ui) -- [Configuration](#configuration) -# How PSPs Work +## How PSPs Work You can assign PSPs at the cluster or project level. @@ -31,7 +22,7 @@ Any workloads that are already running in a cluster or project before a PSP is a Read more about Pod Security Policies in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). -# Default PSPs +## Default PSPs Rancher ships with three default Pod Security Policies (PSPs): the `restricted-noroot`, `restricted` and `unrestricted` policies. @@ -50,7 +41,7 @@ This policy is a relaxed version of the `restricted-noroot` policy, with almost This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project. -# Creating PSPs +## Creating PSPs Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file. @@ -73,6 +64,6 @@ We recommend adding PSPs during cluster and project creation instead of adding i 1. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does. 1. Click **Create**. -# Configuration +## Configuration The Kubernetes documentation on PSPs is [here](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/custom-branding.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/custom-branding.md index 32b4d89e6cd..fbfafbc3bfa 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/custom-branding.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/custom-branding.md @@ -8,13 +8,7 @@ import TabItem from '@theme/TabItem'; Rancher v2.6 introduced the ability to customize Rancher’s branding and navigation links. -- [Changing Brand Settings](#changing-brand-settings) -- [Brand Configuration](#brand-configuration) -- [Custom Navigation Links](#custom-navigation-links) -- [Link Configuration](#link-configuration) -- [Link Examples](#link-examples) - -# Changing Brand Settings +## Changing Brand Settings :::note Prerequisite: @@ -27,7 +21,7 @@ To configure the brand settings, 1. Click **☰ > Global settings**. 2. Click **Branding**. -# Brand Configuration +## Brand Configuration ### Private Label Company Name @@ -67,7 +61,7 @@ To configure banner settings, -# Custom Navigation Links +## Custom Navigation Links In this section, you'll learn how to configure the links in the left navigation bar of the **Cluster Dashboard**. To get to the cluster dashboard, @@ -101,7 +95,7 @@ You will need to have at least cluster member or project member permissions. For more details on setting up links, including optional fields, see [Link Configuration.](#link-configuration) 6. Click **Create**. -# Link Configuration +## Link Configuration ### `name` diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md index c1baf083b3f..3051988697a 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md @@ -13,7 +13,7 @@ For instructions on setting up a private registry with command line options duri If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster. -# Setting a Private Registry with No Credentials as the Default Registry +## Setting a Private Registry with No Credentials as the Default Registry 1. Log into Rancher and configure the default administrator password. 1. Click **☰ > Global Settings**. @@ -22,7 +22,7 @@ If your private registry requires credentials, it cannot be used as the default **Result:** Rancher will use your private registry to pull system images. -# Setting a Private Registry with Credentials when Deploying a Cluster +## Setting a Private Registry with Credentials when Deploying a Cluster You can follow these steps to configure a private registry when you create a cluster: diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-cluster-templates.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-cluster-templates.md index acccba1c949..5097a049aa7 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-cluster-templates.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-cluster-templates.md @@ -5,16 +5,7 @@ weight: 100 Cluster templates encompass both Kubernetes configuration and node pool configuration, allowing a single template to contain all the information Rancher needs to provision new nodes in a cloud provider and install Kubernetes on those nodes. -- [Overview](#overview) -- [RKE2 Cluster Template](#rke2-cluster-template) -- [Adding a Cluster Template to Rancher](#adding-a-cluster-template-to-rancher) -- [Creating a Cluster from a Cluster Template](#creating-a-cluster-from-a-cluster-template) -- [Updating a Cluster Created from a Cluster Template](#updating-a-cluster-created-from-a-cluster-template) -- [Deploying Clusters from a Template with Fleet](#deploying-clusters-from-a-template-with-fleet) -- [Uninstalling Cluster Templates](#uninstalling-cluster-templates) -- [Configuration Options](#configuration-options) - -# Overview +## Overview Cluster templates are provided as Helm charts. To use them, you will need to clone and fork the templates, change them according to your use case, and then install the Helm charts on the Rancher management cluster. When the Helm chart is installed on the Rancher management cluster, a new cluster resource is created, which Rancher uses to provision the new cluster. @@ -28,11 +19,11 @@ Cluster templates can use any Kubernetes distribution. For now, we provide an ex Rancher doesn't manage version control for cluster templates. Version control is handled in the repository containing the template's Helm chart. -# RKE2 Cluster Template +## RKE2 Cluster Template The example repository for an RKE2 cluster template is [here](https://github.com/rancher/cluster-template-examples). As of Rancher v2.6.0, we provide an RKE2 cluster template and may add more in the future. -# Adding a Cluster Template to Rancher +## Adding a Cluster Template to Rancher In this section, you'll learn how to add the cluster template to the `local` cluster's chart repo list. The result is that Rancher will include the cluster template as an option when users install new Kubernetes clusters. @@ -64,7 +55,7 @@ If you are a restricted admin and don’t have access to the `local` cluster, yo ::: -# Creating a Cluster from a Cluster Template +## Creating a Cluster from a Cluster Template :::note Prerequisites: @@ -81,11 +72,11 @@ If you are a restricted admin and don’t have access to the `local` cluster, yo **Result:** After Rancher provisions the new cluster, it is managed in the same way as any other Rancher-launched Kubernetes cluster. You can configure any options through the UI if the cluster template has options for the user to choose from. -# Updating a Cluster Created from a Cluster Template +## Updating a Cluster Created from a Cluster Template You can update any clusters using a template from the **Apps & Marketplace > Installed Apps** page, given there is a new version of a template being used by those clusters. -# Deploying Clusters from a Template with Fleet +## Deploying Clusters from a Template with Fleet :::note Prerequisites: @@ -104,7 +95,7 @@ You can update any clusters using a template from the **Apps & Marketplace > Ins **Result:** After Rancher provisions the new cluster, it is managed by Fleet. -# Uninstalling Cluster Templates +## Uninstalling Cluster Templates 1. Click **☰ > Cluster Management**. 1. Go to the `local` cluster and click **Apps & Marketplace > Chart Repositories.** @@ -115,7 +106,7 @@ You can update any clusters using a template from the **Apps & Marketplace > Ins An admin with access to the `local` cluster can also remove a cluster deployed via cluster templates through the **Apps & Marketplace > Installed Apps** page. -# Configuration Options +## Configuration Options Cluster templates are flexible enough that they can be used to configure all of the following options: diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md index 55908e358ae..8657dad1c72 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md @@ -137,21 +137,21 @@ _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 +:::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. +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. - :::note danger +:::danger - 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 namespaces in other projects they're assigned to, even with only the `Read Only` role assigned. - ::: +::: #### Custom Project Roles diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md index 414cfea5707..fcacb047c6f 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md @@ -7,29 +7,21 @@ Within Rancher, _roles_ determine what actions a user can make within a cluster Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access. -:::tip +:::danger It is possible for a custom role to enable privilege escalation. For details, see [this section.](#privilege-escalation) ::: -This section covers the following topics: -- [Prerequisites](#prerequisites) -- [Creating a custom role](#creating-a-custom-role) -- [Creating a custom role that inherits from another role](#creating-a-custom-role-that-inherits-from-another-role) -- [Deleting a custom role](#deleting-a-custom-role) -- [Assigning a custom role to a group](#assigning-a-custom-role-to-a-group) -- [Privilege escalation](#privilege-escalation) - -# Prerequisites +## Prerequisites To complete the tasks on this page, one of the following permissions are required: - [Administrator Global Permissions](global-permissions.md). - [Custom Global Permissions](global-permissions.md#custom-global-permissions) with the [Manage Roles](global-permissions.md) role assigned. -# Creating A Custom Role +## Creating A Custom Role While Rancher comes out-of-the-box with a set of default user roles, you can also create default custom roles to provide users with very specific permissions within Rancher. @@ -61,7 +53,7 @@ The steps to add custom roles differ depending on the version of Rancher. 1. Click **Create**. -# Creating a Custom Role that Inherits from Another Role +## Creating a Custom Role that Inherits from Another Role If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom role in which all of the rules from another role, such as the administrator role, are copied into a new role. This allows you to only configure the variations between the existing role and the new role. @@ -80,7 +72,7 @@ To create a custom role based on an existing role, 1. Optional: Assign the role as default. 1. Click **Create**. -# Deleting a Custom Role +## Deleting a Custom Role When deleting a custom role, all global role bindings with this custom role are deleted. @@ -95,7 +87,7 @@ To delete a custom role, 2. Go to the custom global role that should be deleted and click **⋮ (…) > Delete**. 3. Click **Delete**. -# Assigning a Custom Role to a Group +## Assigning a Custom Role to a Group If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher. @@ -124,6 +116,6 @@ To assign a custom role to a group, follow these steps: **Result:** The custom role will take effect when the users in the group log into Rancher. -# Privilege Escalation +## Privilege Escalation The `Configure Catalogs` custom permission is powerful and should be used with caution. When an admin assigns the `Configure Catalogs` permission to a standard user, it could result in privilege escalation in which the user could give themselves admin access to Rancher provisioned clusters. Anyone with this permission should be considered equivalent to an admin. \ No newline at end of file diff --git a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md index ccbaa2ebc4b..73d98c50167 100644 --- a/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md +++ b/docs/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md @@ -11,26 +11,13 @@ Global Permissions define user authorization outside the scope of any particular - **Restricted Admin:** These users have full control over downstream clusters, but cannot alter the local Kubernetes cluster. -- **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters. +- **Standard User:** These users can create new clusters and use them. Standard users can also assign other users permissions to their clusters. - **User-Base:** User-Base users have login-access only. You cannot update or delete the built-in Global Permissions. -This section covers the following topics: - -- [Restricted Admin](#restricted-admin) -- [Global permission assignment](#global-permission-assignment) - - [Global permissions for new local users](#global-permissions-for-new-local-users) - - [Global permissions for users with external authentication](#global-permissions-for-users-with-external-authentication) -- [Custom global permissions](#custom-global-permissions) - - [Custom global permissions reference](#custom-global-permissions-reference) - - [Configuring default global permissions for new users](#configuring-default-global-permissions) - - [Configuring global permissions for existing individual users](#configuring-global-permissions-for-existing-individual-users) - - [Configuring global permissions for groups](#configuring-global-permissions-for-groups) - - [Refreshing group memberships](#refreshing-group-memberships) - -# Restricted Admin +## Restricted Admin A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation from the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster. @@ -104,7 +91,7 @@ This can be done through **Security > Users** and moving any Administrator role Signed-in users can change themselves over to the `restricted-admin` if they wish, but they should only do that as the last step, otherwise they won't have the permissions to do so. -# Global Permission Assignment +## Global Permission Assignment Global permissions for local users are assigned differently than users who log in to Rancher using external authentication. @@ -136,7 +123,7 @@ Permissions can be assigned to an individual user with [these steps.](#configuri You can [assign a role to everyone in the group at the same time](#configuring-global-permissions-for-groups) if the external authentication provider supports groups. -# Custom Global Permissions +## Custom Global Permissions Using custom permissions is convenient for providing users with narrow or specialized access to Rancher. diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md index fe8062263d4..c9dce4866f0 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md @@ -8,12 +8,6 @@ This section describes how to manipulate your downstream Kubernetes cluster with For more information on using kubectl, see [Kubernetes Documentation: Overview of kubectl](https://kubernetes.io/docs/reference/kubectl/overview/). -- [Accessing clusters with kubectl shell in the Rancher UI](#accessing-clusters-with-kubectl-shell-in-the-rancher-ui) -- [Accessing clusters with kubectl from your workstation](#accessing-clusters-with-kubectl-from-your-workstation) -- [Note on Resources created using kubectl](#note-on-resources-created-using-kubectl) -- [Authenticating Directly with a Downstream Cluster](#authenticating-directly-with-a-downstream-cluster) - - [Connecting Directly to Clusters with FQDN Defined](#connecting-directly-to-clusters-with-fqdn-defined) - - [Connecting Directly to Clusters without FQDN Defined](#connecting-directly-to-clusters-without-fqdn-defined) ### Accessing Clusters with kubectl Shell in the Rancher UI @@ -50,7 +44,7 @@ These instructions assume that you have already created a Kubernetes cluster, an Rancher will discover and show resources created by `kubectl`. However, these resources might not have all the necessary annotations on discovery. If an operation (for instance, scaling the workload) is done to the resource using the Rancher UI/API, this may trigger recreation of the resources due to the missing annotations. This should only happen the first time an operation is done to the discovered resource. -# Authenticating Directly with a Downstream Cluster +## Authenticating Directly with a Downstream Cluster This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/assign-pod-security-policies.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/assign-pod-security-policies.md index a26b152f502..0118b990014 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/assign-pod-security-policies.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/assign-pod-security-policies.md @@ -9,7 +9,7 @@ _Pod Security Policies_ are objects that control security-sensitive aspects of p When you create a new cluster with RKE, you can configure it to apply a PSP immediately. As you create the cluster, use the **Cluster Options** to enable a PSP. The PSP assigned to the cluster will be the default PSP for projects within the cluster. -:::Prerequisite: +:::note Prerequisite: Create a Pod Security Policy within Rancher. Before you can assign a default PSP to a new cluster, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies](../authentication-permissions-and-global-configuration/create-pod-security-policies.md). diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md index 0a0f6a2b32f..b008843be52 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md @@ -18,15 +18,8 @@ For dynamic storage provisioning, your application will need to use a PVC that i For more information, refer to the [official Kubernetes documentation on storage](https://kubernetes.io/docs/concepts/storage/volumes/) -This section covers the following topics: -- [About persistent volume claims](#about-persistent-volume-claims) - - [PVCs are required for both new and existing persistent storage](#pvcs-are-required-for-both-new-and-existing-persistent-storage) -- [Setting up existing storage with a PVC and PV](#setting-up-existing-storage-with-a-pvc-and-pv) - - [Binding PVs to PVCs](#binding-pvs-to-pvcs) -- [Provisioning new storage with a PVC and storage class](#provisioning-new-storage-with-a-pvc-and-storage-class) - -# About Persistent Volume Claims +## About Persistent Volume Claims Persistent volume claims (PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. A PVC is mounted into a workloads as a volume so that the workload can claim its specified share of the persistent storage. @@ -46,7 +39,7 @@ Rancher lets you create as many PVCs within a project as you'd like. You can mount PVCs to a deployment as you create it, or later, after the deployment is running. -# Setting up Existing Storage with a PVC and PV +## Setting up Existing Storage with a PVC and PV Your pods can store data in [volumes,](https://kubernetes.io/docs/concepts/storage/volumes/) but if the pod fails, that data is lost. To solve this issue, Kubernetes offers persistent volumes (PVs), which are Kubernetes resources that correspond to external storage disks or file systems that your pods can access. If a pod crashes, its replacement pod can access the data in persistent storage without any data loss. @@ -70,7 +63,7 @@ In other words, you can create unlimited PVCs, but they will only be bound to PV To dynamically provision new storage, the PVC mounted in the pod would have to correspond to a storage class instead of a persistent volume. -# Provisioning New Storage with a PVC and Storage Class +## Provisioning New Storage with a PVC and Storage Class Storage Classes allow you to create PVs dynamically without having to create persistent storage in an infrastructure provider first. diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md index 9fe5c3a2146..2f93372cb41 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md @@ -5,28 +5,12 @@ weight: 10 These instructions are about using the external Ceph driver in an RKE2 cluster. If you are using RKE, additional steps are required. For details, refer to [this section.](#using-the-ceph-driver-with-rke) -- [Requirements](#requirements) -- [Using the Ceph Driver with RKE](#using-the-ceph-driver-with-rke) -- [Installing the ceph-csi driver on an RKE2 cluster](#installing-the-ceph-csi-driver-on-an-rke2-cluster) -- [Install the ceph-csi driver using Helm](#install-the-ceph-csi-driver-using-helm) -- [Creating RBD Ceph Resources](#creating-rbd-ceph-resources) -- [Configure RBD Ceph Access Secrets](#configure-rbd-ceph-access-secrets) - - [User Account](#user-account) - - [Admin Account](#admin-account) -- [Create RBD Testing Resources](#create-rbd-testing-resources) - - [Using RBD in Pods](#using-rbd-in-pods) - - [Using RBD in Persistent Volumes](#using-rbd-in-persistent-volumes) - - [Using RBD in Storage Classes](#using-rbd-in-storage-classes) - - [RKE2 Server/Master Provisioning](#rke2-server-master-provisioning) - - [RKE2 Agent/Worker provisioning](#rke2-agent-worker-provisioning) -- [Tested Versions](#tested-versions) -- [Troubleshooting](#troubleshooting) -# Requirements +## Requirements Make sure ceph-common and xfsprogs packages are installed on SLE worker nodes. -# Using the Ceph Driver with RKE +## Using the Ceph Driver with RKE The resources below are fully compatible with RKE based clusters, but there is a need to do an additional kubelet configuration for RKE. @@ -45,7 +29,7 @@ services: For more information about the `extra_binds` directive, refer to [this section.](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds) -# Installing the ceph-csi driver on an RKE2 cluster +## Installing the ceph-csi driver on an RKE2 cluster :::note @@ -77,7 +61,7 @@ min_mon_release 15 (octopus) Later you'll need the fsid and mon addresses values. -# Install the ceph-csi Driver Using Helm +## Install the ceph-csi Driver Using Helm Run these commands: @@ -119,7 +103,7 @@ helm upgrade \ --namespace ceph-csi-rbd ceph-csi-rbd ceph-csi/ceph-csi-rbd --values ceph-csi-rbd-values.yaml ``` -# Creating RBD Ceph Resources +## Creating RBD Ceph Resources ``` # Create a ceph pool: @@ -147,7 +131,7 @@ QVFCK0hDVmdXSjQ1T0JBQXBrc0VtcVhlZFpjc0JwaStIcmU5M3c9PQ== echo "myPoolAdmin" | tr -d '\n' | base64 bXlQb29sQWRtaW4= ``` -# Configure RBD Ceph Access Secrets +## Configure RBD Ceph Access Secrets ### User Account @@ -189,11 +173,11 @@ EOF kubectl apply -f ceph-admin-secret.yaml ``` -# Create RBD Testing Resources +## Create RBD Testing Resources ### Using RBD in Pods -``` +```yaml # pod cat > ceph-rbd-pod-inline.yaml << EOF apiVersion: v1 @@ -231,7 +215,7 @@ kubectl exec pod/ceph-rbd-pod-inline -- df -k | grep rbd ### Using RBD in Persistent Volumes -``` +```yaml # pod-pvc-pv cat > ceph-rbd-pod-pvc-pv-allinone.yaml << EOF apiVersion: v1 @@ -294,7 +278,7 @@ kubectl exec pod/ceph-rbd-pod-pvc-pv -- df -k | grep rbd This example is for dynamic provisioning. The ceph-csi driver is needed. -``` +```yaml # pod-pvc-sc cat > ceph-rbd-pod-pvc-sc-allinone.yaml < Cluster Management**. Then on the **Clusters** page, click **Import Existing**. Then run the provided kubectl command on the server/master node. -# Tested Versions +## Tested Versions OS for running RKE2 nodes: JeOS SLE15-SP2 with installed kernel-default-5.3.18-24.49 @@ -401,7 +385,7 @@ version.BuildInfo{Version:"3.4.1", GitCommit:"c4e74854886b2efe3321e185578e6db9be Kubernetes version on RKE2 cluster: v1.19.7+rke2r1 -# Troubleshooting +## Troubleshooting In case you are using SUSE's ceph-rook based on SES7, it might be useful to expose the monitors on hostNetwork by editing `rook-1.4.5/ceph/cluster.yaml` and setting `spec.network.hostNetwork=true`. diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md index a4c2baf99e9..8c2b4abe82c 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md @@ -7,11 +7,6 @@ To provide stateful workloads with vSphere storage, we recommend creating a vSph In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](../../../../../pages-for-subheaders/vsphere-cloud-provider.md) -- [Prerequisites](#prerequisites) -- [Creating a StorageClass](#creating-a-storageclass) -- [Creating a Workload with a vSphere Volume](#creating-a-workload-with-a-vsphere-volume) -- [Verifying Persistence of the Volume](#verifying-persistence-of-the-volume) -- [Why to Use StatefulSets Instead of Deployments](#why-to-use-statefulsets-instead-of-deployments) ### Prerequisites diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md index e46b38e4da6..3c0b9d1e19a 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md @@ -7,18 +7,8 @@ This guide will show you how to install and use [Kubernetes cluster-autoscaler]( We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`. -- [Prerequisites](#prerequisites) -- [1. Create a Custom Cluster](#1-create-a-custom-cluster) -- [2. Configure the Cloud Provider](#2-configure-the-cloud-provider) -- [3. Deploy Nodes](#3-deploy-nodes) -- [4. Install cluster-autoscaler](#4-install-cluster-autoscaler) - - [Parameters](#parameters) - - [Deployment](#deployment) -- [Testing](#testing) - - [Generating Load](#generating-load) - - [Checking Scale](#checking-scale) -# Prerequisites +## Prerequisites These elements are required to follow this guide: diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md index 2e3e5b3b0d4..0e7c221ad5c 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md @@ -11,26 +11,8 @@ If you want to manage the _cluster_ and not individual nodes, see [Editing Clust ::: -This section covers the following topics: -- [Node options available for each cluster creation option](#node-options-available-for-each-cluster-creation-option) - - [Nodes hosted by an infrastructure provider](#nodes-hosted-by-an-infrastructure-provider) - - [Nodes provisioned by hosted Kubernetes providers](#nodes-provisioned-by-hosted-kubernetes-providers) - - [Registered nodes](#registered-nodes) -- [Managing and editing individual nodes](#managing-and-editing-individual-nodes) -- [Viewing a node in the Rancher API](#viewing-a-node-in-the-rancher-api) -- [Deleting a node](#deleting-a-node) -- [Scaling nodes](#scaling-nodes) -- [SSH into a node hosted by an infrastructure provider](#ssh-into-a-node-hosted-by-an-infrastructure-provider) -- [Cordoning a node](#cordoning-a-node) -- [Draining a node](#draining-a-node) - - [Aggressive and safe draining options](#aggressive-and-safe-draining-options) - - [Grace period](#grace-period) - - [Timeout](#timeout) - - [Drained and cordoned state](#drained-and-cordoned-state) -- [Labeling a node to be ignored by Rancher](#labeling-a-node-to-be-ignored-by-rancher) - -# Node Options Available for Each Cluster Creation Option +## Node Options Available for Each Cluster Creation Option The following table lists which node options are available for each type of cluster in Rancher. Click the links in the **Option** column for more detailed information about each feature. @@ -71,7 +53,7 @@ Options for managing nodes [hosted by a Kubernetes provider](../../../pages-for- Although you can deploy workloads to a [registered cluster](../../new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md) using Rancher, you cannot manage individual cluster nodes. All management of imported cluster nodes must take place outside of Rancher. -# Managing and Editing Individual Nodes +## Managing and Editing Individual Nodes Editing a node lets you: @@ -82,11 +64,11 @@ Editing a node lets you: To manage individual nodes, browse to the cluster that you want to manage and then select **Nodes** from the main menu. You can open the options menu for a node by clicking its **⋮** icon (**..**.). -# Viewing a Node in the Rancher API +## Viewing a Node in the Rancher API Select this option to view the node's [API endpoints](../../../pages-for-subheaders/about-the-api.md). -# Deleting a Node +## Deleting a Node Use **Delete** to remove defective nodes from the cloud provider. @@ -98,11 +80,11 @@ If your cluster is hosted by an infrastructure provider, and you want to scale y ::: -# Scaling Nodes +## Scaling Nodes For nodes hosted by an infrastructure provider, you can scale the number of nodes in each [node pool](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md#node-pools) by using the scale controls. This option isn't available for other cluster types. -# SSH into a Node Hosted by an Infrastructure Provider +## SSH into a Node Hosted by an Infrastructure Provider For [nodes hosted by an infrastructure provider](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md), you have the option of downloading its SSH key so that you can connect to it remotely from your desktop. @@ -117,11 +99,11 @@ For [nodes hosted by an infrastructure provider](../../../pages-for-subheaders/u ssh -i id_rsa root@ ``` -# Cordoning a Node +## Cordoning a Node _Cordoning_ a node marks it as unschedulable. This feature is useful for performing short tasks on the node during small maintenance windows, like reboots, upgrades, or decommissions. When you're done, power back on and make the node schedulable again by uncordoning it. -# Draining a Node +## Draining a Node _Draining_ is the process of first cordoning the node, and then evicting all its pods. This feature is useful for performing node maintenance (like kernel upgrades or hardware maintenance). It prevents new pods from deploying to the node while redistributing existing pods so that users don't experience service interruption. @@ -170,7 +152,7 @@ Once drain successfully completes, the node will be in a state of `drained`. You **Want to know more about cordon and drain?** See the [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#maintenance-on-a-node). -# Labeling a Node to be Ignored by Rancher +## Labeling a Node to be Ignored by Rancher Some solutions, such as F5's BIG-IP integration, may require creating a node that is never registered to a cluster. diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md index 8ca8666898c..b822932a9de 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md @@ -14,18 +14,9 @@ As of Rancher v2.6, projects are de-emphasized on the UI because it is no longer ::: -This section describes how projects and namespaces work with Rancher. It covers the following topics: +This section describes how projects and namespaces work with Rancher. -- [About namespaces](#about-namespaces) -- [About projects](#about-projects) - - [The cluster's default project](#the-cluster-s-default-project) - - [The system project](#the-system-project) -- [Project authorization](#project-authorization) -- [Pod security policies](#pod-security-policies) -- [Creating projects](#creating-projects) -- [Switching between clusters and projects](#switching-between-clusters-and-projects) - -# About Namespaces +## About Namespaces A namespace is a concept introduced by Kubernetes. According to the [official Kubernetes documentation on namespaces,](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) @@ -67,7 +58,7 @@ If your permissions are restricted to the project level, it is better to [create If a standard user is a project owner, the user will be able to create namespaces within that project. The Rancher UI will prevent that user from creating namespaces outside the scope of the projects they have access to. -# About Projects +## About Projects In terms of hierarchy: @@ -117,18 +108,18 @@ In RKE clusters where the project network isolation option is enabled, the `syst ::: -# Project Authorization +## Project Authorization Standard users are only authorized for project access in two situations: - An administrator, cluster owner or cluster member explicitly adds the standard user to the project's **Members** tab. - Standard users can access projects that they create themselves. -# Pod Security Policies +## Pod Security Policies Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the project level in addition to the cluster level. However, as a best practice, we recommend applying Pod Security Policies at the cluster level. -# Creating Projects +## Creating Projects This section describes how to create a new project with a name and with optional pod security policy, members, and resource quotas. diff --git a/docs/how-to-guides/advanced-user-guides/manage-clusters/rotate-encryption-key.md b/docs/how-to-guides/advanced-user-guides/manage-clusters/rotate-encryption-key.md index 51a69ff3661..f2507a7d243 100644 --- a/docs/how-to-guides/advanced-user-guides/manage-clusters/rotate-encryption-key.md +++ b/docs/how-to-guides/advanced-user-guides/manage-clusters/rotate-encryption-key.md @@ -13,7 +13,7 @@ weight: 2043 - OR, apply the following YAML: - ``` + ```yaml rancher_kubernetes_engine_config: services: kube_api: diff --git a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md index 76478d44f7f..ad178cfa58a 100644 --- a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md +++ b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md @@ -5,16 +5,8 @@ weight: 9 If you previously enabled Monitoring, Alerting, or Notifiers in Rancher before v2.5, there is no automatic upgrade path for switching to the new monitoring/alerting solution. Before deploying the new monitoring solution via Cluster Explore, you will need to disable and remove all existing custom alerts, notifiers and monitoring installations for the whole cluster and in all projects. -- [Monitoring Before Rancher v2.5](#monitoring-before-rancher-v2-5) -- [Monitoring and Alerting via Cluster Explorer in Rancher v2.5](#monitoring-and-alerting-via-cluster-explorer-in-rancher-v2-5) -- [Changes to Role-based Access Control](#changes-to-role-based-access-control) -- [Migrating from Monitoring V1 to Monitoring V2](#migrating-from-monitoring-v1-to-monitoring-v2) - - [Migrating Grafana Dashboards](#migrating-grafana-dashboards) - - [Migrating Alerts](#migrating-alerts) - - [Migrating Notifiers](#migrating-notifiers) - - [Migrating for RKE Template Users](#migrating-for-rke-template-users) -# Monitoring Before Rancher v2.5 +## Monitoring Before Rancher v2.5 As of v2.2.0, the global view in the legacy Rancher UI allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster. @@ -24,7 +16,7 @@ Monitoring V1 could be configured on both a cluster-level and on a project-level When Alerts or Notifiers are enabled, Alerting V1 deploys [Prometheus Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) and a set of Rancher controllers onto a cluster that allows users to define alerts and configure alert-based notifications via Email, Slack, PagerDuty, etc. Users can choose to create different types of alerts depending on what needs to be monitored (e.g. System Services, Resources, CIS Scans, etc.); however, PromQL Expression-based alerts can only be created if Monitoring V1 is enabled. -# Monitoring and Alerting via Cluster Explorer in Rancher 2.5 +## Monitoring and Alerting via Cluster Explorer in Rancher 2.5 As of v2.5.0, Rancher's Cluster Explorer now allows users to enable Monitoring & Alerting V2 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) together within a cluster. @@ -34,13 +26,13 @@ Monitoring V2 can only be configured on the cluster level. Project-level monitor For more information on how to configure Monitoring & Alerting V2, see [this page.](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md) -# Changes to Role-based Access Control +## Changes to Role-based Access Control Project owners and members no longer get access to Grafana or Prometheus by default. If view-only users had access to Grafana, they would be able to see data from any namespace. For Kiali, any user can edit things they don’t own in any namespace. For more information about role-based access control in `rancher-monitoring`, refer to [this page.](../../../explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md) -# Migrating from Monitoring V1 to Monitoring V2 +## Migrating from Monitoring V1 to Monitoring V2 While there is no automatic migration available, it is possible to manually migrate custom Grafana dashboards and alerts that were created in Monitoring V1 to Monitoring V2. diff --git a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/enable-prometheus-federator.md b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/enable-prometheus-federator.md index a07e1f268d0..8db8b9c1801 100644 --- a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/enable-prometheus-federator.md +++ b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/enable-prometheus-federator.md @@ -3,10 +3,8 @@ title: Enable Prometheus Federator weight: 1 --- -- [Requirements](#requirements) -- [Install the Prometheus Federator Application](#install-the-prometheus-federator-application) -# Requirements +## Requirements By default, Prometheus Federator is configured and intended to be deployed alongside [rancher-monitoring](https://rancher.com/docs/rancher/v2.6/en/monitoring-alerting/), which deploys Prometheus Operator alongside a Cluster Prometheus that each Project Monitoring Stack is configured to federate namespace-scoped metrics from by default. @@ -18,7 +16,7 @@ The default configuration should already be compatible with your rancher-monitor - [Configure rancher-monitoring to only watch for resources created by the Helm chart itself](#configure-rancher-monitoring-to-only-watch-for-resources-created-by-the-helm-chart-itself). - [Increase the CPU / memory limits of the Cluster Prometheus](#increase-the-cpu--memory-limits-of-the-cluster-prometheus). -## Ensure the cattle-monitoring-system namespace is placed into the System Project (or a similarly locked down Project that has access to other Projects in the cluster) +### Ensure the cattle-monitoring-system namespace is placed into the System Project (or a similarly locked down Project that has access to other Projects in the cluster) ![Select Projects-Namespaces](/img/install-in-system-project.png) @@ -37,7 +35,7 @@ Prometheus Operator's security model expects that the namespace it is deployed i ![Move to a New Project](/img/move-to-new-project.png) -## Configure rancher-monitoring to only watch for resources created by the Helm chart itself +### Configure rancher-monitoring to only watch for resources created by the Helm chart itself Since each Project Monitoring Stack will watch the other namespaces and collect additional custom workload metrics or dashboards already, it's recommended to configure the following settings on all selectors to ensure that the Cluster Prometheus Stack only monitors resources created by the Helm Chart itself: @@ -61,7 +59,7 @@ If you don't want to allow users to be able to create ServiceMonitors and PodMon ::: -## Increase the CPU / memory limits of the Cluster Prometheus +### Increase the CPU / memory limits of the Cluster Prometheus Depending on a cluster's setup, it's generally recommended to give a large amount of dedicated memory to the Cluster Prometheus to avoid restarts due to out-of-memory errors (OOMKilled) usually caused by churn created in the cluster that causes a large number of high cardinality metrics to be generated and ingested by Prometheus within one block of time. This is one of the reasons why the default Rancher Monitoring stack expects around 4GB of RAM to be able to operate in a normal-sized cluster. However, when introducing Project Monitoring Stacks that are all sending `/federate` requests to the same Cluster Prometheus and are reliant on the Cluster Prometheus being "up" to federate that system data on their namespaces, it's even more important that the Cluster Prometheus has an ample amount of CPU / memory assigned to it to prevent an outage that can cause data gaps across all Project Prometheis in the cluster. @@ -71,7 +69,7 @@ There are no specific recommendations on how much memory the Cluster Prometheus ::: -# Install the Prometheus Federator Application +## Install the Prometheus Federator Application 1. Click **☰ > Cluster Management**. 1. Go to the cluster that you want to install Prometheus Federator and click **Explore**. diff --git a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/set-up-workloads.md b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/set-up-workloads.md index 014724b3b7d..d4c5fcb384a 100644 --- a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/set-up-workloads.md +++ b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/prometheus-federator-guides/set-up-workloads.md @@ -3,9 +3,6 @@ title: Setting up Prometheus Federator for a Workload weight: 4 --- -- [Display CPU and Memory Metrics for a Workload](#display-cpu-and-memory-metrics-for-a-workload) -- [Setting up Metrics Beyond CPU and Memory](#setting-up-metrics-beyond-cpu-and-memory) - ### Display CPU and Memory Metrics for a Workload diff --git a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md index 10de8484a9a..7c7c4e999a6 100644 --- a/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md +++ b/docs/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md @@ -3,8 +3,6 @@ title: Setting up Monitoring for a Workload weight: 4 --- -- [Display CPU and Memory Metrics for a Workload](#display-cpu-and-memory-metrics-for-a-workload) -- [Setting up Metrics Beyond CPU and Memory](#setting-up-metrics-beyond-cpu-and-memory) If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default. diff --git a/docs/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md b/docs/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md index c532bee5600..5c610745d13 100644 --- a/docs/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md +++ b/docs/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md @@ -13,7 +13,7 @@ This section assumes familiarity with how monitoring components work together. F ::: -# About the Alertmanager Custom Resource +## About the Alertmanager Custom Resource By default, Rancher Monitoring deploys a single Alertmanager onto a cluster that uses a default Alertmanager Config Secret. diff --git a/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md b/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md index 94774115f1c..c46f953fe1c 100644 --- a/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md +++ b/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md @@ -9,20 +9,6 @@ Rancher recommends configuring recurrent `etcd` snapshots for all production clu Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster. -This section covers the following topics: - -- [How snapshots work](#how-snapshots-work) -- [Configuring recurring snapshots](#configuring-recurring-snapshots) -- [One-time snapshots](#one-time-snapshots) -- [Snapshot backup targets](#snapshot-backup-targets) - - [Local backup target](#local-backup-target) - - [S3 backup target](#s3-backup-target) - - [Using a custom CA certificate for S3](#using-a-custom-ca-certificate-for-s3) - - [IAM Support for storing snapshots in S3](#iam-support-for-storing-snapshots-in-s3) -- [Viewing available snapshots](#viewing-available-snapshots) -- [Safe timestamps](#safe-timestamps) -- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0) - # How Snapshots Work ### Snapshot Components diff --git a/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md b/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md index dc28c051d1f..6ced2eee31f 100644 --- a/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md +++ b/docs/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md @@ -9,13 +9,6 @@ Rancher recommends enabling the [ability to set up recurring snapshots of etcd]( Clusters can also be restored to a prior Kubernetes version and cluster configuration. -This section covers the following topics: - -- [Viewing Available Snapshots](#viewing-available-snapshots) -- [Restoring a Cluster from a Snapshot](#restoring-a-cluster-from-a-snapshot) -- [Recovering etcd without a Snapshot](#recovering-etcd-without-a-snapshot) -- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0) - ## Viewing Available Snapshots The list of all available snapshots for the cluster is available. diff --git a/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md b/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md index 770773157d8..e23bed7bd13 100644 --- a/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md +++ b/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md @@ -7,20 +7,12 @@ Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm. -- [Architecture](#architecture) -- [Accessing Fleet in the Rancher UI](#accessing-fleet-in-the-rancher-ui) -- [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 +## Architecture For information about how Fleet works, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/architecture.md) -# Accessing Fleet in the Rancher UI +## Accessing Fleet in the Rancher UI 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/). @@ -41,27 +33,27 @@ Follow the steps below to access Continuous Delivery in the Rancher UI: 1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI. -# Windows Support +## Windows Support For details on support for clusters with Windows nodes, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md) -# GitHub Repository +## GitHub Repository The Fleet Helm charts are available [here.](https://github.com/rancher/fleet/releases/latest) -# Using Fleet Behind a Proxy +## Using Fleet Behind a Proxy For details on using Fleet behind a proxy, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md) -# Helm Chart Dependencies +## 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 +## Troubleshooting --- * **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator](../backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. @@ -71,6 +63,6 @@ By default, user-defined secrets are not backed up in Fleet. It is necessary to --- -# Documentation +## Documentation The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/) diff --git a/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md b/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md index 3911d56a63a..0660b9b781e 100644 --- a/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md +++ b/docs/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md @@ -11,22 +11,7 @@ Any Helm charts from a global catalog can be used to deploy and manage multi-clu After creating a multi-cluster application, you can program a global DNS entry to make it easier to access the application. -- [Prerequisites](#prerequisites) -- [Launching a multi-cluster app](#launching-a-multi-cluster-app) -- [Multi-cluster app configuration options](#multi-cluster-app-configuration-options) - - [Targets](#targets) - - [Upgrades](#upgrades) - - [Roles](#roles) -- [Application configuration options](#application-configuration-options) - - [Using a questions.yml file](#using-a-questions-yml-file) - - [Key value pairs for native Helm charts](#key-value-pairs-for-native-helm-charts) - - [Members](#members) - - [Overriding application configuration options for specific projects](#overriding-application-configuration-options-for-specific-projects) -- [Upgrading multi-cluster app roles and projects](#upgrading-multi-cluster-app-roles-and-projects) -- [Multi-cluster application management](#multi-cluster-application-management) -- [Deleting a multi-cluster application](#deleting-a-multi-cluster-application) - -# Prerequisites +## Prerequisites ### Permissions @@ -43,7 +28,7 @@ Because multi-cluster apps were deprecated and replaced with Fleet in Rancher v2 1. Click **Feature Flags**. 1. Go to the `legacy` feature flag and click **Activate**. -# Launching a Multi-Cluster App +## Launching a Multi-Cluster App 1. In the upper left corner, click **☰ > Multi-cluster Apps**. 1. Click **Launch**. @@ -58,7 +43,7 @@ Because multi-cluster apps were deprecated and replaced with Fleet in Rancher v2 **Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's: -# Multi-cluster App Configuration Options +## Multi-cluster App Configuration Options Rancher has divided the configuration option for the multi-cluster application into several sections. @@ -94,7 +79,7 @@ There are some applications like _Grafana_ or _Datadog_ that require access to s ::: -# Application Configuration Options +## Application Configuration Options For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm. @@ -146,7 +131,7 @@ The ability to use the same configuration to deploy the same application across - **Answer**: Enter the answer that you want to be used instead. -# Upgrading Multi-Cluster App Roles and Projects +## Upgrading Multi-Cluster App Roles and Projects - **Changing Roles on an existing Multi-Cluster app** The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`. @@ -156,7 +141,7 @@ The creator and any users added with the access-type "owner" to a multi-cluster 2. We do not do these membership checks when removing target projects. This is because the caller's permissions could have with respect to the target project, or the project could have been deleted and hence the caller wants to remove it from targets list. -# Multi-Cluster Application Management +## Multi-Cluster Application Management One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back. @@ -174,7 +159,7 @@ The `legacy` feature flag needs to be enabled. * **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrades) can be modified if you have the correct [access type](#members). * **Rollback**: Rollback your application to a specific version. If after an upgrade, there are issues for your multi-cluster application for one or more of your [targets](#targets), Rancher has stored up to 10 versions of the multi-cluster application. Rolling back a multi-cluster application reverts the application for **all** target clusters and projects, not just the targets(s) affected by the upgrade issue. -# Deleting a Multi-Cluster Application +## Deleting a Multi-Cluster Application :::note Prerequisite: diff --git a/docs/how-to-guides/new-user-guides/helm-charts-in-rancher/create-apps.md b/docs/how-to-guides/new-user-guides/helm-charts-in-rancher/create-apps.md index a5c38f42068..bcb4bf1e198 100644 --- a/docs/how-to-guides/new-user-guides/helm-charts-in-rancher/create-apps.md +++ b/docs/how-to-guides/new-user-guides/helm-charts-in-rancher/create-apps.md @@ -11,15 +11,7 @@ For a complete walkthrough of developing charts, see the [Chart Template Develop ::: -- [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 diff --git a/docs/how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md b/docs/how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md index 7a89f169b8f..3736d52409b 100644 --- a/docs/how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md +++ b/docs/how-to-guides/new-user-guides/infrastructure-setup/amazon-elb-load-balancer.md @@ -11,20 +11,13 @@ This tutorial is about one possible way to set up your load balancer, not the on Rancher only supports using the Amazon NLB when terminating traffic in `tcp` mode for port 443 rather than `tls` mode. This is due to the fact that the NLB does not inject the correct headers into requests when terminated at the NLB. This means that if you want to use certificates managed by the Amazon Certificate Manager (ACM), you should use an ALB. -# Setting up the Load Balancer -Configuring an Amazon NLB is a multistage process: -1. [Create Target Groups](#1-create-target-groups) -2. [Register Targets](#2-register-targets) -3. [Create Your NLB](#3-create-your-nlb) -4. [Add listener to NLB for TCP port 80](#4-add-listener-to-nlb-for-tcp-port-80) - -# Requirements +## Requirements These instructions assume you have already created Linux instances in EC2. The load balancer will direct traffic to these nodes. -# 1. Create Target Groups +## 1. Create Target Groups Begin by creating two target groups for the **TCP** protocol, one with TCP port 443 and one regarding TCP port 80 (providing redirect to TCP port 443). You'll add your Linux nodes to these groups. @@ -42,7 +35,7 @@ Health checks are handled differently based on the Ingress. For details, refer t ::: -### Target Group (TCP port 443) +#### Target Group (TCP port 443) Configure the first target group according to the table below. @@ -67,7 +60,7 @@ Health check settings: Click **Create target group** to create the second target group, regarding TCP port 80. -### Target Group (TCP port 80) +#### Target Group (TCP port 80) Configure the second target group according to the table below. @@ -91,7 +84,7 @@ Health check settings: | Timeout | `6 seconds` | | Interval | `10 seconds` | -# 2. Register Targets +## 2. Register Targets Next, add your Linux nodes to both target groups. @@ -115,7 +108,7 @@ When the instances are added, click **Save** on the bottom right of the screen. Repeat those steps, replacing **rancher-tcp-443** with **rancher-tcp-80**. The same instances need to be added as targets to this target group. -# 3. Create Your NLB +## 3. Create Your NLB Use Amazon's Wizard to create a Network Load Balancer. As part of this process, you'll add the target groups you created in [1. Create Target Groups](#1-create-target-groups). diff --git a/docs/how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md b/docs/how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md index 376df4d2ad1..85b46eef9cf 100644 --- a/docs/how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md +++ b/docs/how-to-guides/new-user-guides/infrastructure-setup/ha-rke2-kubernetes-cluster.md @@ -11,7 +11,7 @@ The recommended infrastructure for the Rancher-only Kubernetes cluster differs d These nodes must be in the same region. You may place these servers in separate availability zones (datacenter). -:: +::: To install the Rancher management server on a high-availability RKE2 cluster, we recommend setting up the following infrastructure: diff --git a/docs/how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md b/docs/how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md index 6486c2d8b1b..9edf3b610c2 100644 --- a/docs/how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md +++ b/docs/how-to-guides/new-user-guides/infrastructure-setup/nginx-load-balancer.md @@ -36,6 +36,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx. :::
Example NGINX config
+ ``` worker_processes 4; worker_rlimit_nofile 40000; diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md index bbb9851ed5b..4efca77715d 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md @@ -5,7 +5,7 @@ weight: 1 There are three roles that can be assigned to nodes: `etcd`, `controlplane` and `worker`. -# Separating Worker Nodes from Nodes with Other Roles +## Separating Worker Nodes from Nodes with Other Roles When designing your cluster(s), you have two options: @@ -21,7 +21,7 @@ Therefore, each node should have one of the following role configurations: * Both `etcd` and `controlplane` * `worker` -# Recommended Number of Nodes with Each Role +## Recommended Number of Nodes with Each Role The cluster should have: @@ -69,6 +69,6 @@ You may have noticed that our [Kubernetes Install](../../../../pages-for-subhead * It maintains multiple instances of the master components by having multiple `controlplane` nodes. * No other workloads than Rancher itself should be created on this cluster. -# References +## References * [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components) diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/roles-for-nodes-in-kubernetes.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/roles-for-nodes-in-kubernetes.md index f0f3b877034..6b1d3c2ba46 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/roles-for-nodes-in-kubernetes.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/roles-for-nodes-in-kubernetes.md @@ -10,7 +10,7 @@ This diagram is applicable to Kubernetes clusters [launched with Rancher using R ![Cluster diagram](/img/clusterdiagram.svg)
Lines show the traffic flow between components. Colors are used purely for visual aid -# etcd +## etcd Nodes with the `etcd` role run etcd, which is a consistent and highly available key value store used as Kubernetes’ backing store for all cluster data. etcd replicates the data to each node. @@ -20,7 +20,7 @@ Nodes with the `etcd` role are shown as `Unschedulable` in the UI, meaning no po ::: -# controlplane +## controlplane Nodes with the `controlplane` role run the Kubernetes master components (excluding `etcd`, as it's a separate role). See [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components) for a detailed list of components. @@ -42,10 +42,10 @@ The Kubernetes controller manager uses leader election using an endpoint in Kube The Kubernetes scheduler uses leader election using an endpoint in Kubernetes. One instance of the `kube-scheduler` will create an entry in the Kubernetes endpoints and updates that entry in a configured interval. Other instances will see an active leader and wait for that entry to expire (for example, when a node is unresponsive). -# worker +## worker Nodes with the `worker` role run the Kubernetes node components. See [Kubernetes: Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for a detailed list of components. -# References +## References * [Kubernetes: Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components) \ No newline at end of file diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md index e6492ecb295..86c5c6b7c13 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md @@ -18,7 +18,7 @@ If you are using Calico, 1. Click **☰ > Cluster Management**. 1. On the **Clusters** page, go to the custom cluster and click **⋮ > Edit YAML.* Enter the following configuration: - ``` + ```yaml rancher_kubernetes_engine_config: cloud_provider: name: gce @@ -40,7 +40,7 @@ If you are using Canal or Flannel, 1. Click **☰ > Cluster Management**. 1. On the **Clusters** page, go to the custom cluster and click **⋮ > Edit YAML.* Enter the following configuration: - ``` + ```yaml rancher_kubernetes_engine_config: cloud_provider: name: gce diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/create-a-vm-template.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/create-a-vm-template.md index d718f33253b..f9b1ec302e8 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/create-a-vm-template.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/create-a-vm-template.md @@ -7,14 +7,8 @@ Creating virtual machines in a repeatable and reliable fashion can often be diff In order to leverage the template to create new VMs, Rancher has some [specific requirements](#requirements) that the VM must have pre-installed. After you configure the VM with these requirements, you will next need to [prepare the VM](#preparing-your-vm) before [creating the template](#creating-a-template). Finally, once preparation is complete, the VM can be [converted to a template](#converting-to-a-template) and [moved into a content library](#moving-to-a-content-library), ready for Rancher node pool usage. -- [Requirements](#requirements) -- [Creating a Template](#creating-a-template) -- [Preparing Your VM](#preparing-your-vm) -- [Converting to a Template](#converting-to-a-template) -- [Moving to a content library](#moving-to-a-content-library) -- [Other Resources](#other-resources) -# Requirements +## Requirements There is specific tooling required for both Linux and Windows VMs to be usable by the vSphere node driver. The most critical dependency is [cloud-init](https://cloud-init.io/) for Linux and [cloudbase-init](https://cloudbase.it/cloudbase-init/) for Windows. Both of these are used for provisioning the VMs by configuring the hostname and by setting up the SSH access and the default Rancher user. Users can add additional content to these as desired if other configuration is needed. In addition, other requirements are listed below for reference. @@ -59,16 +53,16 @@ The list of packages that need to be installed on the template is as follows: ::: -# Creating a Template +## Creating a Template You may either manually create your VM or you can utilize [other alternatives](#alternatives-to-manual-creation) to create your VM. -## Manual Creation +### Manual Creation 1. Manually create your VM by following [these instructions](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-AE8AFBF1-75D1-4172-988C-378C35C9FAF2.html) from VMware. Once you have a VM running, you can manually install the dependencies listed above to configure the VM correctly for the vSphere node driver. 2. Customize as needed based on your specific environment and requirements. 3. Proceed with the final preparation before creating your template. -## Alternatives to Manual Creation +### Alternatives to Manual Creation Other alternative options to create VMs are listed below: @@ -79,17 +73,17 @@ Other alternative options to create VMs are listed below: Packer is a frequently-used alternative. Refer to this [reference](https://github.com/vmware-samples/packer-examples-for-vsphere) for examples of its usage with vSphere. -# Preparing Your VM +## Preparing Your VM After creating a VM with all the required dependencies (and any additional required items), you must perform the most critical step next: preparing the VM to be turned into a template. This preparation will reset critical data such as the VM hostname, IPs, etc., to prevent that information from being brought into a new VM. If you fail to perform this step, you could create a VM with the same hostname, IP address, etc. Note that these preparatory steps differ between Linux and Windows. -## Linux Preparation +### Linux Preparation The commands below will reset your VM in Linux: -```Bash +```bash # Cleaning logs. if [ -f /var/log/audit/audit.log ]; then cat /dev/null > /var/log/audit/audit.log @@ -132,7 +126,7 @@ hostnamectl set-hostname localhost cloud-init clean -s -l ``` -## Windows Preparation +### Windows Preparation Windows has a utility called [sysprep](https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation) that is used to generalize an image and reset the same items listed above for Linux. The command is as follows: @@ -140,7 +134,7 @@ Windows has a utility called [sysprep](https://docs.microsoft.com/en-us/windows- sysprep.exe /generalize /shutdown /oobe ``` -# Converting to a Template +## Converting to a Template 1. Shut down and stop the VM. 2. Right-click on the VM in the inventory list and select **Template**. @@ -150,7 +144,7 @@ sysprep.exe /generalize /shutdown /oobe For additional information on converting a VM to a template, see the [VMware guide](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-5B3737CC-28DB-4334-BD18-6E12011CDC9F.html). -# Moving to a Content library +## Moving to a Content library Rancher has the ability to use templates provided by a content library. Content libraries store and manage content within vSphere, and they also offer the ability to publish and share that content. @@ -159,7 +153,7 @@ Below are some helpful links on content libraries: * [Create a content library](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-2A0F1C13-7336-45CE-B211-610D39A6E1F4.html) * [Clone the template to the content library](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-AC1545F0-F8BA-4CD2-96EB-21B3DFAA1DC1.html) -# Other Resources +## Other Resources Here is a list of additional resources that may be useful: diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index fad3045398c..e71e8198bb0 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -47,7 +47,7 @@ The free ESXi license does not support API access. The vSphere servers must have If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes. -# Creating a vSphere Cluster +## Creating a vSphere Cluster The a vSphere cluster is created in Rancher depends on the Rancher version. @@ -104,7 +104,7 @@ You can access your cluster after its state is updated to **Active**. - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Optional Next Steps +## Optional Next Steps After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster: diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/azure-storageclass-configuration.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/azure-storageclass-configuration.md index 770ee0d9e77..68059088a60 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/azure-storageclass-configuration.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/azure-storageclass-configuration.md @@ -10,29 +10,30 @@ In order to have the Azure platform create the required storage resources, follo 1. [Configure the Azure cloud provider.](../set-up-cloud-providers/other-cloud-providers/azure.md) 1. Configure `kubectl` to connect to your cluster. 1. Copy the `ClusterRole` and `ClusterRoleBinding` manifest for the service account: - - --- - apiVersion: rbac.authorization.k8s.io/v1 + ```yml + --- + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRole + metadata: + name: system:azure-cloud-provider + rules: + - apiGroups: [''] + resources: ['secrets'] + verbs: ['get','create'] + --- + apiVersion: rbac.authorization.k8s.io/v1 + kind: ClusterRoleBinding + metadata: + name: system:azure-cloud-provider + roleRef: kind: ClusterRole - metadata: - name: system:azure-cloud-provider - rules: - - apiGroups: [''] - resources: ['secrets'] - verbs: ['get','create'] - --- - apiVersion: rbac.authorization.k8s.io/v1 - kind: ClusterRoleBinding - metadata: - name: system:azure-cloud-provider - roleRef: - kind: ClusterRole - apiGroup: rbac.authorization.k8s.io - name: system:azure-cloud-provider - subjects: - - kind: ServiceAccount - name: persistent-volume-binder - namespace: kube-system + apiGroup: rbac.authorization.k8s.io + name: system:azure-cloud-provider + subjects: + - kind: ServiceAccount + name: persistent-volume-binder + namespace: kube-system + ``` 1. Create these in your cluster using one of the follow command. diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/workload-migration-guidance.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/workload-migration-guidance.md index dc85c0c2e8b..7dd2ea80e90 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/workload-migration-guidance.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/workload-migration-guidance.md @@ -7,23 +7,6 @@ weight: 3 This document covers how end users can migrate their Windows workloads from RKE1 to RKE2. -- [RKE1 Windows Scheduling](#rke1-windows-scheduling) -- [RKE2 Windows Scheduling](#rke2-windows-scheduling) -- [Example Migrations](#example-migrations) - - [RKE1 to RKE2 Windows Workload](#rke1-to-rke2-windows-workload) - - [RKE1 Windows Cluster Linux-Only Deployment](#rke1-windows-cluster-linux-only-deployment) -- [RKE1 Windows-Supported Windows Server Versions](#rke1-windows-supported-windows-server-versions) - - [Long-Term Servicing Channel (LTSC)](#long-term-servicing-channel-ltsc) - - [Semi-Annual Channel (SAC)](#semi-annual-channel-sac) -- [RKE2 Windows-Supported Windows Server Versions](#rke2-windows-supported-windows-server-versions) - - [Long-Term Servicing Channel in RKE2](#long-term-servicing-channel-in-rke2) -- [Kubernetes Version Support](#kubernetes-version-support) - - [Rancher 2.5 vs. Rancher 2.6 Support Matrix for Windows Clusters](#rancher-2-5-vs-rancher-2-6-support-matrix-for-windows-clusters) - - [Rancher 2.5 vs. Rancher 2.6 Supported Kubernetes Versions for Provisioning RKE1 and RKE2 Windows Clusters](#rancher-2-5-vs-rancher-2-6-supported-kubernetes-versions-for-provisioning-rke1-and-rke2-windows-clusters) -- [Guiding Migrations of Workloads to RKE2 Windows](#guiding-migrations-of-workloads-to-rke2-windows) - - [In-Place Upgrade of Rancher 2.5](#in-place-upgrade-of-rancher-2-5) - - [Migrating Windows Workloads to a new Rancher environment](#migrating-windows-workloads-to-a-new-rancher-environment) - ## RKE1 Windows Scheduling RKE1 Windows workload scheduling is based on taints and tolerations. diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md index fbd72e3ceac..6b5059a307c 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md @@ -14,14 +14,7 @@ If Rancher is installed on a high-availability Kubernetes cluster, the Rancher s ::: -Make sure the nodes for the Rancher server fulfill the following requirements: - -- [Operating systems and container runtime requirements](#operating-systems-and-container-runtime-requirements) -- [Hardware Requirements](#hardware-requirements) -- [Networking Requirements](#networking-requirements) -- [Optional: Security Considerations](#optional-security-considerations) - -# Operating Systems and Container Runtime Requirements +## Operating Systems and Container Runtime Requirements Rancher should work with any modern Linux distribution and any modern Docker version. Linux is required for the etcd and controlplane nodes of all downstream clusters. Worker nodes may run Linux or [Windows Server.](#windows-nodes) @@ -107,7 +100,7 @@ Nodes with Windows Server must run Docker Enterprise Edition. Windows nodes can be used for worker nodes only. See [Configuring Custom Clusters for Windows](../../../pages-for-subheaders/use-windows-clusters.md) -# Hardware Requirements +## Hardware Requirements 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. @@ -117,7 +110,7 @@ For hardware recommendations for large Kubernetes clusters, refer to the officia For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/) -# Networking Requirements +## Networking Requirements For a production cluster, we recommend that you restrict traffic by opening only the ports defined in the port requirements below. @@ -127,7 +120,7 @@ For a breakdown of the port requirements for etcd nodes, controlplane nodes, and Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#downstream-kubernetes-cluster-nodes). -# Optional: Security Considerations +## Optional: Security Considerations If you want to provision a Kubernetes cluster that is compliant with the CIS (Center for Internet Security) Kubernetes Benchmark, we recommend to following our hardening guide to configure your nodes before installing Kubernetes. diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md index beb30a0a31f..8a3a5694970 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md @@ -7,15 +7,8 @@ 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) -- [Prerequisites](#prerequisites) -- [Registering a Cluster](#registering-a-cluster) -- [Management Capabilities for Registered Clusters](#management-capabilities-for-registered-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) -- [Authorized Cluster Endpoint Support for RKE2 and K3s Clusters](#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) -- [Annotating Registered Clusters](#annotating-registered-clusters) -# Prerequisites +## Prerequisites ### Kubernetes Node Roles @@ -45,7 +38,7 @@ If you are registering a K3s cluster, make sure the `cluster.yml` is readable. I EKS clusters must have at least one managed node group to be imported into Rancher or provisioned from Rancher successfully. -# Registering a Cluster +## Registering a Cluster 1. Click **☰ > Cluster Management**. 1. On the **Clusters** page, **Import Existing**. @@ -121,7 +114,7 @@ resource "rancher2_cluster" "my-eks-to-import" { } ``` -# Management Capabilities for Registered Clusters +## Management Capabilities for Registered Clusters The control that Rancher has to manage a registered cluster depends on the type of cluster. @@ -160,7 +153,7 @@ When you delete an EKS cluster or GKE cluster that was created in Rancher, the c The capabilities for registered clusters are listed in the table on [this page.](../../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) -# Configuring K3s Cluster Upgrades +## Configuring K3s Cluster Upgrades :::tip @@ -177,7 +170,7 @@ In the K3s documentation, controlplane nodes are called server nodes. These node 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 +## 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. @@ -199,7 +192,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. -# Authorized Cluster Endpoint Support for RKE2 and K3s Clusters +## Authorized Cluster Endpoint Support for RKE2 and K3s Clusters _Available as of v2.6.3_ @@ -218,29 +211,31 @@ Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and ###### **Manual steps to be taken on the control plane of each downstream cluster to enable ACE:** 1. Create a file at `/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml` with the following contents: - - apiVersion: v1 - kind: Config - clusters: - - name: Default - cluster: - insecure-skip-tls-verify: true - server: http://127.0.0.1:6440/v1/authenticate - users: - - name: Default - user: - insecure-skip-tls-verify: true - current-context: webhook - contexts: - - name: webhook - context: - user: Default - cluster: Default + ```yaml + apiVersion: v1 + kind: Config + clusters: + - name: Default + cluster: + insecure-skip-tls-verify: true + server: http://127.0.0.1:6440/v1/authenticate + users: + - name: Default + user: + insecure-skip-tls-verify: true + current-context: webhook + contexts: + - name: webhook + context: + user: Default + cluster: Default + ``` 1. Add the following to the config file (or create one if it doesn’t exist); note that the default location is `/etc/rancher/{rke2,k3s}/config.yaml`: - - kube-apiserver-arg: - - authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml + ```yaml + kube-apiserver-arg: + - authentication-token-webhook-config-file=/var/lib/rancher/{rke2,k3s}/kube-api-authn-webhook.yaml + ``` 1. Run the following commands: @@ -249,13 +244,13 @@ Authorized Cluster Endpoint (ACE) support has been added for registered RKE2 and 1. Finally, you **must** go back to the Rancher UI and edit the imported cluster there to complete the ACE enablement. Click on **⋮ > Edit Config**, then click the **Networking** tab under Cluster Configuration. Finally, click the **Enabled** button for **Authorized Endpoint**. Once the ACE is enabled, you then have the option of entering a fully qualified domain name (FQDN) and certificate information. - :::note +:::note - The FQDN field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the CA Certificates field. +The FQDN field is optional, and if one is entered, it should point to the downstream cluster. Certificate information is only needed if there is a load balancer in front of the downstream cluster that is using an untrusted certificate. If you have a valid certificate, then nothing needs to be added to the CA Certificates field. - ::: +::: -# Annotating Registered Clusters +## 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. @@ -267,13 +262,13 @@ By annotating a registered 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, diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/aks.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/aks.md index 158193312bd..0ce23e41359 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/aks.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/aks.md @@ -6,18 +6,8 @@ weight: 2115 You can use Rancher to create a cluster hosted in Microsoft Azure Kubernetes Service (AKS). -- [Prerequisites in Microsoft Azure](#prerequisites-in-microsoft-azure) -- [Setting Up the Service Principal with the Azure Command Line Tool](#setting-up-the-service-principal-with-the-azure-command-line-tool) - - [Setting Up the Service Principal from the Azure Portal](#setting-up-the-service-principal-from-the-azure-portal) -- [1. Create the AKS Cloud Credentials](#1-create-the-aks-cloud-credentials) -- [2. Create the AKS Cluster](#2-create-the-aks-cluster) -- [Role-based Access Control](#role-based-access-control) -- [AKS Cluster Configuration Reference](#aks-cluster-configuration-reference) -- [Private Clusters](#private-clusters) -- [Syncing](#syncing) -- [Programmatically Creating AKS Clusters](#programmatically-creating-aks-clusters) -# Prerequisites in Microsoft Azure +## Prerequisites in Microsoft Azure :::caution @@ -104,7 +94,7 @@ To give role-based access to your service principal, **Result:** Your service principal now has access to AKS. -# 1. Create the AKS Cloud Credentials +## 1. Create the AKS Cloud Credentials 1. In the Rancher UI, click **☰ > Cluster Management**. 1. Click **Cloud Credentials**. @@ -113,7 +103,7 @@ To give role-based access to your service principal, 1. Fill out the form. For help with filling out the form, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md#cloud-credentials) 1. Click **Create**. -# 2. Create the AKS Cluster +## 2. Create the AKS Cluster Use Rancher to set up and configure your Kubernetes cluster. @@ -127,16 +117,16 @@ Use Rancher to set up and configure your Kubernetes cluster. You can access your cluster after its state is updated to **Active**. -# Role-based Access Control +## Role-based Access Control When provisioning an AKS cluster in the Rancher UI, RBAC is not configurable because it is required to be enabled. RBAC is required for AKS clusters that are registered or imported into Rancher. -# AKS Cluster Configuration Reference +## AKS Cluster Configuration Reference For more information about how to configure AKS clusters from the Rancher UI, see the [configuration reference.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md) -# Private Clusters +## Private Clusters Typically, AKS worker nodes do not get public IPs, regardless of whether the cluster is private. In a private cluster, the control plane does not have a public endpoint. @@ -154,12 +144,12 @@ Please be aware that when registering an existing AKS cluster, the cluster might For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster) -# Syncing +## Syncing The AKS provisioner can synchronize the state of an AKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md) For information on configuring the refresh interval, see [this section.](../../../../pages-for-subheaders/gke-cluster-configuration.md#configuring-the-refresh-interval) -# Programmatically Creating AKS Clusters +## Programmatically Creating AKS Clusters The most common way to programmatically deploy AKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster) \ No newline at end of file diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/alibaba.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/alibaba.md index 12073512976..c1bfc2751f9 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/alibaba.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/alibaba.md @@ -6,7 +6,7 @@ weight: 2120 You can use Rancher to create a cluster hosted in Alibaba Cloud Kubernetes (ACK). Rancher has already implemented and packaged the [cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for ACK, but by default, this cluster driver is `inactive`. In order to launch ACK clusters, you will need to [enable the ACK cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning ACK clusters. -# Prerequisites Outside of Rancher +## Prerequisites Outside of Rancher :::caution @@ -26,7 +26,7 @@ Deploying to ACK will incur charges. 4. In Alibaba Cloud, create an [SSH key pair](https://www.alibabacloud.com/help/doc-detail/51793.html). This key is used to access nodes in the Kubernetes cluster. -# Prerequisite in Rancher +## Prerequisite in Rancher You will need to enable the Alibaba ACK cluster driver: @@ -36,7 +36,7 @@ You will need to enable the Alibaba ACK cluster driver: When the cluster driver is finished downloading, you will be able to create Alibaba ACK clusters in Rancher. -# Create an ACK Cluster +## Create an ACK Cluster 1. Click **☰ > Cluster Management**. 1. From the **Clusters** page, click **Create**. diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md index 85383530552..6b933e122e8 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md @@ -4,15 +4,8 @@ shortTitle: Google Kubernetes Engine weight: 2105 --- -- [Prerequisites](#prerequisites) -- [Provisioning a GKE Cluster](#provisioning-a-gke-cluster) -- [Private Clusters](#private-clusters) -- [Configuration Reference](#configuration-reference) -- [Updating Kubernetes Version](#updating-kubernetes-version) -- [Syncing](#syncing) -- [Programmatically Creating GKE Clusters](#programmatically-creating-gke-clusters) -# Prerequisites +## Prerequisites Some setup in Google Kubernetes Engine is required. @@ -39,7 +32,7 @@ To create a new project, refer to the Google cloud documentation [here.](https:/ To get the project ID of an existing project, refer to the Google cloud documentation [here.](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects) -# Provisioning a GKE Cluster +## Provisioning a GKE Cluster :::caution @@ -82,14 +75,14 @@ You can access your cluster after its state is updated to **Active**. - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Private Clusters +## Private Clusters Private GKE clusters are supported. Note: This advanced setup can require more steps during the cluster provisioning process. For details, see [this section.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters.md) -# Configuration Reference +## Configuration Reference For details on configuring GKE clusters in Rancher, see [this page.](../../../../pages-for-subheaders/gke-cluster-configuration.md) -# Updating Kubernetes Version +## Updating Kubernetes Version The Kubernetes version of a cluster can be upgraded to any version available in the region or zone fo the GKE cluster. Upgrading the master Kubernetes version does not automatically upgrade worker nodes. Nodes can be upgraded independently. @@ -99,12 +92,12 @@ GKE has removed basic authentication in 1.19+. In order to upgrade a cluster to ::: -# Syncing +## Syncing The GKE provisioner can synchronize the state of a GKE cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md) For information on configuring the refresh interval, see [this section.](../../../../pages-for-subheaders/gke-cluster-configuration.md#configuring-the-refresh-interval) -# Programmatically Creating GKE Clusters +## Programmatically Creating GKE Clusters The most common way to programmatically deploy GKE clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster) \ No newline at end of file diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md index bc3be862e7f..1fff84fc61e 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md @@ -6,7 +6,7 @@ weight: 2130 You can use Rancher to create a cluster hosted in Huawei Cloud Container Engine (CCE). Rancher has already implemented and packaged the [cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for CCE, but by default, this cluster driver is `inactive`. In order to launch CCE clusters, you will need to [enable the CCE cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning CCE clusters. -# Prerequisites in Huawei +## Prerequisites in Huawei :::caution @@ -18,7 +18,7 @@ Deploying to CCE will incur charges. 2. Create an [Access Key ID and Secret Access Key](https://support.huaweicloud.com/en-us/usermanual-iam/en-us_topic_0079477318.html). -# Prerequisite in Rancher +## Prerequisite in Rancher You will need to enable the Huawei CCE cluster driver: @@ -28,11 +28,11 @@ You will need to enable the Huawei CCE cluster driver: When the cluster driver is finished downloading, you will be able to create Huawei CCE clusters in Rancher. -# Limitations +## Limitations Huawei CCE service doesn't support the ability to create clusters with public access through their API. You are required to run Rancher in the same VPC as the CCE clusters that you want to provision. -# Create the CCE Cluster +## Create the CCE Cluster 1. From the **Clusters** page, click **Create**. 1. Click **Huawei CCE**. @@ -53,7 +53,7 @@ You can access your cluster after its state is updated to **Active**. - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Huawei CCE Configuration +## Huawei CCE Configuration |Settings|Description| |---|---| @@ -76,7 +76,7 @@ If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, n ::: -# Node Configuration +## Node Configuration |Settings|Description| |---|---| diff --git a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/tencent.md b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/tencent.md index 61945215fca..46bb9513cb4 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/tencent.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/tencent.md @@ -6,7 +6,7 @@ weight: 2125 You can use Rancher to create a cluster hosted in Tencent Kubernetes Engine (TKE). Rancher has already implemented and packaged the [cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md) for TKE, but by default, this cluster driver is `inactive`. In order to launch TKE clusters, you will need to [enable the TKE cluster driver](../../../advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-cluster-drivers.md#activating-deactivating-cluster-drivers). After enabling the cluster driver, you can start provisioning TKE clusters. -# Prerequisites in Tencent +## Prerequisites in Tencent :::caution @@ -22,7 +22,7 @@ Deploying to TKE will incur charges. 4. Create a [SSH key pair](https://intl.cloud.tencent.com/document/product/213/6092). This key is used to access the nodes in the Kubernetes cluster. -# Prerequisite in Rancher +## Prerequisite in Rancher You will need to enable the Tencent TKE cluster driver: @@ -32,7 +32,7 @@ You will need to enable the Tencent TKE cluster driver: When the cluster driver is finished downloading, you will be able to create Tencent TKE clusters in Rancher. -# Create a TKE Cluster +## Create a TKE Cluster 1. From the **Clusters** page, click **Create**. diff --git a/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md b/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md index 66c67de9efe..ae49f7b3936 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md @@ -115,7 +115,7 @@ The secret has to be created in the same namespace where the workload gets deplo Below is an example `pod.yml` for a workload that uses an image from a private registry. In this example, the pod uses an image from Quay.io, and the .yml specifies the path to the image. The pod authenticates with the registry using credentials stored in a Kubernetes secret called `testquay`, which is specified in `spec.imagePullSecrets` in the `name` field: -``` +```yaml apiVersion: v1 kind: Pod metadata: diff --git a/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration.md b/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration.md index f4710cae60a..cd8ba561e78 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/ingress-configuration.md @@ -4,12 +4,6 @@ description: Ingress configuration weight: 9999 --- -- [NGINX Ingress controller changes in Kubernetes v1.21](#nginx-ingress-controller-changes-in-Kubernetes-v1-21) -- [Specify a hostname to use](#specify-a-hostname-to-use) -- [Use as the default backend](#use-as-the-default-backend) -- [Certificates](#certificates) -- [Labels and Annotations](#labels-and-annotations) - ### NGINX Ingress controller changes in Kubernetes v1.21 For Kubernetes v1.21 and up, the NGINX Ingress controller no longer runs in hostNetwork but uses hostPorts for port 80 and port 443. This was done so the admission webhook can be configured to be accessed using ClusterIP so it can only be reached inside the cluster. diff --git a/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads.md b/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads.md index ce6bb5d29fb..1c4289484a3 100644 --- a/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads.md +++ b/docs/how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/deploy-workloads.md @@ -36,15 +36,15 @@ Deploy a workload to run an application in one or more containers. - **Scaling/Upgrade Policy** - :::note Amazon Note for Volumes: - - To mount an Amazon EBS volume: - - - In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes. - - - The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md). + :::note Amazon Note for Volumes: + + To mount an Amazon EBS volume: + + - In [Amazon AWS](https://aws.amazon.com/), the nodes must be in the same Availability Zone and possess IAM permissions to attach/unattach volumes. + + - The cluster must be using the [AWS cloud provider](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws) option. For more information on enabling this option see [Creating an Amazon EC2 Cluster](../../kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-an-amazon-ec2-cluster.md) or [Creating a Custom Cluster](../../../../pages-for-subheaders/use-existing-nodes.md). - ::: + ::: 1. Click **Show Advanced Options** and configure: diff --git a/docs/pages-for-subheaders/about-rke1-templates.md b/docs/pages-for-subheaders/about-rke1-templates.md index 57b0c31bed0..cae48658872 100644 --- a/docs/pages-for-subheaders/about-rke1-templates.md +++ b/docs/pages-for-subheaders/about-rke1-templates.md @@ -26,7 +26,7 @@ The core features of RKE templates allow DevOps and security teams to: - Control which users can create templates - Require users to create clusters from a template -# Configurable Settings +## Configurable Settings RKE templates can be created in the Rancher UI or defined in YAML format. They can define all the same parameters that can be specified when you use Rancher to provision custom nodes or nodes from an infrastructure provider: @@ -42,7 +42,7 @@ RKE templates can be created in the Rancher UI or defined in YAML format. They c The [add-on section](#add-ons) of an RKE template is especially powerful because it allows a wide range of customization options. -# Scope of RKE Templates +## Scope of RKE Templates RKE templates are supported for Rancher-provisioned clusters. The templates can be used to provision custom clusters or clusters that are launched by an infrastructure provider. @@ -53,7 +53,7 @@ RKE templates can be created from scratch to pre-define cluster configuration. T The settings of an existing cluster can be [saved as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) This creates a new template and binds the cluster settings to the template, so that the cluster can only be upgraded if the [template is updated](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#updating-a-template), and the cluster is upgraded to [use a newer version of the template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) The new template can also be used to create new clusters. -# Example Scenarios +## Example Scenarios When an organization has both basic and advanced Rancher users, administrators might want to give the advanced users more options for cluster creation, while restricting the options for basic users. These [example scenarios](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md) describe how an organization could use templates to standardize cluster creation. @@ -65,7 +65,7 @@ Some of the example scenarios include the following: - **Updating template settings:** If an organization's security and DevOps teams decide to embed best practices into the required settings for new clusters, those best practices could change over time. If the best practices change, [a template can be updated to a new revision](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#updating-templates-and-clusters-created-with-them) and clusters created from the template can [upgrade to the new version](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) of the template. - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to share ownership of the template, this scenario describes how [template ownership can be shared.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#allowing-other-users-to-control-and-share-a-template) -# Template Management +## Template Management When you create an RKE template, it is available in the Rancher UI from the **Cluster Management** view under **RKE Templates**. When you create a template, you become the template owner, which gives you permission to revise and share the template. You can share the RKE templates with specific users or groups, and you can also make it public. @@ -88,7 +88,7 @@ The documents in this section explain the details of RKE template management: An [example YAML configuration file for a template](../reference-guides/rke1-template-example-yaml.md) is provided for reference. -# Applying Templates +## Applying Templates You can [create a cluster from a template](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#creating-a-cluster-from-an-rke-template) that you created, or from a template that has been [shared with you.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/access-or-share-templates.md) @@ -98,13 +98,13 @@ RKE templates can be created from scratch to pre-define cluster configuration. T You can [save the configuration of an existing cluster as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) Then the cluster's settings can only be changed if the template is updated. -# Standardizing Hardware +## Standardizing Hardware RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, one option is to use RKE templates [in conjunction with other tools](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md). Another option is to use [cluster templates,](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-cluster-templates.md) which include node pool configuration options, but don't provide configuration enforcement. -# YAML Customization +## YAML Customization If you define an RKE template as a YAML file, you can modify this [example RKE template YAML](../reference-guides/rke1-template-example-yaml.md). The YAML in the RKE template uses the same customization that Rancher uses when creating an RKE cluster, but since the YAML is located within the context of a Rancher provisioned cluster, you will need to nest the RKE template customization under the `rancher_kubernetes_engine_config` directive in the YAML. diff --git a/docs/pages-for-subheaders/amazon-eks-permissions.md b/docs/pages-for-subheaders/amazon-eks-permissions.md index d78200c71cc..17fda45001d 100644 --- a/docs/pages-for-subheaders/amazon-eks-permissions.md +++ b/docs/pages-for-subheaders/amazon-eks-permissions.md @@ -5,20 +5,8 @@ weight: 2110 --- Amazon EKS provides a managed control plane for your Kubernetes cluster. Amazon EKS runs the Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Rancher provides an intuitive user interface for managing and deploying the Kubernetes clusters you run in Amazon EKS. With this guide, you will use Rancher to quickly and easily launch an Amazon EKS Kubernetes cluster in your AWS account. For more information on Amazon EKS, see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html). -- [Prerequisites in Amazon Web Services](#prerequisites-in-amazon-web-services) - - [Amazon VPC](#amazon-vpc) - - [IAM Policies](#iam-policies) -- [Create the EKS Cluster](#create-the-eks-cluster) -- [EKS Cluster Configuration Reference](#eks-cluster-configuration-reference) -- [Architecture](#architecture) -- [AWS Service Events](#aws-service-events) -- [Security and Compliance](#security-and-compliance) -- [Tutorial](#tutorial) -- [Minimum EKS Permissions](#minimum-eks-permissions) -- [Syncing](#syncing) -- [Troubleshooting](#troubleshooting) -- [Programmatically Creating EKS Clusters](#programmatically-creating-eks-clusters) -# Prerequisites in Amazon Web Services + +## Prerequisites in Amazon Web Services :::caution @@ -51,7 +39,7 @@ It's important to regularly rotate your access and secret keys. See this [docume For more detailed information on IAM policies for EKS, refer to the official [documentation on Amazon EKS IAM Policies, Roles, and Permissions](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html). -# Create the EKS Cluster +## Create the EKS Cluster Use Rancher to set up and configure your Kubernetes cluster. @@ -74,11 +62,11 @@ You can access your cluster after its state is updated to **Active**. - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# EKS Cluster Configuration Reference +## EKS Cluster Configuration Reference For the full list of EKS cluster configuration options, see [this page.](../reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration.md) -# Architecture +## Architecture The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two Kubernetes clusters: one created by RKE and another created by EKS. @@ -86,31 +74,31 @@ The figure below illustrates the high-level architecture of Rancher 2.x. The fig ![Architecture](/img/rancher-architecture-rancher-api-server.svg) -# AWS Service Events +## AWS Service Events To find information on any AWS Service events, please see [this page](https://status.aws.amazon.com/). -# Security and Compliance +## Security and Compliance By default only the IAM user or role that created a cluster has access to it. Attempting to access the cluster with any other user or role without additional configuration will lead to an error. In Rancher, this means using a credential that maps to a user or role that was not used to create the cluster will cause an unauthorized error. For example, an EKSCtl cluster will not register in Rancher unless the credentials used to register the cluster match the role or user used by EKSCtl. Additional users and roles can be authorized to access a cluster by being added to the aws-auth configmap in the kube-system namespace. For a more in-depth explanation and detailed instructions, please see this [documentation](https://aws.amazon.com/premiumsupport/knowledge-center/amazon-eks-cluster-access/). For more information on security and compliance with your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/shared-responsibilty.html). -# Tutorial +## Tutorial This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-rancher/) on the AWS Open Source Blog will walk you through how to set up an EKS cluster with Rancher, deploy a publicly accessible app to test the cluster, and deploy a sample project to track real-time geospatial data using a combination of other open-source software such as Grafana and InfluxDB. -# Minimum EKS Permissions +## Minimum EKS Permissions See [this page](../reference-guides/amazon-eks-permissions/minimum-eks-permissions.md) for the minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. -# Syncing +## Syncing The EKS provisioner can synchronize the state of an EKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md) For information on configuring the refresh interval, refer to [this section.](../reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration.md#configuring-the-refresh-interval) -# Troubleshooting +## Troubleshooting If your changes were overwritten, it could be due to the way the cluster data is synced with EKS. Changes shouldn't be made to the cluster from another source, such as in the EKS console, and in Rancher within a five-minute span. For information on how this works and how to configure the refresh interval, refer to [Syncing.](#syncing) @@ -118,6 +106,6 @@ If an unauthorized error is returned while attempting to modify or register the For any issues or troubleshooting details for your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html). -# Programmatically Creating EKS Clusters +## Programmatically Creating EKS Clusters The most common way to programmatically deploy EKS clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster) \ No newline at end of file diff --git a/docs/pages-for-subheaders/backup-restore-and-disaster-recovery.md b/docs/pages-for-subheaders/backup-restore-and-disaster-recovery.md index 5c26af1eae2..caa8cb67950 100644 --- a/docs/pages-for-subheaders/backup-restore-and-disaster-recovery.md +++ b/docs/pages-for-subheaders/backup-restore-and-disaster-recovery.md @@ -9,22 +9,12 @@ The `rancher-backup` operator is used to backup and restore Rancher on any Kuber 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. -- [Backup and Restore for Rancher installed with Docker](#backup-and-restore-for-rancher-installed-with-docker) -- [How Backups and Restores Work](#how-backups-and-restores-work) -- [Installing the rancher-backup Operator](#installing-the-rancher-backup-operator) - - [Installing rancher-backup with the Rancher UI](#installing-rancher-backup-with-the-rancher-ui) - - [RBAC](#rbac) -- [Backing up Rancher](#backing-up-rancher) -- [Restoring Rancher](#restoring-rancher) -- [Migrating Rancher to a New Cluster](#migrating-rancher-to-a-new-cluster) -- [Default Storage Location Configuration](#default-storage-location-configuration) - - [Example values.yaml for the rancher-backup Helm Chart](#example-values-yaml-for-the-rancher-backup-helm-chart) -# Backup and Restore for Rancher installed with Docker +## Backup and Restore for Rancher installed with Docker For Rancher installed with Docker, refer to [this page](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md) to perform backups and [this page](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md) to perform restores. -# How Backups and Restores Work +## How Backups and Restores Work The `rancher-backup` operator introduces three custom resources: Backups, Restores, and ResourceSets. The following cluster-scoped custom resource definitions are added to the cluster: @@ -48,7 +38,7 @@ Refer [here](../how-to-guides/new-user-guides/backup-restore-and-disaster-recove ::: -# Installing the rancher-backup Operator +## Installing the rancher-backup Operator 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.*) @@ -83,19 +73,19 @@ Only the rancher admins and the local cluster’s cluster-owner can: * Perform a backup or restore by creating a Backup CR and Restore CR respectively * List backups/restores performed so far -# Backing up Rancher +## Backing up Rancher A backup is performed by creating a Backup custom resource. For a tutorial, refer to [this page.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) -# Restoring Rancher +## Restoring Rancher A restore is performed by creating a Restore custom resource. For a tutorial, refer to [this page.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md) -# Migrating Rancher to a New Cluster +## Migrating Rancher to a New Cluster A migration is performed by following [these steps.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) -# Default Storage Location Configuration +## Default Storage Location Configuration Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible or Minio object store. diff --git a/docs/pages-for-subheaders/cis-scans.md b/docs/pages-for-subheaders/cis-scans.md index 21a09de5183..0ab6303e7df 100644 --- a/docs/pages-for-subheaders/cis-scans.md +++ b/docs/pages-for-subheaders/cis-scans.md @@ -7,15 +7,8 @@ Rancher can run a security scan to check whether Kubernetes is deployed accordin The `rancher-cis-benchmark` app leverages kube-bench, an open-source tool from Aqua Security, to check clusters for CIS Kubernetes Benchmark compliance. Also, to generate a cluster-wide report, the application utilizes Sonobuoy for report aggregation. -- [About the CIS Benchmark](#about-the-cis-benchmark) -- [About the Generated Report](#about-the-generated-report) -- [Test Profiles](#test-profiles) -- [About Skipped and Not Applicable Tests](#about-skipped-and-not-applicable-tests) -- [Roles-based Access Control](#roles-based-access-control) -- [Configuration](#configuration) -- [How-to Guides](#how-to-guides) -# About the CIS Benchmark +## About the CIS Benchmark The Center for Internet Security is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace". The organization is headquartered in East Greenbush, New York, with members including large corporations, government agencies, and academic institutions. @@ -24,7 +17,7 @@ CIS Benchmarks are best practices for the secure configuration of a target syste The official Benchmark documents are available through the CIS website. The sign-up form to access the documents is here. -# About the Generated Report +## About the Generated Report Each scan generates a report can be viewed in the Rancher UI and can be downloaded in CSV format. @@ -55,7 +48,7 @@ The report contains the following information: Refer to [the table in the cluster hardening guide](./rancher-security.md) for information on which versions of Kubernetes, the Benchmark, Rancher, and our cluster hardening guide correspond to each other. Also refer to the hardening guide for configuration files of CIS-compliant clusters and information on remediating failed tests. -# Test Profiles +## Test Profiles The following profiles are available: @@ -95,7 +88,7 @@ The `rancher-cis-benchmark` supports the CIS 1.6 Benchmark version. - For RKE2 Kubernetes clusters, the RKE2 Permissive 1.6 profile is the default. - For cluster types other than RKE, RKE2, EKS and GKE, the Generic CIS 1.5 profile will be used by default. -# About Skipped and Not Applicable Tests +## About Skipped and Not Applicable Tests For a list of skipped and not applicable tests, refer to [this page](../how-to-guides/advanced-user-guides/cis-scan-guides/skip-tests.md). @@ -103,14 +96,14 @@ For now, only user-defined skipped tests are marked as skipped in the generated Any skipped tests that are defined as being skipped by one of the default profiles are marked as not applicable. -# Roles-based Access Control +## Roles-based Access Control For information about permissions, refer to [this page](../explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md) -# Configuration +## Configuration For more information about configuring the custom resources for the scans, profiles, and benchmark versions, refer to [this page](../explanations/integrations-in-rancher/cis-scans/configuration-reference.md) -# How-to Guides +## How-to Guides Please refer [here](../pages-for-subheaders/cis-scan-guides.md) for how-to guides on CIS scans. \ No newline at end of file diff --git a/docs/pages-for-subheaders/configuration-options.md b/docs/pages-for-subheaders/configuration-options.md index fb5004c75cd..998b4545bd3 100644 --- a/docs/pages-for-subheaders/configuration-options.md +++ b/docs/pages-for-subheaders/configuration-options.md @@ -3,14 +3,6 @@ title: Configuration Options weight: 3 --- -- [Egress Support](#egress-support) -- [Enabling Automatic Sidecar Injection](#enabling-automatic-sidecar-injection) -- [Overlay File](#overlay-file) -- [Selectors and Scrape Configs](#selectors-and-scrape-configs) -- [Enable Istio with Pod Security Policies](#enable-istio-with-pod-security-policies) -- [Additional Steps for Installing Istio on an RKE2 Cluster](#additional-steps-for-installing-istio-on-an-rke2-cluster) -- [Additional Steps for Project Network Isolation](#additional-steps-for-project-network-isolation) - ### Egress Support By default the Egress gateway is disabled, but can be enabled on install or upgrade through the values.yaml or via the [overlay file](#overlay-file). diff --git a/docs/pages-for-subheaders/configure-shibboleth-saml.md b/docs/pages-for-subheaders/configure-shibboleth-saml.md index d89107d27b8..7ed37f1fe4f 100644 --- a/docs/pages-for-subheaders/configure-shibboleth-saml.md +++ b/docs/pages-for-subheaders/configure-shibboleth-saml.md @@ -11,16 +11,6 @@ If you also configure OpenLDAP as the back end to Shibboleth, it will return a S > The instructions in this section assume that you understand how Rancher, Shibboleth, and OpenLDAP work together. For a more detailed explanation of how it works, refer to [this page.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/configure-shibboleth-saml/about-group-permissions.md) -This section covers the following topics: - -- [Setting up Shibboleth in Rancher](#setting-up-shibboleth-in-rancher) - - [Shibboleth Prerequisites](#shibboleth-prerequisites) - - [Configure Shibboleth in Rancher](#configure-shibboleth-in-rancher) - - [SAML Provider Caveats](#saml-provider-caveats) -- [Setting up OpenLDAP in Rancher](#setting-up-openldap-in-rancher) - - [OpenLDAP Prerequisites](#openldap-prerequisites) - - [Configure OpenLDAP in Rancher](#configure-openldap-in-rancher) - - [Troubleshooting](#troubleshooting) # Setting up Shibboleth in Rancher diff --git a/docs/pages-for-subheaders/fleet-gitops-at-scale.md b/docs/pages-for-subheaders/fleet-gitops-at-scale.md index 4d110ce2ef2..0a84674278c 100644 --- a/docs/pages-for-subheaders/fleet-gitops-at-scale.md +++ b/docs/pages-for-subheaders/fleet-gitops-at-scale.md @@ -6,20 +6,12 @@ Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm. -- [Architecture](#architecture) -- [Accessing Fleet in the Rancher UI](#accessing-fleet-in-the-rancher-ui) -- [Windows Support](#windows-support) -- [GitHub Repository](#github-repository) -- [Use Fleet Behind a Proxy](#use-fleet-behind-a-proxy) -- [Helm Chart Dependencies](#helm-chart-dependencies) -- [Troubleshooting](#troubleshooting) -- [Documentation](#documentation) -# Architecture +## Architecture For information about how Fleet works, see [this page](../explanations/integrations-in-rancher/fleet-gitops-at-scale/architecture.md). -# Accessing Fleet in the Rancher UI +## Accessing Fleet in the Rancher UI Fleet comes preinstalled in Rancher and is managed by the **Continuous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/). @@ -43,30 +35,30 @@ Follow the steps below to access Continuous Delivery in the Rancher UI: 1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI. -# Windows Support +## Windows Support For details on support for clusters with Windows nodes, see [this page](../explanations/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md). -# GitHub Repository +## GitHub Repository The Fleet Helm charts are available [here](https://github.com/rancher/fleet/releases/tag/v0.3.10). -# Using Fleet Behind a Proxy +## Using Fleet Behind a Proxy For details on using Fleet behind a proxy, see [this page](../explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md). -# Helm Chart Dependencies +## 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 +## Troubleshooting - **Known Issue**: clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/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 +## Documentation The Fleet documentation is at https://fleet.rancher.io/. \ No newline at end of file diff --git a/docs/pages-for-subheaders/gke-cluster-configuration.md b/docs/pages-for-subheaders/gke-cluster-configuration.md index 1bbc4e1780e..1c2764f5367 100644 --- a/docs/pages-for-subheaders/gke-cluster-configuration.md +++ b/docs/pages-for-subheaders/gke-cluster-configuration.md @@ -4,13 +4,13 @@ shortTitle: GKE Cluster Configuration weight: 3 --- -# Changes in Rancher v2.6 +## Changes in Rancher v2.6 - Support for additional configuration options: - Project network isolation - Network tags -# Cluster Location +## Cluster Location | Value | Description | |--------|--------------| @@ -19,7 +19,7 @@ weight: 3 | Additional Zones | For zonal clusters, you can select additional zones to create a [multi-zone cluster.](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#multi-zonal_clusters) | | Region | For [regional clusters,](https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters#regional_clusters) you can select a region. For more information about available regions and zones, refer to [this section](https://cloud.google.com/compute/docs/regions-zones#available). The first part of each zone name is the name of the region. | -# Cluster Options +## Cluster Options ### Kubernetes Version diff --git a/docs/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md b/docs/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md index 99b4cbdac9c..c2d55ff8880 100644 --- a/docs/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md +++ b/docs/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md @@ -9,8 +9,6 @@ import TabItem from '@theme/TabItem'; In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI. -- [Prerequisites](#prerequisites) -- [Install the Rancher Helm Chart](#install-the-rancher-helm-chart) # Prerequisites diff --git a/docs/pages-for-subheaders/istio-setup-guide.md b/docs/pages-for-subheaders/istio-setup-guide.md index 9426d0949ba..9385ca93aa3 100644 --- a/docs/pages-for-subheaders/istio-setup-guide.md +++ b/docs/pages-for-subheaders/istio-setup-guide.md @@ -18,7 +18,9 @@ The workloads and services that you want to be controlled by Istio must meet [Is # Install -:::tip Quick Setup Tip: If you don't need external traffic to reach Istio, and you just want to set up Istio for monitoring and tracing traffic within the cluster, skip the steps for [setting up the Istio gateway](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-istio-gateway.md) and [setting up Istio's components for traffic management.](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-traffic-management.md) +:::tip Quick Setup Tip: + +If you don't need external traffic to reach Istio, and you just want to set up Istio for monitoring and tracing traffic within the cluster, skip the steps for [setting up the Istio gateway](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-istio-gateway.md) and [setting up Istio's components for traffic management.](../how-to-guides/advanced-user-guides/istio-setup-guide/set-up-traffic-management.md) ::: diff --git a/docs/pages-for-subheaders/istio.md b/docs/pages-for-subheaders/istio.md index 4e202f8a2ed..fe03eea65de 100644 --- a/docs/pages-for-subheaders/istio.md +++ b/docs/pages-for-subheaders/istio.md @@ -19,17 +19,8 @@ After [setting up istio](istio-setup-guide.md) you can leverage Istio's control Istio needs to be set up by a `cluster-admin` before it can be used in a project. -- [What's New in Rancher v2.5](#what-s-new-in-rancher-v2-5) -- [Tools Bundled with Istio](#tools-bundled-with-istio) -- [Prerequisites](#prerequisites) -- [Setup Guide](#setup-guide) -- [Remove Istio](#remove-istio) -- [Migrate from Previous Istio Version](#migrate-from-previous-istio-version) -- [Accessing Visualizations](#accessing-visualizations) -- [Architecture](#architecture) -- [Additional steps for installing Istio on an RKE2 cluster](#additional-steps-for-installing-istio-on-an-rke2-cluster) -# What's New in Rancher v2.5 +## What's New in Rancher v2.5 The overall architecture of Istio has been simplified. A single component, Istiod, has been created by combining Pilot, Citadel, Galley and the sidecar injector. Node Agent functionality has also been merged into istio-agent. @@ -41,7 +32,7 @@ Istio has migrated away from Helm as a way to install Istio and now provides ins This Helm chart will be available via the Apps and Marketplace in the UI. A user that has access to the Rancher Chart's catalog will need to set up Istio before it can be used in the project. -# Tools Bundled with Istio +## Tools Bundled with Istio Our [Istio](https://istio.io/) installer wraps the istioctl binary commands in a handy Helm chart, including an overlay file option to allow complex customization. @@ -59,7 +50,7 @@ Our Istio installer includes a quick-start, all-in-one installation of [Jaeger,] Note that this is not a production-qualified deployment of Jaeger. This deployment uses an in-memory storage component, while a persistent storage component is recommended for production. For more information on which deployment strategy you may need, refer to the [Jaeger documentation.](https://www.jaegertracing.io/docs/latest/operator/#production-strategy) -# Prerequisites +## Prerequisites Before enabling Istio, we recommend that you confirm that your Rancher worker nodes have enough [CPU and memory](../explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md) to run all of the components of Istio. @@ -67,15 +58,15 @@ If you are installing Istio on RKE2 cluster, some additional steps are required. Note that Istio v2 (upstream Istio v1.7+) cannot be upgraded in an air gapped environment. -# Setup Guide +## Setup Guide Refer to the [setup guide](istio-setup-guide.md) for instructions on how to set up Istio and use it in a project. -# Remove Istio +## Remove Istio To remove Istio components from a cluster, namespace, or workload, refer to the section on [uninstalling Istio.](../explanations/integrations-in-rancher/istio/disable-istio.md) -# Migrate From Previous Istio Version +## Migrate From Previous Istio Version There is no upgrade path for Istio versions less than 1.7.x. To successfully install Istio through **Apps & Marketplace,** you will need to disable your existing Istio from the global view in the legacy Rancher UI. @@ -83,7 +74,7 @@ If you have a significant amount of additional Istio CRDs you might consider man Another option is to manually uninstall istio resources one at a time, but leave the resources that are supported in both versions of Istio and that will not be installed by the newest version. This method is more likely to result in issues installing the new version, but could be a good option depending on your situation. -# Accessing Visualizations +## Accessing Visualizations > By default, only cluster-admins have access to Kiali. For instructions on how to allow admin, edit or views roles to access them, see [this section.](../explanations/integrations-in-rancher/istio/rbac-for-istio.md) @@ -107,7 +98,7 @@ By default, all namespace will picked up by prometheus and make data available f Your access to the visualizations depend on your role. Grafana and Prometheus are only available for `cluster-admin` roles. The Kiali UI is available only to `cluster-admin` by default, but `cluster-admin` can allow other roles to access them by editing the Istio values.yaml. -# Architecture +## Architecture Istio installs a service mesh that uses [Envoy](https://www.envoyproxy.io/learn/service-mesh) sidecar proxies to intercept traffic to each workload. These sidecars intercept and manage service-to-service communication, allowing fine-grained observation and control over traffic within the cluster. @@ -129,6 +120,6 @@ By default, each Rancher-provisioned cluster has one NGINX ingress controller al By default the Egress gateway is disabled, but can be enabled on install or upgrade through the values.yaml or via the [overlay file](configuration-options.md#overlay-file). -# Additional Steps for Installing Istio on an RKE2 Cluster +## Additional Steps for Installing Istio on an RKE2 Cluster To install Istio on an RKE2 cluster, follow the steps in [this section.](../explanations/integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md) diff --git a/docs/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md b/docs/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md index b838fc0807a..a12df1e653a 100644 --- a/docs/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md +++ b/docs/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md @@ -10,19 +10,7 @@ This section assumes a basic familiarity with Docker and Kubernetes. For a brief For a conceptual overview of how the Rancher server provisions clusters and what tools it uses to provision them, refer to the [architecture](rancher-manager-architecture.md) page. -This section covers the following topics: - - -- [Cluster Management Capabilities by Cluster Type](#cluster-management-capabilities-by-cluster-type) -- [Setting up clusters in a hosted Kubernetes provider](#setting-up-clusters-in-a-hosted-kubernetes-provider) -- [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) -- [Programmatically Creating Clusters](#programmatically-creating-clusters) - - ### Cluster Management Capabilities by Cluster Type @@ -32,7 +20,7 @@ import ClusterCapabilitiesTable from '../shared-files/_cluster-capabilities-tabl -# Setting up Clusters in a Hosted Kubernetes Provider +## Setting up Clusters in a Hosted Kubernetes Provider In this scenario, Rancher does not provision Kubernetes because it is installed by providers such as Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes, or Azure Kubernetes Service. @@ -40,7 +28,7 @@ If you use a Kubernetes provider such as Google GKE, Rancher integrates with its For more information, refer to the section on [hosted Kubernetes clusters.](set-up-clusters-from-hosted-kubernetes-providers.md) -# Launching Kubernetes with Rancher +## Launching Kubernetes with Rancher Rancher uses the [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) as a library when provisioning Kubernetes on your own nodes. RKE is Rancher’s own lightweight Kubernetes installer. @@ -72,7 +60,7 @@ You can bring any nodes you want to Rancher and use them to create a cluster. These nodes include on-prem bare metal servers, cloud-hosted virtual machines, or on-prem virtual machines. -# Registering Existing Clusters +## Registering Existing Clusters The cluster registration feature replaces the feature to import clusters. @@ -82,7 +70,7 @@ When you delete an EKS cluster that was created in Rancher, the cluster is destr For more information, see [this page.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md) -# Programmatically Creating Clusters +## Programmatically Creating Clusters The most common way to programmatically deploy Kubernetes clusters through Rancher is by using the Rancher2 Terraform provider. The documentation for creating clusters with Terraform is [here.](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster) diff --git a/docs/pages-for-subheaders/load-balancer-and-ingress-controller.md b/docs/pages-for-subheaders/load-balancer-and-ingress-controller.md index 793605dcf92..c7ca9c0ec9a 100644 --- a/docs/pages-for-subheaders/load-balancer-and-ingress-controller.md +++ b/docs/pages-for-subheaders/load-balancer-and-ingress-controller.md @@ -27,10 +27,9 @@ Load Balancers have a couple of limitations you should be aware of: - If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), the load balancer must be running within that cloud provider's infrastructure. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters: +- [Support for Layer-4 Load Balancing](../how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#support-for-layer-4-load-balancing) - - [Support for Layer-4 Load Balancing](../how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#support-for-layer-4-load-balancing) - - - [Support for Layer-7 Load Balancing](../how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#support-for-layer-7-load-balancing) +- [Support for Layer-7 Load Balancing](../how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#support-for-layer-7-load-balancing) ## Ingress diff --git a/docs/pages-for-subheaders/logging.md b/docs/pages-for-subheaders/logging.md index e7c34bdd805..05beaf29161 100644 --- a/docs/pages-for-subheaders/logging.md +++ b/docs/pages-for-subheaders/logging.md @@ -10,22 +10,8 @@ The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging For an overview of the changes in v2.5, see [this section.](../explanations/integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v2-5) For information about migrating from Logging V1, see [this page.](../explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md) -- [Enabling Logging](#enabling-logging) -- [Uninstall Logging](#uninstall-logging) -- [Architecture](#architecture) -- [Role-based Access Control](#role-based-access-control) -- [Configuring the Logging Custom Resources](#configuring-the-logging-custom-resources) - - [Flows and ClusterFlows](#flows-and-clusterflows) - - [Outputs and ClusterOutputs](#outputs-and-clusteroutputs) -- [Configuring the Logging Helm Chart](#configuring-the-logging-helm-chart) - - [Windows Support](#windows-support) - - [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory) - - [Working with Taints and Tolerations](#working-with-taints-and-tolerations) - - [Logging V2 with SELinux](#logging-v2-with-selinux) - - [Additional Logging Sources](#additional-logging-sources) -- [Troubleshooting](#troubleshooting) -# Enabling Logging +## Enabling Logging You can enable the logging for a Rancher managed cluster by going to the Apps page and installing the logging app. @@ -35,7 +21,7 @@ You can enable the logging for a Rancher managed cluster by going to the Apps pa **Result:** The logging app is deployed in the `cattle-logging-system` namespace. -# Uninstall Logging +## Uninstall Logging 1. Go to the cluster where you want to install logging and click **Apps & Marketplace**. 1. Click **Installed Apps**. @@ -45,17 +31,17 @@ You can enable the logging for a Rancher managed cluster by going to the Apps pa **Result** `rancher-logging` is uninstalled. -# Architecture +## Architecture For more information about how the logging application works, see [this section.](../explanations/integrations-in-rancher/logging/logging-architecture.md) -# Role-based Access Control +## Role-based Access Control Rancher logging has two roles, `logging-admin` and `logging-view`. For more information on how and when to use these roles, see [this page.](../explanations/integrations-in-rancher/logging/rbac-for-logging.md) -# Configuring Logging Custom Resources +## Configuring Logging Custom Resources To manage `Flows,` `ClusterFlows`, `Outputs`, and `ClusterOutputs`, @@ -71,7 +57,7 @@ For help with configuring `Flows` and `ClusterFlows`, see [this page.](../explan For help with configuring `Outputs` and `ClusterOutputs`, see [this page.](../explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md) -# Configuring the Logging Helm Chart +## Configuring the Logging Helm Chart For a list of options that can be configured when the logging application is installed or upgraded, see [this page.](../explanations/integrations-in-rancher/logging/logging-helm-chart-options.md) @@ -100,7 +86,7 @@ For information on enabling the logging application for SELinux-enabled nodes, s By default, Rancher collects logs for control plane components and node components for all cluster types. In some cases additional logs can be collected. For details, see [this section.](../explanations/integrations-in-rancher/logging/logging-helm-chart-options.md#additional-logging-sources) -# Troubleshooting +## Troubleshooting ### The `cattle-logging` Namespace Being Recreated diff --git a/docs/pages-for-subheaders/monitoring-and-alerting.md b/docs/pages-for-subheaders/monitoring-and-alerting.md index e5d41e4650c..12b7e811e19 100644 --- a/docs/pages-for-subheaders/monitoring-and-alerting.md +++ b/docs/pages-for-subheaders/monitoring-and-alerting.md @@ -7,13 +7,6 @@ weight: 13 Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster. -- [Features](#features) -- [How Monitoring Works](#how-monitoring-works) -- [Default Components and Deployments](#default-components-and-deployments) -- [Role-based Access Control](#role-based-access-control) -- [Guides](#guides) -- [Windows Cluster Support](#windows-cluster-support) -- [Known Issues](#known-issues) ### Features diff --git a/docs/pages-for-subheaders/pipelines.md b/docs/pages-for-subheaders/pipelines.md index d69ac8193e9..39734bd78a1 100644 --- a/docs/pages-for-subheaders/pipelines.md +++ b/docs/pages-for-subheaders/pipelines.md @@ -34,25 +34,12 @@ Rancher's pipeline provides a simple CI/CD experience, but it does not offer the ::: -This section covers the following topics: -- [Concepts](#concepts) -- [How Pipelines Work](#how-pipelines-work) -[Roles-based Access Control for Pipelines](#role-based-access-control-for-pipelines) -- [Setting up Pipelines](#setting-up-pipelines) - - [Configure version control providers](#1-configure-version-control-providers) - - [Configure repositories](#2-configure-repositories) - - [Configure the pipeline](#3-configure-the-pipeline) -- [Pipeline Configuration Reference](#pipeline-configuration-reference) -- [Running your Pipelines](#running-your-pipelines) -- [Triggering a Pipeline](#triggering-a-pipeline) - - [Modifying the Event Triggers for the Repository](#modifying-the-event-triggers-for-the-repository) - -# Concepts +## Concepts For an explanation of concepts and terminology used in this section, refer to [this page.](../reference-guides/pipelines/concepts.md) -# How Pipelines Work +## How Pipelines Work After enabling the ability to use pipelines in a project, you can configure multiple pipelines in each project. Each pipeline is unique and can be configured independently. @@ -86,7 +73,7 @@ When you configure a pipeline in one of your projects, a namespace specifically ::: -# Role-based Access Control for Pipelines +## Role-based Access Control for Pipelines If you can access a project, you can enable repositories to start building pipelines. @@ -94,7 +81,7 @@ Only [administrators](../how-to-guides/advanced-user-guides/authentication-permi Project members can only configure repositories and pipelines. -# Setting up Pipelines +## Setting up Pipelines ### Prerequisite @@ -241,7 +228,7 @@ Now that repositories are added to your project, you can start configuring the p **Results:** Your pipeline is now configured and ready to be run. -# Pipeline Configuration Reference +## Pipeline Configuration Reference Refer to [this page](../reference-guides/pipelines/pipeline-configuration.md) for details on how to configure a pipeline to: @@ -260,7 +247,7 @@ The configuration reference also covers how to configure: - Secrets -# Running your Pipelines +## Running your Pipelines Run your pipeline for the first time. Find your pipeline and select the vertical **⋮ > Run**. @@ -272,7 +259,7 @@ During this initial run, your pipeline is tested, and the following pipeline com This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab. -# Triggering a Pipeline +## Triggering a Pipeline When a repository is enabled, a webhook is automatically set in the version control provider. By default, the pipeline is triggered by a **push** event to a repository, but you can modify the event(s) that trigger running the pipeline. diff --git a/docs/pages-for-subheaders/rancher-on-a-single-node-with-docker.md b/docs/pages-for-subheaders/rancher-on-a-single-node-with-docker.md index 319c7f5eb34..7965ae43566 100644 --- a/docs/pages-for-subheaders/rancher-on-a-single-node-with-docker.md +++ b/docs/pages-for-subheaders/rancher-on-a-single-node-with-docker.md @@ -57,7 +57,7 @@ If you are installing Rancher in a development or testing environment where iden Log into your host, and run the command below: -```bash +``` docker run -d --restart=unless-stopped \ -p 80:80 -p 443:443 \ --privileged \ @@ -87,7 +87,7 @@ After creating your certificate, run the Docker command below to install Rancher Log into your host, and run the command below: -```bash +``` docker run -d --restart=unless-stopped \ -p 80:80 -p 443:443 \ -v //:/etc/rancher/ssl/cert.pem \ @@ -123,7 +123,7 @@ After obtaining your certificate, run the Docker command below. Log into your host, and run the command below: -```bash +``` docker run -d --restart=unless-stopped \ -p 80:80 -p 443:443 \ -v //:/etc/rancher/ssl/cert.pem \ @@ -177,7 +177,7 @@ If you are installing Rancher in a development or testing environment where you Log into your host, and run the command below: -```bash +``` docker run -d --restart=unless-stopped \ -p 80:80 -p 443:443 \ --privileged \ diff --git a/docs/pages-for-subheaders/rancher-security.md b/docs/pages-for-subheaders/rancher-security.md index a2e153af491..3dfad6c1983 100644 --- a/docs/pages-for-subheaders/rancher-security.md +++ b/docs/pages-for-subheaders/rancher-security.md @@ -24,17 +24,7 @@ aliases: Security is at the heart of all Rancher features. From integrating with all the popular authentication tools and services, to an enterprise grade [RBAC capability](manage-role-based-access-control-rbac.md), Rancher makes your Kubernetes clusters even more secure. -On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters: - -- [NeuVector Integration with Rancher](#neuvector-integration-with-rancher) -- [Running a CIS security scan on a Kubernetes cluster](#running-a-cis-security-scan-on-a-kubernetes-cluster) -- [SELinux RPM](#selinux-rpm) -- [Guide to hardening Rancher installations](#rancher-hardening-guide) -- [The CIS Benchmark and self-assessment](#the-cis-benchmark-and-self-assessment) -- [Third-party penetration test reports](#third-party-penetration-test-reports) -- [Rancher Security Advisories and CVEs](#rancher-security-advisories-and-cves) -- [Kubernetes Security Best Practices](#kubernetes-security-best-practices) - +On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters. ### NeuVector Integration with Rancher _New in v2.6.5_ diff --git a/docs/pages-for-subheaders/rancher-v2.6-hardening-guides.md b/docs/pages-for-subheaders/rancher-v2.6-hardening-guides.md index 49e6bb89588..ca4685cd4bb 100644 --- a/docs/pages-for-subheaders/rancher-v2.6-hardening-guides.md +++ b/docs/pages-for-subheaders/rancher-v2.6-hardening-guides.md @@ -12,14 +12,8 @@ aliases: Rancher provides specific security hardening guides for each supported Rancher's Kubernetes distributions. -- [Rancher Kubernetes Distributions](#rancher-kubernetes-distributions) -- [Hardening Guides and Benchmark Versions](#hardening-guides-and-benchmark-versions) - - [RKE Guides](#rke-guides) - - [RKE2 Guides](#rke2-guides) - - [K3s Guides](#k3s) -- [Rancher with SELinux](#rancher-with-selinux) -# Rancher Kubernetes Distributions +## Rancher Kubernetes Distributions Rancher uses the following Kubernetes distributions: @@ -29,7 +23,7 @@ Rancher uses the following Kubernetes distributions: To harden a Kubernetes cluster outside of Rancher's distributions, refer to your Kubernetes provider docs. -# Hardening Guides and Benchmark Versions +## Hardening Guides and Benchmark Versions These guides have been tested along with the Rancher v2.6 release. Each self-assessment guide is accompanied with a hardening guide and tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can choose to use the existing guides until a newer version is added. @@ -58,7 +52,7 @@ These guides have been tested along with the Rancher v2.6 release. Each self-ass | ------------------ | --------------------- | --------------------- | ---------------- | | Kubernetes v1.21 and v1.22 | CIS v1.6 | [Link](https://rancher.com/docs/k3s/latest/en/security/self_assessment/) | [Link](https://rancher.com/docs/k3s/latest/en/security/hardening_guide/) | -# Rancher with SELinux +## Rancher with SELinux [Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on RHEL and CentOS. diff --git a/docs/pages-for-subheaders/use-existing-nodes.md b/docs/pages-for-subheaders/use-existing-nodes.md index cf3c02f89b6..4ad3a5f0c29 100644 --- a/docs/pages-for-subheaders/use-existing-nodes.md +++ b/docs/pages-for-subheaders/use-existing-nodes.md @@ -19,13 +19,6 @@ See [Configuring Custom Clusters for Windows](use-windows-clusters.md) before yo ::: - - -- [1. Provision a Linux Host](#1-provision-a-linux-host) -- [2. Create the Custom Cluster](#2-create-the-custom-cluster) -- [3. Amazon Only: Tag Resources](#3-amazon-only-tag-resources) - - ### 1. Provision a Linux Host diff --git a/docs/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md b/docs/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md index 90a485ebc76..b02640832c7 100644 --- a/docs/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md +++ b/docs/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md @@ -3,23 +3,6 @@ title: Launching Kubernetes on New Nodes in an Infrastructure Provider weight: 2205 --- -This section covers the following topics: - -- [RKE Clusters](#rke-clusters) - - [Node templates](#node-templates) - - [Node labels](#node-labels) - - [Node taints](#node-taints) - - [Administrator control of node templates](#administrator-control-of-node-templates) - - [Node pools](#node-pools) - - [Node pool taints](#node-pool-taints) - - [About node auto-replace](#about-node-auto-replace) - - [Enabling node auto-replace](#enabling-node-auto-replace) - - [Disabling node auto-replace](#disabling-node-auto-replace) - - [Cloud credentials](#cloud-credentials) - - [Node drivers](#node-drivers) -- [RKE2 Clusters](#rke2-clusters) - - [Node roles in RKE2](#node-roles-in-rke2) - When you create an RKE or RKE2 cluster using a node template in Rancher, each resulting node pool is shown in a new **Machine Pools** tab. You can see the machine pools by doing the following: 1. Click **☰ > Cluster Management**. @@ -85,6 +68,7 @@ The recommended setup is to have: By default, Rancher tries to run the Docker Install script when provisioning RKE1 downstream cluster nodes, such as in vSphere. However, the Rancher Docker installation script would fail in air-gapped environments. To work around this issue, you may choose to skip installing Docker when creating a Node Template where Docker is pre-installed onto a VM image. You can accomplish this by selecting **None** in the dropdown list for `Docker Install URL` under **Engine Options** in the Rancher UI.
**Engine Options Dropdown:**
+ ![Engine Options Dropdown](/img/node-template-engine-options-rke1.png) #### Node Pool Taints diff --git a/docs/pages-for-subheaders/use-windows-clusters.md b/docs/pages-for-subheaders/use-windows-clusters.md index 57f3396d5eb..095e7853764 100644 --- a/docs/pages-for-subheaders/use-windows-clusters.md +++ b/docs/pages-for-subheaders/use-windows-clusters.md @@ -18,17 +18,8 @@ For the full list of requirements, see [this section.](#requirements-for-windows For a summary of Kubernetes features supported in Windows, see the Kubernetes documentation on [supported functionality and limitations for using Kubernetes with Windows](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#supported-functionality-and-limitations) or the [guide for scheduling Windows containers in Kubernetes](https://kubernetes.io/docs/setup/production-environment/windows/user-guide-windows-containers/). -This guide covers the following topics: - - -- [Changes in Rancher v2.6](#changes-in-rancher-v2-6) -- [Requirements](#requirements-for-windows-clusters) -- [Tutorial: How to Create a Cluster with Windows Support](#tutorial-how-to-create-a-cluster-with-windows-support) -- [Configuration for Storage Classes in Azure](#configuration-for-storage-classes-in-azure) - - -# Changes in Rancher v2.6 +## Changes in Rancher v2.6 Rancher v2.6 introduces provisioning for [RKE2](https://docs.rke2.io/) clusters directly from the Rancher UI. RKE2, also known as RKE Government, is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector. @@ -55,7 +46,7 @@ Rancher will allow Windows workload pods to deploy on both Windows and Linux wor - HostProcess containers in Windows RKE2 are supported in Kubernetes v1.24.1 and up. See [the upstream documentation](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) for more information. -# Requirements for Windows Clusters +## Requirements for Windows Clusters The general node requirements for networking, operating systems, and Docker are the same as the node requirements for a [Rancher installation](installation-requirements.md). @@ -156,7 +147,7 @@ If you are using the GCE (Google Compute Engine) cloud provider, you must do the - Enable the GCE cloud provider in the `cluster.yml` by following [these steps.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md) - When provisioning the cluster in Rancher, choose **Custom cloud provider** as the cloud provider in the Rancher UI. -# Tutorial: How to Create a Cluster with Windows Support +## Tutorial: How to Create a Cluster with Windows Support This tutorial describes how to create a Rancher-provisioned cluster with the three nodes in the [recommended architecture.](#guide-architecture) @@ -164,15 +155,8 @@ When you provision a cluster with Rancher on existing nodes, you will add nodes To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below. - -1. [Provision Hosts](#1-provision-hosts) -1. [Create the Cluster on Existing Nodes](#2-create-the-cluster-on-existing-nodes) -1. [Add Nodes to the Cluster](#3-add-nodes-to-the-cluster) -1. [Optional: Configuration for Azure Files](#4-optional-configuration-for-azure-files) - - -# 1. Provision Hosts +### 1. Provision Hosts To begin provisioning a cluster on existing nodes with Windows support, prepare your hosts. @@ -196,7 +180,7 @@ You will provision three nodes: If your nodes are hosted by a **Cloud Provider** and you want automation support such as loadbalancers or persistent storage devices, your nodes have additional configuration requirements. For details, see [Selecting Cloud Providers.](set-up-cloud-providers.md) -# 2. Create the Cluster on Existing Nodes +### 2. Create the Cluster on Existing Nodes The instructions for creating a Windows cluster on existing nodes are very similar to the general [instructions for creating a custom cluster](use-existing-nodes.md) with some Windows-specific requirements. @@ -216,11 +200,11 @@ For Host Gateway (L2bridge) networking, it's best to use the same Layer 2 ::: -# 3. Add Nodes to the Cluster +### 3. Add Nodes to the Cluster This section describes how to register your Linux and Worker nodes to your cluster. You will run a command on each node, which will install the Rancher agent and allow Rancher to manage each node. -### Add Linux Master Node +#### Add Linux Master Node In this section, we fill out a form on the Rancher UI to get a custom command to install the Rancher agent on the Linux master node. Then we will copy the command and run it on our Linux master node to register the node in the cluster. @@ -247,7 +231,7 @@ You can access your cluster after its state is updated to **Active**. It may take a few minutes for the node to be registered in your cluster. -### Add Linux Worker Node +#### Add Linux Worker Node In this section, we run a command to register the Linux worker node to the cluster. @@ -275,7 +259,7 @@ For each Linux worker node added into the cluster, the following taints will be ::: -### Add a Windows Worker Node +#### Add a Windows Worker Node In this section, we run a command to register the Windows worker node to the cluster. @@ -298,6 +282,6 @@ After creating your cluster, you can access it through the Rancher UI. As a best - **Access your cluster with the kubectl CLI:** Follow [these steps](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI. - **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through the Rancher server. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster. -# Configuration for Storage Classes in Azure +## Configuration for Storage Classes in Azure If you are using Azure VMs for your nodes, you can use [Azure files](https://docs.microsoft.com/en-us/azure/aks/azure-files-dynamic-pv) as a StorageClass for the cluster. For details, refer to [this section.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/azure-storageclass-configuration.md) diff --git a/docs/pages-for-subheaders/vsphere.md b/docs/pages-for-subheaders/vsphere.md index d27e2e6d7e0..b80685cc1d1 100644 --- a/docs/pages-for-subheaders/vsphere.md +++ b/docs/pages-for-subheaders/vsphere.md @@ -13,12 +13,7 @@ Rancher can provision nodes in vSphere and install Kubernetes on them. When crea A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role. -- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v2-3) -- [Creating a vSphere Cluster](#creating-a-vsphere-cluster) -- [Provisioning Storage](#provisioning-storage) -- [Enabling the vSphere Cloud Provider](#enabling-the-vsphere-cloud-provider) - -# vSphere Enhancements in Rancher v2.3 +## vSphere Enhancements in Rancher v2.3 The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements: @@ -48,15 +43,15 @@ In this YouTube video, we demonstrate how to set up a node template with the new -# Creating a vSphere Cluster +## Creating a vSphere Cluster In [this section,](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere. -# Provisioning Storage +## Provisioning Storage For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md) In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](vsphere-cloud-provider.md) -# Enabling the vSphere Cloud Provider +## Enabling the vSphere Cloud Provider When a cloud provider is set up in Rancher, the Rancher server can automatically provision new infrastructure for the cluster, including new nodes or persistent storage devices. diff --git a/docs/reference-guides/backup-restore-configuration/backup-configuration.md b/docs/reference-guides/backup-restore-configuration/backup-configuration.md index 97702378797..9351a312631 100644 --- a/docs/reference-guides/backup-restore-configuration/backup-configuration.md +++ b/docs/reference-guides/backup-restore-configuration/backup-configuration.md @@ -6,17 +6,8 @@ weight: 1 The Backup Create page lets you configure a schedule, enable encryption and specify the storage location for your backups. -- [Schedule](#schedule) -- [Encryption](#encryption) -- [Storage Location](#storage-location) - - [S3](#s3) - - [Example S3 Storage Configuration](#example-s3-storage-configuration) - - [Example MinIO Configuration](#example-minio-configuration) - - [Example credentialSecret](#example-credentialsecret) - - [IAM Permissions for EC2 Nodes to Access S3](#iam-permissions-for-ec2-nodes-to-access-s3) -- [Examples](#examples) -# Schedule +## Schedule Select the first option to perform a one-time backup, or select the second option to schedule recurring backups. Selecting **Recurring Backups** lets you configure following two fields: @@ -30,7 +21,7 @@ Select the first option to perform a one-time backup, or select the second optio | `schedule` | Provide the cron string for scheduling recurring backups. | | `retentionCount` | Provide the number of backup files to be retained. | -# Encryption +## Encryption The rancher-backup gathers resources by making calls to the kube-apiserver. Objects returned by apiserver are decrypted, so even if [encryption At rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) is enabled, even the encrypted objects gathered by the backup will be in plaintext. @@ -70,7 +61,7 @@ In the example command above, the name `encryptionconfig` can be changed to anyt | ---------------- | ---------------- | | `encryptionConfigSecretName` | Provide the name of the Secret from `cattle-resources-system` namespace, that contains the encryption config file. | -# Storage Location +## Storage Location If the StorageLocation is specified in the Backup, the operator will retrieve the backup location from that particular S3 bucket. If not specified, the operator will try to find this file in the default operator-level S3 store, and in the operator-level PVC store. The default storage location is configured during the deployment of the `rancher-backup` operator. @@ -175,6 +166,6 @@ To allow a node to access S3, follow the instructions in the [AWS documentation] After the role is created, and you have attached the corresponding instance profile to your EC2 instance(s), the `credentialSecretName` directive can be left empty in the Backup custom resource. -# Examples +## Examples For example Backup custom resources, refer to [this page.](examples.md#backup) diff --git a/docs/reference-guides/backup-restore-configuration/examples.md b/docs/reference-guides/backup-restore-configuration/examples.md index 23aabd701bb..fbb9685cc20 100644 --- a/docs/reference-guides/backup-restore-configuration/examples.md +++ b/docs/reference-guides/backup-restore-configuration/examples.md @@ -9,25 +9,7 @@ The default backup storage location is configured when the `rancher-backup` oper Encrypted backups can only be restored if the Restore custom resource uses the same encryption configuration secret that was used to create the backup. -- [Backup](#backup) - - [Backup in the default location with encryption](#backup-in-the-default-location-with-encryption) - - [Recurring backup in the default location](#recurring-backup-in-the-default-location) - - [Encrypted recurring backup in the default location](#encrypted-recurring-backup-in-the-default-location) - - [Encrypted backup in Minio](#encrypted-backup-in-minio) - - [Backup in S3 using AWS credential secret](#backup-in-s3-using-aws-credential-secret) - - [Recurring backup in S3 using AWS credential secret](#recurring-backup-in-s3-using-aws-credential-secret) - - [Backup from EC2 nodes with IAM permission to access S3](#backup-from-ec2-nodes-with-iam-permission-to-access-s3) -- [Restore](#restore) - - [Restore using the default backup file location](#restore-using-the-default-backup-file-location) - - [Restore for Rancher migration](#restore-for-rancher-migration) - - [Restore from encrypted backup](#restore-from-encrypted-backup) - - [Restore an encrypted backup from Minio](#restore-an-encrypted-backup-from-minio) - - [Restore from backup using an AWS credential secret to access S3](#restore-from-backup-using-an-aws-credential-secret-to-access-s3) - - [Restore from EC2 nodes with IAM permissions to access S3](#restore-from-ec2-nodes-with-iam-permissions-to-access-s3) -- [Example Credential Secret for Storing Backups in S3](#example-credential-secret-for-storing-backups-in-s3) -- [Example EncryptionConfiguration](#example-encryptionconfiguration) - -# Backup +## Backup This section contains example Backup custom resources. @@ -153,7 +135,7 @@ spec: encryptionConfigSecretName: encryptionconfig ``` -# Restore +## Restore This section contains example Restore custom resources. diff --git a/docs/reference-guides/backup-restore-configuration/restore-configuration.md b/docs/reference-guides/backup-restore-configuration/restore-configuration.md index 36b2679f011..40dc764e0ab 100644 --- a/docs/reference-guides/backup-restore-configuration/restore-configuration.md +++ b/docs/reference-guides/backup-restore-configuration/restore-configuration.md @@ -8,15 +8,8 @@ The Restore Create page lets you provide details of the backup to restore from ![](/img/backup_restore/restore/restore.png) -- [Backup Source](#backup-source) - - [An Existing Backup Config](#an-existing-backup-config) - - [The default storage target](#the-default-storage-target) - - [An S3-compatible object store](#an-s3-compatible-object-store) -- [Encryption](#encryption) -- [Prune during restore](#prune-during-restore) -- [Getting the Backup Filename from S3](#getting-the-backup-filename-from-s3) -# Backup Source +## Backup Source Provide details of the backup file and its storage location, which the operator will then use to perform the restore. Select from the following options to provide these details @@ -43,7 +36,7 @@ Select this option if no default storage location is configured at the operator- ![](/img/backup_restore/restore/s3store.png) -# Encryption +## Encryption If the backup was created with encryption enabled, its file will have `.enc` suffix. Choosing such a Backup, or providing a backup filename with `.enc` suffix will display another dropdown named **Encryption Config Secret**. @@ -63,7 +56,7 @@ This field should only be set if the backup was created with encryption enabled. ::: -# Prune During Restore +## Prune During Restore * **Prune**: In order to fully restore Rancher from a backup, and to go back to the exact state it was at when the backup was performed, we need to delete any additional resources that were created by Rancher after the backup was taken. The operator does so if the **Prune** flag is enabled. Prune is enabled by default and it is recommended to keep it enabled. * **Delete Timeout**: This is the amount of time the operator will wait while deleting a resource before editing the resource to remove finalizers and attempt deletion again. @@ -73,7 +66,7 @@ This field should only be set if the backup was created with encryption enabled. | `prune` | Delete the resources managed by Rancher that are not present in the backup (Recommended). | | `deleteTimeoutSeconds` | Amount of time the operator will wait while deleting a resource before editing the resource to remove finalizers and attempt deletion again. | -# Getting the Backup Filename from S3 +## Getting the Backup Filename from S3 This is the name of the backup file that the `rancher-backup` operator will use to perform the restore. diff --git a/docs/reference-guides/backup-restore-configuration/storage-configuration.md b/docs/reference-guides/backup-restore-configuration/storage-configuration.md index 5df67541fdf..5b26205cf94 100644 --- a/docs/reference-guides/backup-restore-configuration/storage-configuration.md +++ b/docs/reference-guides/backup-restore-configuration/storage-configuration.md @@ -8,15 +8,8 @@ Configure a storage location where all backups are saved by default. You will ha Only one storage location can be configured at the operator level. -- [Storage Location Configuration](#storage-location-configuration) - - [No Default Storage Location](#no-default-storage-location) - - [S3-compatible Object Store](#s3-compatible-object-store) - - [Use an existing StorageClass](#existing-storageclass) - - [Use an existing PersistentVolume](#existing-persistent-volume) -- [Encryption](#encryption) -- [Example values.yaml for the rancher-backup Helm Chart](#example-values-yaml-for-the-rancher-backup-helm-chart) -# Storage Location Configuration +## Storage Location Configuration ### No Default Storage Location @@ -57,7 +50,7 @@ It is highly recommended to use a Persistent Volume with a reclaim policy of "Re ::: -# Example values.yaml for the rancher-backup Helm Chart +## Example values.yaml for the rancher-backup Helm Chart The documented `values.yaml` file that can be used to configure `rancher-backup` operator when the Helm CLI is used can be found in the [backup-restore-operator repository.](https://github.com/rancher/backup-restore-operator/blob/master/charts/rancher-backup/values.yaml) diff --git a/docs/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md b/docs/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md index 42edadf1bdb..733bfb40555 100644 --- a/docs/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md +++ b/docs/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md @@ -14,7 +14,7 @@ Rancher provides a flexible experience for log aggregation. With the logging fea "Under the hood", Rancher logging uses the Banzai Cloud logging operator. We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters. -# Cluster-level Logging +## Cluster-level Logging ### Cluster-wide Scraping @@ -32,7 +32,7 @@ Currently the logs from RKE containers are collected, but are not able to easily A future release of Rancher will include the source container name which will enable filtering of these component logs. Once that change is made, you will be able to customize a _ClusterFlow_ to retrieve **only** the Kubernetes component logs, and direct them to an appropriate output. -# Application Logging +## Application Logging Best practice not only in Kubernetes but in all container-based applications is to direct application logs to `stdout`/`stderr`. The container runtime will then trap these logs and do **something** with them - typically writing them to a file. Depending on the container runtime (and its configuration), these logs can end up in any number of locations. @@ -48,7 +48,7 @@ The goal of setting up a streaming sidecar is to take log files that are written To set this up, edit your workload resource (e.g. Deployment) and add the following sidecar definition: -``` +```yaml ... containers: - args: @@ -68,7 +68,7 @@ This will add a container to your workload definition that will now stream the c This log stream is then automatically collected according to any _Flows_ or _ClusterFlows_ you have setup. You may also wish to consider creating a _Flow_ specifically for this log file by targeting the name of the container. See example: -``` +```yaml ... spec: match: @@ -79,7 +79,7 @@ spec: ``` -# General Best Practices +## General Best Practices - Where possible, output structured log entries (e.g. `syslog`, JSON). This makes handling of the log entry easier as there are already parsers written for these formats. - Try to provide the name of the application that is creating the log entry, in the entry itself. This can make troubleshooting easier as Kubernetes objects do not always carry the name of the application as the object name. For instance, a pod ID may be something like `myapp-098kjhsdf098sdf98` which does not provide much information about the application running inside the container. diff --git a/docs/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md b/docs/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md index 166eb9442d2..b4fd44d748d 100644 --- a/docs/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md +++ b/docs/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md @@ -7,19 +7,11 @@ Configuring sensible monitoring and alerting rules is vital for running any prod The [Rancher monitoring documentation](../../../pages-for-subheaders/monitoring-and-alerting.md) describes how you can set up a complete Prometheus and Grafana stack. Out of the box this will scrape monitoring data from all system and Kubernetes components in your cluster and provide sensible dashboards and alerts for them to get started. But for a reliable setup, you also need to monitor your own workloads and adapt Prometheus and Grafana to your own specific use cases and cluster sizes. This document aims to give you best practices for this. -- [What to Monitor](#what-to-monitor) -- [Configuring Prometheus Resource Usage](#configuring-prometheus-resource-usage) -- [Scraping Custom Workloads](#scraping-custom-workloads) -- [Monitoring in a (Micro)Service Architecture](#monitoring-in-a-micro-service-architecture) -- [Real User Monitoring](#real-user-monitoring) -- [Security Monitoring](#security-monitoring) -- [Setting up Alerts](#setting-up-alerts) - -# What to Monitor +## What to Monitor Kubernetes itself, as well as applications running inside of it, form a distributed system where different components interact with each other. For the whole system and each individual component, you have to ensure performance, availability, reliability and scalability. A good resource with more details and information is Google's free [Site Reliability Engineering Book](https://landing.google.com/sre/sre-book/), especially the chapter about [Monitoring distributed systems](https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/). -# Configuring Prometheus Resource Usage +## Configuring Prometheus Resource Usage When installing the integrated monitoring stack, Rancher allows to configure several settings that are dependent on the size of your cluster and the workloads running in it. This chapter covers these in more detail. @@ -63,7 +55,7 @@ Prometheus is not meant to store metrics for a long amount of time, but should o In order to store some, or all metrics for a long time, you can leverage Prometheus' [remote read/write](https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations) capabilities to connect it to storage systems like [Thanos](https://thanos.io/), [InfluxDB](https://www.influxdata.com/), [M3DB](https://www.m3db.io/), or others. You can find an example setup in this [blog post](https://rancher.com/blog/2020/prometheus-metric-federation). -# Scraping Custom Workloads +## Scraping Custom Workloads While the integrated Rancher Monitoring already scrapes system metrics from a cluster's nodes and system components, the custom workloads that you deploy on Kubernetes should also be scraped for data. For that you can configure Prometheus to do an HTTP request to an endpoint of your applications in a certain interval. These endpoints should then return their metrics in a Prometheus format. @@ -91,23 +83,23 @@ To still get metrics for these use cases, you can set up [prometheus-pushgateway Sometimes it is useful to monitor workloads from the outside. For this, you can use the [Prometheus blackbox-exporter](https://github.com/prometheus/blackbox_exporter) which allows probing any kind of endpoint over HTTP, HTTPS, DNS, TCP and ICMP. -# Monitoring in a (Micro)Service Architecture +## Monitoring in a (Micro)Service Architecture If you have a (micro)service architecture where multiple individual workloads within your cluster are communicating with each other, it is really important to have detailed metrics and traces about this traffic to understand how all these workloads are communicating with each other and where a problem or bottleneck may be. Of course you can monitor all this internal traffic in all your workloads and expose these metrics to Prometheus. But this can quickly become quite work intensive. Service Meshes like Istio, which can be installed with [a click](https://rancher.com/docs/rancher/v2.6/en/istio/) in Rancher, can do this automatically and provide rich telemetry about the traffic between all services. -# Real User Monitoring +## Real User Monitoring Monitoring the availability and performance of all your internal workloads is vitally important to run stable, reliable and fast applications. But these metrics only show you parts of the picture. To get a complete view it is also necessary to know how your end users are actually perceiving it. For this you can look into various [Real user monitoring solutions](https://en.wikipedia.org/wiki/Real_user_monitoring). -# Security Monitoring +## Security Monitoring In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../pages-for-subheaders/cis-scan-guides.md) which check if the cluster is configured according to security best practices. For the workloads, you can have a look at Kubernetes and Container security solutions like [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/). -# Setting up Alerts +## Setting up Alerts Getting all the metrics into a monitoring systems and visualizing them in dashboards is great, but you also want to be pro-actively alerted if something goes wrong. diff --git a/docs/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md b/docs/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md index 3a0f0ca3448..40d7848ba5a 100644 --- a/docs/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md +++ b/docs/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md @@ -6,17 +6,12 @@ weight: 3 This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware. -- [1. Load Balancer Considerations](#1-load-balancer-considerations) -- [2. VM Considerations](#2-vm-considerations) -- [3. Network Considerations](#3-network-considerations) -- [4. Storage Considerations](#4-storage-considerations) -- [5. Backups and Disaster Recovery](#5-backups-and-disaster-recovery)
Solution Overview
![Solution Overview](/img/rancher-on-prem-vsphere.svg) -# 1. Load Balancer Considerations +## 1. Load Balancer Considerations A load balancer is required to direct traffic to the Rancher workloads residing on the RKE nodes. @@ -42,7 +37,7 @@ Avoid implementing a software load balancer within the management cluster. Configure appropriate Firewall / ACL rules to only expose access to Rancher -# 2. VM Considerations +## 2. VM Considerations ### Size the VM's According to Rancher Documentation @@ -64,7 +59,7 @@ Doing so will ensure node VM's are spread across multiple datastores - preventin It’s important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double-checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node. -# 3. Network Considerations +## 3. Network Considerations ### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes @@ -74,13 +69,13 @@ Deploy etcd members within a single data center where possible to avoid latency Each node used should have a static IP configured. In the case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated. -# 4. Storage Considerations +## 4. Storage Considerations ### Leverage SSD Drives for ETCD Nodes ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible. -# 5. Backups and Disaster Recovery +## 5. Backups and Disaster Recovery ### Perform Regular Management Cluster Backups diff --git a/docs/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md b/docs/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md index c31fdec2fdc..e3b03c4b21c 100644 --- a/docs/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md +++ b/docs/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md @@ -8,7 +8,7 @@ There are two recommended deployment strategies for a Rancher server that manage * [Hub and Spoke](#hub-and-spoke-strategy) * [Regional](#regional-strategy) -# Hub & Spoke Strategy +## Hub & Spoke Strategy --- In this deployment scenario, there is a single Rancher control plane managing Kubernetes clusters across the globe. The control plane would be run on a high-availability Kubernetes cluster, and there would be impact due to latencies. @@ -26,7 +26,7 @@ In this deployment scenario, there is a single Rancher control plane managing Ku * Subject to network latencies. * If the control plane goes out, global provisioning of new services is unavailable until it is restored. However, each Kubernetes cluster can continue to be managed individually. -# Regional Strategy +## Regional Strategy --- In the regional deployment model a control plane is deployed in close proximity to the compute nodes. diff --git a/docs/reference-guides/cli-with-rancher/kubectl-utility.md b/docs/reference-guides/cli-with-rancher/kubectl-utility.md index 70f04de5a27..ba5b1ea464e 100644 --- a/docs/reference-guides/cli-with-rancher/kubectl-utility.md +++ b/docs/reference-guides/cli-with-rancher/kubectl-utility.md @@ -2,10 +2,6 @@ title: kubectl Utility --- -- [kubectl](#kubectl) - - [kubectl Utility](#kubectl-utility) - - [Authentication with kubectl and kubeconfig Tokens with TTL](#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) - # kubectl Interact with Rancher using kubectl. diff --git a/docs/reference-guides/cli-with-rancher/rancher-cli.md b/docs/reference-guides/cli-with-rancher/rancher-cli.md index 45f87875e6c..a31c262a291 100644 --- a/docs/reference-guides/cli-with-rancher/rancher-cli.md +++ b/docs/reference-guides/cli-with-rancher/rancher-cli.md @@ -4,15 +4,6 @@ description: Interact with Rancher using command line interface (CLI) tools from weight: 21 --- -- [Rancher CLI](#rancher-cli) - - [Download Rancher CLI](#download-rancher-cli) - - [Requirements](#requirements) - - [CLI Authentication](#cli-authentication) - - [Project Selection](#project-selection) - - [Commands](#commands) - - [Rancher CLI Help](#rancher-cli-help) - - [Limitations](#limitations) - The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI. ### Download Rancher CLI diff --git a/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md b/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md index a4ae10d8ece..7b96868bf97 100644 --- a/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md +++ b/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md @@ -3,14 +3,8 @@ title: Nutanix Node Template Configuration weight: 2 --- -- [Account Access](#account-access) -- [Scheduling](#scheduling) -- [Instance Options](#instance-options) -- [Networks](#networks) -- [VM Categories](#vm-categories) -- [cloud-init](#cloud-init) -# Account Access +## Account Access | Parameter | Required | Description | Default |:-----------------------------|:--------:|:-----------------------------------------------------------------|:----- @@ -19,7 +13,7 @@ weight: 2 | Password | ✓ | Password of the Prism Central user | | Allow insecure communication | | Set to true to allow insecure SSL communication to Prism Central | False -# Scheduling +## Scheduling Choose what Nutanix cluster the virtual machine will be scheduled to. @@ -27,7 +21,7 @@ Choose what Nutanix cluster the virtual machine will be scheduled to. |:----------|:--------:|:---------------------------------------------------------------------------- | Cluster | ✓ | Name of the Nutanix cluster where the VM should be deployed (case sensitive) -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. @@ -45,15 +39,15 @@ In the **Instance Options** section, configure the number of vCPUs, memory, and The VM may use any modern Linux operating system that is configured with support for [cloud-init](https://cloudinit.readthedocs.io/en/latest/) using the [Config Drive v2 datasource](https://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html). -# Networks +## Networks The node template allows a VM to be provisioned with multiple networks. In the **Network** field, you can click **Add** to add any networks available to you in AOS. -# VM Categories +## VM Categories A category is a grouping of entities into a key value pair. Typically, VMs are assigned to a category based on some criteria. Policies can then be tied to those entities that are assigned (grouped by) a specific category value. -# cloud-init +## cloud-init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users or authorizing SSH keys. diff --git a/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md b/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md index 81c66fd8416..911200879ec 100644 --- a/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md +++ b/docs/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md @@ -3,14 +3,8 @@ title: VSphere Node Template Configuration weight: 2 --- -- [Account Access](#account-access) -- [Scheduling](#scheduling) -- [Instance Options](#instance-options) -- [Networks](#networks) -- [Node tags and custom attributes](#node-tags-and-custom-attributes) -- [cloud-init](#cloud-init) -# Account Access +## Account Access | Parameter | Required | Description | |:----------------------|:--------:|:-----| @@ -24,7 +18,7 @@ Your cloud credential has these fields: | Port | Optional: configure configure the port of the vCenter or ESXi server. | | Username and password | Enter your vSphere login username and password. | -# Scheduling +## Scheduling Choose what hypervisor the virtual machine will be scheduled to. @@ -38,7 +32,7 @@ The fields in the **Scheduling** section should auto-populate with the data cent | Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The VM folders in this dropdown menu directly correspond to your VM folders in vSphere. The folder name should be prefaced with `vm/` in your vSphere config file. | | Host | | The IP of the host system to schedule VMs in. Leave this field blank for a standalone ESXi or for a cluster with DRS (Distributed Resource Scheduler). If specified, the host system's pool will be used and the **Resource Pool** parameter will be ignored. | -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. @@ -66,11 +60,11 @@ Choose the way that the VM will be created: - **Clone an existing virtual machine:** In the **Virtual machine** field, choose an existing VM that the new VM will be cloned from. - **Install from boot2docker ISO:** Ensure that the **OS ISO URL** field contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`). Note that this URL must be accessible from the nodes running your Rancher server installation. -# Networks +## Networks The node template now allows a VM to be provisioned with multiple networks. In the **Networks** field, you can now click **Add Network** to add any networks available to you in vSphere. -# Node Tags and Custom Attributes +## Node Tags and Custom Attributes Tags allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects. @@ -84,7 +78,7 @@ Custom attributes are a legacy feature that will eventually be removed from vSph ::: -# cloud-init +## cloud-init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network. diff --git a/docs/reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md b/docs/reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md index d27ddf7f621..2286f367cfe 100644 --- a/docs/reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md +++ b/docs/reference-guides/cluster-configuration/rancher-server-configuration/aks-cluster-configuration.md @@ -4,20 +4,20 @@ title: AKS Cluster Configuration Reference weight: 4 --- -# Changes in Rancher v2.6 +## Changes in Rancher v2.6 - Support for adding more than one node pool - Support for private clusters - Enabled autoscaling node pools - The AKS permissions are now configured in cloud credentials -# Role-based Access Control +## Role-based Access Control When provisioning an AKS cluster in the Rancher UI, RBAC cannot be disabled. If role-based access control is disabled for the cluster in AKS, the cluster cannot be registered or imported into Rancher. Rancher can configure member roles for AKS clusters in the same way as any other cluster. For more information, see the section on [role-based access control.](../../../pages-for-subheaders/manage-role-based-access-control-rbac.md) -# Cloud Credentials +## Cloud Credentials :::note @@ -50,19 +50,19 @@ Microsoft provides multiple [clouds](https://docs.microsoft.com/en-us/cli/azure/ - AzureChinaCloud - AzureUSGovernmentCloud -# Account Access +## Account Access In this section you will need to select an existing Azure cloud credential or create a new one. For help configuring your Azure cloud credential, see [this section.](#cloud-credentials) -# Cluster Location +## Cluster Location Configure the cluster and node location. For more information on availability zones for AKS, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/availability-zones) The high availability locations include multiple availability zones. -# Cluster Options +## Cluster Options ### Kubernetes Version @@ -92,7 +92,7 @@ The key used to create an SSH connection to the Linux nodes. Cluster tags can be useful if your organization uses tags as a way to organize resources across multiple Azure services. These tags don't apply to resources within the cluster. -# Networking Options +## Networking Options ### LoadBalancer SKU @@ -177,7 +177,7 @@ Please be aware that when registering an existing AKS cluster, the cluster might For more information about connecting to an AKS private cluster, see the [AKS documentation.](https://docs.microsoft.com/en-us/azure/aks/private-clusters#options-for-connecting-to-the-private-cluster) -# Node Pools +## Node Pools ### Mode diff --git a/docs/reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md b/docs/reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md index a827719123c..98ed41cc8a4 100644 --- a/docs/reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md +++ b/docs/reference-guides/cluster-configuration/rancher-server-configuration/k3s-cluster-configuration.md @@ -6,14 +6,14 @@ weight: 6 This section covers the configuration options that are available in Rancher for a new or existing K3s Kubernetes cluster. -# Overview +## Overview You can configure the Kubernetes options one of two ways: - [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster. - [Cluster Config File](#cluster-config-file): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create a K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation. -# Configuration Options in the Rancher UI +## Configuration Options in the Rancher UI :::tip @@ -138,7 +138,7 @@ Option to remove all pods from the node prior to upgrading. Option to set kubelet options for different nodes. For available options, refer to the [Kubernetes documentation](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/). -# Cluster Config File +## Cluster Config File Instead of using the Rancher UI forms to choose Kubernetes options for the cluster, advanced users can create an K3s config file. Using a config file allows you to set any of the [options](https://rancher.com/docs/k3s/latest/en/installation/install-options/) available in an K3s installation. diff --git a/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md b/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md index cffc95e467c..c4846d3d232 100644 --- a/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md +++ b/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md @@ -8,38 +8,8 @@ When Rancher installs Kubernetes, it uses [RKE](../../../pages-for-subheaders/la This section covers the configuration options that are available in Rancher for a new or existing RKE Kubernetes cluster. -- [Overview](#overview) -- [Editing Clusters with a Form in the Rancher UI](#editing-clusters-with-a-form-in-the-rancher-ui) -- [Editing Clusters with YAML](#editing-clusters-with-yaml) -- [Configuration Options in the Rancher UI](#configuration-options-in-the-rancher-ui) - - [Kubernetes Version](#kubernetes-version) - - [Network Provider](#network-provider) - - [Project Network Isolation](#project-network-isolation) - - [Kubernetes Cloud Providers](#kubernetes-cloud-providers) - - [Private Registries](#private-registries) - - [Authorized Cluster Endpoint](#authorized-cluster-endpoint) - - [Node Pools](#node-pools) - - [NGINX Ingress](#nginx-ingress) - - [Metrics Server Monitoring](#metrics-server-monitoring) - - [Pod Security Policy Support](#pod-security-policy-support) - - [Docker Version on Nodes](#docker-version-on-nodes) - - [Docker Root Directory](#docker-root-directory) - - [Default Pod Security Policy](#default-pod-security-policy) - - [Node Port Range](#node-port-range) - - [Recurring etcd Snapshots](#recurring-etcd-snapshots) - - [Agent Environment Variables](#agent-environment-variables) - - [Updating ingress-nginx](#updating-ingress-nginx) -- [RKE Cluster Config File Reference](#rke-cluster-config-file-reference) - - [Config File Structure in Rancher](#config-file-structure-in-rancher) - - [Default DNS Provider](#default-dns-provider) -- [Rancher Specific Parameters in YAML](#rancher-specific-parameters-in-yaml) - - [docker_root_dir](#docker_root_dir) - - [enable_cluster_monitoring](#enable_cluster_monitoring) - - [enable_network_policy](#enable_network_policy) - - [local_cluster_auth_endpoint](#local_cluster_auth_endpoint) - - [Custom Network Plug-in](#custom-network-plug-in) -# Overview +## Overview You can configure the Kubernetes options one of two ways: @@ -54,7 +24,7 @@ For an example of RKE config file syntax, see the [RKE documentation](https://ra The forms in the Rancher UI don't include all advanced options for configuring RKE. For the complete reference of configurable options for RKE Kubernetes clusters in YAML, see the [RKE documentation.](https://rancher.com/docs/rke/latest/en/config-options/) -# Editing Clusters with a Form in the Rancher UI +## Editing Clusters with a Form in the Rancher UI To edit your cluster, @@ -62,7 +32,7 @@ To edit your cluster, 1. Go to the cluster you want to configure and click **⋮ > Edit Config**. -# Editing Clusters with YAML +## Editing Clusters with YAML Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the options available in an RKE installation, except for system_images configuration, by specifying them in YAML. @@ -75,7 +45,7 @@ To edit an RKE config file directly from the Rancher UI, 1. In the configuration form, scroll down and click **Edit as YAML**. 1. Edit the RKE options under the `rancher_kubernetes_engine_config` directive. -# Configuration Options in the Rancher UI +## Configuration Options in the Rancher UI :::tip @@ -217,7 +187,7 @@ If the `updateStrategy` of `ingress-nginx` is `OnDelete`, you will need to delet -# RKE Cluster Config File Reference +## RKE Cluster Config File Reference Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available](https://rancher.com/docs/rke/latest/en/config-options/) in an RKE installation, except for `system_images` configuration. The `system_images` option is not supported when creating a cluster with the Rancher UI or API. @@ -332,7 +302,7 @@ The table below indicates what DNS provider is deployed by default. See [RKE doc | v2.2.5 and higher | v1.13.x and lower | kube-dns | | v2.2.4 and lower | any | kube-dns | -# Rancher Specific Parameters in YAML +## Rancher Specific Parameters in YAML Besides the RKE config file options, there are also Rancher specific settings that can be configured in the Config File (YAML): diff --git a/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md b/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md index ccf364b6fab..8418c5d8a5a 100644 --- a/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md +++ b/docs/reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md @@ -6,21 +6,21 @@ weight: 5 This section covers the configuration options that are available in Rancher for a new or existing RKE2 Kubernetes cluster. -# Overview +## Overview You can configure the Kubernetes options in one of the two following ways: - [Rancher UI](#configuration-options-in-the-rancher-ui): Use the Rancher UI to select options that are commonly customized when setting up a Kubernetes cluster. - [Cluster Config File](#cluster-config-file): Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE2 config file. Using a config file allows you to set many additional [options](https://docs.rke2.io/install/install_options/install_options) available for an RKE2 installation. -# Editing Clusters with a Form in the Rancher UI +## Editing Clusters with a Form in the Rancher UI To edit your cluster, 1. In the upper left corner, click **☰ > Cluster Management**. 1. Go to the cluster you want to configure and click **⋮ > Edit Config**. -# Editing Clusters with YAML +## Editing Clusters with YAML Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE2 config file. Using a config file allows you to set any of the options available in an RKE2 installation by specifying them in YAML. @@ -30,7 +30,7 @@ To edit an RKE2 config file directly from the Rancher UI, 1. Go to the cluster you want to configure and click **⋮ > Edit as YAML**. 1. Edit the RKE options under the `rkeConfig` directive. -# Configuration Options in the Rancher UI +## Configuration Options in the Rancher UI :::tip diff --git a/docs/reference-guides/configure-openldap/openldap-config-reference.md b/docs/reference-guides/configure-openldap/openldap-config-reference.md index 1a02ee9b236..d91c5adc93b 100644 --- a/docs/reference-guides/configure-openldap/openldap-config-reference.md +++ b/docs/reference-guides/configure-openldap/openldap-config-reference.md @@ -9,11 +9,6 @@ For further details on configuring OpenLDAP, refer to the [official documentatio > Before you proceed with the configuration, please familiarize yourself with the concepts of [External Authentication Configuration and Principal Users](../../pages-for-subheaders/about-authentication.md#external-authentication-configuration-and-principal-users). -- [Background: OpenLDAP Authentication Flow](#background-openldap-authentication-flow) -- [OpenLDAP server configuration](#openldap-server-configuration) -- [User/group schema configuration](#user-group-schema-configuration) - - [User schema configuration](#user-schema-configuration) - - [Group schema configuration](#group-schema-configuration) ## Background: OpenLDAP Authentication Flow diff --git a/docs/reference-guides/installation-references/helm-chart-options.md b/docs/reference-guides/installation-references/helm-chart-options.md index fadc2f7a746..4580373ca27 100644 --- a/docs/reference-guides/installation-references/helm-chart-options.md +++ b/docs/reference-guides/installation-references/helm-chart-options.md @@ -11,18 +11,7 @@ For help choosing a Helm chart version, refer to [this page.](../../getting-star For information on enabling experimental features, refer to [this page.](../../pages-for-subheaders/enable-experimental-features.md) -- [Common Options](#common-options) -- [Advanced Options](#advanced-options) -- [API Audit Log](#api-audit-log) -- [Setting Extra Environment Variables](#setting-extra-environment-variables) -- [TLS Settings](#tls-settings) -- [Customizing your Ingress](#customizing-your-ingress) -- [HTTP Proxy](#http-proxy) -- [Additional Trusted CAs](#additional-trusted-cas) -- [Private Registry and Air Gap Installs](#private-registry-and-air-gap-installs) -- [External TLS Termination](#external-tls-termination) - -### Common Options +## Common Options | Option | Default Value | Description | | ------------------------- | ------------- | ---------------------------------------------------------------------------------- | @@ -35,7 +24,7 @@ For information on enabling experimental features, refer to [this page.](../../p
-### Advanced Options +## Advanced Options | Option | Default Value | Description | | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | diff --git a/docs/reference-guides/kubernetes-concepts.md b/docs/reference-guides/kubernetes-concepts.md index 8b8c007ab08..d5666042c95 100644 --- a/docs/reference-guides/kubernetes-concepts.md +++ b/docs/reference-guides/kubernetes-concepts.md @@ -5,18 +5,7 @@ weight: 4 This page explains concepts related to Kubernetes that are important for understanding how Rancher works. The descriptions below provide a simplified overview of Kubernetes components. For more details, refer to the [official documentation on Kubernetes components.](https://kubernetes.io/docs/concepts/overview/components/) -This section covers the following topics: - -- [About Docker](#about-docker) -- [About Kubernetes](#about-kubernetes) -- [What is a Kubernetes Cluster?](#what-is-a-kubernetes-cluster) -- [Roles for Nodes in Kubernetes Clusters](#roles-for-nodes-in-kubernetes-clusters) - - [etcd Nodes](#etcd-nodes) - - [Controlplane Nodes](#controlplane-nodes) - - [Worker Nodes](#worker-nodes) -- [About Helm](#about-helm) - -# About Docker +## About Docker Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](https://hub.docker.com) is the most popular public registry. Many organizations also set up private Docker registries. Docker is primarily used to manage containers on individual nodes. @@ -26,17 +15,17 @@ Although Rancher 1.6 supported Docker Swarm clustering technology, it is no long ::: -# About Kubernetes +## About Kubernetes Kubernetes is the container cluster management standard. YAML files specify containers and other resources that form an application. Kubernetes performs functions such as scheduling, scaling, service discovery, health check, secret management, and configuration management. -# What is a Kubernetes Cluster? +## What is a Kubernetes Cluster? A cluster is a group of computers that work together as a single system. A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestration system](https://kubernetes.io/) to deploy, maintain, and scale Docker containers, allowing your organization to automate application operations. -# Roles for Nodes in Kubernetes Clusters +## Roles for Nodes in Kubernetes Clusters Each computing resource in a Kubernetes cluster is called a _node_. Nodes can be either bare-metal servers or virtual machines. Kubernetes classifies nodes into three types: _etcd_ nodes, _control plane_ nodes, and _worker_ nodes. @@ -67,7 +56,7 @@ Each [worker node](https://kubernetes.io/docs/concepts/architecture/nodes/) runs Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your [workloads](../pages-for-subheaders/workloads-and-pods.md). -# About Helm +## About Helm For high-availability installations of Rancher, Helm is the tool used to install Rancher on a Kubernetes cluster. diff --git a/docs/reference-guides/monitoring-v2-configuration/helm-chart-options.md b/docs/reference-guides/monitoring-v2-configuration/helm-chart-options.md index 17cd311beec..b89d70ec743 100644 --- a/docs/reference-guides/monitoring-v2-configuration/helm-chart-options.md +++ b/docs/reference-guides/monitoring-v2-configuration/helm-chart-options.md @@ -3,15 +3,8 @@ title: Helm Chart Options weight: 8 --- -- [Configuring Resource Limits and Requests](#configuring-resource-limits-and-requests) -- [Trusted CA for Notifiers](#trusted-ca-for-notifiers) -- [Additional Scrape Configurations](#additional-scrape-configurations) -- [Configuring Applications Packaged within Monitoring V2](#configuring-applications-packaged-within-monitoring-v2) -- [Increase the Replicas of Alertmanager](#increase-the-replicas-of-alertmanager) -- [Configuring the Namespace for a Persistent Grafana Dashboard](#configuring-the-namespace-for-a-persistent-grafana-dashboard) - -# Configuring Resource Limits and Requests +## Configuring Resource Limits and Requests The resource requests and limits can be configured when installing `rancher-monitoring`. @@ -32,7 +25,7 @@ The default values in the table below are the minimum required resource limits a At least 50Gi storage is recommended. -# Trusted CA for Notifiers +## Trusted CA for Notifiers If you need to add a trusted CA to your notifier, follow these steps: @@ -43,7 +36,7 @@ If you need to add a trusted CA to your notifier, follow these steps: **Result:** The default Alertmanager custom resource will have access to your trusted CA. -# Additional Scrape Configurations +## Additional Scrape Configurations If the scrape configuration you want cannot be specified via a ServiceMonitor or PodMonitor at the moment, you can provide an `additionalScrapeConfigSecret` on deploying or upgrading `rancher-monitoring`. @@ -52,7 +45,7 @@ A [scrape_config section](https://prometheus.io/docs/prometheus/latest/configura An example of where this might be used is with Istio. For more information, see [this section.](../../explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md) -# Configuring Applications Packaged within Monitoring v2 +## Configuring Applications Packaged within Monitoring v2 We deploy kube-state-metrics and node-exporter with monitoring v2. Node exporter are deployed as DaemonSets. In the monitoring v2 helm chart, in the values.yaml, each of the things are deployed as sub charts. diff --git a/docs/reference-guides/monitoring-v2-configuration/receivers.md b/docs/reference-guides/monitoring-v2-configuration/receivers.md index d98bb21fb6a..3e11265ad1c 100644 --- a/docs/reference-guides/monitoring-v2-configuration/receivers.md +++ b/docs/reference-guides/monitoring-v2-configuration/receivers.md @@ -15,22 +15,8 @@ This section assumes familiarity with how monitoring components work together. F ::: -- [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui) -- [Receiver Configuration](#receiver-configuration) - - [Slack](#slack) - - [Email](#email) - - [PagerDuty](#pagerduty) - - [Opsgenie](#opsgenie) - - [Webhook](#webhook) - - [Custom](#custom) - - [Teams](#teams) - - [SMS](#sms) -- [Configuring Multiple Receivers](#configuring-multiple-receivers) -- [Example Alertmanager Config](examples.md#example-alertmanager-config) -- [Example Route Config for CIS Scan Alerts](#example-route-config-for-cis-scan-alerts) -- [Trusted CA for Notifiers](#trusted-ca-for-notifiers) -# Creating Receivers in the Rancher UI +## Creating Receivers in the Rancher UI :::note Prerequisites: @@ -64,7 +50,7 @@ To create notification receivers in the Rancher UI, **Result:** Alerts can be configured to send notifications to the receiver(s). -# Receiver Configuration +## Receiver Configuration The notification integrations are configured with the `receiver`, which is explained in the [Prometheus documentation.](https://prometheus.io/docs/alerting/latest/configuration/#receiver) @@ -91,7 +77,7 @@ The following types of receivers can be configured in the Rancher UI: The custom receiver option can be used to configure any receiver in YAML that cannot be configured by filling out the other forms in the Rancher UI. -# Slack +## Slack | Field | Type | Description | |------|--------------|------| @@ -100,7 +86,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca | Proxy URL | String | Proxy for the webhook notifications. | | Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | -# Email +## Email | Field | Type | Description | |------|--------------|------| @@ -117,7 +103,7 @@ SMTP options: | Username | String | Enter a username to authenticate with the SMTP server. | | Password | String | Enter a password to authenticate with the SMTP server. | -# PagerDuty +## PagerDuty | Field | Type | Description | |------|------|-------| @@ -126,7 +112,7 @@ SMTP options: | Proxy URL | String | Proxy for the PagerDuty notifications. | | Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | -# Opsgenie +## Opsgenie | Field | Description | |------|-------------| @@ -141,7 +127,7 @@ Opsgenie Responders: | Type | String | Schedule, Team, User, or Escalation. For more information on alert responders, refer to the [Opsgenie documentation.](https://docs.opsgenie.com/docs/alert-recipients-and-teams) | | Send To | String | Id, Name, or Username of the Opsgenie recipient. | -# Webhook +## Webhook | Field | Description | |-------|--------------| @@ -151,11 +137,11 @@ Opsgenie Responders: -# Custom +## Custom The YAML provided here will be directly appended to your receiver within the Alertmanager Config Secret. -# Teams +## Teams ### Enabling the Teams Receiver for Rancher Managed Clusters @@ -188,7 +174,7 @@ url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance- -# SMS +## SMS ### Enabling the SMS Receiver for Rancher Managed Clusters @@ -233,7 +219,7 @@ url http://rancher-alerting-drivers-sachet.ns-1.svc:9876/alert -# Configuring Multiple Receivers +## Configuring Multiple Receivers By editing the forms in the Rancher UI, you can set up a Receiver resource with all the information Alertmanager needs to send alerts to your notification system. @@ -242,7 +228,7 @@ It is also possible to send alerts to multiple notification systems. One way is You can also set up multiple receivers by using the `continue` option for a route, so that the alerts sent to a receiver continue being evaluated in the next level of the routing tree, which could contain another receiver. -# Example Alertmanager Configs +## Example Alertmanager Configs ### Slack To set up notifications via Slack, the following Alertmanager Config YAML can be placed into the `alertmanager.yaml` key of the Alertmanager Config Secret, where the `api_url` should be updated to use your Webhook URL from Slack: @@ -289,7 +275,7 @@ receivers: - service_key: 'database-integration-key' ``` -# Example Route Config for CIS Scan Alerts +## Example Route Config for CIS Scan Alerts While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. @@ -314,6 +300,6 @@ spec: For more information on enabling alerting for `rancher-cis-benchmark`, see [this section.](../../pages-for-subheaders/cis-scan-guides.md#enabling-alerting-for-rancher-cis-benchmark) -# Trusted CA for Notifiers +## Trusted CA for Notifiers If you need to add a trusted CA to your notifier, follow the steps in [this section.](helm-chart-options.md#trusted-ca-for-notifiers) diff --git a/docs/reference-guides/monitoring-v2-configuration/routes.md b/docs/reference-guides/monitoring-v2-configuration/routes.md index 5b07c72f9f4..58dadde17cf 100644 --- a/docs/reference-guides/monitoring-v2-configuration/routes.md +++ b/docs/reference-guides/monitoring-v2-configuration/routes.md @@ -19,13 +19,9 @@ This section assumes familiarity with how monitoring components work together. F ::: -- [Route Restrictions](#route-restrictions) -- [Route Configuration](#route-configuration) - - [Receiver](#receiver) - - [Grouping](#grouping) - - [Matching](#matching) -# Route Restrictions + +## Route Restrictions Alertmanager proxies alerts for Prometheus based on its receivers and a routing tree that filters alerts to certain receivers based on labels. @@ -35,7 +31,7 @@ In the Rancher UI for configuring routes and receivers, you can configure routin Each receiver is for one or more notification providers. So if you know that every alert for Slack should also go to PagerDuty, you can configure both in the same receiver. -# Route Configuration +## Route Configuration ### Note on Labels and Annotations diff --git a/docs/reference-guides/pipelines/configure-persistent-data.md b/docs/reference-guides/pipelines/configure-persistent-data.md index 6c074272a72..4b741979bf2 100644 --- a/docs/reference-guides/pipelines/configure-persistent-data.md +++ b/docs/reference-guides/pipelines/configure-persistent-data.md @@ -31,24 +31,24 @@ This section assumes that you understand how persistent storage works in Kuberne 1. Complete the form that displays to choose a persistent volume for the internal Docker registry. - + - 1. Enter a **Name** for the volume claim. - 1. Select a volume claim **Source**: - - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. - - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Select a volume claim **Source**: + - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. + - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - - + + - 1. Enter a **Name** for the volume claim. - 1. Choose a **Persistent Volume Claim** from the dropdown. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Choose a **Persistent Volume Claim** from the dropdown. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - + 1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container. @@ -69,24 +69,24 @@ This section assumes that you understand how persistent storage works in Kuberne 1. Complete the form that displays to choose a persistent volume for the internal Docker registry. - + - 1. Enter a **Name** for the volume claim. - 1. Select a volume claim **Source**: - - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. - - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Select a volume claim **Source**: + - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. + - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - - + + - 1. Enter a **Name** for the volume claim. - 1. Choose a **Persistent Volume Claim** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Choose a **Persistent Volume Claim** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - + 1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container. diff --git a/docs/reference-guides/pipelines/pipeline-configuration.md b/docs/reference-guides/pipelines/pipeline-configuration.md index 689a504d8ce..6cc04130514 100644 --- a/docs/reference-guides/pipelines/pipeline-configuration.md +++ b/docs/reference-guides/pipelines/pipeline-configuration.md @@ -5,26 +5,8 @@ weight: 1 In this section, you'll learn how to configure pipelines. -- [Step Types](#step-types) -- [Step Type: Run Script](#step-type-run-script) -- [Step Type: Build and Publish Images](#step-type-build-and-publish-images) -- [Step Type: Publish Catalog Template](#step-type-publish-catalog-template) -- [Step Type: Deploy YAML](#step-type-deploy-yaml) -- [Step Type: Deploy Catalog App](#step-type-deploy-catalog-app) -- [Notifications](#notifications) -- [Timeouts](#timeouts) -- [Triggers and Trigger Rules](#triggers-and-trigger-rules) -- [Environment Variables](#environment-variables) -- [Secrets](#secrets) -- [Pipeline Variable Substitution Reference](#pipeline-variable-substitution-reference) -- [Global Pipeline Execution Settings](#global-pipeline-execution-settings) - - [Executor Quota](#executor-quota) - - [Resource Quota for Executors](#resource-quota-for-executors) - - [Custom CA](#custom-ca) -- [Persistent Data for Pipeline Components](#persistent-data-for-pipeline-components) -- [Example rancher-pipeline.yml](#example-rancher-pipeline-yml) -# Step Types +## Step Types Within each stage, you can add as many steps as you'd like. When there are multiple steps in one stage, they run concurrently. @@ -100,7 +82,7 @@ stages: image: golang shellScript: go build ``` -# Step Type: Build and Publish Images +## Step Type: Build and Publish Images The **Build and Publish Image** step builds and publishes a Docker image. This process requires a Dockerfile in your source code's repository to complete successfully. @@ -150,7 +132,7 @@ stages: PLUGIN_INSECURE: "true" ``` -# Step Type: Publish Catalog Template +## Step Type: Publish Catalog Template The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a git hosted chart repository. It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. Any variables in the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) is supported for any file in the chart folder. @@ -206,7 +188,7 @@ stages: sourceKey: DEPLOY_KEY ``` -# Step Type: Deploy YAML +## Step Type: Deploy YAML This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml). Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables. @@ -229,7 +211,7 @@ stages: path: ./deployment.yaml ``` -# Step Type :Deploy Catalog App +## Step Type :Deploy Catalog App The **Deploy Catalog App** step deploys a catalog app in the project. It will install a new app if it is not present, or upgrade an existing one. @@ -275,7 +257,7 @@ stages: targetNamespace: test ``` -# Timeouts +## Timeouts By default, each pipeline execution has a timeout of 60 minutes. If the pipeline execution cannot complete within its timeout period, the pipeline is aborted. @@ -299,7 +281,7 @@ stages: timeout: 30 ``` -# Notifications +## Notifications You can enable notifications to any notifiers based on the build status of a pipeline. Before enabling notifications, Rancher recommends setting up notifiers so it will be easy to add recipients immediately. @@ -351,7 +333,7 @@ notification: message: "my-message" ``` -# Triggers and Trigger Rules +## Triggers and Trigger Rules After you configure a pipeline, you can trigger it using different methods: @@ -375,13 +357,6 @@ If all conditions evaluate to `true`, then the pipeline/stage/step is executed. Wildcard character (`*`) expansion is supported in `branch` conditions. -This section covers the following topics: - -- [Configuring pipeline triggers](#configuring-pipeline-triggers) -- [Configuring stage triggers](#configuring-stage-triggers) -- [Configuring step triggers](#configuring-step-triggers) -- [Configuring triggers by YAML](#configuring-triggers-by-yaml) - ### Configuring Pipeline Triggers 1. In the upper left corner, click **☰ > Cluster Management**. @@ -468,7 +443,7 @@ branch: exclude: [ dev ] ``` -# Environment Variables +## Environment Variables When configuring a pipeline, certain [step types](#step-types) allow you to use environment variables to configure the step's script. @@ -500,7 +475,7 @@ stages: SECOND_KEY: VALUE2 ``` -# Secrets +## Secrets If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes [secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md). @@ -543,7 +518,7 @@ stages: targetKey: ALIAS_ENV ``` -# Pipeline Variable Substitution Reference +## Pipeline Variable Substitution Reference For your convenience, the following variables are available for your pipeline configuration scripts. During pipeline executions, these variables are replaced by metadata. You can reference them in the form of `${VAR_NAME}`. @@ -562,7 +537,7 @@ Variable Name | Description `CICD_REGISTRY` | Address for the Docker registry for the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. `CICD_IMAGE` | Name of the image built from the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. It does not contain the image tag.

[Example](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml) -# Global Pipeline Execution Settings +## Global Pipeline Execution Settings After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. @@ -655,6 +630,6 @@ The internal Docker registry and the Minio workloads use ephemeral volumes by de For details on setting up persistent storage for pipelines, refer to [this page.](configure-persistent-data.md) -# Example rancher-pipeline.yml +## Example rancher-pipeline.yml An example pipeline configuration file is on [this page.](example-yaml.md) diff --git a/docs/reference-guides/rancher-cluster-tools.md b/docs/reference-guides/rancher-cluster-tools.md index 68a105ecfe1..513c7b50cab 100644 --- a/docs/reference-guides/rancher-cluster-tools.md +++ b/docs/reference-guides/rancher-cluster-tools.md @@ -1,22 +1,12 @@ --- -title: Tools for Logging, Monitoring, and Visibility +title: Cluster Tools for Logging, Monitoring, and Visibility weight: 2033 --- Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories: - -- [Logging](#logging) -- [Monitoring and Alerts](#monitoring-and-alerts) -- [Istio](#istio) -- [OPA Gatekeeper](#opa-gatekeeper) -- [CIS Scans](#cis-scans) - - - - -# Logging +## Logging Logging is helpful because it allows you to: @@ -29,7 +19,7 @@ Logging is helpful because it allows you to: Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd. For more information, refer to the logging documentation [here.](../pages-for-subheaders/logging.md) -# Monitoring and Alerts +## Monitoring and Alerts Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. @@ -41,18 +31,18 @@ Alerts are rules that trigger those notifications. Before you can receive alerts For more information, refer to the monitoring documentation [here.](../pages-for-subheaders/monitoring-and-alerting.md) -# Istio +## Istio [Istio](https://istio.io/) is an open-source tool that makes it easier for DevOps teams to observe, control, troubleshoot, and secure the traffic within a complex network of microservices. Rancher's integration with Istio was improved in Rancher v2.5. For more information, refer to the Istio documentation [here.](../pages-for-subheaders/istio.md) -# OPA Gatekeeper +## OPA Gatekeeper [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is an open-source project that provides integration between OPA and Kubernetes to provide policy control via admission controller webhooks. For details on how to enable Gatekeeper in Rancher, refer to the [OPA Gatekeeper section.](../explanations/integrations-in-rancher/opa-gatekeeper.md) -# CIS Scans +## CIS Scans Rancher can run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the CIS Kubernetes Benchmark. diff --git a/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md index 99022aa6912..c99754d886a 100644 --- a/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -5,15 +5,6 @@ weight: 3 If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) -This section covers the following topics: - -- [Separation of Rancher and User Clusters](#separation-of-rancher-and-user-clusters) -- [Why HA is Better for Rancher in Production](#why-ha-is-better-for-rancher-in-production) -- [Recommended Load Balancer Configuration for Kubernetes Installations](#recommended-load-balancer-configuration-for-kubernetes-installations) -- [Environment for Kubernetes Installations](#environment-for-kubernetes-installations) -- [Recommended Node Roles for Kubernetes Installations](#recommended-node-roles-for-kubernetes-installations) -- [Architecture for an Authorized Cluster Endpoint (ACE)](#architecture-for-an-authorized-cluster-endpoint-ace) - # Separation of Rancher and User Clusters A user cluster is a downstream Kubernetes cluster that runs your apps and services. diff --git a/docs/reference-guides/rancher-project-tools.md b/docs/reference-guides/rancher-project-tools.md index 1bfba4bf217..fb03f1c980c 100644 --- a/docs/reference-guides/rancher-project-tools.md +++ b/docs/reference-guides/rancher-project-tools.md @@ -1,16 +1,10 @@ --- -title: Tools for Logging, Monitoring, and Visibility +title: Project Tools for Logging, Monitoring, and Visibility weight: 2525 --- -Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories: - +Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. -- [Notifiers and Alerts](#notifiers-and-alerts) -- [Logging](#logging) -- [Monitoring](#monitoring) - - ## Notifiers and Alerts diff --git a/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md b/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md index f2870ee0890..88c63a97884 100644 --- a/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md +++ b/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke1-hardening-guide-with-cis-v1.6-benchmark.md @@ -21,14 +21,6 @@ This hardening guide is intended to be used for RKE clusters and associated with [Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.6/Rancher_v2-6_CIS_v1-6_Hardening_Guide.pdf). -- [Overview](#overview) -- [Configure Kernel Runtime Parameters](#configure-kernel-runtime-parameters) -- [Configure `etcd` user and group](#configure-etcd-user-and-group) -- [Configure `default` service account](#configure-default-service-account) -- [Configure Network Policy](#configure-network-policy) -- [Reference Hardened RKE `cluster.yml` Configuration](#reference-hardened-rke-cluster-yml-configuration) -- [Reference Hardened RKE Template Configuration](#reference-hardened-rke-template-configuration) -- [Reference Hardened **cloud-config** Configuration](#reference-hardened-cloud-config-configuration) ### Overview diff --git a/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md b/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md index 4d4ff7ad2e1..20d0e9d8528 100644 --- a/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md +++ b/docs/reference-guides/rancher-security/rancher-v2.6-hardening-guides/rke2-hardening-guide-with-cis-v1.6-benchmark.md @@ -19,14 +19,6 @@ This hardening guide is intended to be used for RKE2 clusters and associated wit [Click here to download a PDF version of this document](https://releases.rancher.com/documents/security/2.6/Rancher_RKE2_v2-6_CIS_v1-6_Hardening_Guide.pdf). -- [Overview](#overview) -- [Host-level requirements](#host-level-requirements) -- [Setting up hosts](#setting-up-hosts) -- [Kubernetes runtime requirements](#kubernetes-runtime-requirements) -- [API Server audit configuration](#api-server-audit-configuration) -- [Known issues](#known-issues) -- [Reference Hardened RKE2 Template Configuration](#reference-hardened-rke2-template-configuration) -- [Conclusion](#conclusion) ### Overview diff --git a/docs/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md b/docs/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md index 3f00ec4fd77..d7358c29b62 100644 --- a/docs/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md +++ b/docs/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md @@ -8,7 +8,7 @@ The `rancher-selinux` RPM only contains policies for the [rancher-logging applic The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/rancher-selinux) -# Installing the rancher-selinux RPM +## Installing the rancher-selinux RPM :::note Requirement: @@ -53,7 +53,7 @@ Install the RPM: yum -y install rancher-selinux ``` -# Configuring the Logging Application to Work with SELinux +## Configuring the Logging Application to Work with SELinux :::note Requirement: diff --git a/docs/reference-guides/rke1-template-example-yaml.md b/docs/reference-guides/rke1-template-example-yaml.md index 3c85e86d616..2be8946bfb7 100644 --- a/docs/reference-guides/rke1-template-example-yaml.md +++ b/docs/reference-guides/rke1-template-example-yaml.md @@ -1,5 +1,5 @@ --- -title: Example YAML +title: RKE1 Example YAML weight: 60 --- diff --git a/docs/reference-guides/single-node-rancher-in-docker/advanced-options.md b/docs/reference-guides/single-node-rancher-in-docker/advanced-options.md index c5cca0e8296..2a3005723fc 100644 --- a/docs/reference-guides/single-node-rancher-in-docker/advanced-options.md +++ b/docs/reference-guides/single-node-rancher-in-docker/advanced-options.md @@ -3,14 +3,6 @@ title: Advanced Options for Docker Installs weight: 5 --- -When installing Rancher, there are several advanced options that can be enabled: - -- [Custom CA Certificate](#custom-ca-certificate) -- [API Audit Log](#api-audit-log) -- [TLS Settings](#tls-settings) -- [Air Gap](#air-gap) -- [Persistent Data](#persistent-data) -- [Running `rancher/rancher` and `rancher/rancher-agent` on the Same Node](#running-rancher-rancher-and-rancher-rancher-agent-on-the-same-node) ### Custom CA Certificate diff --git a/docs/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md b/docs/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md index f83d241a08a..6f39f307282 100644 --- a/docs/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md +++ b/docs/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md @@ -5,25 +5,8 @@ weight: 1 This section contains commands and tips for troubleshooting nodes with the `etcd` role. -This page covers the following topics: -- [Checking if the etcd Container is Running](#checking-if-the-etcd-container-is-running) -- [etcd Container Logging](#etcd-container-logging) -- [etcd Cluster and Connectivity Checks](#etcd-cluster-and-connectivity-checks) - - [Check etcd Members on all Nodes](#check-etcd-members-on-all-nodes) - - [Check Endpoint Status](#check-endpoint-status) - - [Check Endpoint Health](#check-endpoint-health) - - [Check Connectivity on Port TCP/2379](#check-connectivity-on-port-tcp-2379) - - [Check Connectivity on Port TCP/2380](#check-connectivity-on-port-tcp-2380) -- [etcd Alarms](#etcd-alarms) -- [etcd Space Errors](#etcd-space-errors) -- [Log Level](#log-level) -- [etcd Content](#etcd-content) - - [Watch Streaming Events](#watch-streaming-events) - - [Query etcd Directly](#query-etcd-directly) -- [Replacing Unhealthy etcd Nodes](#replacing-unhealthy-etcd-nodes) - -# Checking if the etcd Container is Running +## Checking if the etcd Container is Running The container for etcd should have status **Up**. The duration shown after **Up** is the time the container has been running. @@ -37,7 +20,7 @@ CONTAINER ID IMAGE COMMAND CREAT 605a124503b9 rancher/coreos-etcd:v3.2.18 "/usr/local/bin/et..." 2 hours ago Up 2 hours etcd ``` -# etcd Container Logging +## etcd Container Logging The logging of the container can contain information on what the problem could be. @@ -52,7 +35,7 @@ docker logs etcd | `rafthttp: request cluster ID mismatch` | The node with the etcd instance logging `rafthttp: request cluster ID mismatch` is trying to join a cluster that has already been formed with another peer. The node should be removed from the cluster, and re-added. | | `rafthttp: failed to find member` | The cluster state (`/var/lib/etcd`) contains wrong information to join the cluster. The node should be removed from the cluster, the state directory should be cleaned and the node should be re-added. -# etcd Cluster and Connectivity Checks +## etcd Cluster and Connectivity Checks The address where etcd is listening depends on the address configuration of the host etcd is running on. If an internal address is configured for the host etcd is running on, the endpoint for `etcdctl` needs to be specified explicitly. If any of the commands respond with `Error: context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster) @@ -177,7 +160,7 @@ Validating connection to https://IP:2380/version {"etcdserver":"3.2.18","etcdcluster":"3.2.0"} ``` -# etcd Alarms +## etcd Alarms etcd will trigger alarms, for instance when it runs out of space. @@ -198,7 +181,7 @@ memberID:x alarm:NOSPACE memberID:x alarm:NOSPACE ``` -# etcd Space Errors +## etcd Space Errors Related error messages are `etcdserver: mvcc: database space exceeded` or `applying raft message exceeded backend quota`. Alarm `NOSPACE` will be triggered. @@ -298,7 +281,7 @@ docker exec etcd etcdctl alarm disarm docker exec etcd etcdctl alarm list ``` -# Log Level +## Log Level The log level of etcd can be changed dynamically via the API. You can configure debug logging using the commands below. @@ -324,7 +307,7 @@ Command when using etcd version lower than 3.3.x (Kubernetes 1.13.x and lower) a docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv ETCDCTL_ENDPOINT)/config/local/log ``` -# etcd Content +## etcd Content If you want to investigate the contents of your etcd, you can either watch streaming events or you can query etcd directly, see below for examples. @@ -360,6 +343,6 @@ You can process the data to get a summary of count per key, using the command be docker exec etcd etcdctl get /registry --prefix=true --keys-only | grep -v ^$ | awk -F'/' '{ if ($3 ~ /cattle.io/) {h[$3"/"$4]++} else { h[$3]++ }} END { for(k in h) print h[k], k }' | sort -nr ``` -# Replacing Unhealthy etcd Nodes +## Replacing Unhealthy etcd Nodes When a node in your etcd cluster becomes unhealthy, the recommended approach is to fix or remove the failed or unhealthy node before adding a new etcd node to the cluster. diff --git a/docs/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md b/docs/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md index 9e12c47125a..17b30b5d701 100644 --- a/docs/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md +++ b/docs/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md @@ -7,31 +7,8 @@ The commands/steps listed on this page can be used to check the most important K 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) - - [Get node conditions](#get-node-conditions) -- [Kubernetes leader election](#kubernetes-leader-election) - - [Kubernetes controller manager leader](#kubernetes-controller-manager-leader) - - [Kubernetes scheduler leader](#kubernetes-scheduler-leader) -- [Ingress controller](#ingress-controller) - - [Pod details](#pod-details) - - [Pod container logs](#pod-container-logs) - - [Namespace events](#namespace-events) - - [Debug logging](#debug-logging) - - [Check configuration](#check-configuration) -- [Rancher agents](#rancher-agents) - - [cattle-node-agent](#cattle-node-agent) - - [cattle-cluster-agent](#cattle-cluster-agent) -- [Jobs and pods](#jobs-and-pods) - - [Check that pods or jobs have status Running/Completed](#check-that-pods-or-jobs-have-status-running-completed) - - [Describe pod](#describe-pod) - - [Pod container logs](#pod-container-logs) - - [Describe job](#describe-job) - - [Logs from the containers of pods of the job](#logs-from-the-containers-of-pods-of-the-job) - - [Evicted pods](#evicted-pods) - - [Job does not complete](#job-does-not-complete) -# Nodes +## Nodes ### Get nodes @@ -76,7 +53,7 @@ Example output: worker-0: DiskPressure:True ``` -# Kubernetes leader election +## Kubernetes leader election ### Kubernetes Controller Manager leader @@ -96,7 +73,7 @@ kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.anno {"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}> ``` -# Ingress Controller +## Ingress Controller The default Ingress Controller is NGINX and is deployed as a DaemonSet in the `ingress-nginx` namespace. The pods are only scheduled to nodes with the `worker` role. @@ -160,7 +137,7 @@ Retrieve generated configuration in each pod: kubectl -n ingress-nginx get pods -l app=ingress-nginx --no-headers -o custom-columns=.NAME:.metadata.name | while read pod; do kubectl -n ingress-nginx exec $pod -- cat /etc/nginx/nginx.conf; done ``` -# Rancher agents +## Rancher agents Communication to the cluster (Kubernetes API via `cattle-cluster-agent`) and communication to the nodes (cluster provisioning via `cattle-node-agent`) is done through Rancher agents. @@ -212,7 +189,7 @@ Check logging of cattle-cluster-agent pod: kubectl -n cattle-system logs -l app=cattle-cluster-agent ``` -# Jobs and Pods +## Jobs and Pods ### Check that pods or jobs have status **Running**/**Completed** diff --git a/versioned_docs/version-2.0-2.4/contribute-to-rancher.md b/versioned_docs/version-2.0-2.4/contribute-to-rancher.md index da4e11a73ac..8c4b863b171 100644 --- a/versioned_docs/version-2.0-2.4/contribute-to-rancher.md +++ b/versioned_docs/version-2.0-2.4/contribute-to-rancher.md @@ -17,7 +17,7 @@ For more detailed information on how to contribute to the development of Rancher On the Rancher Users Slack, the channel for developers is **#developer**. -# Repositories +## Repositories All of repositories are located within our main GitHub organization. There are many repositories used for Rancher, but we'll provide descriptions of some of the main ones used in Rancher. @@ -41,13 +41,13 @@ To see all libraries/projects used in Rancher, see the [`go.mod` file](https://g ![Rancher diagram](/img/ranchercomponentsdiagram.svg)
Rancher components used for provisioning/managing Kubernetes clusters. -# Building +## Building Every repository should have a Makefile and can be built using the `make` command. The `make` targets are based on the scripts in the `/scripts` directory in the repository, and each target will use [Dapper](https://github.com/rancher/dapper) to run the target in an isolated environment. The `Dockerfile.dapper` will be used for this process, and includes all the necessary build tooling needed. The default target is `ci`, and will run `./scripts/validate`, `./scripts/build`, `./scripts/test` and `./scripts/package`. The resulting binaries of the build will be in `./build/bin` and are usually also packaged in a Docker image. -# Bugs, Issues or Questions +## Bugs, Issues or Questions If you find any bugs or are having any trouble, please search the [reported issue](https://github.com/rancher/rancher/issues) as someone may have experienced the same issue or we are actively working on a solution. @@ -113,7 +113,7 @@ Please follow this checklist when filing an issue which will helps us investigat - `/var/log/docker.log` - **Metrics:** If you are experiencing performance issues, please provide as much of data (files or screenshots) of metrics which can help determining what is going on. If you have an issue related to a machine, it helps to supply output of `top`, `free -m`, `df` which shows processes/memory/disk usage. -# Docs +## Docs If you have any updates to our documentation, please make any pull request to our docs repo. diff --git a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md index b1a58cb69c1..67e5d801129 100644 --- a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md +++ b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md @@ -12,10 +12,8 @@ This section lists the tests that are skipped in the permissive test profile for All the tests that are skipped and not applicable on this page will be counted as Not Applicable in the generated report. The skipped test count will only mention the user-defined skipped tests. This allows user-skipped tests to be distinguished from the tests that are skipped by default in the RKE permissive test profile. -- [CIS Benchmark v1.5](#cis-benchmark-v1-5) -- [CIS Benchmark v1.4](#cis-benchmark-v1-4) -# CIS Benchmark v1.5 +## CIS Benchmark v1.5 ### CIS Benchmark v1.5 Skipped Tests @@ -61,7 +59,7 @@ All the tests that are skipped and not applicable on this page will be counted a | 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. | -# CIS Benchmark v1.4 +## CIS Benchmark v1.4 The skipped and not applicable tests for CIS Benchmark v1.4 are as follows: diff --git a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/expression.md b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/expression.md index 5e85a787200..24aa96e50bc 100644 --- a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/expression.md +++ b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/expression.md @@ -15,68 +15,6 @@ The PromQL expressions in this doc can be used to configure [alerts.](../../../p For more information about querying Prometheus, refer to the official [Prometheus documentation.](https://prometheus.io/docs/prometheus/latest/querying/basics/) - - -- [Cluster Metrics](#cluster-metrics) - - [Cluster CPU Utilization](#cluster-cpu-utilization) - - [Cluster Load Average](#cluster-load-average) - - [Cluster Memory Utilization](#cluster-memory-utilization) - - [Cluster Disk Utilization](#cluster-disk-utilization) - - [Cluster Disk I/O](#cluster-disk-i-o) - - [Cluster Network Packets](#cluster-network-packets) - - [Cluster Network I/O](#cluster-network-i-o) -- [Node Metrics](#node-metrics) - - [Node CPU Utilization](#node-cpu-utilization) - - [Node Load Average](#node-load-average) - - [Node Memory Utilization](#node-memory-utilization) - - [Node Disk Utilization](#node-disk-utilization) - - [Node Disk I/O](#node-disk-i-o) - - [Node Network Packets](#node-network-packets) - - [Node Network I/O](#node-network-i-o) -- [Etcd Metrics](#etcd-metrics) - - [Etcd Has a Leader](#etcd-has-a-leader) - - [Number of Times the Leader Changes](#number-of-times-the-leader-changes) - - [Number of Failed Proposals](#number-of-failed-proposals) - - [GRPC Client Traffic](#grpc-client-traffic) - - [Peer Traffic](#peer-traffic) - - [DB Size](#db-size) - - [Active Streams](#active-streams) - - [Raft Proposals](#raft-proposals) - - [RPC Rate](#rpc-rate) - - [Disk Operations](#disk-operations) - - [Disk Sync Duration](#disk-sync-duration) -- [Kubernetes Components Metrics](#kubernetes-components-metrics) - - [API Server Request Latency](#api-server-request-latency) - - [API Server Request Rate](#api-server-request-rate) - - [Scheduling Failed Pods](#scheduling-failed-pods) - - [Controller Manager Queue Depth](#controller-manager-queue-depth) - - [Scheduler E2E Scheduling Latency](#scheduler-e2e-scheduling-latency) - - [Scheduler Preemption Attempts](#scheduler-preemption-attempts) - - [Ingress Controller Connections](#ingress-controller-connections) - - [Ingress Controller Request Process Time](#ingress-controller-request-process-time) -- [Rancher Logging Metrics](#rancher-logging-metrics) - - [Fluentd Buffer Queue Rate](#fluentd-buffer-queue-rate) - - [Fluentd Input Rate](#fluentd-input-rate) - - [Fluentd Output Errors Rate](#fluentd-output-errors-rate) - - [Fluentd Output Rate](#fluentd-output-rate) -- [Workload Metrics](#workload-metrics) - - [Workload CPU Utilization](#workload-cpu-utilization) - - [Workload Memory Utilization](#workload-memory-utilization) - - [Workload Network Packets](#workload-network-packets) - - [Workload Network I/O](#workload-network-i-o) - - [Workload Disk I/O](#workload-disk-i-o) -- [Pod Metrics](#pod-metrics) - - [Pod CPU Utilization](#pod-cpu-utilization) - - [Pod Memory Utilization](#pod-memory-utilization) - - [Pod Network Packets](#pod-network-packets) - - [Pod Network I/O](#pod-network-i-o) - - [Pod Disk I/O](#pod-disk-i-o) -- [Container Metrics](#container-metrics) - - [Container CPU Utilization](#container-cpu-utilization) - - [Container Memory Utilization](#container-memory-utilization) - - [Container Disk I/O](#container-disk-i-o) - - # Cluster Metrics diff --git a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/project-monitoring.md b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/project-monitoring.md index ad2ac7824e4..84026c59477 100644 --- a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/project-monitoring.md +++ b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/cluster-monitoring/project-monitoring.md @@ -11,13 +11,6 @@ _Available as of v2.2.4_ Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. -This section covers the following topics: - -- [Monitoring scope](#monitoring-scope) -- [Permissions to configure project monitoring](#permissions-to-configure-project-monitoring) -- [Enabling project monitoring](#enabling-project-monitoring) -- [Project-level monitoring resource requirements](#project-level-monitoring-resource-requirements) -- [Project metrics](#project-metrics) ### Monitoring Scope diff --git a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md index 8f4ea071ea3..f460ce16177 100644 --- a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md +++ b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md @@ -35,7 +35,7 @@ istio-pilot |discovery| 500m | 2048Mi | 1000m | 4096Mi | Y **Total** | **-** | **3950m** | **5546Mi** | **>12300m** | **>14848Mi** | **-** -# Configuring Resource Allocations +## Configuring Resource Allocations You can individually configure the resource allocation for each type of Istio component. This section includes the default resource allocations for each component. diff --git a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md index 14c9dc514ff..8d09cfff0db 100644 --- a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md +++ b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md @@ -22,13 +22,6 @@ Rancher integrates with a variety of popular IT services, including: - **DingTalk**: (Available as of v2.4.6) Send alert notifications to DingTalk using a webhook. - **Microsoft Teams**: (Available as of v2.4.6) Send alert notifications to Teams using a webhook. -This section covers the following topics: - -- [Roles-based access control for notifiers](#roles-based-access-control-for-notifiers) -- [Adding notifiers](#adding-notifiers) -- [Configuration](#configuration) -- [Managing notifiers](#managing-notifiers) -- [Example payload for a webhook alert notifier](#example-payload-for-a-webhook-alert-notifier) # Roles-based Access Control for Notifiers diff --git a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/opa-gatekeeper.md b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/opa-gatekeeper.md index 287a22f629d..cb5c6343874 100644 --- a/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/opa-gatekeeper.md +++ b/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/opa-gatekeeper.md @@ -21,13 +21,13 @@ OPA provides a high-level declarative language that lets you specify policy as c To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/) -# How the OPA Gatekeeper Integration Works +## How the OPA Gatekeeper Integration Works Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies. OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.` -# Enabling OPA Gatekeeper in a Cluster +## Enabling OPA Gatekeeper in a Cluster > **Prerequisites:** > @@ -39,7 +39,7 @@ OPA Gatekeeper is made available via Rancher's Helm system chart, and it is inst 1. To install Gatekeeper with the default configuration, click on **Enable Gatekeeper (v0.1.0) with defaults.** 1. To change any default configuration, click on **Customize Gatekeeper yaml configuration.** -# Constraint Templates +## Constraint Templates [Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/) @@ -49,7 +49,7 @@ To list the constraint templates installed in the cluster, go to the left side m Rancher also provides the ability to create your own constraint templates by importing YAML definitions. -# Creating and Configuring Constraints +## Creating and Configuring Constraints [Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together. @@ -71,7 +71,7 @@ To limit the scope of the constraint only to user namespaces, always specify the Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints. -# Enforcing Constraints in your Cluster +## Enforcing Constraints in your Cluster When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny.** @@ -79,7 +79,7 @@ When the **Enforcement Action** is **Dryrun,** then any resources that violate t To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny.** -# Audit and Violations in your Cluster +## Audit and Violations in your Cluster OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper. @@ -89,7 +89,7 @@ Also under **Constraints,** the number of violations of the constraint can be fo The detail view of each constraint lists information about the resource that violated the constraint. -# Disabling Gatekeeper +## Disabling Gatekeeper 1. Navigate to the cluster's Dashboard view 1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper.** diff --git a/versioned_docs/version-2.0-2.4/faq/rancher-is-no-longer-needed.md b/versioned_docs/version-2.0-2.4/faq/rancher-is-no-longer-needed.md index d2180ad5d71..ba6847d10b7 100644 --- a/versioned_docs/version-2.0-2.4/faq/rancher-is-no-longer-needed.md +++ b/versioned_docs/version-2.0-2.4/faq/rancher-is-no-longer-needed.md @@ -10,11 +10,6 @@ aliases: This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted. -- [If the Rancher server is deleted, what happens to the workloads in my downstream clusters?](#if-the-rancher-server-is-deleted-what-happens-to-the-workloads-in-my-downstream-clusters) -- [If the Rancher server is deleted, how do I access my downstream clusters?](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters) -- [What if I don't want Rancher anymore?](#what-if-i-don-t-want-rancher-anymore) -- [What if I don't want my imported cluster managed by Rancher?](#what-if-i-don-t-want-my-imported-cluster-managed-by-rancher) -- [What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?](#what-if-i-don-t-want-my-rke-cluster-or-hosted-kubernetes-cluster-managed-by-rancher) ### If the Rancher server is deleted, what happens to the workloads in my downstream clusters? diff --git a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md index 0b5d6ee3383..8d66e18655c 100644 --- a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md +++ b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md @@ -23,13 +23,6 @@ Make sure that your node fulfills the general [installation requirements.](../.. ## Installation Outline - - -- [1. Provision Linux Host](#1-provision-linux-host) -- [2. Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher) -- [3. Configure Load Balancer](#3-configure-load-balancer) - - ## 1. Provision Linux Host diff --git a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-4-lb.md b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-4-lb.md index 8235db92d70..603c26fe84b 100644 --- a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-4-lb.md +++ b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-4-lb.md @@ -29,22 +29,6 @@ In an HA setup that uses a layer 4 load balancer, the load balancer accepts Ranc Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete. - - -- [1. Provision Linux Hosts](#1-provision-linux-hosts) -- [2. Configure Load Balancer](#2-configure-load-balancer) -- [3. Configure DNS](#3-configure-dns) -- [4. Install RKE](#4-install-rke) -- [5. Download RKE Config File Template](#5-download-rke-config-file-template) -- [6. Configure Nodes](#6-configure-nodes) -- [7. Configure Certificates](#7-configure-certificates) -- [8. Configure FQDN](#8-configure-fqdn) -- [9. Configure Rancher version](#9-configure-rancher-version) -- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file) -- [11. Run RKE](#11-run-rke) -- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file) - -
diff --git a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-7-lb.md b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-7-lb.md index 15ddd45d774..16dd7b103ce 100644 --- a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-7-lb.md +++ b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/rke-add-on/layer-7-lb.md @@ -29,23 +29,6 @@ In an HA setup that uses a layer 7 load balancer, the load balancer accepts Ranc Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete. - - -- [1. Provision Linux Hosts](#1-provision-linux-hosts) -- [2. Configure Load Balancer](#2-configure-load-balancer) -- [3. Configure DNS](#3-configure-dns) -- [4. Install RKE](#4-install-rke) -- [5. Download RKE Config File Template](#5-download-rke-config-file-template) -- [6. Configure Nodes](#6-configure-nodes) -- [7. Configure Certificates](#7-configure-certificates) -- [8. Configure FQDN](#8-configure-fqdn) -- [9. Configure Rancher version](#9-configure-rancher-version) -- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file) -- [11. Run RKE](#11-run-rke) -- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file) - - - ## 1. Provision Linux Hosts Provision three Linux hosts according to our [Requirements](../../../../../pages-for-subheaders/installation-requirements.md). diff --git a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md index 19202707fbf..1a1314b2655 100644 --- a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md +++ b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md @@ -87,7 +87,7 @@ sudo ./get_helm.sh Next, create a YAML file that describes the RKE cluster. Ensure that the IP addresses of the nodes and the SSH username are correct. For more information on the cluster YAML, have a look at the [RKE documentation](https://rancher.com/docs/rke/latest/en/example-yamls/). -``` +```yml nodes: - address: 10.0.1.200 user: ubuntu diff --git a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md index e71a60861c9..b21d00950fc 100644 --- a/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md +++ b/versioned_docs/version-2.0-2.4/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md @@ -10,20 +10,6 @@ Following an upgrade to the latest version of Rancher, downstream Kubernetes clu Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/). -This section covers the following topics: - -- [New Features](#new-features) -- [Tested Kubernetes Versions](#tested-kubernetes-versions) -- [How Upgrades Work](#how-upgrades-work) -- [Recommended Best Practice for Upgrades](#recommended-best-practice-for-upgrades) -- [Upgrading the Kubernetes Version](#upgrading-the-kubernetes-version) -- [Rolling Back](#rolling-back) -- [Configuring the Upgrade Strategy](#configuring-the-upgrade-strategy) - - [Configuring the Maximum Unavailable Worker Nodes in the Rancher UI](#configuring-the-maximum-unavailable-worker-nodes-in-the-rancher-ui) - - [Enabling Draining Nodes During Upgrades from the Rancher UI](#enabling-draining-nodes-during-upgrades-from-the-rancher-ui) - - [Maintaining Availability for Applications During Upgrades](#maintaining-availability-for-applications-during-upgrades) - - [Configuring the Upgrade Strategy in the cluster.yml](#configuring-the-upgrade-strategy-in-the-cluster-yml) -- [Troubleshooting](#troubleshooting) # New Features diff --git a/versioned_docs/version-2.0-2.4/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.0-2.4/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index 4d1e56c7370..064f39ae9e4 100644 --- a/versioned_docs/version-2.0-2.4/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.0-2.4/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -14,18 +14,6 @@ Howdy Partner! This tutorial walks you through: This Quick Start Guide is divided into different tasks for easier consumption. - - - -1. [Provision a Linux Host](#1-provision-a-linux-host) - -1. [Install Rancher](#2-install-rancher) - -1. [Log In](#3-log-in) - -1. [Create the Cluster](#4-create-the-cluster) - -
### 1. Provision a Linux Host diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md index 572a081d03f..e58a1b75f64 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md @@ -23,16 +23,6 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco >**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later. - - -- [1. Register Rancher with Azure](#1-register-rancher-with-azure) -- [2. Create a new client secret](#2-create-a-new-client-secret) -- [3. Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher) -- [4. Add a Reply URL](#4-add-a-reply-url) -- [5. Copy Azure Application Data](#5-copy-azure-application-data) -- [6. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher) - - ### 1. Register Rancher with Azure diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md index 6d59d6af2a9..b2a12927645 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md @@ -11,12 +11,6 @@ As of Rancher v2.3.3, you can [save the configuration of an existing cluster as You can't change a cluster to use a different RKE template. You can only update the cluster to a new revision of the same template. -This section covers the following topics: - -- [Creating a cluster from an RKE template](#creating-a-cluster-from-an-rke-template) -- [Updating a cluster created with an RKE template](#updating-a-cluster-created-with-an-rke-template) -- [Converting an existing cluster to use an RKE template](#converting-an-existing-cluster-to-use-an-rke-template) - ### Creating a Cluster from an RKE Template To add a cluster [hosted by an infrastructure provider](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) using an RKE template, use these steps: diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md index 3d6fb987667..5df3a1f5a19 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md @@ -15,7 +15,7 @@ Users can only create new templates if the administrator [gives them permission. After a cluster is created with an RKE template, the cluster creator cannot edit settings that are defined in the template. The only way to change those settings after the cluster is created is to [upgrade the cluster to a new revision](apply-templates.md#updating-a-cluster-created-with-an-rke-template) of the same template. If cluster creators want to change template-defined settings, they would need to contact the template owner to get a new revision of the template. For details on how template revisions work, refer to the [documentation on revising templates.](manage-rke1-templates.md#updating-a-template) -# Requiring New Clusters to Use an RKE Template +## Requiring New Clusters to Use an RKE Template You might want to require new clusters to use a template to ensure that any cluster launched by a [standard user](../manage-role-based-access-control-rbac/global-permissions.md) will use the Kubernetes and/or Rancher settings that are vetted by administrators. @@ -27,7 +27,7 @@ To require new clusters to use an RKE template, administrators can turn on RKE t **Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator. -# Disabling RKE Template Enforcement +## Disabling RKE Template Enforcement To allow new clusters to be created without an RKE template, administrators can turn off RKE template enforcement with the following steps: diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md index 850fe6ce2f6..1f6f907a2eb 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md @@ -11,7 +11,7 @@ These example scenarios describe how an organization could use templates to stan - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to delegate ownership of the template, this scenario describes how [template ownership can be shared.](#allowing-other-users-to-control-and-share-a-template) -# Enforcing a Template Setting for Everyone +## Enforcing a Template Setting for Everyone Let's say there is an organization in which the administrators decide that all new clusters should be created with Kubernetes version 1.14. @@ -27,7 +27,7 @@ Let's say there is an organization in which the administrators decide that all n In this way, the administrators enforce the Kubernetes version across the organization, while still allowing end users to configure everything else. -# Templates for Basic and Advanced Users +## Templates for Basic and Advanced Users Let's say an organization has both basic and advanced users. Administrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want. @@ -42,7 +42,7 @@ Let's say an organization has both basic and advanced users. Administrators want **Result:** All Rancher users, except for administrators, are required to use a template when creating a cluster. Everyone has access to the restrictive template, but only advanced users have permission to use the more permissive template. The basic users are more restricted, while advanced users have more freedom when configuring their Kubernetes clusters. -# Updating Templates and Clusters Created with Them +## Updating Templates and Clusters Created with Them Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the administrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes. @@ -54,7 +54,7 @@ The template owner has several options for allowing the cluster creators to upgr - **Allow any Kubernetes version on the template:** When creating a template revision, the template owner can also mark the the Kubernetes version as **Allow User Override** using the switch near that setting on the Rancher UI. This will allow clusters that upgrade to this template revision to use any version of Kubernetes. - **Allow the latest minor Kubernetes version on the template:** The template owner can also create a template revision in which the Kubernetes version is defined as **Latest v1.14 (Allows patch version upgrades).** This means clusters that use that revision will be able to get patch version upgrades, but major version upgrades will not be allowed. -# Allowing Other Users to Control and Share a Template +## Allowing Other Users to Control and Share a Template Let's say Alice is a Rancher administrator. She owns an RKE template that reflects her organization's agreed-upon best practices for creating a cluster. diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md index 38524924ff6..749f2173717 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md @@ -29,7 +29,7 @@ Terraform allows you to: - Incorporate infrastructure changes into standard development practices - Prevent configuration drift, in which some servers become configured differently than others -# How Does Terraform Work? +## How Does Terraform Work? Terraform is written in files with the extension `.tf`. It is written in HashiCorp Configuration Language, which is a declarative language that lets you define the infrastructure you want in your cluster, the cloud provider you are using, and your credentials for the provider. Then Terraform makes API calls to the provider in order to efficiently create that infrastructure. @@ -39,7 +39,7 @@ Then Terraform calls the Rancher API to provision your infrastructure, and Ranch When you need to make changes to your infrastructure, instead of manually updating the servers, you can make changes in the Terraform configuration files. Then those files can be committed to version control, validated, and reviewed as necessary. Then when you run `terraform apply`, the changes would be deployed. -# Tips for Working with Terraform +## Tips for Working with Terraform - There are examples of how to provide most aspects of a cluster in the [documentation for the Rancher 2 provider.](https://www.terraform.io/docs/providers/rancher2/) @@ -51,7 +51,7 @@ When you need to make changes to your infrastructure, instead of manually updati - If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware. -# Tip for Creating CIS Benchmark Compliant Clusters +## Tip for Creating CIS Benchmark Compliant Clusters This section describes one way that you can make security and compliance-related config files standard in your clusters. @@ -63,7 +63,7 @@ Then you would make sure that the `kube-api-server` flag in your RKE template us In this way, you can create flags that comply with the CIS benchmark. -# Resources +## Resources - [Terraform documentation](https://www.terraform.io/docs/) - [Rancher2 Terraform provider documentation](https://www.terraform.io/docs/providers/rancher2/) diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md index 6b394eeeb97..cc179d8b89a 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md @@ -11,21 +11,6 @@ Template revisions can be used in two ways: to create a new cluster, or to upgra The template owner has full control over template revisions, and can create new revisions to update the template, delete or disable revisions that should not be used to create clusters, and choose which template revision is the default. -This section covers the following topics: - -- [Prerequisites](#prerequisites) -- [Creating a template](#creating-a-template) -- [Updating a template](#updating-a-template) -- [Deleting a template](#deleting-a-template) -- [Creating a revision based on the default revision](#creating-a-revision-based-on-the-default-revision) -- [Creating a revision based on a cloned revision](#creating-a-revision-based-on-a-cloned-revision) -- [Disabling a template revision](#disabling-a-template-revision) -- [Re-enabling a disabled template revision](#re-enabling-a-disabled-template-revision) -- [Setting a template revision as default](#setting-a-template-revision-as-default) -- [Deleting a template revision](#deleting-a-template-revision) -- [Upgrading a cluster to use a new template revision](#upgrading-a-cluster-to-use-a-new-template-revision) -- [Exporting a running cluster to a new RKE template and revision](#exporting-a-running-cluster-to-a-new-rke-template-and-revision) - ### Prerequisites You can create RKE templates if you have the **Create RKE Templates** permission, which can be [given by an administrator.](creator-permissions.md) diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md index d7be44bfc16..9a58163c995 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md @@ -11,16 +11,8 @@ _Pod Security Policies_ (or PSPs) are objects that control security-sensitive as If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod is forbidden: unable to validate...`. -- [How PSPs Work](#how-psps-work) -- [Default PSPs](#default-psps) - - [Restricted](#restricted) - - [Unrestricted](#unrestricted) -- [Creating PSPs](#creating-psps) - - [Requirements](#requirements) - - [Creating PSPs in the Rancher UI](#creating-psps-in-the-rancher-ui) -- [Configuration](#configuration) -# How PSPs Work +## How PSPs Work You can assign PSPs at the cluster or project level. @@ -34,7 +26,7 @@ Any workloads that are already running in a cluster or project before a PSP is a Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). -# Default PSPs +## Default PSPs _Available as of v2.0.7_ @@ -51,7 +43,7 @@ This policy is based on the Kubernetes [example restricted policy](https://raw.g This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project. -# Creating PSPs +## Creating PSPs Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file. @@ -76,7 +68,7 @@ We recommend adding PSPs during cluster and project creation instead of adding i 3. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does. -# Configuration +## Configuration The Kubernetes documentation on PSPs is [here.](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md index 59392800861..471b48c892a 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md @@ -14,7 +14,7 @@ For instructions on setting up a private registry with command line options duri If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster. -# Setting a Private Registry with No Credentials as the Default Registry +## Setting a Private Registry with No Credentials as the Default Registry 1. Log into Rancher and configure the default administrator password. @@ -32,7 +32,7 @@ If your private registry requires credentials, it cannot be used as the default **Result:** Rancher will use your private registry to pull system images. -# Setting a Private Registry with Credentials when Deploying a Cluster +## Setting a Private Registry with Credentials when Deploying a Cluster You can follow these steps to configure a private registry when you provision a cluster with Rancher: diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md index 71cc0ba754d..26f11198257 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md @@ -12,13 +12,6 @@ Within Rancher, _roles_ determine what actions a user can make within a cluster Note that _roles_ are different from _permissions_, which determine what clusters and projects you can access. -This section covers the following topics: - -- [Prerequisites](#prerequisites) -- [Creating a custom role for a cluster or project](#creating-a-custom-role-for-a-cluster-or-project) -- [Creating a custom global role](#creating-a-custom-global-role) -- [Deleting a custom global role](#deleting-a-custom-global-role) -- [Assigning a custom global role to a group](#assigning-a-custom-global-role-to-a-group) ## Prerequisites diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md index b9dd90f3d71..b2ae5dea843 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md @@ -15,17 +15,6 @@ Global Permissions define user authorization outside the scope of any particular You cannot update or delete the built-in Global Permissions. -This section covers the following topics: - -- [Global permission assignment](#global-permission-assignment) - - [Global permissions for new local users](#global-permissions-for-new-local-users) - - [Global permissions for users with external authentication](#global-permissions-for-users-with-external-authentication) -- [Custom global permissions](#custom-global-permissions) - - [Custom global permissions reference](#custom-global-permissions-reference) - - [Configuring default global permissions for new users](#configuring-default-global-permissions) - - [Configuring global permissions for existing individual users](#configuring-global-permissions-for-existing-individual-users) - - [Configuring global permissions for groups](#configuring-global-permissions-for-groups) - - [Refreshing group memberships](#refreshing-group-memberships) # Global Permission Assignment diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md index 6c815abefd4..b686020fe3f 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md @@ -14,12 +14,6 @@ This section describes how to manipulate your downstream Kubernetes cluster with For more information on using kubectl, see [Kubernetes Documentation: Overview of kubectl](https://kubernetes.io/docs/reference/kubectl/overview/). -- [Accessing clusters with kubectl shell in the Rancher UI](#accessing-clusters-with-kubectl-shell-in-the-rancher-ui) -- [Accessing clusters with kubectl from your workstation](#accessing-clusters-with-kubectl-from-your-workstation) -- [Note on Resources created using kubectl](#note-on-resources-created-using-kubectl) -- [Authenticating Directly with a Downstream Cluster](#authenticating-directly-with-a-downstream-cluster) - - [Connecting Directly to Clusters with FQDN Defined](#connecting-directly-to-clusters-with-fqdn-defined) - - [Connecting Directly to Clusters without FQDN Defined](#connecting-directly-to-clusters-without-fqdn-defined) ### Accessing Clusters with kubectl Shell in the Rancher UI @@ -52,7 +46,7 @@ This alternative method of accessing the cluster allows you to authenticate with Rancher will discover and show resources created by `kubectl`. However, these resources might not have all the necessary annotations on discovery. If an operation (for instance, scaling the workload) is done to the resource using the Rancher UI/API, this may trigger recreation of the resources due to the missing annotations. This should only happen the first time an operation is done to the discovered resource. -# Authenticating Directly with a Downstream Cluster +## Authenticating Directly with a Downstream Cluster This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/backing-up-etcd.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/backing-up-etcd.md index ec5122ad08b..5293be13f3c 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/backing-up-etcd.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/backing-up-etcd.md @@ -14,19 +14,6 @@ Rancher recommends configuring recurrent `etcd` snapshots for all production clu Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster. -This section covers the following topics: - -- [How snapshots work](#how-snapshots-work) -- [Configuring recurring snapshots](#configuring-recurring-snapshots) -- [One-time snapshots](#one-time-snapshots) -- [Snapshot backup targets](#snapshot-backup-targets) - - [Local backup target](#local-backup-target) - - [S3 backup target](#s3-backup-target) - - [Using a custom CA certificate for S3](#using-a-custom-ca-certificate-for-s3) - - [IAM Support for storing snapshots in S3](#iam-support-for-storing-snapshots-in-s3) -- [Viewing available snapshots](#viewing-available-snapshots) -- [Safe timestamps](#safe-timestamps) -- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0) # How Snapshots Work diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md index db37ec5d8cf..131cd7dda3f 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md @@ -20,15 +20,8 @@ For dynamic storage provisioning, your application will need to use a PVC that i For more information, refer to the [official Kubernetes documentation on storage](https://kubernetes.io/docs/concepts/storage/volumes/) -This section covers the following topics: -- [About persistent volume claims](#about-persistent-volume-claims) - - [PVCs are required for both new and existing persistent storage](#pvcs-are-required-for-both-new-and-existing-persistent-storage) -- [Setting up existing storage with a PVC and PV](#setting-up-existing-storage-with-a-pvc-and-pv) - - [Binding PVs to PVCs](#binding-pvs-to-pvcs) -- [Provisioning new storage with a PVC and storage class](#provisioning-new-storage-with-a-pvc-and-storage-class) - -# About Persistent Volume Claims +## About Persistent Volume Claims Persistent volume claims (PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. A PVC is mounted into a workloads as a volume so that the workload can claim its specified share of the persistent storage. @@ -48,7 +41,7 @@ Rancher lets you create as many PVCs within a project as you'd like. You can mount PVCs to a deployment as you create it, or later, after the deployment is running. -# Setting up Existing Storage with a PVC and PV +## Setting up Existing Storage with a PVC and PV Your pods can store data in [volumes,](https://kubernetes.io/docs/concepts/storage/volumes/) but if the pod fails, that data is lost. To solve this issue, Kubernetes offers persistent volumes (PVs), which are Kubernetes resources that correspond to external storage disks or file systems that your pods can access. If a pod crashes, its replacement pod can access the data in persistent storage without any data loss. @@ -68,7 +61,7 @@ In other words, you can create unlimited PVCs, but they will only be bound to PV To dynamically provision new storage, the PVC mounted in the pod would have to correspond to a storage class instead of a persistent volume. -# Provisioning New Storage with a PVC and Storage Class +## Provisioning New Storage with a PVC and Storage Class Storage Classes allow you to create PVs dynamically without having to create persistent storage in an infrastructure provider first. diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md index ad49d9dba58..cca3afc9b9e 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md @@ -9,11 +9,6 @@ To provide stateful workloads with vSphere storage, we recommend creating a vSph In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](../../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/vsphere.md) -- [Prerequisites](#prerequisites) -- [Creating a StorageClass](#creating-a-storageclass) -- [Creating a Workload with a vSphere Volume](#creating-a-workload-with-a-vsphere-volume) -- [Verifying Persistence of the Volume](#verifying-persistence-of-the-volume) -- [Why to Use StatefulSets Instead of Deployments](#why-to-use-statefulsets-instead-of-deployments) ### Prerequisites diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md index 06cd2b0ac0d..c9f834b9181 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md @@ -7,18 +7,8 @@ This guide will show you how to install and use [Kubernetes cluster-autoscaler]( We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`. -- [Prerequisites](#prerequisites) -- [1. Create a Custom Cluster](#1-create-a-custom-cluster) -- [2. Configure the Cloud Provider](#2-configure-the-cloud-provider) -- [3. Deploy Nodes](#3-deploy-nodes) -- [4. Install cluster-autoscaler](#4-install-cluster-autoscaler) - - [Parameters](#parameters) - - [Deployment](#deployment) -- [Testing](#testing) - - [Generating Load](#generating-load) - - [Checking Scale](#checking-scale) -# Prerequisites +## Prerequisites These elements are required to follow this guide: diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md index 699293b8c2c..2c9b78c2316 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md @@ -10,24 +10,6 @@ After you launch a Kubernetes cluster in Rancher, you can manage individual node > If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters](../../../pages-for-subheaders/cluster-configuration.md#editing-clusters-with-yaml). -This section covers the following topics: - -- [Node options available for each cluster creation option](#node-options-available-for-each-cluster-creation-option) - - [Nodes hosted by an infrastructure provider](#nodes-hosted-by-an-infrastructure-provider) - - [Nodes provisioned by hosted Kubernetes providers](#nodes-provisioned-by-hosted-kubernetes-providers) - - [Imported nodes](#imported-nodes) -- [Managing and editing individual nodes](#managing-and-editing-individual-nodes) -- [Viewing a node in the Rancher API](#viewing-a-node-in-the-rancher-api) -- [Deleting a node](#deleting-a-node) -- [Scaling nodes](#scaling-nodes) -- [SSH into a node hosted by an infrastructure provider](#ssh-into-a-node-hosted-by-an-infrastructure-provider) -- [Cordoning a node](#cordoning-a-node) -- [Draining a node](#draining-a-node) - - [Aggressive and safe draining options](#aggressive-and-safe-draining-options) - - [Grace period](#grace-period) - - [Timeout](#timeout) - - [Drained and cordoned state](#drained-and-cordoned-state) -- [Labeling a node to be ignored by Rancher](#labeling-a-node-to-be-ignored-by-rancher) # Node Options Available for Each Cluster Creation Option diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md index 98928c96eff..4f05ad22973 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md @@ -15,16 +15,8 @@ A project is a group of namespaces, and it is a concept introduced by Rancher. P This section describes how projects and namespaces work with Rancher. It covers the following topics: -- [About namespaces](#about-namespaces) -- [About projects](#about-projects) - - [The cluster's default project](#the-cluster-s-default-project) - - [The system project](#the-system-project) -- [Project authorization](#project-authorization) -- [Pod security policies](#pod-security-policies) -- [Creating projects](#creating-projects) -- [Switching between clusters and projects](#switching-between-clusters-and-projects) -# About Namespaces +## About Namespaces A namespace is a concept introduced by Kubernetes. According to the [official Kubernetes documentation on namespaces,](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) @@ -62,7 +54,7 @@ If your permissions are restricted to the project level, it is better to [create If a standard user is a project owner, the user will be able to create namespaces within that project. The Rancher UI will prevent that user from creating namespaces outside the scope of the projects they have access to. -# About Projects +## About Projects In terms of hierarchy: @@ -115,18 +107,18 @@ The `system` project: > >The `system` project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health. -# Project Authorization +## Project Authorization Standard users are only authorized for project access in two situations: - An administrator, cluster owner or cluster member explicitly adds the standard user to the project's **Members** tab. - Standard users can access projects that they create themselves. -# Pod Security Policies +## Pod Security Policies Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policluster-admin/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level. -# Creating Projects +## Creating Projects This section describes how to create a new project with a name and with optional pod security policy, members, and resource quotas. @@ -194,7 +186,7 @@ To add a resource quota, | Project Limit | The overall resource limit for the project. | | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project when created. The combined limit of all project namespaces shouldn't exceed the project limit. | -# Switching between Clusters and Projects +## Switching between Clusters and Projects To switch between clusters and projects, use the **Global** drop-down available in the main menu. diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/restoring-etcd.md b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/restoring-etcd.md index 49a1a9b014f..ea5ebc8cb3c 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/restoring-etcd.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/advanced-user-guides/manage-clusters/restoring-etcd.md @@ -14,12 +14,6 @@ Rancher recommends enabling the [ability to set up recurring snapshots of etcd]( As of Rancher v2.4.0, clusters can also be restored to a prior Kubernetes version and cluster configuration. -This section covers the following topics: - -- [Viewing Available Snapshots](#viewing-available-snapshots) -- [Restoring a Cluster from a Snapshot](#restoring-a-cluster-from-a-snapshot) -- [Recovering etcd without a Snapshot](#recovering-etcd-without-a-snapshot) -- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0) ## Viewing Available Snapshots @@ -111,6 +105,6 @@ If the group of etcd nodes loses quorum, the Kubernetes cluster will report a fa 6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster](../../../pages-for-subheaders/use-existing-nodes.md) and you want to reuse an old node, you are required to [clean up the nodes](./clean-cluster-nodes.md) before attempting to add them back into a cluster. -# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0 +## Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0 If you have any Rancher launched Kubernetes clusters that were created before v2.2.0, after upgrading Rancher, you must [edit the cluster](../../../pages-for-subheaders/cluster-configuration.md) and _save_ it, in order to enable the updated snapshot features. Even if you were already creating snapshots before v2.2.0, you must do this step as the older snapshots will not be available to use to [back up and restore etcd through the UI](restoring-etcd.md). diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md index e3f27b53d49..35c008542ac 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md @@ -17,16 +17,6 @@ This will restore the Kubernetes configuration and the Rancher database and stat > **Note:** This document covers clusters set up with RKE >= v0.2.x, for older RKE versions refer to the [RKE Documentation](https://rancher.com/docs/rke/latest/en/etcd-snapshots/restoring-from-backup). -## Restore Outline - - - -- [1. Preparation](#1-preparation) -- [2. Place Snapshot](#2-place-snapshot) -- [3. Configure RKE](#3-configure-rke) -- [4. Restore the Database and bring up the Cluster](#4-restore-the-database-and-bring-up-the-cluster) - - ### 1. Preparation diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/creating-apps.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/creating-apps.md index b834c3aef1a..53a2b785ac5 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/creating-apps.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/helm-charts-in-rancher/creating-apps.md @@ -13,15 +13,6 @@ Rancher's catalog service requires any custom catalogs to be structured in a spe > 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 diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md index bbb9851ed5b..4efca77715d 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md @@ -5,7 +5,7 @@ weight: 1 There are three roles that can be assigned to nodes: `etcd`, `controlplane` and `worker`. -# Separating Worker Nodes from Nodes with Other Roles +## Separating Worker Nodes from Nodes with Other Roles When designing your cluster(s), you have two options: @@ -21,7 +21,7 @@ Therefore, each node should have one of the following role configurations: * Both `etcd` and `controlplane` * `worker` -# Recommended Number of Nodes with Each Role +## Recommended Number of Nodes with Each Role The cluster should have: @@ -69,6 +69,6 @@ You may have noticed that our [Kubernetes Install](../../../../pages-for-subhead * It maintains multiple instances of the master components by having multiple `controlplane` nodes. * No other workloads than Rancher itself should be created on this cluster. -# References +## References * [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components) diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md index 000b537c110..548ff88ba96 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md @@ -14,7 +14,7 @@ If you are using Calico, 1. Go to the cluster view in the Rancher UI, and click **⋮ > Edit.** 1. Click **Edit as YAML,** and enter the following configuration: - ``` + ```yaml rancher_kubernetes_engine_config: cloud_provider: name: gce @@ -36,7 +36,7 @@ If you are using Canal or Flannel, 1. Go to the cluster view in the Rancher UI, and click **⋮ > Edit.** 1. Click **Edit as YAML,** and enter the following configuration: - ``` + ```yaml rancher_kubernetes_engine_config: cloud_provider: name: gce diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index 82416b404d8..29640a42ea7 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -50,7 +50,7 @@ The free ESXi license does not support API access. The vSphere servers must have If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes. -# Creating a vSphere Cluster +## Creating a vSphere Cluster The a vSphere cluster is created in Rancher depends on the Rancher version. @@ -142,7 +142,7 @@ You can access your cluster after its state is updated to **Active.** -# Optional Next Steps +## Optional Next Steps After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster: diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/v2.1-v2.2.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/v2.1-v2.2.md index ca2456c5011..2caa61deb9a 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/v2.1-v2.2.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/v2.1-v2.2.md @@ -32,17 +32,6 @@ For a summary of Kubernetes features supported in Windows, see [Using Windows in When setting up a custom cluster with support for Windows nodes and containers, complete the series of tasks below. - - -- [1. Provision Hosts](#1-provision-hosts) -- [2. Cloud-host VM Networking Configuration](#2-cloud-hosted-vm-networking-configuration) -- [3. Create the Custom Cluster](#3-create-the-custom-cluster) -- [4. Add Linux Host for Ingress Support](#4-add-linux-host-for-ingress-support) -- [5. Adding Windows Workers](#5-adding-windows-workers) -- [6. Cloud-host VM Routes Configuration](#6-cloud-hosted-vm-routes-configuration) - - - ## 1. Provision Hosts To begin provisioning a custom cluster with Windows support, prepare your host servers. Provision three nodes according to our [requirements](../../../../../pages-for-subheaders/installation-requirements.md)—two Linux, one Windows. Your hosts can be: diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md index 297cf50a406..bd7e623e129 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md @@ -10,14 +10,7 @@ This page describes the requirements for the Rancher managed Kubernetes clusters > If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.](../../../pages-for-subheaders/installation-requirements.md) -Make sure the nodes for the Rancher server fulfill the following requirements: - -- [Operating systems and container runtime requirements](#operating-systems-and-container-runtime-requirements) -- [Hardware Requirements](#hardware-requirements) -- [Networking Requirements](#networking-requirements) -- [Optional: Security Considerations](#optional-security-considerations) - -# Operating Systems and Container Runtime Requirements +## Operating Systems and Container Runtime Requirements Rancher should work with any modern Linux distribution and any modern Docker version. Linux is required for the etcd and controlplane nodes of all downstream clusters. Worker nodes may run Linux or [Windows Server.](#windows-nodes) The capability to use Windows worker nodes in downstream clusters was added in Rancher v2.3.0. @@ -94,7 +87,7 @@ Nodes with Windows Server must run Docker Enterprise Edition. Windows nodes can be used for worker nodes only. See [Configuring Custom Clusters for Windows](../../../pages-for-subheaders/use-windows-clusters.md) -# Hardware Requirements +## Hardware Requirements 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. @@ -104,7 +97,7 @@ For hardware recommendations for large Kubernetes clusters, refer to the officia For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/) -# Networking Requirements +## Networking Requirements For a production cluster, we recommend that you restrict traffic by opening only the ports defined in the port requirements below. @@ -114,7 +107,7 @@ For a breakdown of the port requirements for etcd nodes, controlplane nodes, and Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#downstream-kubernetes-cluster-nodes). -# Optional: Security Considerations +## Optional: Security Considerations If you want to provision a Kubernetes cluster that is compliant with the CIS (Center for Internet Security) Kubernetes Benchmark, we recommend to following our hardening guide to configure your nodes before installing Kubernetes. diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md index d0e156615b3..a11ef38a44b 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md @@ -42,7 +42,7 @@ You can access your cluster after its state is updated to **Active.** - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Huawei CCE Configuration +## Huawei CCE Configuration |Settings|Description| |---|---| @@ -61,7 +61,7 @@ You can access your cluster after its state is updated to **Active.** **Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that as of Rancher v2.3.0, cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure in Rancher v2.3.0+.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#config-file-structure-in-rancher-v2-3-0) -# Node Configuration +## Node Configuration |Settings|Description| |---|---| diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md index 6694fe7c3ce..335c0fe861d 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md @@ -69,7 +69,7 @@ The secret has to be created in the same namespace where the workload gets deplo Below is an example `pod.yml` for a workload that uses an image from a private registry. In this example, the pod uses an image from Quay.io, and the .yml specifies the path to the image. The pod authenticates with the registry using credentials stored in a Kubernetes secret called `testquay`, which is specified in `spec.imagePullSecrets` in the `name` field: -``` +```yaml apiVersion: v1 kind: Pod metadata: diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/discover-services.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/discover-services.md index 6b3b7feeede..b07f2fd4a0a 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/discover-services.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/discover-services.md @@ -13,17 +13,6 @@ This document will also show you how to link the workloads and services that you ![Resolve Link Directive](/img/resolve-links.png) -## In This Document - - - - -- [Service Discovery: Rancher v1.6 vs. v2.x](#service-discovery-rancher-v1-6-vs-v2-x) -- [Service Discovery Within and Across Namespaces](#service-discovery-within-and-across-namespaces) -- [Container Discovery](#container-discovery) -- [Service Name Alias Creation](#service-name-alias-creation) - - ## Service Discovery: Rancher v1.6 vs. v2.x diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/expose-services.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/expose-services.md index 2901cbeb91b..1b0bcc8e1a6 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/expose-services.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/expose-services.md @@ -14,18 +14,6 @@ Use this document to correct workloads that list `ports` in `output.txt`. You ca ![Resolve Ports](/img/resolve-ports.png) -## In This Document - - - -- [What's Different About Exposing Services in Rancher v2.x?](#what-s-different-about-exposing-services-in-rancher-v2-x) -- [HostPorts](#hostport) -- [Setting HostPort](#setting-hostport) -- [NodePorts](#nodeport) -- [Setting NodePort](#setting-nodeport) - - - ## What's Different About Exposing Services in Rancher v2.x? In Rancher v1.6, we used the term _Port Mapping_ for exposing an IP address and port where your you and your users can access a service. diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/install-and-configure-rancher.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/install-and-configure-rancher.md index 7deaf5c0e7e..fddb7f51a25 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/install-and-configure-rancher.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/install-and-configure-rancher.md @@ -6,18 +6,6 @@ aliases: --- Get started with your migration to Rancher v2.x by installing Rancher and configuring your new Rancher environment. -## Outline - - - -- [A. Install Rancher v2.x](#a-install-rancher-v2-x) -- [B. Configure Authentication](#b-configure-authentication) -- [C. Provision a Cluster and Project](#c-provision-a-cluster-and-project) -- [D. Create Stacks](#d-create-stacks) - - - - ## A. Install Rancher v2.x The first step in migrating from v1.6 to v2.x is to install the Rancher v2.x Server side-by-side with your v1.6 Server, as you'll need your old install during the migration process. Due to the architecture changes between v1.6 and v2.x, there is no direct path for upgrade. You'll have to install v2.x independently and then migrate your v1.6 services to v2.x. diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/load-balancing.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/load-balancing.md index 33f2a948478..f6d22af159d 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/load-balancing.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/load-balancing.md @@ -15,18 +15,6 @@ If you encounter the `output.txt` text below after parsing your v1.6 Compose fil ![Resolve Load Balancer Directive](/img/resolve-load-balancer.png) -## In This Document - - - -- [Load Balancing Protocol Options](#load-balancing-protocol-options) -- [Load Balancer Deployment](#load-balancer-deployment) -- [Load Balancing Architecture](#load-balancing-architecture) -- [Ingress Caveats](#ingress-caveats) -- [Deploying Ingress](#deploying-ingress) -- [Rancher v2.x Load Balancing Limitations](#rancher-v2-x-load-balancing-limitations) - - ## Load Balancing Protocol Options diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/migrate-services.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/migrate-services.md index 205734bb643..b07af309fce 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/migrate-services.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/migrate-services.md @@ -18,19 +18,6 @@ This command line interface tool will: - Parse Compose files that you’ve exported from your Rancher v1.6 stacks and converts them to Kubernetes manifests that Rancher v2.x can consume. The tool also outputs a list of directives present in the Compose files that cannot be converted automatically to Rancher v2.x. These are directives that you’ll have to manually configure using the Rancher v2.x UI. -## Outline - - - -- [A. Download the migration-tools CLI](#a-download-the-migration-tools-cli) -- [B. Configure the migration-tools CLI](#b-configure-the-migration-tools-cli) -- [C. Run the migration-tools CLI](#c-run-the-migration-tools-cli) -- [D. Deploy Services Using Rancher CLI](#d-re-deploy-services-as-kubernetes-manifests) -- [What Now?](#what-now) - - - - ## A. Download the migration-tools CLI diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/monitor-apps.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/monitor-apps.md index e1f163f5123..935ecce54e1 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/monitor-apps.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/monitor-apps.md @@ -20,15 +20,6 @@ For example, for the image below, we would configure liveness probes for the `we ![Resolve health_check](/img/resolve-health-checks.png) -## In This Document - - - -- [Rancher v1.6 Health Checks](#rancher-v1-6-health-checks) -- [Rancher v2.x Health Checks](#rancher-v2-x-health-checks) -- [Configuring Probes in Rancher v2.x](#configuring-probes-in-rancher-v2-x) - - ## Rancher v1.6 Health Checks diff --git a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/schedule-services.md b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/schedule-services.md index 965a85165e8..8529eb78113 100644 --- a/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/schedule-services.md +++ b/versioned_docs/version-2.0-2.4/how-to-guides/new-user-guides/migrate-from-v1.6-v2.x/schedule-services.md @@ -17,22 +17,9 @@ You can schedule your migrated v1.6 services while editing a deployment. Schedul ![Workload Type and Node Scheduling Sections](/img/migrate-schedule-workloads.png) -## In This Document - - -- [What's Different for Scheduling Services?](#whats-different-for-scheduling-services) -- [Node Scheduling Options](#node-scheduling-options) -- [Scheduling Pods to a Specific Node](#scheduling-pods-to-a-specific-node) -- [Scheduling Using Labels](#scheduling-using-labels) -- [Scheduling Pods Using Resource Constraints](#scheduling-pods-using-resource-constraints) -- [Preventing Scheduling Specific Services to Specific Nodes](#preventing-scheduling-specific-services-to-specific-nodes) -- [Scheduling Global Services](#scheduling-global-services) - - - ## What's Different for Scheduling Services? diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/about-rke1-templates.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/about-rke1-templates.md index 00998ad99a5..d9a212eb719 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/about-rke1-templates.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/about-rke1-templates.md @@ -28,7 +28,7 @@ The core features of RKE templates allow DevOps and security teams to: - Control which users can create templates - Require users to create clusters from a template -# Configurable Settings +## Configurable Settings RKE templates can be created in the Rancher UI or defined in YAML format. They can define all the same parameters that can be specified when you use Rancher to provision custom nodes or nodes from an infrastructure provider: @@ -44,7 +44,7 @@ RKE templates can be created in the Rancher UI or defined in YAML format. They c The [add-on section](#add-ons) of an RKE template is especially powerful because it allows a wide range of customization options. -# Scope of RKE Templates +## Scope of RKE Templates RKE templates are supported for Rancher-provisioned clusters. The templates can be used to provision custom clusters or clusters that are launched by an infrastructure provider. @@ -55,7 +55,7 @@ RKE templates can be created from scratch to pre-define cluster configuration. T As of v2.3.3, the settings of an existing cluster can be [saved as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) This creates a new template and binds the cluster settings to the template, so that the cluster can only be upgraded if the [template is updated](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#updating-a-template), and the cluster is upgraded to [use a newer version of the template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) The new template can also be used to create new clusters. -# Example Scenarios +## Example Scenarios When an organization has both basic and advanced Rancher users, administrators might want to give the advanced users more options for cluster creation, while restricting the options for basic users. These [example scenarios](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md) describe how an organization could use templates to standardize cluster creation. @@ -67,7 +67,7 @@ Some of the example scenarios include the following: - **Updating template settings:** If an organization's security and DevOps teams decide to embed best practices into the required settings for new clusters, those best practices could change over time. If the best practices change, [a template can be updated to a new revision](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#updating-templates-and-clusters-created-with-them) and clusters created from the template can [upgrade to the new version](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) of the template. - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to share ownership of the template, this scenario describes how [template ownership can be shared.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#allowing-other-users-to-control-and-share-a-template) -# Template Management +## Template Management When you create an RKE template, it is available in the Rancher UI from the **Global** view under **Tools > RKE Templates.** When you create a template, you become the template owner, which gives you permission to revise and share the template. You can share the RKE templates with specific users or groups, and you can also make it public. @@ -90,7 +90,7 @@ The documents in this section explain the details of RKE template management: An [example YAML configuration file for a template](../reference-guides/rke1-template-example-yaml.md) is provided for reference. -# Applying Templates +## Applying Templates You can [create a cluster from a template](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#creating-a-cluster-from-an-rke-template) that you created, or from a template that has been [shared with you.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/access-or-share-templates.md) @@ -100,11 +100,11 @@ RKE templates can be created from scratch to pre-define cluster configuration. T As of Rancher v2.3.3, you can [save the configuration of an existing cluster as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) Then the cluster's settings can only be changed if the template is updated. -# Standardizing Hardware +## Standardizing Hardware RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjunction with other tools](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md). -# YAML Customization +## YAML Customization If you define an RKE template as a YAML file, you can modify this [example RKE template YAML](../reference-guides/rke1-template-example-yaml.md). The YAML in the RKE template uses the same customization that Rancher uses when creating an RKE cluster, but since the YAML is located within the context of a Rancher provisioned cluster, you will need to nest the RKE template customization under the `rancher_kubernetes_engine_config` directive in the YAML. diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-alerts.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-alerts.md index 0ffe482dcfe..87186ee0f3d 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-alerts.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-alerts.md @@ -11,22 +11,6 @@ aliases: To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions. -This section covers the following topics: - -- [About Alerts](#about-alerts) - - [Alert Event Examples](#alert-event-examples) - - [Alerts Triggered by Prometheus Queries](#alerts-triggered-by-prometheus-queries) - - [Urgency Levels](#urgency-levels) - - [Scope of Alerts](#scope-of-alerts) - - [Managing Cluster Alerts](#managing-cluster-alerts) -- [Adding Cluster Alerts](#adding-cluster-alerts) -- [Cluster Alert Configuration](#cluster-alert-configuration) - - [System Service Alerts](#system-service-alerts) - - [Resource Event Alerts](#resource-event-alerts) - - [Node Alerts](#node-alerts) - - [Node Selector Alerts](#node-selector-alerts) - - [CIS Scan Alerts](#cis-scan-alerts) - - [Metric Expression Alerts](#metric-expression-alerts) # About Alerts diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-logging.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-logging.md index 0888dd724ab..20d98a45aea 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-logging.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-logging.md @@ -29,12 +29,6 @@ Rancher supports integration with the following services: - Syslog - Fluentd -This section covers the following topics: - -- [How logging integrations work](#how-logging-integrations-work) -- [Requirements](#requirements) -- [Logging scope](#logging-scope) -- [Enabling cluster logging](#enabling-cluster-logging) # How Logging Integrations Work diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-monitoring.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-monitoring.md index ec0e50a53bc..7592cdf4b46 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-monitoring.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/cluster-monitoring.md @@ -16,15 +16,6 @@ _Available as of v2.2.0_ Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. -This section covers the following topics: - -- [About Prometheus](#about-prometheus) -- [Monitoring scope](#monitoring-scope) -- [Enabling cluster monitoring](#enabling-cluster-monitoring) -- [Resource consumption](#resource-consumption) - - [Resource consumption of Prometheus pods](#resource-consumption-of-prometheus-pods) - - [Resource consumption of other pods](#resource-consumption-of-other-pods) - # About Prometheus Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/): diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/configure-shibboleth-saml.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/configure-shibboleth-saml.md index 6875687246e..6f6e8bf7a49 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/configure-shibboleth-saml.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/configure-shibboleth-saml.md @@ -13,16 +13,6 @@ If you also configure OpenLDAP as the back end to Shibboleth, it will return a S > The instructions in this section assume that you understand how Rancher, Shibboleth, and OpenLDAP work together. For a more detailed explanation of how it works, refer to [this page.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/configure-shibboleth-saml/about-group-permissions.md) -This section covers the following topics: - -- [Setting up Shibboleth in Rancher](#setting-up-shibboleth-in-rancher) - - [Shibboleth Prerequisites](#shibboleth-prerequisites) - - [Configure Shibboleth in Rancher](#configure-shibboleth-in-rancher) - - [SAML Provider Caveats](#saml-provider-caveats) -- [Setting up OpenLDAP in Rancher](#setting-up-openldap-in-rancher) - - [OpenLDAP Prerequisites](#openldap-prerequisites) - - [Configure OpenLDAP in Rancher](#configure-openldap-in-rancher) - - [Troubleshooting](#troubleshooting) # Setting up Shibboleth in Rancher diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md index e62e8155e81..ef7efb0705f 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm-charts-in-rancher.md @@ -17,19 +17,7 @@ Rancher provides the ability to use a catalog of Helm charts that make it easy t Rancher improves on Helm catalogs and charts. All native Helm charts can work within Rancher, but Rancher adds several enhancements to improve their user experience. -This section covers the following topics: - -- [Catalog scopes](#catalog-scopes) -- [Catalog Helm Deployment Versions](#catalog-helm-deployment-versions) -- [When to use Helm 3](#when-to-use-helm-3) -- [Helm 3 Backwards Compatibility](#helm-3-backwards-compatibility) -- [Built-in global catalogs](#built-in-global-catalogs) -- [Custom catalogs](#custom-catalogs) -- [Creating and launching applications](#creating-and-launching-applications) -- [Chart compatibility with Rancher](#chart-compatibility-with-rancher) -- [Global DNS](#global-dns) - -# Catalog Scopes +## Catalog Scopes Within Rancher, you can manage catalogs at three different scopes. Global catalogs are shared across all clusters and project. There are some use cases where you might not want to share catalogs between different clusters or even projects in the same cluster. By leveraging cluster and project scoped catalogs, you will be able to provide applications for specific teams without needing to share them with all clusters and/or projects. @@ -39,7 +27,7 @@ Global | All clusters and all projects can access the Helm charts in this catalo Cluster | All projects in the specific cluster can access the Helm charts in this catalog | v2.2.0 | Project | This specific cluster can access the Helm charts in this catalog | v2.2.0 | -# Catalog Helm Deployment Versions +## Catalog Helm Deployment Versions _Applicable as of v2.4.0_ @@ -53,7 +41,7 @@ By default, catalogs are assumed to be deployed using Helm 2. If you run an app Charts that are specific to Helm 2 should only be added to a Helm 2 catalog, and Helm 3 specific charts should only be added to a Helm 3 catalog. -# When to use Helm 3 +## When to use Helm 3 _Applicable as of v2.4.0_ @@ -62,7 +50,7 @@ _Applicable as of v2.4.0_ Overall Helm 3 is a movement towards a more standardized Kubernetes feel. As the Kubernetes community has evolved, standards and best practices have as well. Helm 3 is an attempt to adopt those practices and streamline how charts are maintained. -# Helm 3 Backwards Compatibility +## Helm 3 Backwards Compatibility _Applicable as of v2.4.0_ @@ -72,31 +60,25 @@ Helm 3 does not create a namespace for you, so you will have to provide an exist apiVersion `v2` is now reserved for Helm 3 charts. This apiVersion enforcement could cause issues as older versions of Helm 2 did not validate the apiVersion in the `Chart.yaml` file. In general, your Helm 2 chart’s apiVersion should be set to `v1` and your Helm 3 chart’s apiVersion should be set to `v2`. You can install charts with apiVersion `v1` with Helm 3, but you cannot install `v2` charts into Helm 2. -# Built-in Global Catalogs +## Built-in Global Catalogs Within Rancher, there are default catalogs packaged as part of Rancher. These can be enabled or disabled by an administrator. For details, refer to the section on managing [built-in global catalogs.](../how-to-guides/new-user-guides/helm-charts-in-rancher/built-in.md) -# Custom Catalogs +## Custom Catalogs There are two types of catalogs in Rancher: [Built-in global catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/built-in.md) and [custom catalogs.](../how-to-guides/new-user-guides/helm-charts-in-rancher/adding-catalogs.md) Any user can create custom catalogs to add into Rancher. Custom catalogs can be added into Rancher at the global level, cluster level, or project level. For details, refer to the [section on adding custom catalogs](../how-to-guides/new-user-guides/helm-charts-in-rancher/adding-catalogs.md) and the [catalog configuration reference.](../how-to-guides/new-user-guides/helm-charts-in-rancher/catalog-config.md) -# Creating and Launching Applications +## Creating and Launching Applications -In Rancher, applications are deployed from the templates in a catalog. This section covers the following topics: +In Rancher, applications are deployed from the templates in a catalog. -* [Multi-cluster applications](../how-to-guides/new-user-guides/helm-charts-in-rancher/multi-cluster-apps.md) -* [Creating catalog apps](../how-to-guides/new-user-guides/helm-charts-in-rancher/creating-apps.md) -* [Launching catalog apps within a project](../how-to-guides/new-user-guides/helm-charts-in-rancher/launching-apps.md) -* [Managing catalog apps](../how-to-guides/new-user-guides/helm-charts-in-rancher/managing-apps.md) -* [Tutorial: Example custom chart creation](../how-to-guides/new-user-guides/helm-charts-in-rancher/tutorial.md) - -# Chart Compatibility with Rancher +## Chart Compatibility with Rancher Charts now support the fields `rancher_min_version` and `rancher_max_version` in the [`questions.yml` file](https://github.com/rancher/integration-test-charts/blob/master/charts/chartmuseum/v1.6.0/questions.yml) to specify the versions of Rancher that the chart is compatible with. When using the UI, only app versions that are valid for the version of Rancher running will be shown. API validation is done to ensure apps that don't meet the Rancher requirements cannot be launched. An app that is already running will not be affected on a Rancher upgrade if the newer Rancher version does not meet the app's requirements. -# Global DNS +## Global DNS _Available as v2.2.0_ diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-4-lb.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-4-lb.md index e21f49c8940..4be5a038d84 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-4-lb.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-4-lb.md @@ -23,27 +23,6 @@ In a Kubernetes setup that uses a layer 4 load balancer, the load balancer accep Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers ![High-availability Kubernetes installation of Rancher](/img/ha/rancher2ha.svg) -## Installation Outline - -Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete. - - - -- [1. Provision Linux Hosts](#1-provision-linux-hosts) -- [2. Configure Load Balancer](#2-configure-load-balancer) -- [3. Configure DNS](#3-configure-dns) -- [4. Install RKE](#4-install-rke) -- [5. Download RKE Config File Template](#5-download-rke-config-file-template) -- [6. Configure Nodes](#6-configure-nodes) -- [7. Configure Certificates](#7-configure-certificates) -- [8. Configure FQDN](#8-configure-fqdn) -- [9. Configure Rancher version](#9-configure-rancher-version) -- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file) -- [11. Run RKE](#11-run-rke) -- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file) - - -
## 1. Provision Linux Hosts diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-7-lb.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-7-lb.md index c2c7c241657..690971033c5 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-7-lb.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/helm2-rke-add-on-layer-7-lb.md @@ -24,27 +24,6 @@ In an Kubernetes setup that uses a layer 7 load balancer, the load balancer acce Kubernetes Rancher install with layer 7 load balancer, depicting SSL termination at load balancer ![Rancher HA](/img/ha/rancher2ha-l7.svg) -## Installation Outline - -Installation of Rancher in a high-availability configuration involves multiple procedures. Review this outline to learn about each procedure you need to complete. - - - -- [1. Provision Linux Hosts](#1-provision-linux-hosts) -- [2. Configure Load Balancer](#2-configure-load-balancer) -- [3. Configure DNS](#3-configure-dns) -- [4. Install RKE](#4-install-rke) -- [5. Download RKE Config File Template](#5-download-rke-config-file-template) -- [6. Configure Nodes](#6-configure-nodes) -- [7. Configure Certificates](#7-configure-certificates) -- [8. Configure FQDN](#8-configure-fqdn) -- [9. Configure Rancher version](#9-configure-rancher-version) -- [10. Back Up Your RKE Config File](#10-back-up-your-rke-config-file) -- [11. Run RKE](#11-run-rke) -- [12. Back Up Auto-Generated Config File](#12-back-up-auto-generated-config-file) - - - ## 1. Provision Linux Hosts Provision three Linux hosts according to our [Requirements](installation-requirements.md). diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md index 6306c7703c1..65326865b44 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md @@ -14,18 +14,6 @@ This section assumes a basic familiarity with Docker and Kubernetes. For a brief For a conceptual overview of how the Rancher server provisions clusters and what tools it uses to provision them, refer to the [architecture](rancher-manager-architecture.md) page. -This section covers the following topics: - - - -- [Setting up clusters in a hosted Kubernetes provider](#setting-up-clusters-in-a-hosted-kubernetes-provider) -- [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) -- [Importing Existing Clusters](#importing-existing-clusters) - - - The following table summarizes the options and settings available for each cluster type: import ClusterCapabilitiesTable from '../shared-files/_cluster-capabilities-table.md'; diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/pipelines.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/pipelines.md index bbb241a7f13..434869c3d41 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/pipelines.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/pipelines.md @@ -26,25 +26,12 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins >- Still using v2.0.x? See the pipeline documentation for [previous versions](../reference-guides/pipelines/v2.0.x.md). >- Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses. -This section covers the following topics: -- [Concepts](#concepts) -- [How Pipelines Work](#how-pipelines-work) -- [Roles-based Access Control for Pipelines](#roles-based-access-control-for-pipelines) -- [Setting up Pipelines](#setting-up-pipelines) - - [Configure version control providers](#1-configure-version-control-providers) - - [Configure repositories](#2-configure-repositories) - - [Configure the pipeline](#3-configure-the-pipeline) -- [Pipeline Configuration Reference](#pipeline-configuration-reference) -- [Running your Pipelines](#running-your-pipelines) -- [Triggering a Pipeline](#triggering-a-pipeline) - - [Modifying the Event Triggers for the Repository](#modifying-the-event-triggers-for-the-repository) - -# Concepts +## Concepts For an explanation of concepts and terminology used in this section, refer to [this page.](../reference-guides/pipelines/concepts.md) -# How Pipelines Work +## How Pipelines Work After enabling the ability to use pipelines in a project, you can configure multiple pipelines in each project. Each pipeline is unique and can be configured independently. @@ -70,7 +57,7 @@ When you configure a pipeline in one of your projects, a namespace specifically >**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components](../reference-guides/pipelines/configure-persistent-data.md). -# Roles-based Access Control for Pipelines +## Roles-based Access Control for Pipelines If you can access a project, you can enable repositories to start building pipelines. @@ -78,7 +65,7 @@ Only [administrators](../how-to-guides/advanced-user-guides/authentication-permi Project members can only configure repositories and pipelines. -# Setting up Pipelines +## Setting up Pipelines To set up pipelines, you will need to do the following: @@ -228,7 +215,7 @@ Now that repositories are added to your project, you can start configuring the p **Results:** Your pipeline is now configured and ready to be run. -# Pipeline Configuration Reference +## Pipeline Configuration Reference Refer to [this page](../reference-guides/pipelines/pipeline-configuration.md) for details on how to configure a pipeline to: @@ -247,7 +234,7 @@ The configuration reference also covers how to configure: - Secrets -# Running your Pipelines +## Running your Pipelines Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** (In versions before v2.3.0, go to the **Pipelines** tab.) Find your pipeline and select the vertical **⋮ > Run**. @@ -259,7 +246,7 @@ During this initial run, your pipeline is tested, and the following pipeline com This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab. -# Triggering a Pipeline +## Triggering a Pipeline When a repository is enabled, a webhook is automatically set in the version control provider. By default, the pipeline is triggered by a **push** event to a repository, but you can modify the event(s) that trigger running the pipeline. diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/project-tools.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/project-tools.md index 48b661738c6..34efe6fec16 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/project-tools.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/project-tools.md @@ -3,15 +3,7 @@ title: Tools for Logging, Monitoring, and More weight: 2525 --- -Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories: - - -- [Notifiers](#notifiers) -- [Alerts](#alerts) -- [Logging](#logging) -- [Monitoring](#monitoring) - - +Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. # Notifiers diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-existing-nodes.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-existing-nodes.md index 4309e881eec..1b2be54cf0c 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-existing-nodes.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-existing-nodes.md @@ -20,13 +20,6 @@ This section describes how to set up a custom cluster. > >See [Configuring Custom Clusters for Windows](use-windows-clusters.md) before you start. - - -- [1. Provision a Linux Host](#1-provision-a-linux-host) -- [2. Create the Custom Cluster](#2-create-the-custom-cluster) -- [3. Amazon Only: Tag Resources](#3-amazon-only-tag-resources) - - ### 1. Provision a Linux Host diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md index 14550b9601f..b605b066635 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md @@ -11,19 +11,6 @@ One benefit of installing Kubernetes on node pools hosted by an infrastructure p The available cloud providers to create a node template are decided based on active [node drivers](use-new-nodes-in-an-infra-provider.md#node-drivers). -This section covers the following topics: - -- [Node templates](#node-templates) - - [Node labels](#node-labels) - - [Node taints](#node-taints) - - [Administrator control of node templates](#administrator-control-of-node-templates) -- [Node pools](#node-pools) - - [Node pool taints](#node-pool-taints) - - [About node auto-replace](#about-node-auto-replace) - - [Enabling node auto-replace](#enabling-node-auto-replace) - - [Disabling node auto-replace](#disabling-node-auto-replace) -- [Cloud credentials](#cloud-credentials) -- [Node drivers](#node-drivers) # Node Templates diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-windows-clusters.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-windows-clusters.md index f888574a056..11432f16517 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-windows-clusters.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/use-windows-clusters.md @@ -20,14 +20,6 @@ For the full list of requirements, see [this section.](#requirements-for-windows For a summary of Kubernetes features supported in Windows, see the Kubernetes documentation on [supported functionality and limitations for using Kubernetes with Windows](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#supported-functionality-and-limitations) or the [guide for scheduling Windows containers in Kubernetes](https://kubernetes.io/docs/setup/production-environment/windows/user-guide-windows-containers/). -This guide covers the following topics: - - - -- [Requirements](#requirements-for-windows-clusters) -- [Tutorial: How to Create a Cluster with Windows Support](#tutorial-how-to-create-a-cluster-with-windows-support) -- [Configuration for Storage Classes in Azure](#configuration-for-storage-classes-in-azure) - # Requirements for Windows Clusters @@ -112,13 +104,6 @@ When you provision a cluster with Rancher on existing nodes, you will add nodes To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below. - - -1. [Provision Hosts](#1-provision-hosts) -1. [Create the Cluster on Existing Nodes](#2-create-the-cluster-on-existing-nodes) -1. [Add Nodes to the Cluster](#3-add-nodes-to-the-cluster) -1. [Optional: Configuration for Azure Files](#4-optional-configuration-for-azure-files) - # 1. Provision Hosts diff --git a/versioned_docs/version-2.0-2.4/pages-for-subheaders/vsphere.md b/versioned_docs/version-2.0-2.4/pages-for-subheaders/vsphere.md index 5c0c0d7b5f5..2e85aa6a6fe 100644 --- a/versioned_docs/version-2.0-2.4/pages-for-subheaders/vsphere.md +++ b/versioned_docs/version-2.0-2.4/pages-for-subheaders/vsphere.md @@ -15,12 +15,7 @@ Rancher can provision nodes in vSphere and install Kubernetes on them. When crea A vSphere cluster may consist of multiple groups of VMs with distinct properties, such as the amount of memory or the number of vCPUs. This grouping allows for fine-grained control over the sizing of nodes for each Kubernetes role. -- [vSphere Enhancements in Rancher v2.3](#vsphere-enhancements-in-rancher-v2-3) -- [Creating a vSphere Cluster](#creating-a-vsphere-cluster) -- [Provisioning Storage](#provisioning-storage) -- [Enabling the vSphere Cloud Provider](#enabling-the-vsphere-cloud-provider) - -# vSphere Enhancements in Rancher v2.3 +## vSphere Enhancements in Rancher v2.3 The vSphere node templates have been updated, allowing you to bring cloud operations on-premises with the following enhancements: @@ -52,15 +47,15 @@ In this YouTube video, we demonstrate how to set up a node template with the new -# Creating a vSphere Cluster +## Creating a vSphere Cluster In [this section,](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere. -# Provisioning Storage +## Provisioning Storage For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md) In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/vsphere.md) -# Enabling the vSphere Cloud Provider +## Enabling the vSphere Cloud Provider When a cloud provider is set up in Rancher, the Rancher server can automatically provision new infrastructure for the cluster, including new nodes or persistent storage devices. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/kubectl-utility.md b/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/kubectl-utility.md index ab64a6a23ed..decccb345ae 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/kubectl-utility.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/kubectl-utility.md @@ -2,10 +2,6 @@ title: kubectl Utility --- -- [kubectl](#kubectl) - - [kubectl Utility](#kubectl-utility) - - [Authentication with kubectl and kubeconfig Tokens with TTL](#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) - # kubectl Interact with Rancher using kubectl. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/rancher-cli.md b/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/rancher-cli.md index 45f87875e6c..a31c262a291 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/rancher-cli.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cli-with-rancher/rancher-cli.md @@ -4,15 +4,6 @@ description: Interact with Rancher using command line interface (CLI) tools from weight: 21 --- -- [Rancher CLI](#rancher-cli) - - [Download Rancher CLI](#download-rancher-cli) - - [Requirements](#requirements) - - [CLI Authentication](#cli-authentication) - - [Project Selection](#project-selection) - - [Commands](#commands) - - [Rancher CLI Help](#rancher-cli-help) - - [Limitations](#limitations) - The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI. ### Download Rancher CLI diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/prior-to-v2.0.4.md b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/prior-to-v2.0.4.md index 9d0791eb81d..ff78b02de48 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/prior-to-v2.0.4.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/prior-to-v2.0.4.md @@ -6,14 +6,8 @@ aliases: - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/prior-to-2.0.4/ --- -- [Account access](#account-access) -- [Scheduling](#scheduling) -- [Instance options](#instance-options) -- [Disk UUIDs](#disk-uuids) -- [Node Tags and Custom Attributes](#node-tags-and-custom-attributes) -- [Cloud Init](#cloud-init) -# Account Access +## Account Access In the **Account Access** section, enter the vCenter FQDN or IP address and the credentials for the vSphere user account. | Parameter | Required | Description | @@ -24,7 +18,7 @@ In the **Account Access** section, enter the vCenter FQDN or IP address and the | Password | * | User's password. | -# Scheduling +## Scheduling Choose what hypervisor the virtual machine will be scheduled to. @@ -37,7 +31,7 @@ Choose what hypervisor the virtual machine will be scheduled to. | Data Store | * | Datastore to store the VM disks. | | Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. | -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. Only VMs booting from RancherOS ISO are supported. @@ -54,7 +48,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche | OS ISO URL | * | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). | | Configuration Parameters | | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). | -# Disk UUIDs +## Disk UUIDs In order to provision nodes with RKE, all nodes must be configured with disk UUIDs. Follow these instructions to enable UUIDs for the nodes in your vSphere cluster. @@ -71,7 +65,7 @@ To enable disk UUIDs for all VMs created for a cluster, **Result:** The disk UUID is enabled in the vSphere node template. -# Node Tags and Custom Attributes +## Node Tags and Custom Attributes These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects. @@ -83,7 +77,7 @@ Optionally, you can: > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. -# Cloud Init +## Cloud Init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.0.4.md b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.0.4.md index 83f7c9b58bf..6e0bdfcbf42 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.0.4.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.0.4.md @@ -5,13 +5,9 @@ weight: 4 aliases: - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.0.4/ --- -- [Account access](#account-access) -- [Scheduling](#scheduling) -- [Instance options](#instance-options) -- [Node Tags and Custom Attributes](#node-tags-and-custom-attributes) -- [Cloud Init](#cloud-init) -# Account Access + +## Account Access In the **Account Access** section, enter the vCenter FQDN or IP address and the credentials for the vSphere user account. | Parameter | Required | Description | @@ -21,7 +17,7 @@ In the **Account Access** section, enter the vCenter FQDN or IP address and the | Username | * | vCenter/ESXi user to authenticate with the server. | | Password | * | User's password. | -# Scheduling +## Scheduling Choose what hypervisor the virtual machine will be scheduled to. @@ -34,7 +30,7 @@ Choose what hypervisor the virtual machine will be scheduled to. | Data Store | * | Datastore to store the VM disks. | | Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. | -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. Only VMs booting from RancherOS ISO are supported. @@ -50,7 +46,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche | OS ISO URL | * | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). | | Configuration Parameters | | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). | -# Node Tags and Custom Attributes +## Node Tags and Custom Attributes These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects. @@ -62,7 +58,7 @@ Optionally, you can: > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. -# Cloud Init +## Cloud Init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.2.0.md b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.2.0.md index a5352740e85..7372f695040 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.2.0.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.2.0.md @@ -5,13 +5,9 @@ weight: 3 aliases: - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.2.0/ --- -- [Account Access](#account-access) -- [Scheduling](#scheduling) -- [Instance Options](#instance-options) -- [Node tags and custom attributes](#node-tags-and-custom-attributes) -- [Cloud Init](#cloud-init) -# Account Access + +## Account Access | Parameter | Required | Description | |:----------------------|:--------:|:-----| @@ -25,7 +21,7 @@ Your cloud credential has these fields: | Port | Optional: configure configure the port of the vCenter or ESXi server. | | Username and password | Enter your vSphere login username and password. | -# Scheduling +## Scheduling Choose what hypervisor the virtual machine will be scheduled to. | Parameter | Required | Description | @@ -37,7 +33,7 @@ Choose what hypervisor the virtual machine will be scheduled to. | Data Store | * | Datastore to store the VM disks. | | Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. | -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. @@ -54,7 +50,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche | OS ISO URL | * | URL of a RancherOS vSphere ISO file to boot the VMs from. You can find URLs for specific versions in the [Rancher OS GitHub Repo](https://github.com/rancher/os). | | Configuration Parameters | | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). | -# Node Tags and Custom Attributes +## Node Tags and Custom Attributes These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects. @@ -66,7 +62,7 @@ Optionally, you can: > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. -# Cloud Init +## Cloud Init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network. You may specify the URL of a RancherOS cloud-config.yaml file in the the **Cloud Init** field. Refer to the [RancherOS Documentation](https://rancher.com/docs/os/v1.x/en/configuration/#cloud-config) for details on the supported configuration directives. Note that the URL must be network accessible from the VMs created by the template. \ No newline at end of file diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.0.md b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.0.md index c664e2f2465..723579cf366 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.0.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.0.md @@ -5,13 +5,8 @@ weight: 2 aliases: - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.0/ --- -- [Account Access](#account-access) -- [Scheduling](#scheduling) -- [Instance Options](#instance-options) -- [Node tags and custom attributes](#node-tags-and-custom-attributes) -- [Cloud Init](#cloud-init) -# Account Access +## Account Access | Parameter | Required | Description | |:----------------------|:--------:|:-----| @@ -25,7 +20,7 @@ Your cloud credential has these fields: | Port | Optional: configure configure the port of the vCenter or ESXi server. | | Username and password | Enter your vSphere login username and password. | -# Scheduling +## Scheduling Choose what hypervisor the virtual machine will be scheduled to. In the **Scheduling** section, enter: @@ -43,7 +38,7 @@ In the **Scheduling** section, enter: | Data Store | * | Datastore to store the VM disks. | | Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The folder name should be prefaced with `vm/` in your vSphere config file. | -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. @@ -61,7 +56,7 @@ Ensure that the OS ISO URL contains the URL of the VMware ISO release for Ranche | Configuration Parameters | | Additional configuration parameters for the VMs. These correspond to the [Advanced Settings](https://kb.vmware.com/s/article/1016098) in the vSphere console. Example use cases include providing RancherOS [guestinfo]({{}}/os/v1.x/en/installation/cloud/vmware-esxi/#vmware-guestinfo) parameters or enabling disk UUIDs for the VMs (`disk.EnableUUID=TRUE`). | -# Node Tags and Custom Attributes +## Node Tags and Custom Attributes These attributes allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects. @@ -73,7 +68,7 @@ Optionally, you can: > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. -# Cloud Init +## Cloud Init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.3.md b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.3.md index a9d55fe1e5b..24912c78d8a 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.3.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere/v2.3.3.md @@ -5,14 +5,9 @@ weight: 1 aliases: - /rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/vsphere/vsphere-node-template-config/v2.3.3/ --- -- [Account Access](#account-access) -- [Scheduling](#scheduling) -- [Instance Options](#instance-options) -- [Networks](#networks) -- [Node tags and custom attributes](#node-tags-and-custom-attributes) -- [cloud-init](#cloud-init) -# Account Access + +## Account Access | Parameter | Required | Description | |:----------------------|:--------:|:-----| @@ -26,7 +21,7 @@ Your cloud credential has these fields: | Port | Optional: configure configure the port of the vCenter or ESXi server. | | Username and password | Enter your vSphere login username and password. | -# Scheduling +## Scheduling Choose what hypervisor the virtual machine will be scheduled to. @@ -40,7 +35,7 @@ The fields in the **Scheduling** section should auto-populate with the data cent | Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The VM folders in this dropdown menu directly correspond to your VM folders in vSphere. The folder name should be prefaced with `vm/` in your vSphere config file. | | Host | | The IP of the host system to schedule VMs in. Leave this field blank for a standalone ESXi or for a cluster with DRS (Distributed Resource Scheduler). If specified, the host system's pool will be used and the **Resource Pool** parameter will be ignored. | -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. @@ -68,11 +63,11 @@ Choose the way that the VM will be created: - **Clone an existing virtual machine:** In the **Virtual machine** field, choose an existing VM that the new VM will be cloned from. - **Install from boot2docker ISO:** Ensure that the **OS ISO URL** field contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`). Note that this URL must be accessible from the nodes running your Rancher server installation. -# Networks +## Networks The node template now allows a VM to be provisioned with multiple networks. In the **Networks** field, you can now click **Add Network** to add any networks available to you in vSphere. -# Node Tags and Custom Attributes +## Node Tags and Custom Attributes Tags allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects. @@ -82,7 +77,7 @@ In the custom attributes, Rancher will let you select all the custom attributes > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. -# cloud-init +## cloud-init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md index 3d754b828d1..b2de3fa8d7f 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md @@ -16,28 +16,8 @@ In Rancher v2.0.0-v2.2.x, the RKE cluster config file in Rancher is identical to This section is a cluster configuration reference, covering the following topics: -- [Rancher UI Options](#rancher-ui-options) - - [Kubernetes version](#kubernetes-version) - - [Network provider](#network-provider) - - [Kubernetes cloud providers](#kubernetes-cloud-providers) - - [Private registries](#private-registries) - - [Authorized cluster endpoint](#authorized-cluster-endpoint) - - [Node pools](#node-pools) -- [Advanced Options](#advanced-options) - - [NGINX Ingress](#nginx-ingress) - - [Node port range](#node-port-range) - - [Metrics server monitoring](#metrics-server-monitoring) - - [Pod security policy support](#pod-security-policy-support) - - [Docker version on nodes](#docker-version-on-nodes) - - [Docker root directory](#docker-root-directory) - - [Recurring etcd snapshots](#recurring-etcd-snapshots) -- [Cluster config file](#cluster-config-file) - - [Config file structure in Rancher v2.3.0+](#config-file-structure-in-rancher-v2-3-0) - - [Config file structure in Rancher v2.0.0-v2.2.x](#config-file-structure-in-rancher-v2-0-0-v2-2-x) - - [Default DNS provider](#default-dns-provider) -- [Rancher specific parameters](#rancher-specific-parameters) -# Rancher UI Options +## Rancher UI Options When creating a cluster using one of the options described in [Rancher Launched Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md), you can configure basic Kubernetes options using the **Cluster Options** section. @@ -120,7 +100,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det For information on using the Rancher UI to set up node pools in an RKE cluster, refer to [this page.](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md) -# Advanced Options +## Advanced Options The following options are available when you create clusters in the Rancher UI. They are located under **Advanced Options.** @@ -152,7 +132,7 @@ If the nodes you are adding to the cluster have Docker configured with a non-def Option to enable or disable [recurring etcd snapshots](https://rancher.com/docs/rke/latest/en/etcd-snapshots/#etcd-recurring-snapshots). -# Cluster Config File +## Cluster Config File Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available](https://rancher.com/docs/rke/latest/en/config-options/) in an RKE installation, except for `system_images` configuration. The `system_images` option is not supported when creating a cluster with the Rancher UI or API. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/installation-references/amazon-eks-permissions.md b/versioned_docs/version-2.0-2.4/reference-guides/installation-references/amazon-eks-permissions.md index dc98a57a813..babdc2f9870 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/installation-references/amazon-eks-permissions.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/installation-references/amazon-eks-permissions.md @@ -8,22 +8,8 @@ aliases: Amazon EKS provides a managed control plane for your Kubernetes cluster. Amazon EKS runs the Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Rancher provides an intuitive user interface for managing and deploying the Kubernetes clusters you run in Amazon EKS. With this guide, you will use Rancher to quickly and easily launch an Amazon EKS Kubernetes cluster in your AWS account. For more information on Amazon EKS, see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html). -- [Prerequisites in Amazon Web Services](#prerequisites-in-amazon-web-services) - - [Amazon VPC](#amazon-vpc) - - [IAM Policies](#iam-policies) -- [Architecture](#architecture) -- [Create the EKS Cluster](#create-the-eks-cluster) -- [EKS Cluster Configuration Reference](#eks-cluster-configuration-reference) -- [Troubleshooting](#troubleshooting) -- [AWS Service Events](#aws-service-events) -- [Security and Compliance](#security-and-compliance) -- [Tutorial](#tutorial) -- [Minimum EKS Permissions](#minimum-eks-permissions) - - [Service Role Permissions](#service-role-permissions) - - [VPC Permissions](#vpc-permissions) -- [Syncing](#syncing) -# Prerequisites in Amazon Web Services +## Prerequisites in Amazon Web Services >**Note** >Deploying to Amazon AWS will incur charges. For more information, refer to the [EKS pricing page](https://aws.amazon.com/eks/pricing/). @@ -48,7 +34,7 @@ Rancher needs access to your AWS account in order to provision and administer yo For more detailed information on IAM policies for EKS, refer to the official [documentation on Amazon EKS IAM Policies, Roles, and Permissions](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html). -# Architecture +## Architecture The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two Kubernetes clusters: one created by RKE and another created by EKS. @@ -56,7 +42,7 @@ The figure below illustrates the high-level architecture of Rancher 2.x. The fig ![Architecture](/img/rancher-architecture-rancher-api-server.svg) -# Create the EKS Cluster +## Create the EKS Cluster Use Rancher to set up and configure your Kubernetes cluster. @@ -84,7 +70,7 @@ You can access your cluster after its state is updated to **Active.** - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# EKS Cluster Configuration Reference +## EKS Cluster Configuration Reference ### Account Access @@ -194,7 +180,7 @@ Custom AMI Override | If you want to use a custom [Amazon Machine Image](https:/ Desired ASG Size | The number of instances that your cluster will provision. User Data | Custom commands can to be passed to perform automated configuration tasks **WARNING: Modifying this may cause your nodes to be unable to join the cluster.** _Note: Available as of v2.2.0_ -# Troubleshooting +## Troubleshooting If your changes were overwritten, it could be due to the way the cluster data is synced with EKS. Changes shouldn't be made to the cluster from another source, such as in the EKS console, and in Rancher within a five-minute span. For information on how this works and how to configure the refresh interval, refer to [Syncing.](#syncing) @@ -202,21 +188,21 @@ If an unauthorized error is returned while attempting to modify or import the cl For any issues or troubleshooting details for your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html). -# AWS Service Events +## AWS Service Events To find information on any AWS Service events, please see [this page](https://status.aws.amazon.com/). -# Security and Compliance +## Security and Compliance By default only the IAM user or role that created a cluster has access to it. Attempting to access the cluster with any other user or role without additional configuration will lead to an error. In Rancher, this means using a credential that maps to a user or role that was not used to create the cluster will cause an unauthorized error. For example, an EKSCtl cluster will not be imported in Rancher unless the credentials used to import the cluster match the role or user used by EKSCtl. Additional users and roles can be authorized to access a cluster by being added to the aws-auth configmap in the kube-system namespace. For a more in-depth explanation and detailed instructions, please see this [documentation](https://aws.amazon.com/premiumsupport/knowledge-center/amazon-eks-cluster-access/). For more information on security and compliance with your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/shared-responsibilty.html). -# Tutorial +## Tutorial This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-rancher/) on the AWS Open Source Blog will walk you through how to set up an EKS cluster with Rancher, deploy a publicly accessible app to test the cluster, and deploy a sample project to track real-time geospatial data using a combination of other open-source software such as Grafana and InfluxDB. -# Minimum EKS Permissions +## Minimum EKS Permissions Documented here is a minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. Additional permissions are required for Rancher to provision the `Service Role` and `VPC` resources. Optionally these resources can be created **before** the cluster creation and will be selectable when defining the cluster configuration. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/installation-references/helm-chart-options.md b/versioned_docs/version-2.0-2.4/reference-guides/installation-references/helm-chart-options.md index 9b9bb2c4c2b..4f44df77932 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/installation-references/helm-chart-options.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/installation-references/helm-chart-options.md @@ -14,18 +14,8 @@ For help choosing a Helm chart version, refer to [this page.](../../getting-star For information on enabling experimental features, refer to [this page.](../../pages-for-subheaders/enable-experimental-features.md) -- [Common Options](#common-options) -- [Advanced Options](#advanced-options) -- [API Audit Log](#api-audit-log) -- [Setting Extra Environment Variables](#setting-extra-environment-variables) -- [TLS Settings](#tls-settings) -- [Customizing your Ingress](#customizing-your-ingress) -- [HTTP Proxy](#http-proxy) -- [Additional Trusted CAs](#additional-trusted-cas) -- [Private Registry and Air Gap Installs](#private-registry-and-air-gap-installs) -- [External TLS Termination](#external-tls-termination) -### Common Options +## Common Options | Option | Default Value | Description | | ------------------------- | ------------- | ---------------------------------------------------------------------------------- | @@ -37,7 +27,7 @@ For information on enabling experimental features, refer to [this page.](../../p
-### Advanced Options +## Advanced Options | Option | Default Value | Description | | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | diff --git a/versioned_docs/version-2.0-2.4/reference-guides/kubernetes-concepts.md b/versioned_docs/version-2.0-2.4/reference-guides/kubernetes-concepts.md index c6813e7ba08..91766c781dd 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/kubernetes-concepts.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/kubernetes-concepts.md @@ -5,34 +5,24 @@ weight: 4 This page explains concepts related to Kubernetes that are important for understanding how Rancher works. The descriptions below provide a simplified interview of Kubernetes components. For more details, refer to the [official documentation on Kubernetes components.](https://kubernetes.io/docs/concepts/overview/components/) -This section covers the following topics: -- [About Docker](#about-docker) -- [About Kubernetes](#about-kubernetes) -- [What is a Kubernetes Cluster?](#what-is-a-kubernetes-cluster) -- [Roles for Nodes in Kubernetes Clusters](#roles-for-nodes-in-kubernetes-clusters) - - [etcd Nodes](#etcd-nodes) - - [Controlplane Nodes](#controlplane-nodes) - - [Worker Nodes](#worker-nodes) -- [About Helm](#about-helm) - -# About Docker +## About Docker Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](https://hub.docker.com) is the most popular public registry. Many organizations also set up private Docker registries. Docker is primarily used to manage containers on individual nodes. >**Note:** Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.x due to the success of Kubernetes. -# About Kubernetes +## About Kubernetes Kubernetes is the container cluster management standard. YAML files specify containers and other resources that form an application. Kubernetes performs functions such as scheduling, scaling, service discovery, health check, secret management, and configuration management. -# What is a Kubernetes Cluster? +## What is a Kubernetes Cluster? A cluster is a group of computers that work together as a single system. A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestration system](https://kubernetes.io/) to deploy, maintain, and scale Docker containers, allowing your organization to automate application operations. -# Roles for Nodes in Kubernetes Clusters +## Roles for Nodes in Kubernetes Clusters Each computing resource in a Kubernetes cluster is called a _node_. Nodes can be either bare-metal servers or virtual machines. Kubernetes classifies nodes into three types: _etcd_ nodes, _control plane_ nodes, and _worker_ nodes. @@ -63,7 +53,7 @@ Each [worker node](https://kubernetes.io/docs/concepts/architecture/nodes/) runs Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your [workloads](../pages-for-subheaders/workloads-and-pods.md). -# About Helm +## About Helm For high-availability installations of Rancher, Helm is the tool used to install Rancher on a Kubernetes cluster. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/pipelines/configure-persistent-data.md b/versioned_docs/version-2.0-2.4/reference-guides/pipelines/configure-persistent-data.md index 8dcbcef9c0f..13dd3a0cfde 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/pipelines/configure-persistent-data.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/pipelines/configure-persistent-data.md @@ -29,24 +29,24 @@ This section assumes that you understand how persistent storage works in Kuberne 1. Complete the form that displays to choose a persistent volume for the internal Docker registry. - + - 1. Enter a **Name** for the volume claim. - 1. Select a volume claim **Source**: - - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. - - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Select a volume claim **Source**: + - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. + - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - - + + - 1. Enter a **Name** for the volume claim. - 1. Choose a **Persistent Volume Claim** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Choose a **Persistent Volume Claim** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - + 1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container. @@ -64,24 +64,24 @@ This section assumes that you understand how persistent storage works in Kuberne 1. Complete the form that displays to choose a persistent volume for the internal Docker registry. - + - 1. Enter a **Name** for the volume claim. - 1. Select a volume claim **Source**: - - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. - - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Select a volume claim **Source**: + - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. + - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - - + + - 1. Enter a **Name** for the volume claim. - 1. Choose a **Persistent Volume Claim** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Choose a **Persistent Volume Claim** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - + 1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/pipelines/pipeline-configuration.md b/versioned_docs/version-2.0-2.4/reference-guides/pipelines/pipeline-configuration.md index 53c182c0c35..609598d27fc 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/pipelines/pipeline-configuration.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/pipelines/pipeline-configuration.md @@ -7,26 +7,8 @@ aliases: In this section, you'll learn how to configure pipelines. -- [Step Types](#step-types) -- [Step Type: Run Script](#step-type-run-script) -- [Step Type: Build and Publish Images](#step-type-build-and-publish-images) -- [Step Type: Publish Catalog Template](#step-type-publish-catalog-template) -- [Step Type: Deploy YAML](#step-type-deploy-yaml) -- [Step Type: Deploy Catalog App](#step-type-deploy-catalog-app) -- [Notifications](#notifications) -- [Timeouts](#timeouts) -- [Triggers and Trigger Rules](#triggers-and-trigger-rules) -- [Environment Variables](#environment-variables) -- [Secrets](#secrets) -- [Pipeline Variable Substitution Reference](#pipeline-variable-substitution-reference) -- [Global Pipeline Execution Settings](#global-pipeline-execution-settings) - - [Executor Quota](#executor-quota) - - [Resource Quota for Executors](#resource-quota-for-executors) - - [Custom CA](#custom-ca) -- [Persistent Data for Pipeline Components](#persistent-data-for-pipeline-components) -- [Example rancher-pipeline.yml](#example-rancher-pipeline-yml) -# Step Types +## Step Types Within each stage, you can add as many steps as you'd like. When there are multiple steps in one stage, they run concurrently. @@ -82,7 +64,7 @@ stages: pushRemote: true registry: reg.example.com ``` -# Step Type: Run Script +## Step Type: Run Script The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience, you can use variables to refer to metadata of a pipeline execution. Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables. @@ -102,7 +84,7 @@ stages: image: golang shellScript: go build ``` -# Step Type: Build and Publish Images +## Step Type: Build and Publish Images _Available as of Rancher v2.1.0_ @@ -154,7 +136,7 @@ stages: PLUGIN_INSECURE: "true" ``` -# Step Type: Publish Catalog Template +## Step Type: Publish Catalog Template _Available as of v2.2.0_ @@ -212,7 +194,7 @@ stages: sourceKey: DEPLOY_KEY ``` -# Step Type: Deploy YAML +## Step Type: Deploy YAML This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml). Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables. @@ -235,7 +217,7 @@ stages: path: ./deployment.yaml ``` -# Step Type :Deploy Catalog App +## Step Type :Deploy Catalog App _Available as of v2.2.0_ @@ -283,7 +265,7 @@ stages: targetNamespace: test ``` -# Timeouts +## Timeouts By default, each pipeline execution has a timeout of 60 minutes. If the pipeline execution cannot complete within its timeout period, the pipeline is aborted. @@ -307,7 +289,7 @@ stages: timeout: 30 ``` -# Notifications +## Notifications You can enable notifications to any [notifiers](../../explanations/integrations-in-rancher/notifiers.md) based on the build status of a pipeline. Before enabling notifications, Rancher recommends [setting up notifiers](../../explanations/integrations-in-rancher/notifiers.md) so it will be easy to add recipients immediately. @@ -358,7 +340,7 @@ notification: message: "my-message" ``` -# Triggers and Trigger Rules +## Triggers and Trigger Rules After you configure a pipeline, you can trigger it using different methods: @@ -382,12 +364,6 @@ If all conditions evaluate to `true`, then the pipeline/stage/step is executed. Wildcard character (`*`) expansion is supported in `branch` conditions. -This section covers the following topics: - -- [Configuring pipeline triggers](#configuring-pipeline-triggers) -- [Configuring stage triggers](#configuring-stage-triggers) -- [Configuring step triggers](#configuring-step-triggers) -- [Configuring triggers by YAML](#configuring-triggers-by-yaml) ### Configuring Pipeline Triggers @@ -483,7 +459,7 @@ branch: exclude: [ dev ] ``` -# Environment Variables +## Environment Variables When configuring a pipeline, certain [step types](#step-types) allow you to use environment variables to configure the step's script. @@ -520,7 +496,7 @@ stages: SECOND_KEY: VALUE2 ``` -# Secrets +## Secrets If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes [secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md). @@ -563,7 +539,7 @@ stages: targetKey: ALIAS_ENV ``` -# Pipeline Variable Substitution Reference +## Pipeline Variable Substitution Reference For your convenience, the following variables are available for your pipeline configuration scripts. During pipeline executions, these variables are replaced by metadata. You can reference them in the form of `${VAR_NAME}`. @@ -582,7 +558,7 @@ Variable Name | Description `CICD_REGISTRY` | Address for the Docker registry for the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. `CICD_IMAGE` | Name of the image built from the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. It does not contain the image tag.

[Example](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml) -# Global Pipeline Execution Settings +## Global Pipeline Execution Settings After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. These settings can be edited by selecting **Tools > Pipelines** in the navigation bar. In versions before v2.2.0, you can select **Resources > Pipelines**. @@ -649,12 +625,12 @@ If you want to use a version control provider with a certificate from a custom/i **Result:** Pipelines can be used and new pods will be able to work with the self-signed-certificate. -# Persistent Data for Pipeline Components +## Persistent Data for Pipeline Components The internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes. For details on setting up persistent storage for pipelines, refer to [this page.](./configure-persistent-data.md) -# Example rancher-pipeline.yml +## Example rancher-pipeline.yml An example pipeline configuration file is on [this page.](./example-yaml.md) diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rancher-cluster-tools.md b/versioned_docs/version-2.0-2.4/reference-guides/rancher-cluster-tools.md index c45b2b9638b..97727f725f6 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rancher-cluster-tools.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rancher-cluster-tools.md @@ -5,19 +5,7 @@ aliases: - /rancher/v2.0-v2.4/en/toolcluster-admin/tools/notifiers-and-alerts/ --- -Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories: - - - -- [Logging](#logging) -- [Monitoring](#monitoring) -- [Alerts](#alerts) -- [Notifiers](#notifiers) -- [Istio](#istio) -- [OPA Gatekeeper](#opa-gatekeeper) -- [CIS Scans](#cis-scans) - - +Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. # Logging diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md index 609ba7bfc97..8f0dfa99dc3 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -5,15 +5,6 @@ weight: 3 Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the cluster running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) -This section covers the following topics: - -- [Separation of Rancher and User Clusters](#separation-of-rancher-and-user-clusters) -- [Why HA is Better for Rancher in Production](#why-ha-is-better-for-rancher-in-production) -- [Recommended Load Balancer Configuration for Kubernetes Installations](#recommended-load-balancer-configuration-for-kubernetes-installations) -- [Environment for Kubernetes Installations](#environment-for-kubernetes-installations) -- [Recommended Node Roles for Kubernetes Installations](#recommended-node-roles-for-kubernetes-installations) -- [Architecture for an Authorized Cluster Endpoint](#architecture-for-an-authorized-cluster-endpoint) - # Separation of Rancher and User Clusters A user cluster is a downstream Kubernetes cluster that runs your apps and services. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index e432001b419..fabdcd6f8b9 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -75,7 +75,7 @@ With this endpoint enabled for the downstream cluster, Rancher generates an extr You will need to use a context defined in this kubeconfig file to access the cluster if Rancher goes down. Therefore, we recommend exporting the kubeconfig file so that if Rancher goes down, you can still use the credentials in the file to access your cluster. For more information, refer to the section on accessing your cluster with [kubectl and the kubeconfig file.](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) -# Important Files +## Important Files The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster: @@ -87,7 +87,7 @@ The files mentioned below are needed to maintain, troubleshoot and upgrade your For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) documentation. -# Tools for Provisioning Kubernetes Clusters +## Tools for Provisioning Kubernetes Clusters The tools that Rancher uses to provision downstream user clusters depends on the type of cluster that is being provisioned. @@ -113,7 +113,7 @@ Rancher provisions this type of cluster using [kontainer-engine.](https://github 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. -# Rancher Server Components and Source Code +## Rancher Server Components and Source Code This diagram shows each component that the Rancher server is composed of: diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/project-alerts.md b/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/project-alerts.md index 4377903b69c..16ebcb2ecad 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/project-alerts.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rancher-project-tools/project-alerts.md @@ -16,20 +16,8 @@ Before you can receive alerts, one or more [notifier](../../explanations/integra Only [administrators](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md), [cluster owners or members](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles), or [project owners](../../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) can manage project alerts. -This section covers the following topics: -- [Alerts scope](#alerts-scope) -- [Default project-level alerts](#default-project-level-alerts) -- [Adding project alerts](#adding-project-alerts) -- [Managing project alerts](#managing-project-alerts) -- [Project Alert Rule Configuration](#project-alert-rule-configuration) - - [Pod Alerts](#pod-alerts) - - [Workload Alerts](#workload-alerts) - - [Workload Selector Alerts](#workload-selector-alerts) - - [Metric Expression Alerts](#metric-expression-alerts) - - -# Alerts Scope +## Alerts Scope The scope for alerts can be set at either the [cluster level](../../pages-for-subheaders/cluster-alerts.md) or project level. @@ -40,7 +28,7 @@ At the project level, Rancher monitors specific deployments and sends alerts for * Pod status * The Prometheus expression cross the thresholds -# Default Project-level Alerts +## Default Project-level Alerts When you enable monitoring for the project, some project-level alerts are provided. You can receive these alerts if a [notifier](../../explanations/integrations-in-rancher/notifiers.md) for them is configured at the cluster level. @@ -51,7 +39,7 @@ When you enable monitoring for the project, some project-level alerts are provid For information on other default alerts, refer to the section on [cluster-level alerts.](../../explanations/integrations-in-rancher/cluster-alerts/default-alerts.md) -# Adding Project Alerts +## Adding Project Alerts >**Prerequisite:** Before you can receive project alerts, you must add a notifier. @@ -75,7 +63,7 @@ For information on other default alerts, refer to the section on [cluster-level **Result:** Your alert is configured. A notification is sent when the alert is triggered. -# Managing Project Alerts +## Managing Project Alerts To manage project alerts, browse to the project that alerts you want to manage. Then select **Tools > Alerts**. In versions before v2.2.0, you can choose **Resources > Alerts**. You can: @@ -86,14 +74,14 @@ To manage project alerts, browse to the project that alerts you want to manage. - Unmute muted alerts -# Project Alert Rule Configuration +## Project Alert Rule Configuration - [Pod Alerts](#pod-alerts) - [Workload Alerts](#workload-alerts) - [Workload Selector Alerts](#workload-selector-alerts) - [Metric Expression Alerts](#metric-expression-alerts) -# Pod Alerts +## Pod Alerts This alert type monitors for the status of a specific pod. @@ -131,7 +119,7 @@ You can disable these advanced options when configuring a specific rule. - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds. - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour. -# Workload Alerts +## Workload Alerts This alert type monitors for the availability of a workload. @@ -165,7 +153,7 @@ You can disable these advanced options when configuring a specific rule. - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds. - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour. -# Workload Selector Alerts +## Workload Selector Alerts This alert type monitors for the availability of all workloads marked with tags that you've specified. @@ -199,7 +187,7 @@ You can disable these advanced options when configuring a specific rule. - **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds. - **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour. -# Metric Expression Alerts +## Metric Expression Alerts _Available as of v2.2.4_ If you enable [project monitoring](../../pages-for-subheaders/project-tools.md#monitoring), this alert type monitors for the overload from Prometheus expression querying. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rke1-template-example-yaml.md b/versioned_docs/version-2.0-2.4/reference-guides/rke1-template-example-yaml.md index 3c85e86d616..2be8946bfb7 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rke1-template-example-yaml.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rke1-template-example-yaml.md @@ -1,5 +1,5 @@ --- -title: Example YAML +title: RKE1 Example YAML weight: 60 --- diff --git a/versioned_docs/version-2.0-2.4/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md b/versioned_docs/version-2.0-2.4/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md index f83d241a08a..6f39f307282 100644 --- a/versioned_docs/version-2.0-2.4/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md +++ b/versioned_docs/version-2.0-2.4/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md @@ -5,25 +5,8 @@ weight: 1 This section contains commands and tips for troubleshooting nodes with the `etcd` role. -This page covers the following topics: -- [Checking if the etcd Container is Running](#checking-if-the-etcd-container-is-running) -- [etcd Container Logging](#etcd-container-logging) -- [etcd Cluster and Connectivity Checks](#etcd-cluster-and-connectivity-checks) - - [Check etcd Members on all Nodes](#check-etcd-members-on-all-nodes) - - [Check Endpoint Status](#check-endpoint-status) - - [Check Endpoint Health](#check-endpoint-health) - - [Check Connectivity on Port TCP/2379](#check-connectivity-on-port-tcp-2379) - - [Check Connectivity on Port TCP/2380](#check-connectivity-on-port-tcp-2380) -- [etcd Alarms](#etcd-alarms) -- [etcd Space Errors](#etcd-space-errors) -- [Log Level](#log-level) -- [etcd Content](#etcd-content) - - [Watch Streaming Events](#watch-streaming-events) - - [Query etcd Directly](#query-etcd-directly) -- [Replacing Unhealthy etcd Nodes](#replacing-unhealthy-etcd-nodes) - -# Checking if the etcd Container is Running +## Checking if the etcd Container is Running The container for etcd should have status **Up**. The duration shown after **Up** is the time the container has been running. @@ -37,7 +20,7 @@ CONTAINER ID IMAGE COMMAND CREAT 605a124503b9 rancher/coreos-etcd:v3.2.18 "/usr/local/bin/et..." 2 hours ago Up 2 hours etcd ``` -# etcd Container Logging +## etcd Container Logging The logging of the container can contain information on what the problem could be. @@ -52,7 +35,7 @@ docker logs etcd | `rafthttp: request cluster ID mismatch` | The node with the etcd instance logging `rafthttp: request cluster ID mismatch` is trying to join a cluster that has already been formed with another peer. The node should be removed from the cluster, and re-added. | | `rafthttp: failed to find member` | The cluster state (`/var/lib/etcd`) contains wrong information to join the cluster. The node should be removed from the cluster, the state directory should be cleaned and the node should be re-added. -# etcd Cluster and Connectivity Checks +## etcd Cluster and Connectivity Checks The address where etcd is listening depends on the address configuration of the host etcd is running on. If an internal address is configured for the host etcd is running on, the endpoint for `etcdctl` needs to be specified explicitly. If any of the commands respond with `Error: context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster) @@ -177,7 +160,7 @@ Validating connection to https://IP:2380/version {"etcdserver":"3.2.18","etcdcluster":"3.2.0"} ``` -# etcd Alarms +## etcd Alarms etcd will trigger alarms, for instance when it runs out of space. @@ -198,7 +181,7 @@ memberID:x alarm:NOSPACE memberID:x alarm:NOSPACE ``` -# etcd Space Errors +## etcd Space Errors Related error messages are `etcdserver: mvcc: database space exceeded` or `applying raft message exceeded backend quota`. Alarm `NOSPACE` will be triggered. @@ -298,7 +281,7 @@ docker exec etcd etcdctl alarm disarm docker exec etcd etcdctl alarm list ``` -# Log Level +## Log Level The log level of etcd can be changed dynamically via the API. You can configure debug logging using the commands below. @@ -324,7 +307,7 @@ Command when using etcd version lower than 3.3.x (Kubernetes 1.13.x and lower) a docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv ETCDCTL_ENDPOINT)/config/local/log ``` -# etcd Content +## etcd Content If you want to investigate the contents of your etcd, you can either watch streaming events or you can query etcd directly, see below for examples. @@ -360,6 +343,6 @@ You can process the data to get a summary of count per key, using the command be docker exec etcd etcdctl get /registry --prefix=true --keys-only | grep -v ^$ | awk -F'/' '{ if ($3 ~ /cattle.io/) {h[$3"/"$4]++} else { h[$3]++ }} END { for(k in h) print h[k], k }' | sort -nr ``` -# Replacing Unhealthy etcd Nodes +## Replacing Unhealthy etcd Nodes When a node in your etcd cluster becomes unhealthy, the recommended approach is to fix or remove the failed or unhealthy node before adding a new etcd node to the cluster. diff --git a/versioned_docs/version-2.0-2.4/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md b/versioned_docs/version-2.0-2.4/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md index 47a93677e85..5ca8cff1038 100644 --- a/versioned_docs/version-2.0-2.4/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md +++ b/versioned_docs/version-2.0-2.4/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md @@ -7,31 +7,7 @@ The commands/steps listed on this page can be used to check the most important K 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. -- [Nodes](#nodes) - - [Get nodes](#get-nodes) - - [Get node conditions](#get-node-conditions) -- [Kubernetes leader election](#kubernetes-leader-election) - - [Kubernetes controller manager leader](#kubernetes-controller-manager-leader) - - [Kubernetes scheduler leader](#kubernetes-scheduler-leader) -- [Ingress controller](#ingress-controller) - - [Pod details](#pod-details) - - [Pod container logs](#pod-container-logs) - - [Namespace events](#namespace-events) - - [Debug logging](#debug-logging) - - [Check configuration](#check-configuration) -- [Rancher agents](#rancher-agents) - - [cattle-node-agent](#cattle-node-agent) - - [cattle-cluster-agent](#cattle-cluster-agent) -- [Jobs and pods](#jobs-and-pods) - - [Check that pods or jobs have status Running/Completed](#check-that-pods-or-jobs-have-status-running-completed) - - [Describe pod](#describe-pod) - - [Pod container logs](#pod-container-logs) - - [Describe job](#describe-job) - - [Logs from the containers of pods of the job](#logs-from-the-containers-of-pods-of-the-job) - - [Evicted pods](#evicted-pods) - - [Job does not complete](#job-does-not-complete) - -# Nodes +## Nodes ### Get nodes @@ -76,7 +52,7 @@ Example output: worker-0: DiskPressure:True ``` -# Kubernetes leader election +## Kubernetes leader election ### Kubernetes Controller Manager leader @@ -96,7 +72,7 @@ kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.anno {"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}> ``` -# Ingress Controller +## Ingress Controller The default Ingress Controller is NGINX and is deployed as a DaemonSet in the `ingress-nginx` namespace. The pods are only scheduled to nodes with the `worker` role. @@ -152,7 +128,7 @@ Retrieve generated configuration in each pod: kubectl -n ingress-nginx get pods -l app=ingress-nginx --no-headers -o custom-columns=.NAME:.metadata.name | while read pod; do kubectl -n ingress-nginx exec $pod -- cat /etc/nginx/nginx.conf; done ``` -# Rancher agents +## Rancher agents Communication to the cluster (Kubernetes API via `cattle-cluster-agent`) and communication to the nodes (cluster provisioning via `cattle-node-agent`) is done through Rancher agents. @@ -204,7 +180,7 @@ Check logging of cattle-cluster-agent pod: kubectl -n cattle-system logs -l app=cattle-cluster-agent ``` -# Jobs and Pods +## Jobs and Pods ### Check that pods or jobs have status **Running**/**Completed** diff --git a/versioned_docs/version-2.5/cluster-provisioning/rke-clusters/options/options.md b/versioned_docs/version-2.5/cluster-provisioning/rke-clusters/options/options.md index 3da69710155..0337111c18a 100644 --- a/versioned_docs/version-2.5/cluster-provisioning/rke-clusters/options/options.md +++ b/versioned_docs/version-2.5/cluster-provisioning/rke-clusters/options/options.md @@ -19,31 +19,8 @@ You can configure the Kubernetes options one of two ways: The RKE cluster config options are nested under the `rancher_kubernetes_engine_config` directive. For more information, see the section about the [cluster config file.](#cluster-config-file) -This section is a cluster configuration reference, covering the following topics: -- [Rancher UI Options](#rancher-ui-options) - - [Kubernetes version](#kubernetes-version) - - [Network provider](#network-provider) - - [Project network isolation](#project-network-isolation) - - [Kubernetes cloud providers](#kubernetes-cloud-providers) - - [Private registries](#private-registries) - - [Authorized cluster endpoint](#authorized-cluster-endpoint) - - [Node pools](#node-pools) -- [Advanced Options](#advanced-options) - - [NGINX Ingress](#nginx-ingress) - - [Node port range](#node-port-range) - - [Metrics server monitoring](#metrics-server-monitoring) - - [Pod security policy support](#pod-security-policy-support) - - [Docker version on nodes](#docker-version-on-nodes) - - [Docker root directory](#docker-root-directory) - - [Recurring etcd snapshots](#recurring-etcd-snapshots) - - [Agent Environment Variables](#agent-environment-variables) -- [Cluster config file](#cluster-config-file) - - [Config file structure in Rancher v2.3.0+](#config-file-structure-in-rancher-v2-3-0) - - [Default DNS provider](#default-dns-provider) -- [Rancher specific parameters](#rancher-specific-parameters) - -# Rancher UI Options +## Rancher UI Options When creating a cluster using one of the options described in [Rancher Launched Kubernetes](../../../pages-for-subheaders/launch-kubernetes-with-rancher.md), you can configure basic Kubernetes options using the **Cluster Options** section. @@ -125,7 +102,7 @@ We recommend using a load balancer with the authorized cluster endpoint. For det For information on using the Rancher UI to set up node pools in an RKE cluster, refer to [this page.](../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md) -# Advanced Options +## Advanced Options The following options are available when you create clusters in the Rancher UI. They are located under **Advanced Options.** @@ -164,7 +141,7 @@ _Available as of v2.5.6_ Option to set environment variables for [rancher agents](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/about-rancher-agents.md). 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 +## Cluster Config File Instead of using the Rancher UI to choose Kubernetes options for the cluster, advanced users can create an RKE config file. Using a config file allows you to set any of the [options available](https://rancher.com/docs/rke/latest/en/config-options/) in an RKE installation, except for `system_images` configuration. The `system_images` option is not supported when creating a cluster with the Rancher UI or API. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md index 993ba956891..2a2d01225ca 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/custom-benchmark.md @@ -19,11 +19,6 @@ When a cluster scan is run, you need to select a Profile which points to a speci Follow all the steps below to add a custom Benchmark Version and run a scan using it. -1. [Prepare the Custom Benchmark Version ConfigMap](#1-prepare-the-custom-benchmark-version-configmap) -2. [Add a Custom Benchmark Version to a Cluster](#2-add-a-custom-benchmark-version-to-a-cluster) -3. [Create a New Profile for the Custom Benchmark Version](#3-create-a-new-profile-for-the-custom-benchmark-version) -4. [Run a Scan Using the Custom Benchmark Version](#4-run-a-scan-using-the-custom-benchmark-version) - ### 1. Prepare the Custom Benchmark Version ConfigMap To create a custom benchmark version, first you need to create a ConfigMap containing the benchmark version's config files and upload it to your Kubernetes cluster where you want to run the scan. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md index 1f389469cb0..dc158048ef1 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md @@ -23,7 +23,7 @@ Note: If you were using the `cis-edit` role added in Rancher v2.5 setup, it has Rancher v2.5.2 because it essentially is same as `cis-admin`. If you happen to create any clusterrolebindings for `cis-edit`, please update them to use `cis-admin` ClusterRole instead. -# Cluster-Admin Access +## Cluster-Admin Access Rancher CIS Scans is a cluster-admin only feature by default. This means only the Rancher global admins, and the cluster’s cluster-owner can: @@ -36,7 +36,7 @@ This means only the Rancher global admins, and the cluster’s cluster-owner can - View and Download the ClusterScanReport created after the ClusterScan is complete -# Summary of Default Permissions for Kubernetes Default Roles +## Summary of Default Permissions for Kubernetes Default Roles The rancher-cis-benchmark creates three `ClusterRoles` and adds the CIS Benchmark CRD access to the following default K8s `ClusterRoles`: diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md index 3312a9c3940..47211e6c724 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md @@ -11,7 +11,7 @@ This section lists the tests that are skipped in the permissive test profile for > All the tests that are skipped and not applicable on this page will be counted as Not Applicable in the v2.5 generated report. The skipped test count will only mention the user-defined skipped tests. This allows user-skipped tests to be distinguished from the tests that are skipped by default in the RKE permissive test profile. -# CIS Benchmark v1.5 +## CIS Benchmark v1.5 ### CIS Benchmark v1.5 Skipped Tests diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md index 518f6b51465..d0b777f262e 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md @@ -17,7 +17,7 @@ For public downstream clusters, it is sufficient to [set the required environmen For private nodes or private clusters, the environment variables need to be set on the nodes themselves. Then the environment variables are configured from the Rancher UI, typically when provisioning a custom cluster or when registering the private cluster. For an example of how to set the environment variables on Ubuntu node in a K3s Kubernetes cluster, see [this section.](#setting-environment-variables-on-private-nodes) -# Required Environment Variables +## Required Environment Variables When adding Fleet agent environment variables for the proxy, replace with your private proxy IP. @@ -27,7 +27,7 @@ When adding Fleet agent environment variables for the proxy, replace | `HTTPS_PROXY` | http://:8888 | `NO_PROXY` | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local | -# Setting Environment Variables in the Rancher UI +## Setting Environment Variables in the Rancher UI To add the environment variable to an existing cluster, @@ -40,7 +40,7 @@ To add the environment variable to an existing cluster, **Result:** The Fleet agent works behind a proxy. -# Setting Environment Variables on Private Nodes +## Setting Environment Variables on Private Nodes For private nodes and private clusters, the proxy environment variables need to be set on the nodes themselves, as well as configured from the Rancher UI. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md index de8eb086074..f6ab646cedb 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/configuration-options/selectors-and-scrape-configurations.md @@ -13,11 +13,6 @@ This ensures you can view traffic, metrics and graphs for resources deployed in If you would like to limit Prometheus to specific namespaces, set `prometheus.prometheusSpec.ignoreNamespaceSelectors=true`. Once you do this, you will need to add additional configuration to continue to monitor your resources. -- [Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True](#limiting-monitoring-to-specific-namespaces-by-setting-ignorenamespaceselectors-to-true) -- [Enabling Prometheus to Detect Resources in Other Namespaces](#enabling-prometheus-to-detect-resources-in-other-namespaces) -- [Monitoring Specific Namespaces: Create a Service Monitor or Pod Monitor](#monitoring-specific-namespaces-create-a-service-monitor-or-pod-monitor) -- [Monitoring Across Namespaces: Set ignoreNamespaceSelectors to False](#monitoring-across-namespaces-set-ignorenamespaceselectors-to-false) - ### Limiting Monitoring to Specific Namespaces by Setting ignoreNamespaceSelectors to True This limits monitoring to specific namespaces. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/disable-istio.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/disable-istio.md index 3ac12ff2248..d258d8827c2 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/disable-istio.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/istio/disable-istio.md @@ -8,7 +8,7 @@ aliases: This section describes how to uninstall Istio in a cluster or disable a namespace, or workload. -# Uninstall Istio in a Cluster +## Uninstall Istio in a Cluster To uninstall Istio, @@ -26,7 +26,7 @@ To uninstall Istio, This could mean a few things. You either selected all the apps in the `istio-system` namespace and deleted them at the same time, or you deleted `rancher-istio` chart dependencies prior to deleting the `rancher-istio` chart. Since the uninstall did not complete properly, you will have resources remaining in the `istio-system` namespace that you will need to manually clean up. Another option to avoid manual clean up is to install `rancher-istio` again, then uninstall it in the correct order. -# Disable Istio in a Namespace +## Disable Istio in a Namespace 1. From the **Cluster Explorer** view, use the side-nav to select **Namespaces** page 1. On the **Namespace** page, you will see a list of namespaces. Go to the namespace where you want to disable and click the select **Edit as Form** or **Edit as Yaml** @@ -35,6 +35,6 @@ This could mean a few things. You either selected all the apps in the `istio-sys **Result:** When workloads are deployed in this namespace, they will not have the Istio sidecar. -# Remove the Istio Sidecar from a Workload +## Remove the Istio Sidecar from a Workload Disable Istio in the namespace, then redeploy the workloads with in it. They will be deployed without the Istio sidecar. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md index e5ae7af09f2..b6c8755a798 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/flows-and-clusterflows.md @@ -11,7 +11,7 @@ For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai - [Configuration](#configuration) - [YAML Example](#yaml-example) -# Configuration +## Configuration @@ -22,14 +22,14 @@ For the full details on configuring `Flows` and `ClusterFlows`, see the [Banzai - [Outputs](#outputs-2-5-8) - [ClusterFlows](#clusterflows-2-5-8) -# Changes in v2.5.8 +## Changes in v2.5.8 The `Flows` and `ClusterFlows` can now be configured by filling out forms in the Rancher UI. -# Flows +## Flows A `Flow` defines which logs to collect and filter and which output to send the logs to. @@ -70,7 +70,7 @@ This `Output` will receive logs from the `Flow`. Because the `Flow` is a namespa -# ClusterFlows +## ClusterFlows Matches, filters and `Outputs` are configured for `ClusterFlows` in the same way that they are configured for `Flows`. The key difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces. @@ -89,7 +89,7 @@ After `ClusterFlow` selects logs from all namespaces in the cluster, logs from t -# Flows +## Flows A `Flow` defines which logs to collect and filter and which `Output` to send the logs to. The `Flow` is a namespaced resource, which means logs will only be collected from the namespace that the `Flow` is deployed in. @@ -126,7 +126,7 @@ Because the `Flow` is a namespaced resource, the `Output` must reside in same na -# ClusterFlows +## ClusterFlows Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only difference is that the `ClusterFlow` is scoped at the cluster level and can configure log collection across all namespaces. @@ -138,7 +138,7 @@ Matches, filters and `Outputs` are also configured for `ClusterFlows`. The only -# YAML Example +## YAML Example The following example `Flow` transforms the log messages from the default namespace and sends them to an S3 `Output`: diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md index 7ccf7d0677d..8fa7b835653 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md @@ -8,14 +8,8 @@ import TabItem from '@theme/TabItem'; For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Banzai Cloud Logging operator documentation.](https://banzaicloud.com/docs/one-eye/logging-operator/configuration/output/) -- [Configuration](#configuration) -- [YAML Examples](#yaml-examples) - - [Cluster Output to ElasticSearch](#cluster-output-to-elasticsearch) - - [Output to Splunk](#output-to-splunk) - - [Output to Syslog](#output-to-syslog) - - [Unsupported Outputs](#unsupported-outputs) -# Configuration +## Configuration @@ -23,7 +17,7 @@ For the full details on configuring `Outputs` and `ClusterOutputs`, see the [Ban - [Outputs](#outputs-2-5-8) - [ClusterOutputs](#clusteroutputs-2-5-8) -# Changes in v2.5.8 +## Changes in v2.5.8 The `Outputs` and `ClusterOutputs` can now be configured by filling out forms in the Rancher UI. @@ -65,7 +59,7 @@ For example configuration for each logging plugin supported by the logging opera -# ClusterOutputs +## ClusterOutputs `ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator. @@ -93,7 +87,7 @@ For examples of configuration for each logging plugin supported by the logging o -# ClusterOutputs +## ClusterOutputs `ClusterOutput` defines an `Output` without namespace restrictions. It is only effective when deployed in the same namespace as the logging operator. @@ -107,7 +101,7 @@ For example configuration for each logging plugin supported by the logging opera -# YAML Examples +## YAML Examples Once logging is installed, you can use these examples to help craft your own logging pipeline. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md index 6433010ae5b..585fb6c9404 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/logging-helm-chart-options.md @@ -4,12 +4,6 @@ shortTitle: Helm Chart Options weight: 4 --- -- [Enable/Disable Windows Node Logging](#enable-disable-windows-node-logging) -- [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory) -- [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints) -- [Enabling the Logging Application to Work with SELinux](#enabling-the-logging-application-to-work-with-selinux) -- [Additional Logging Sources](#additional-logging-sources) - ### Enable/Disable Windows Node Logging diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md index a5e6ff00d4c..8a53b44c63e 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md @@ -11,20 +11,8 @@ Among the many features and changes in the new logging functionality is the remo > Note: The pre-v2.5 user interface is now referred to as the _Cluster Manager_. The v2.5+ dashboard is referred to as the _Cluster Explorer_. -- [Installation](#installation) - - [Terminology](#terminology) -- [Cluster Logging](#cluster-logging) -- [Project Logging](#project-logging) -- [Output Configuration](#output-configuration) - - [Elasticsearch](#elasticsearch) - - [Splunk](#splunk) - - [Kafka](#kafka) - - [Fluentd](#fluentd) - - [Syslog](#syslog) -- [Custom Log Fields](#custom-log-fields) -- [System Logging](#system-logging) -# Installation +## Installation To install logging in Rancher v2.5+, refer to the [installation instructions](../../../pages-for-subheaders/logging.md#enabling-logging). @@ -52,7 +40,7 @@ There are four key concepts to understand for v2.5+ logging: `ClusterFlows` serve the same function as `Flows`, but at the cluster level. They are used to configure log collection for an entire cluster, instead of on a per-namespace level. `ClusterFlows` are also where mutations and filters are defined, same as `Flows` (in functionality). -# Cluster Logging +## Cluster Logging To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs. @@ -68,7 +56,7 @@ In legacy logging, in order to collect logs from across the entire cluster, one This will result in logs from all sources in the cluster (all pods, and all system components) being collected and sent to the `Output` or `Outputs` you defined in the `ClusterFlow`. -# Project Logging +## Project Logging Logging in v2.5+ is not project-aware. This means that in order to collect logs from pods running in project namespaces, you will need to define `Flows` for those namespaces. @@ -84,7 +72,7 @@ This will result in logs from all sources in the namespace (pods) being collecte > To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label. -# Output Configuration +## Output Configuration In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+. @@ -103,7 +91,7 @@ In legacy logging, there are five logging destinations to choose from: Elasticse In legacy logging, indices were automatically created according to the format in the "Index Patterns" section. In v2.5 logging, default behavior has been changed to logging to a single index. You can still configure index pattern functionality on the `Output` object by editing as YAML and inputting the following values: -``` +```yaml ... spec: elasticsearch: @@ -172,7 +160,7 @@ _(1) These values are to be specified as paths to files. Those files must be mou As of v2.5.2, syslog is not currently supported for `Outputs` using v2.5+ logging. -# Custom Log Fields +## Custom Log Fields In order to add custom log fields, you will need to add the following YAML to your `Flow` configuration: @@ -187,7 +175,7 @@ spec: (replace `foo: "bar"` with custom log fields you wish to add) -# System Logging +## System Logging In legacy logging, collecting logs from system components was accomplished by checking a box labeled "Include System Log" when setting up cluster logging. In v2.5+ logging, system logs are gathered in one of two ways: diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/longhorn.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/longhorn.md index df97fa46e74..ea2cf176ffe 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/longhorn.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/longhorn.md @@ -22,6 +22,7 @@ With Longhorn, you can: - Upgrade Longhorn without disrupting persistent volumes
Longhorn Dashboard
+ ![Longhorn Dashboard](/img/longhorn-screenshot.png) ### New in Rancher v2.5 diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md index cdaac5fb0cb..cefaa88cf4c 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/built-in-dashboards.md @@ -3,11 +3,7 @@ title: Built-in Dashboards weight: 3 --- -- [Grafana UI](#grafana-ui) -- [Alertmanager UI](#alertmanager-ui) -- [Prometheus UI](#prometheus-ui) - -# Grafana UI +## Grafana UI [Grafana](https://grafana.com/grafana/) allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture. @@ -26,7 +22,7 @@ To create a persistent Grafana dashboard, see [this page.](../../../how-to-guide For information about role-based access control for Grafana, see [this section.](rbac-for-monitoring.md#role-based-access-control-for-grafana) -# Alertmanager UI +## Alertmanager UI When `rancher-monitoring` is installed, the Prometheus Alertmanager UI is deployed, allowing you to view your alerts and the current Alertmanager configuration. @@ -52,13 +48,14 @@ To see the Alertmanager UI, go to the **Cluster Explorer.** In the top left corn To see alerts that are fired by default, go to the Alertmanager UI and click **Expand all groups.** -# Prometheus UI +## Prometheus UI By default, the [kube-state-metrics service](https://github.com/kubernetes/kube-state-metrics) provides a wealth of information about CPU and memory utilization to the monitoring application. These metrics cover Kubernetes resources across namespaces. This means that in order to see resource metrics for a service, you don't need to create a new ServiceMonitor for it. Because the data is already in the time series database, you can go to the Prometheus UI and run a PromQL query to get the information. The same query can be used to configure a Grafana dashboard to show a graph of those metrics over time. To see the Prometheus UI, install `rancher-monitoring`. Then go to the **Cluster Explorer.** In the top left corner, click **Cluster Explorer > Monitoring.** Then click **Prometheus Graph.**
Prometheus Graph UI
+ ![Prometheus Graph UI](/img/prometheus-graph-ui.png) ### Viewing the Prometheus Targets diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md index d2937abac79..5f9cd11cf73 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md @@ -3,13 +3,8 @@ title: How Monitoring Works weight: 1 --- -1. [Architecture Overview](#1-architecture-overview) -2. [How Prometheus Works](#2-how-prometheus-works) -3. [How Alertmanager Works](#3-how-alertmanager-works) -4. [Monitoring V2 Specific Components](#4-monitoring-v2-specific-components) -5. [Scraping and Exposing Metrics](#5-scraping-and-exposing-metrics) -# 1. Architecture Overview +## 1. Architecture Overview _**The following sections describe how data flows through the Monitoring V2 application:**_ @@ -67,7 +62,7 @@ Once Prometheus determines that an alert needs to be fired, alerts are forwarded
How data flows through the monitoring application:
-# 2. How Prometheus Works +## 2. How Prometheus Works ### Storing Time Series Data @@ -111,7 +106,7 @@ The Rule file adds labels and annotations to alerts before firing them, dependin - Annotations denote information that doesn't affect where an alert is routed, for example, a runbook or an error message. -# 3. How Alertmanager Works +## 3. How Alertmanager Works The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of the following tasks: @@ -139,7 +134,7 @@ By editing the forms in the Rancher UI, you can set up a Receiver resource with By editing custom YAML in the Alertmanager or Receiver configuration, you can also send alerts to multiple notification systems. For more information, see the section on configuring [Receivers.](../../../reference-guides/monitoring-v2-configuration/receivers.md#configuring-multiple-receivers) -# 4. Monitoring V2 Specific Components +## 4. Monitoring V2 Specific Components Prometheus Operator introduces a set of [Custom Resource Definitions](https://github.com/prometheus-operator/prometheus-operator#customresourcedefinitions) that allow users to deploy and manage Prometheus and Alertmanager instances by creating and modifying those custom resources on a cluster. @@ -185,7 +180,7 @@ Since the metrics for Kubernetes components are generally exposed on the host ne Refer to [Scraping Metrics with PushProx](#scraping-metrics-with-pushprox) for more. -# 5. Scraping and Exposing Metrics +## 5. Scraping and Exposing Metrics ### Defining what Metrics are Scraped diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md index 40a128118dd..5850793ed2d 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/promql-expressions.md @@ -14,70 +14,8 @@ The PromQL expressions in this doc can be used to configure alerts. For more information about querying the Prometheus time series database, refer to the official [Prometheus documentation.](https://prometheus.io/docs/prometheus/latest/querying/basics/) - -- [Cluster Metrics](#cluster-metrics) - - [Cluster CPU Utilization](#cluster-cpu-utilization) - - [Cluster Load Average](#cluster-load-average) - - [Cluster Memory Utilization](#cluster-memory-utilization) - - [Cluster Disk Utilization](#cluster-disk-utilization) - - [Cluster Disk I/O](#cluster-disk-i-o) - - [Cluster Network Packets](#cluster-network-packets) - - [Cluster Network I/O](#cluster-network-i-o) -- [Node Metrics](#node-metrics) - - [Node CPU Utilization](#node-cpu-utilization) - - [Node Load Average](#node-load-average) - - [Node Memory Utilization](#node-memory-utilization) - - [Node Disk Utilization](#node-disk-utilization) - - [Node Disk I/O](#node-disk-i-o) - - [Node Network Packets](#node-network-packets) - - [Node Network I/O](#node-network-i-o) -- [Etcd Metrics](#etcd-metrics) - - [Etcd Has a Leader](#etcd-has-a-leader) - - [Number of Times the Leader Changes](#number-of-times-the-leader-changes) - - [Number of Failed Proposals](#number-of-failed-proposals) - - [GRPC Client Traffic](#grpc-client-traffic) - - [Peer Traffic](#peer-traffic) - - [DB Size](#db-size) - - [Active Streams](#active-streams) - - [Raft Proposals](#raft-proposals) - - [RPC Rate](#rpc-rate) - - [Disk Operations](#disk-operations) - - [Disk Sync Duration](#disk-sync-duration) -- [Kubernetes Components Metrics](#kubernetes-components-metrics) - - [API Server Request Latency](#api-server-request-latency) - - [API Server Request Rate](#api-server-request-rate) - - [Scheduling Failed Pods](#scheduling-failed-pods) - - [Controller Manager Queue Depth](#controller-manager-queue-depth) - - [Scheduler E2E Scheduling Latency](#scheduler-e2e-scheduling-latency) - - [Scheduler Preemption Attempts](#scheduler-preemption-attempts) - - [Ingress Controller Connections](#ingress-controller-connections) - - [Ingress Controller Request Process Time](#ingress-controller-request-process-time) -- [Rancher Logging Metrics](#rancher-logging-metrics) - - [Fluentd Buffer Queue Rate](#fluentd-buffer-queue-rate) - - [Fluentd Input Rate](#fluentd-input-rate) - - [Fluentd Output Errors Rate](#fluentd-output-errors-rate) - - [Fluentd Output Rate](#fluentd-output-rate) -- [Workload Metrics](#workload-metrics) - - [Workload CPU Utilization](#workload-cpu-utilization) - - [Workload Memory Utilization](#workload-memory-utilization) - - [Workload Network Packets](#workload-network-packets) - - [Workload Network I/O](#workload-network-i-o) - - [Workload Disk I/O](#workload-disk-i-o) -- [Pod Metrics](#pod-metrics) - - [Pod CPU Utilization](#pod-cpu-utilization) - - [Pod Memory Utilization](#pod-memory-utilization) - - [Pod Network Packets](#pod-network-packets) - - [Pod Network I/O](#pod-network-i-o) - - [Pod Disk I/O](#pod-disk-i-o) -- [Container Metrics](#container-metrics) - - [Container CPU Utilization](#container-cpu-utilization) - - [Container Memory Utilization](#container-memory-utilization) - - [Container Disk I/O](#container-disk-i-o) - - - -# Cluster Metrics +## Cluster Metrics ### Cluster CPU Utilization @@ -128,7 +66,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m])) by (instance)
| | Summary |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*"}[5m]))
| -# Node Metrics +## Node Metrics ### Node CPU Utilization @@ -179,7 +117,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m])) by (device)
| | Summary |
receivesum(rate(node_network_receive_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))
transmitsum(rate(node_network_transmit_bytes_total{device!~"lo | veth.* | docker.* | flannel.* | cali.* | cbr.*",instance=~"$instance"}[5m]))
| -# Etcd Metrics +## Etcd Metrics ### Etcd Has a Leader @@ -249,7 +187,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
wal`histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le))`
db`histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le))`
| | Summary |
wal`sum(histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) by (instance, le)))`
db`sum(histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[5m])) by (instance, le)))`
| -# Kubernetes Components Metrics +## Kubernetes Components Metrics ### API Server Request Latency @@ -307,7 +245,7 @@ For more information about querying the Prometheus time series database, refer t | Detail | `topk(10, histogram_quantile(0.95,sum by (le, host, path)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` | | Summary | `topk(10, histogram_quantile(0.95,sum by (le, host)(rate(nginx_ingress_controller_request_duration_seconds_bucket{host!="_"}[5m]))))` | -# Rancher Logging Metrics +## Rancher Logging Metrics ### Fluentd Buffer Queue Rate @@ -338,7 +276,7 @@ For more information about querying the Prometheus time series database, refer t | Detail | `sum(rate(fluentd_output_status_num_records_total[5m])) by (instance)` | | Summary | `sum(rate(fluentd_output_status_num_records_total[5m]))` | -# Workload Metrics +## Workload Metrics ### Workload CPU Utilization @@ -375,7 +313,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m])) by (pod_name)`
| | Summary |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name=~"$podName",container_name!=""}[5m]))`
| -# Pod Metrics +## Pod Metrics ### Pod CPU Utilization @@ -412,7 +350,7 @@ For more information about querying the Prometheus time series database, refer t | Detail |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m])) by (container_name)`
| | Summary |
read`sum(rate(container_fs_reads_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`
write`sum(rate(container_fs_writes_bytes_total{namespace="$namespace",pod_name="$podName",container_name!=""}[5m]))`
| -# Container Metrics +## Container Metrics ### Container CPU Utilization diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md index 03b10ec375c..a9040d3044d 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md @@ -10,18 +10,7 @@ aliases: --- This section describes the expectations for RBAC for Rancher Monitoring. -- [Cluster Admins](#cluster-admins) -- [Users with Kubernetes ClusterRole-based Permissions](#users-with-kubernetes-clusterrole-based-permissions) - - [Users with Kubernetes Admin/Edit Permissions](#users-with-kubernetes-admin-edit-permissions) - - [Users with Kubernetes View Permissions](#users-with-kubernetes-view-permissions) - - [Additional Monitoring Roles](#additional-monitoring-roles) - - [Additional Monitoring ClusterRoles](#additional-monitoring-clusterroles) -- [Users with Rancher Cluster Manager Based Permissions](#users-with-rancher-cluster-manager-based-permissions) - - [Differences in 2.5.x](#differences-in-2-5-x) - - [Assigning Additional Access](#assigning-additional-access) -- [Role-based Access Control for Grafana](#role-based-access-control-for-grafana) - -# Cluster Admins +## Cluster Admins By default, only those with the cluster-admin `ClusterRole` should be able to: @@ -32,7 +21,7 @@ By default, only those with the cluster-admin `ClusterRole` should be able to: - Persist new Grafana dashboards or datasources via creating ConfigMaps in the appropriate namespace - Expose certain Prometheus metrics to the k8s Custom Metrics API for HPA via a Secret in the `cattle-monitoring-system` namespace -# Users with Kubernetes ClusterRole-based Permissions +## Users with Kubernetes ClusterRole-based Permissions The `rancher-monitoring` chart installs the following three `ClusterRoles`. By default, they aggregate into the corresponding k8s `ClusterRoles`: @@ -97,7 +86,7 @@ An alternative method to using Rancher to attach a `Role` or `ClusterRole` to a * **Roles**: Below is an example of a YAML file to help you configure `RoleBindings` in Kubernetes to attach to a user. You will need to fill in the name below, and name is case-sensitive. -``` +```yaml # monitoring-config-view-role-binding.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding @@ -118,7 +107,7 @@ subjects: * **`kubectl apply -f monitoring-config-view-role-binding.yaml` -# Users with Rancher Cluster Manager Based Permissions +## Users with Rancher Cluster Manager Based Permissions The relationship between the default roles deployed by Rancher Cluster Manager (i.e. cluster-owner, cluster-member, project-owner, project-member), the default k8s roles, and the roles deployed by the rancher-monitoring chart are detailed in the table below: @@ -165,7 +154,7 @@ If cluster-admins would like to provide additional admin/edit access to users ou -# Role-based Access Control for Grafana +## Role-based Access Control for Grafana Rancher allows any users who are authenticated by Kubernetes and have access the Grafana service deployed by the Rancher Monitoring chart to access Grafana via the Rancher Dashboard UI. By default, all users who are able to access Grafana are given the [Viewer](https://grafana.com/docs/grafana/latest/permissions/organization_roles/#viewer-role) role, which allows them to view any of the default dashboards deployed by Rancher. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md index 3a2b0e3deda..9549b841f1b 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md @@ -12,13 +12,13 @@ Starting at Monitoring V2 14.5.100 (used by default in Rancher 2.5.8), Monitorin - [Cluster Requirements](#cluster-requirements) - [Upgrading Existing Clusters to wins v0.1.0](#upgrading-existing-clusters-to-wins-v0-1-0) -# Comparison to Monitoring V1 +## Comparison to Monitoring V1 Unlike Monitoring V1 for Windows, metrics collected by `windows_exporter` will be labeled as `windows_` instead of `wmi_` in accordance to a naming change from upstream from `wmi_exporter` to `windows_exporter`. In addition, Monitoring V2 for Windows will no longer require users to keep port 9796 open on Windows hosts since the host metrics will published directly onto a port exposed on the windows-exporter Pod. This feature was powered by recent changes made by `wins` v0.1.0 to support publishing ports exposed on the hostNetwork on Pods that use wins to run a privileged Windows binary as a host process. -# Cluster Requirements +## Cluster Requirements Monitoring V2 for Windows can only scrape metrics from Windows hosts that have a minimum `wins` version of v0.1.0. To be able to fully deploy Monitoring V2 for Windows, all of your hosts must meet this requirement. diff --git a/versioned_docs/version-2.5/explanations/integrations-in-rancher/opa-gatekeeper.md b/versioned_docs/version-2.5/explanations/integrations-in-rancher/opa-gatekeeper.md index e868c51b534..25244ffa96f 100644 --- a/versioned_docs/version-2.5/explanations/integrations-in-rancher/opa-gatekeeper.md +++ b/versioned_docs/version-2.5/explanations/integrations-in-rancher/opa-gatekeeper.md @@ -20,13 +20,13 @@ OPA provides a high-level declarative language that lets you specify policy as c To read more about OPA, please refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/) -# How the OPA Gatekeeper Integration Works +## How the OPA Gatekeeper Integration Works Kubernetes provides the ability to extend API server functionality via admission controller webhooks, which are invoked whenever a resource is created, updated or deleted. Gatekeeper is installed as a validating webhook and enforces policies defined by Kubernetes custom resource definitions. In addition to the admission control usage, Gatekeeper provides the capability to audit existing resources in Kubernetes clusters and mark current violations of enabled policies. OPA Gatekeeper is made available via Rancher's Helm system chart, and it is installed in a namespace named `gatekeeper-system.` -# Enabling OPA Gatekeeper in a Cluster +## Enabling OPA Gatekeeper in a Cluster > In Rancher v2.5, the OPA Gatekeeper application was improved. The Rancher v2.4 feature can't be upgraded to the new version in Rancher v2.5. If you installed OPA Gatekeeper in Rancher v2.4, you will need to uninstall OPA Gatekeeper and its CRDs from the old UI, then reinstall it in Rancher v2.5. To uninstall the CRDs run the following command in the kubectl console `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh`. @@ -52,7 +52,7 @@ OPA Gatekeeper can be installed from the new **Cluster Explorer** view in Ranche **Result:** OPA Gatekeeper is deployed in your Kubernetes cluster. -# Constraint Templates +## Constraint Templates [Constraint templates](https://github.com/open-policy-agent/gatekeeper#constraint-templates) are Kubernetes custom resources that define the schema and Rego logic of the OPA policy to be applied by Gatekeeper. For more information on the Rego policy language, refer to the [official documentation.](https://www.openpolicyagent.org/docs/latest/policy-language/) @@ -62,7 +62,7 @@ To list the constraint templates installed in the cluster, go to the left side m Rancher also provides the ability to create your own constraint templates by importing YAML definitions. -# Creating and Configuring Constraints +## Creating and Configuring Constraints [Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together. @@ -84,7 +84,7 @@ To limit the scope of the constraint only to user namespaces, always specify the Also, the constraint may interfere with other Rancher functionality and deny system workloads from being deployed. To avoid this, exclude all Rancher-specific namespaces from your constraints. -# Enforcing Constraints in your Cluster +## Enforcing Constraints in your Cluster When the **Enforcement Action** is **Deny,** the constraint is immediately enabled and will deny any requests that violate the policy defined. By default, the enforcement value is **Deny.** @@ -92,7 +92,7 @@ When the **Enforcement Action** is **Dryrun,** then any resources that violate t To enforce constraints, create a constraint using the form. In the **Enforcement Action** field, choose **Deny.** -# Audit and Violations in your Cluster +## Audit and Violations in your Cluster OPA Gatekeeper runs a periodic audit to check if any existing resource violates any enforced constraint. The audit-interval (default 300s) can be configured while installing Gatekeeper. @@ -102,7 +102,7 @@ Also under **Constraints,** the number of violations of the constraint can be fo The detail view of each constraint lists information about the resource that violated the constraint. -# Disabling Gatekeeper +## Disabling Gatekeeper 1. Navigate to the cluster's Dashboard view 1. On the left side menu, expand the cluster menu and click on **OPA Gatekeeper.** diff --git a/versioned_docs/version-2.5/faq/rancher-is-no-longer-needed.md b/versioned_docs/version-2.5/faq/rancher-is-no-longer-needed.md index d546c81d683..99431449ced 100644 --- a/versioned_docs/version-2.5/faq/rancher-is-no-longer-needed.md +++ b/versioned_docs/version-2.5/faq/rancher-is-no-longer-needed.md @@ -11,11 +11,6 @@ aliases: This page is intended to answer questions about what happens if you don't want Rancher anymore, if you don't want a cluster to be managed by Rancher anymore, or if the Rancher server is deleted. -- [If the Rancher server is deleted, what happens to the workloads in my downstream clusters?](#if-the-rancher-server-is-deleted-what-happens-to-the-workloads-in-my-downstream-clusters) -- [If the Rancher server is deleted, how do I access my downstream clusters?](#if-the-rancher-server-is-deleted-how-do-i-access-my-downstream-clusters) -- [What if I don't want Rancher anymore?](#what-if-i-don-t-want-rancher-anymore) -- [What if I don't want my registered cluster managed by Rancher?](#what-if-i-don-t-want-my-registered-cluster-managed-by-rancher) -- [What if I don't want my RKE cluster or hosted Kubernetes cluster managed by Rancher?](#what-if-i-don-t-want-my-rke-cluster-or-hosted-kubernetes-cluster-managed-by-rancher) ### If the Rancher server is deleted, what happens to the workloads in my downstream clusters? diff --git a/versioned_docs/version-2.5/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md b/versioned_docs/version-2.5/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md index c8ded03d68f..64d17ebc1af 100644 --- a/versioned_docs/version-2.5/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md +++ b/versioned_docs/version-2.5/getting-started/installation-and-upgrade/advanced-options/advanced-use-cases/configure-layer-7-nginx-load-balancer.md @@ -22,15 +22,6 @@ This install procedure walks you through deployment of Rancher using a single co Make sure that your node fulfills the general [installation requirements.](../../../../pages-for-subheaders/installation-requirements.md) -## Installation Outline - - - -- [1. Provision Linux Host](#1-provision-linux-host) -- [2. Choose an SSL Option and Install Rancher](#2-choose-an-ssl-option-and-install-rancher) -- [3. Configure Load Balancer](#3-configure-load-balancer) - - ## 1. Provision Linux Host diff --git a/versioned_docs/version-2.5/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md b/versioned_docs/version-2.5/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md index 7cd1227b694..a26aa6d8b8a 100644 --- a/versioned_docs/version-2.5/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md +++ b/versioned_docs/version-2.5/getting-started/installation-and-upgrade/upgrade-and-roll-back-kubernetes.md @@ -9,33 +9,19 @@ Following an upgrade to the latest version of Rancher, downstream Kubernetes clu Rancher calls RKE (Rancher Kubernetes Engine) as a library when provisioning and editing RKE clusters. For more information on configuring the upgrade strategy for RKE clusters, refer to the [RKE documentation](https://rancher.com/docs/rke/latest/en/). -This section covers the following topics: -- [New Features](#new-features) -- [Tested Kubernetes Versions](#tested-kubernetes-versions) -- [How Upgrades Work](#how-upgrades-work) -- [Recommended Best Practice for Upgrades](#recommended-best-practice-for-upgrades) -- [Upgrading the Kubernetes Version](#upgrading-the-kubernetes-version) -- [Rolling Back](#rolling-back) -- [Configuring the Upgrade Strategy](#configuring-the-upgrade-strategy) - - [Configuring the Maximum Unavailable Worker Nodes in the Rancher UI](#configuring-the-maximum-unavailable-worker-nodes-in-the-rancher-ui) - - [Enabling Draining Nodes During Upgrades from the Rancher UI](#enabling-draining-nodes-during-upgrades-from-the-rancher-ui) - - [Maintaining Availability for Applications During Upgrades](#maintaining-availability-for-applications-during-upgrades) - - [Configuring the Upgrade Strategy in the cluster.yml](#configuring-the-upgrade-strategy-in-the-cluster-yml) -- [Troubleshooting](#troubleshooting) - -# Tested Kubernetes Versions +## Tested Kubernetes Versions Before a new version of Rancher is released, it's tested with the latest minor versions of Kubernetes to ensure compatibility. For details on which versions of Kubernetes were tested on each Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.5.9/) -# How Upgrades Work +## How Upgrades Work RKE v1.1.0 changed the way that clusters are upgraded. In this section of the [RKE documentation,](https://rancher.com/docs/rke/latest/en/upgrades/how-upgrades-work) you'll learn what happens when you edit or upgrade your RKE Kubernetes cluster. -# Recommended Best Practice for Upgrades +## Recommended Best Practice for Upgrades When upgrading the Kubernetes version of a cluster, we recommend that you: @@ -45,7 +31,7 @@ When upgrading the Kubernetes version of a cluster, we recommend that you: The restore operation will work on a cluster that is not in a healthy or active state. -# Upgrading the Kubernetes Version +## Upgrading the Kubernetes Version > **Prerequisites:** > @@ -69,7 +55,7 @@ A cluster can be restored to a backup in which the previous Kubernetes version w - [Backing up a cluster](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md#how-snapshots-work) - [Restoring a cluster from backup](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md#restoring-a-cluster-from-a-snapshot) -# Configuring the Upgrade Strategy +## Configuring the Upgrade Strategy As of RKE v1.1.0, additional upgrade options became available to give you more granular control over the upgrade process. These options can be used to maintain availability of your applications during a cluster upgrade if certain [conditions and requirements](https://rancher.com/docs/rke/latest/en/upgrades/maintaining-availability) are met. @@ -120,7 +106,7 @@ More advanced upgrade strategy configuration options are available by editing th For details, refer to [Configuring the Upgrade Strategy](https://rancher.com/docs/rke/latest/en/upgrades/configuring-strategy) in the RKE documentation. The section also includes an example `cluster.yml` for configuring the upgrade strategy. -# Troubleshooting +## Troubleshooting If a node doesn't come up after an upgrade, the `rke up` command errors out. diff --git a/versioned_docs/version-2.5/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md b/versioned_docs/version-2.5/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md index 433b70b4043..6d44e8f8259 100644 --- a/versioned_docs/version-2.5/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md +++ b/versioned_docs/version-2.5/getting-started/quick-start-guides/deploy-rancher-manager/helm-cli.md @@ -12,22 +12,6 @@ Howdy Partner! This tutorial walks you through: >**Note:** The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../../pages-for-subheaders/installation-and-upgrade.md). -## Quick Start Outline - -This Quick Start Guide is divided into different tasks for easier consumption. - - - - -1. [Provision a Linux Host](#1-provision-a-linux-host) - -1. [Install Rancher](#2-install-rancher) - -1. [Log In](#3-log-in) - -1. [Create the Cluster](#4-create-the-cluster) - -
### 1. Provision a Linux Host diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md index 622ddaf634a..62c5118a853 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/authentication-config/configure-azure-ad.md @@ -31,15 +31,6 @@ Configuring Rancher to allow your users to authenticate with their Azure AD acco >**Tip:** Before you start, we recommend creating an empty text file. You can use this file to copy values from Azure that you'll paste into Rancher later. - - -- [1. Register Rancher with Azure](#1-register-rancher-with-azure) -- [2. Create a new client secret](#2-create-a-new-client-secret) -- [3. Set Required Permissions for Rancher](#3-set-required-permissions-for-rancher) -- [4. Copy Azure Application Data](#5-copy-azure-application-data) -- [5. Configure Azure AD in Rancher](#6-configure-azure-ad-in-rancher) - - #### 1. Register Rancher with Azure diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md index 66898351d16..cc943799b90 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md @@ -13,12 +13,6 @@ You can [save the configuration of an existing cluster as an RKE template.](#con You can't change a cluster to use a different RKE template. You can only update the cluster to a new revision of the same template. -This section covers the following topics: - -- [Creating a cluster from an RKE template](#creating-a-cluster-from-an-rke-template) -- [Updating a cluster created with an RKE template](#updating-a-cluster-created-with-an-rke-template) -- [Converting an existing cluster to use an RKE template](#converting-an-existing-cluster-to-use-an-rke-template) - ### Creating a Cluster from an RKE Template To add a cluster [hosted by an infrastructure provider](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) using an RKE template, use these steps: diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md index d8d9cac1bc0..b9c2c010935 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/enforce-templates.md @@ -17,7 +17,7 @@ Users can only create new templates if the administrator [gives them permission. After a cluster is created with an RKE template, the cluster creator cannot edit settings that are defined in the template. The only way to change those settings after the cluster is created is to [upgrade the cluster to a new revision](apply-templates.md#updating-a-cluster-created-with-an-rke-template) of the same template. If cluster creators want to change template-defined settings, they would need to contact the template owner to get a new revision of the template. For details on how template revisions work, refer to the [documentation on revising templates.](manage-rke1-templates.md#updating-a-template) -# Requiring New Clusters to Use an RKE Template +## Requiring New Clusters to Use an RKE Template You might want to require new clusters to use a template to ensure that any cluster launched by a [standard user](../manage-role-based-access-control-rbac/global-permissions.md) will use the Kubernetes and/or Rancher settings that are vetted by administrators. @@ -29,7 +29,7 @@ To require new clusters to use an RKE template, administrators can turn on RKE t **Result:** All clusters provisioned by Rancher must use a template, unless the creator is an administrator. -# Disabling RKE Template Enforcement +## Disabling RKE Template Enforcement To allow new clusters to be created without an RKE template, administrators can turn off RKE template enforcement with the following steps: diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md index a5a1c1ede93..ec700d51cb5 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md @@ -13,7 +13,7 @@ These example scenarios describe how an organization could use templates to stan - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to delegate ownership of the template, this scenario describes how [template ownership can be shared.](#allowing-other-users-to-control-and-share-a-template) -# Enforcing a Template Setting for Everyone +## Enforcing a Template Setting for Everyone Let's say there is an organization in which the administrators decide that all new clusters should be created with Kubernetes version 1.14. @@ -29,7 +29,7 @@ Let's say there is an organization in which the administrators decide that all n In this way, the administrators enforce the Kubernetes version across the organization, while still allowing end users to configure everything else. -# Templates for Basic and Advanced Users +## Templates for Basic and Advanced Users Let's say an organization has both basic and advanced users. Administrators want the basic users to be required to use a template, while the advanced users and administrators create their clusters however they want. @@ -44,7 +44,7 @@ Let's say an organization has both basic and advanced users. Administrators want **Result:** All Rancher users, except for administrators, are required to use a template when creating a cluster. Everyone has access to the restrictive template, but only advanced users have permission to use the more permissive template. The basic users are more restricted, while advanced users have more freedom when configuring their Kubernetes clusters. -# Updating Templates and Clusters Created with Them +## Updating Templates and Clusters Created with Them Let's say an organization has a template that requires clusters to use Kubernetes v1.14. However, as time goes on, the administrators change their minds. They decide they want users to be able to upgrade their clusters to use newer versions of Kubernetes. @@ -56,7 +56,7 @@ The template owner has several options for allowing the cluster creators to upgr - **Allow any Kubernetes version on the template:** When creating a template revision, the template owner can also mark the the Kubernetes version as **Allow User Override** using the switch near that setting on the Rancher UI. This will allow clusters that upgrade to this template revision to use any version of Kubernetes. - **Allow the latest minor Kubernetes version on the template:** The template owner can also create a template revision in which the Kubernetes version is defined as **Latest v1.14 (Allows patch version upgrades).** This means clusters that use that revision will be able to get patch version upgrades, but major version upgrades will not be allowed. -# Allowing Other Users to Control and Share a Template +## Allowing Other Users to Control and Share a Template Let's say Alice is a Rancher administrator. She owns an RKE template that reflects her organization's agreed-upon best practices for creating a cluster. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md index bed1648d4d8..0b9dac6d5ed 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md @@ -31,7 +31,7 @@ Terraform allows you to: - Incorporate infrastructure changes into standard development practices - Prevent configuration drift, in which some servers become configured differently than others -# How Does Terraform Work? +## How Does Terraform Work? Terraform is written in files with the extension `.tf`. It is written in HashiCorp Configuration Language, which is a declarative language that lets you define the infrastructure you want in your cluster, the cloud provider you are using, and your credentials for the provider. Then Terraform makes API calls to the provider in order to efficiently create that infrastructure. @@ -41,7 +41,7 @@ Then Terraform calls the Rancher API to provision your infrastructure, and Ranch When you need to make changes to your infrastructure, instead of manually updating the servers, you can make changes in the Terraform configuration files. Then those files can be committed to version control, validated, and reviewed as necessary. Then when you run `terraform apply`, the changes would be deployed. -# Tips for Working with Terraform +## Tips for Working with Terraform - There are examples of how to provide most aspects of a cluster in the [documentation for the Rancher 2 provider.](https://www.terraform.io/docs/providers/rancher2/) @@ -53,7 +53,7 @@ When you need to make changes to your infrastructure, instead of manually updati - If you want to manage Kubernetes cluster settings, Rancher settings, and hardware settings all in one place, use [Terraform modules](https://github.com/rancher/terraform-modules). You can pass a cluster configuration YAML file or an RKE template configuration file to a Terraform module so that the Terraform module will create it. In that case, you could use your infrastructure-as-code to manage the version control and revision history of both your Kubernetes cluster and its underlying hardware. -# Tip for Creating CIS Benchmark Compliant Clusters +## Tip for Creating CIS Benchmark Compliant Clusters This section describes one way that you can make security and compliance-related config files standard in your clusters. @@ -65,7 +65,7 @@ Then you would make sure that the `kube-api-server` flag in your RKE template us In this way, you can create flags that comply with the CIS benchmark. -# Resources +## Resources - [Terraform documentation](https://www.terraform.io/docs/) - [Rancher2 Terraform provider documentation](https://www.terraform.io/docs/providers/rancher2/) diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md index 12320d8bab3..07084a79bff 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md @@ -13,21 +13,6 @@ Template revisions can be used in two ways: to create a new cluster, or to upgra The template owner has full control over template revisions, and can create new revisions to update the template, delete or disable revisions that should not be used to create clusters, and choose which template revision is the default. -This section covers the following topics: - -- [Prerequisites](#prerequisites) -- [Creating a template](#creating-a-template) -- [Updating a template](#updating-a-template) -- [Deleting a template](#deleting-a-template) -- [Creating a revision based on the default revision](#creating-a-revision-based-on-the-default-revision) -- [Creating a revision based on a cloned revision](#creating-a-revision-based-on-a-cloned-revision) -- [Disabling a template revision](#disabling-a-template-revision) -- [Re-enabling a disabled template revision](#re-enabling-a-disabled-template-revision) -- [Setting a template revision as default](#setting-a-template-revision-as-default) -- [Deleting a template revision](#deleting-a-template-revision) -- [Upgrading a cluster to use a new template revision](#upgrading-a-cluster-to-use-a-new-template-revision) -- [Exporting a running cluster to a new RKE template and revision](#exporting-a-running-cluster-to-a-new-rke-template-and-revision) - ### Prerequisites You can create RKE templates if you have the **Create RKE Templates** permission, which can be [given by an administrator.](creator-permissions.md) diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md index d7b08ae0ea0..2ff58e0fe25 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/create-pod-security-policies.md @@ -12,16 +12,8 @@ _Pod Security Policies_ (or PSPs) are objects that control security-sensitive as If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message of `Pod is forbidden: unable to validate...`. -- [How PSPs Work](#how-psps-work) -- [Default PSPs](#default-psps) - - [Restricted](#restricted) - - [Unrestricted](#unrestricted) -- [Creating PSPs](#creating-psps) - - [Requirements](#requirements) - - [Creating PSPs in the Rancher UI](#creating-psps-in-the-rancher-ui) -- [Configuration](#configuration) -# How PSPs Work +## How PSPs Work You can assign PSPs at the cluster or project level. @@ -35,7 +27,7 @@ Any workloads that are already running in a cluster or project before a PSP is a Read more about Pod Security Policies in the [Kubernetes Documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/). -# Default PSPs +## Default PSPs Rancher ships with two default Pod Security Policies (PSPs): the `restricted` and `unrestricted` policies. @@ -50,7 +42,7 @@ This policy is based on the Kubernetes [example restricted policy](https://raw.g This policy is equivalent to running Kubernetes with the PSP controller disabled. It has no restrictions on what pods can be deployed into a cluster or project. -# Creating PSPs +## Creating PSPs Using Rancher, you can create a Pod Security Policy using our GUI rather than creating a YAML file. @@ -75,7 +67,7 @@ We recommend adding PSPs during cluster and project creation instead of adding i 3. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does. -# Configuration +## Configuration The Kubernetes documentation on PSPs is [here.](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md index 3f9babe4a8f..9d9624806fa 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/global-default-private-registry.md @@ -15,7 +15,7 @@ For instructions on setting up a private registry with command line options duri If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster. -# Setting a Private Registry with No Credentials as the Default Registry +## Setting a Private Registry with No Credentials as the Default Registry 1. Log into Rancher and configure the default administrator password. @@ -33,7 +33,7 @@ If your private registry requires credentials, it cannot be used as the default **Result:** Rancher will use your private registry to pull system images. -# Setting a Private Registry with Credentials when Deploying a Cluster +## Setting a Private Registry with Credentials when Deploying a Cluster You can follow these steps to configure a private registry when you provision a cluster with Rancher: diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md index 3be1c53fc00..906f313e3b8 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md @@ -12,23 +12,15 @@ Note that _roles_ are different from _permissions_, which determine what cluster > It is possible for a custom role to enable privilege escalation. For details, see [this section.](#privilege-escalation) -This section covers the following topics: -- [Prerequisites](#prerequisites) -- [Creating a custom role for a cluster or project](#creating-a-custom-role-for-a-cluster-or-project) -- [Creating a custom global role](#creating-a-custom-global-role) -- [Deleting a custom global role](#deleting-a-custom-global-role) -- [Assigning a custom global role to a group](#assigning-a-custom-global-role-to-a-group) -- [Privilege escalation](#privilege-escalation) - -# Prerequisites +## Prerequisites To complete the tasks on this page, one of the following permissions are required: - [Administrator Global Permissions](global-permissions.md). - [Custom Global Permissions](global-permissions.md#custom-global-permissions) with the [Manage Roles](global-permissions.md) role assigned. -# Creating A Custom Role for a Cluster or Project +## Creating A Custom Role for a Cluster or Project While Rancher comes out-of-the-box with a set of default user roles, you can also create default custom roles to provide users with very specific permissions within Rancher. @@ -61,7 +53,7 @@ The steps to add custom roles differ depending on the version of Rancher. 1. Click **Create**. -# Creating a Custom Global Role +## Creating a Custom Global Role ### Creating a Custom Global Role that Copies Rules from an Existing Role @@ -95,7 +87,7 @@ Custom global roles don't have to be based on existing roles. To create a custom 1. Click **Save.** -# Deleting a Custom Global Role +## Deleting a Custom Global Role When deleting a custom global role, all global role bindings with this custom role are deleted. @@ -109,7 +101,7 @@ To delete a custom global role, 2. On the **Global** tab, go to the custom global role that should be deleted and click **⋮ (…) > Delete.** 3. Click **Delete.** -# Assigning a Custom Global Role to a Group +## Assigning a Custom Global Role to a Group If you have a group of individuals that need the same level of access in Rancher, it can save time to create a custom global role. When the role is assigned to a group, the users in the group have the appropriate level of access the first time they sign into Rancher. @@ -134,7 +126,7 @@ To assign a custom global role to a group, follow these steps: **Result:** The custom global role will take effect when the users in the group log into Rancher. -# Privilege Escalation +## Privilege Escalation The `Configure Catalogs` custom permission is powerful and should be used with caution. When an admin assigns the `Configure Catalogs` permission to a standard user, it could result in privilege escalation in which the user could give themselves admin access to Rancher provisioned clusters. Anyone with this permission should be considered equivalent to an admin. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md index 3571ebfa117..f6ad8d03459 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md @@ -20,19 +20,6 @@ Global Permissions define user authorization outside the scope of any particular You cannot update or delete the built-in Global Permissions. -This section covers the following topics: - -- [Restricted Admin](#restricted-admin) -- [Global permission assignment](#global-permission-assignment) - - [Global permissions for new local users](#global-permissions-for-new-local-users) - - [Global permissions for users with external authentication](#global-permissions-for-users-with-external-authentication) -- [Custom global permissions](#custom-global-permissions) - - [Custom global permissions reference](#custom-global-permissions-reference) - - [Configuring default global permissions for new users](#configuring-default-global-permissions) - - [Configuring global permissions for existing individual users](#configuring-global-permissions-for-existing-individual-users) - - [Configuring global permissions for groups](#configuring-global-permissions-for-groups) - - [Refreshing group memberships](#refreshing-group-memberships) - # Restricted Admin A new `restricted-admin` role was created in Rancher v2.5 in order to prevent privilege escalation from the local Rancher server Kubernetes cluster. This role has full administrator access to all downstream clusters managed by Rancher, but it does not have permission to alter the local Kubernetes cluster. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md index 9ccf6c0309f..02b74aedc2c 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md @@ -15,13 +15,6 @@ This section describes how to manipulate your downstream Kubernetes cluster with For more information on using kubectl, see [Kubernetes Documentation: Overview of kubectl](https://kubernetes.io/docs/reference/kubectl/overview/). -- [Accessing clusters with kubectl shell in the Rancher UI](#accessing-clusters-with-kubectl-shell-in-the-rancher-ui) -- [Accessing clusters with kubectl from your workstation](#accessing-clusters-with-kubectl-from-your-workstation) -- [Note on Resources created using kubectl](#note-on-resources-created-using-kubectl) -- [Authenticating Directly with a Downstream Cluster](#authenticating-directly-with-a-downstream-cluster) - - [Connecting Directly to Clusters with FQDN Defined](#connecting-directly-to-clusters-with-fqdn-defined) - - [Connecting Directly to Clusters without FQDN Defined](#connecting-directly-to-clusters-without-fqdn-defined) - ### Accessing Clusters with kubectl Shell in the Rancher UI @@ -53,7 +46,7 @@ This alternative method of accessing the cluster allows you to authenticate with Rancher will discover and show resources created by `kubectl`. However, these resources might not have all the necessary annotations on discovery. If an operation (for instance, scaling the workload) is done to the resource using the Rancher UI/API, this may trigger recreation of the resources due to the missing annotations. This should only happen the first time an operation is done to the discovered resource. -# Authenticating Directly with a Downstream Cluster +## Authenticating Directly with a Downstream Cluster This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md index 527c9fe4bbe..1673fb99a87 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md @@ -21,15 +21,8 @@ For dynamic storage provisioning, your application will need to use a PVC that i For more information, refer to the [official Kubernetes documentation on storage](https://kubernetes.io/docs/concepts/storage/volumes/) -This section covers the following topics: -- [About persistent volume claims](#about-persistent-volume-claims) - - [PVCs are required for both new and existing persistent storage](#pvcs-are-required-for-both-new-and-existing-persistent-storage) -- [Setting up existing storage with a PVC and PV](#setting-up-existing-storage-with-a-pvc-and-pv) - - [Binding PVs to PVCs](#binding-pvs-to-pvcs) -- [Provisioning new storage with a PVC and storage class](#provisioning-new-storage-with-a-pvc-and-storage-class) - -# About Persistent Volume Claims +## About Persistent Volume Claims Persistent volume claims (PVCs) are objects that request storage resources from your cluster. They're similar to a voucher that your deployment can redeem for storage access. A PVC is mounted into a workloads as a volume so that the workload can claim its specified share of the persistent storage. @@ -49,7 +42,7 @@ Rancher lets you create as many PVCs within a project as you'd like. You can mount PVCs to a deployment as you create it, or later, after the deployment is running. -# Setting up Existing Storage with a PVC and PV +## Setting up Existing Storage with a PVC and PV Your pods can store data in [volumes,](https://kubernetes.io/docs/concepts/storage/volumes/) but if the pod fails, that data is lost. To solve this issue, Kubernetes offers persistent volumes (PVs), which are Kubernetes resources that correspond to external storage disks or file systems that your pods can access. If a pod crashes, its replacement pod can access the data in persistent storage without any data loss. @@ -69,7 +62,7 @@ In other words, you can create unlimited PVCs, but they will only be bound to PV To dynamically provision new storage, the PVC mounted in the pod would have to correspond to a storage class instead of a persistent volume. -# Provisioning New Storage with a PVC and Storage Class +## Provisioning New Storage with a PVC and Storage Class Storage Classes allow you to create PVs dynamically without having to create persistent storage in an infrastructure provider first. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md index 46dd40bfcaf..5a144889b9a 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/use-external-ceph-driver.md @@ -7,28 +7,12 @@ aliases: These instructions are about using the external Ceph driver in an RKE2 cluster. If you are using RKE, additional steps are required. For details, refer to [this section.](#using-the-ceph-driver-with-rke) -- [Requirements](#requirements) -- [Using the Ceph Driver with RKE](#using-the-ceph-driver-with-rke) -- [Installing the ceph-csi driver on an RKE2 cluster](#installing-the-ceph-csi-driver-on-an-rke2-cluster) -- [Install the ceph-csi driver using Helm](#install-the-ceph-csi-driver-using-helm) -- [Creating RBD Ceph Resources](#creating-rbd-ceph-resources) -- [Configure RBD Ceph Access Secrets](#configure-rbd-ceph-access-secrets) - - [User Account](#user-account) - - [Admin Account](#admin-account) -- [Create RBD Testing Resources](#create-rbd-testing-resources) - - [Using RBD in Pods](#using-rbd-in-pods) - - [Using RBD in Persistent Volumes](#using-rbd-in-persistent-volumes) - - [Using RBD in Storage Classes](#using-rbd-in-storage-classes) - - [RKE2 Server/Master Provisioning](#rke2-server-master-provisioning) - - [RKE2 Agent/Worker provisioning](#rke2-agent-worker-provisioning) -- [Tested Versions](#tested-versions) -- [Troubleshooting](#troubleshooting) -# Requirements +## Requirements Make sure ceph-common and xfsprogs packages are installed on SLE worker nodes. -# Using the Ceph Driver with RKE +## Using the Ceph Driver with RKE The resources below are fully compatible with RKE based clusters, but there is a need to do an additional kubelet configuration for RKE. @@ -47,7 +31,7 @@ services: For more information about the `extra_binds` directive, refer to [this section.](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds) -# Installing the ceph-csi driver on an RKE2 cluster +## Installing the ceph-csi driver on an RKE2 cluster > **Note:** These steps are needed for dynamic RBD provisioning only. @@ -75,7 +59,7 @@ min_mon_release 15 (octopus) Later you'll need the fsid and mon addresses values. -# Install the ceph-csi Driver Using Helm +## Install the ceph-csi Driver Using Helm Run these commands: @@ -117,7 +101,7 @@ helm upgrade \ --namespace ceph-csi-rbd ceph-csi-rbd ceph-csi/ceph-csi-rbd --values ceph-csi-rbd-values.yaml ``` -# Creating RBD Ceph Resources +## Creating RBD Ceph Resources ``` # Create a ceph pool: @@ -145,13 +129,13 @@ QVFCK0hDVmdXSjQ1T0JBQXBrc0VtcVhlZFpjc0JwaStIcmU5M3c9PQ== echo "myPoolAdmin" | tr -d '\n' | base64 bXlQb29sQWRtaW4= ``` -# Configure RBD Ceph Access Secrets +## Configure RBD Ceph Access Secrets ### User Account For static RBD provisioning (the image within the ceph pool must exist), run these commands: -``` +```yaml cat > ceph-user-secret.yaml << EOF apiVersion: v1 kind: Secret @@ -171,7 +155,7 @@ kubectl apply -f ceph-user-secret.yaml For dynamic RBD provisioning (used for automatic image creation within a given ceph pool), run these commands: -``` +```yaml cat > ceph-admin-secret.yaml << EOF apiVersion: v1 kind: Secret @@ -187,11 +171,11 @@ EOF kubectl apply -f ceph-admin-secret.yaml ``` -# Create RBD Testing Resources +## Create RBD Testing Resources ### Using RBD in Pods -``` +```yaml # pod cat > ceph-rbd-pod-inline.yaml << EOF apiVersion: v1 @@ -229,7 +213,7 @@ kubectl exec pod/ceph-rbd-pod-inline -- df -k | grep rbd ### Using RBD in Persistent Volumes -``` +```yaml # pod-pvc-pv cat > ceph-rbd-pod-pvc-pv-allinone.yaml << EOF apiVersion: v1 @@ -292,7 +276,7 @@ kubectl exec pod/ceph-rbd-pod-pvc-pv -- df -k | grep rbd This example is for dynamic provisioning. The ceph-csi driver is needed. -``` +```yaml # pod-pvc-sc cat > ceph-rbd-pod-pvc-sc-allinone.yaml < Other Cluster.** Then run the provided kubectl command on the server/master node. -# Tested Versions +## Tested Versions OS for running RKE2 nodes: JeOS SLE15-SP2 with installed kernel-default-5.3.18-24.49 @@ -399,7 +383,7 @@ version.BuildInfo{Version:"3.4.1", GitCommit:"c4e74854886b2efe3321e185578e6db9be Kubernetes version on RKE2 cluster: v1.19.7+rke2r1 -# Troubleshooting +## Troubleshooting In case you are using SUSE's ceph-rook based on SES7, it might be useful to expose the monitors on hostNetwork by editing `rook-1.4.5/ceph/cluster.yaml` and setting `spec.network.hostNetwork=true`. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md index 1d62a6a6915..0b6d90350c3 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md @@ -10,11 +10,6 @@ To provide stateful workloads with vSphere storage, we recommend creating a vSph In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](../../../../../pages-for-subheaders/vsphere-cloud-provider.md) -- [Prerequisites](#prerequisites) -- [Creating a StorageClass](#creating-a-storageclass) -- [Creating a Workload with a vSphere Volume](#creating-a-workload-with-a-vsphere-volume) -- [Verifying Persistence of the Volume](#verifying-persistence-of-the-volume) -- [Why to Use StatefulSets Instead of Deployments](#why-to-use-statefulsets-instead-of-deployments) ### Prerequisites diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md index 0d4d648698e..102a674be11 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/install-cluster-autoscaler/use-aws-ec2-auto-scaling-groups.md @@ -9,18 +9,8 @@ This guide will show you how to install and use [Kubernetes cluster-autoscaler]( We are going to install a Rancher RKE custom cluster with a fixed number of nodes with the etcd and controlplane roles, and a variable nodes with the worker role, managed by `cluster-autoscaler`. -- [Prerequisites](#prerequisites) -- [1. Create a Custom Cluster](#1-create-a-custom-cluster) -- [2. Configure the Cloud Provider](#2-configure-the-cloud-provider) -- [3. Deploy Nodes](#3-deploy-nodes) -- [4. Install cluster-autoscaler](#4-install-cluster-autoscaler) - - [Parameters](#parameters) - - [Deployment](#deployment) -- [Testing](#testing) - - [Generating Load](#generating-load) - - [Checking Scale](#checking-scale) -# Prerequisites +## Prerequisites These elements are required to follow this guide: diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md index 13f946bcb54..7b9497b7df4 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/nodes-and-node-pools.md @@ -9,24 +9,6 @@ After you launch a Kubernetes cluster in Rancher, you can manage individual node > If you want to manage the _cluster_ and not individual nodes, see [Editing Clusters](../../../pages-for-subheaders/cluster-configuration.md). -This section covers the following topics: - -- [Node options available for each cluster creation option](#node-options-available-for-each-cluster-creation-option) - - [Nodes hosted by an infrastructure provider](#nodes-hosted-by-an-infrastructure-provider) - - [Nodes provisioned by hosted Kubernetes providers](#nodes-provisioned-by-hosted-kubernetes-providers) - - [Registered nodes](#registered-nodes) -- [Managing and editing individual nodes](#managing-and-editing-individual-nodes) -- [Viewing a node in the Rancher API](#viewing-a-node-in-the-rancher-api) -- [Deleting a node](#deleting-a-node) -- [Scaling nodes](#scaling-nodes) -- [SSH into a node hosted by an infrastructure provider](#ssh-into-a-node-hosted-by-an-infrastructure-provider) -- [Cordoning a node](#cordoning-a-node) -- [Draining a node](#draining-a-node) - - [Aggressive and safe draining options](#aggressive-and-safe-draining-options) - - [Grace period](#grace-period) - - [Timeout](#timeout) - - [Drained and cordoned state](#drained-and-cordoned-state) -- [Labeling a node to be ignored by Rancher](#labeling-a-node-to-be-ignored-by-rancher) # Node Options Available for Each Cluster Creation Option diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md index 8b5505cd819..251046fa91b 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/manage-clusters/projects-and-namespaces.md @@ -14,18 +14,9 @@ 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. -This section describes how projects and namespaces work with Rancher. It covers the following topics: +This section describes how projects and namespaces work with Rancher. -- [About namespaces](#about-namespaces) -- [About projects](#about-projects) - - [The cluster's default project](#the-cluster-s-default-project) - - [The system project](#the-system-project) -- [Project authorization](#project-authorization) -- [Pod security policies](#pod-security-policies) -- [Creating projects](#creating-projects) -- [Switching between clusters and projects](#switching-between-clusters-and-projects) - -# About Namespaces +## About Namespaces A namespace is a concept introduced by Kubernetes. According to the [official Kubernetes documentation on namespaces,](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) @@ -63,7 +54,7 @@ If your permissions are restricted to the project level, it is better to [create If a standard user is a project owner, the user will be able to create namespaces within that project. The Rancher UI will prevent that user from creating namespaces outside the scope of the projects they have access to. -# About Projects +## About Projects In terms of hierarchy: @@ -109,18 +100,18 @@ The `system` project: >**Note:** In RKE clusters where the project network isolation option is enabled, the `system` project overrides the project network isolation option so that it can communicate with other projects, collect logs, and check health. -# Project Authorization +## Project Authorization Standard users are only authorized for project access in two situations: - An administrator, cluster owner or cluster member explicitly adds the standard user to the project's **Members** tab. - Standard users can access projects that they create themselves. -# Pod Security Policies +## Pod Security Policies Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policluster-admin/pod-security-policy/) at the [project level](../manage-projects/manage-pod-security-policies.md) in addition to the [cluster level.](./add-a-pod-security-policy.md) However, as a best practice, we recommend applying Pod Security Policies at the cluster level. -# Creating Projects +## Creating Projects This section describes how to create a new project with a name and with optional pod security policy, members, and resource quotas. @@ -186,7 +177,7 @@ To add a resource quota, | Project Limit | The overall resource limit for the project. | | Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project when created. The combined limit of all project namespaces shouldn't exceed the project limit. | -# Switching between Clusters and Projects +## Switching between Clusters and Projects To switch between clusters and projects, use the **Global** drop-down available in the main menu. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md index f518bd8f007..041906d0d4c 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md @@ -8,16 +8,7 @@ aliases: If you previously enabled Monitoring, Alerting, or Notifiers in Rancher before v2.5, there is no automatic upgrade path for switching to the new monitoring/alerting solution. Before deploying the new monitoring solution via Cluster Explore, you will need to disable and remove all existing custom alerts, notifiers and monitoring installations for the whole cluster and in all projects. -- [Monitoring Before Rancher v2.5](#monitoring-before-rancher-v2-5) -- [Monitoring and Alerting via Cluster Explorer in Rancher v2.5](#monitoring-and-alerting-via-cluster-explorer-in-rancher-v2-5) -- [Changes to Role-based Access Control](#changes-to-role-based-access-control) -- [Migrating from Monitoring V1 to Monitoring V2](#migrating-from-monitoring-v1-to-monitoring-v2) - - [Migrating Grafana Dashboards](#migrating-grafana-dashboards) - - [Migrating Alerts](#migrating-alerts) - - [Migrating Notifiers](#migrating-notifiers) - - [Migrating for RKE Template Users](#migrating-for-rke-template-users) - -# Monitoring Before Rancher v2.5 +## Monitoring Before Rancher v2.5 As of v2.2.0, Rancher's Cluster Manager allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster. @@ -27,7 +18,7 @@ Monitoring V1 could be configured on both a cluster-level and on a project-level When Alerts or Notifiers are enabled, Alerting V1 deploys [Prometheus Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) and a set of Rancher controllers onto a cluster that allows users to define alerts and configure alert-based notifications via Email, Slack, PagerDuty, etc. Users can choose to create different types of alerts depending on what needs to be monitored (e.g. System Services, Resources, CIS Scans, etc.); however, PromQL Expression-based alerts can only be created if Monitoring V1 is enabled. -# Monitoring and Alerting via Cluster Explorer in Rancher 2.5 +## Monitoring and Alerting via Cluster Explorer in Rancher 2.5 As of v2.5.0, Rancher's Cluster Explorer now allows users to enable Monitoring & Alerting V2 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) together within a cluster. @@ -37,13 +28,13 @@ Monitoring V2 can only be configured on the cluster level. Project-level monitor For more information on how to configure Monitoring & Alerting V2, see [this page.](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md) -# Changes to Role-based Access Control +## Changes to Role-based Access Control Project owners and members no longer get access to Grafana or Prometheus by default. If view-only users had access to Grafana, they would be able to see data from any namespace. For Kiali, any user can edit things they don’t own in any namespace. For more information about role-based access control in `rancher-monitoring`, refer to [this page.](../../../explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md) -# Migrating from Monitoring V1 to Monitoring V2 +## Migrating from Monitoring V1 to Monitoring V2 While there is no automatic migration available, it is possible to manually migrate custom Grafana dashboards and alerts that were created in Monitoring V1 to Monitoring V2. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md index 2397003911c..2c8ed38dc62 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/set-up-monitoring-for-workloads.md @@ -3,9 +3,6 @@ title: Setting up Monitoring for a Workload weight: 4 --- -- [Display CPU and Memory Metrics for a Workload](#display-cpu-and-memory-metrics-for-a-workload) -- [Setting up Metrics Beyond CPU and Memory](#setting-up-metrics-beyond-cpu-and-memory) - If you only need CPU and memory time series for the workload, you don't need to deploy a ServiceMonitor or PodMonitor because the monitoring application already collects metrics data on resource usage by default. The steps for setting up monitoring for workloads depend on whether you want basic metrics such as CPU and memory for the workload, or whether you want to scrape custom metrics from the workload. diff --git a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md index f5b27efc8bb..d0c98222ce8 100644 --- a/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md +++ b/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md @@ -9,7 +9,7 @@ When Receivers and Routes are updated, the monitoring application will automatic > This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#how-alertmanager-works) -# About the Alertmanager Custom Resource +## About the Alertmanager Custom Resource By default, Rancher Monitoring deploys a single Alertmanager onto a cluster that uses a default Alertmanager Config Secret. diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md index 11f44ddff26..05d9ae9e513 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher-launched-kubernetes-clusters.md @@ -11,20 +11,6 @@ Rancher recommends configuring recurrent `etcd` snapshots for all production clu Snapshots of the etcd database are taken and saved either [locally onto the etcd nodes](#local-backup-target) or to a [S3 compatible target](#s3-backup-target). The advantages of configuring S3 is that if all etcd nodes are lost, your snapshot is saved remotely and can be used to restore the cluster. -This section covers the following topics: - -- [How snapshots work](#how-snapshots-work) -- [Configuring recurring snapshots](#configuring-recurring-snapshots) -- [One-time snapshots](#one-time-snapshots) -- [Snapshot backup targets](#snapshot-backup-targets) - - [Local backup target](#local-backup-target) - - [S3 backup target](#s3-backup-target) - - [Using a custom CA certificate for S3](#using-a-custom-ca-certificate-for-s3) - - [IAM Support for storing snapshots in S3](#iam-support-for-storing-snapshots-in-s3) -- [Viewing available snapshots](#viewing-available-snapshots) -- [Safe timestamps](#safe-timestamps) -- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0) - # How Snapshots Work ### Snapshot Components diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md index 04485d9db2c..4b5f810056b 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher-launched-kubernetes-clusters-from-backup.md @@ -11,13 +11,6 @@ Rancher recommends enabling the [ability to set up recurring snapshots of etcd]( Clusters can also be restored to a prior Kubernetes version and cluster configuration. -This section covers the following topics: - -- [Viewing Available Snapshots](#viewing-available-snapshots) -- [Restoring a Cluster from a Snapshot](#restoring-a-cluster-from-a-snapshot) -- [Recovering etcd without a Snapshot](#recovering-etcd-without-a-snapshot) -- [Enabling snapshot features for clusters created before Rancher v2.2.0](#enabling-snapshot-features-for-clusters-created-before-rancher-v2-2-0) - ## Viewing Available Snapshots The list of all available snapshots for the cluster is available. diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md index bc7a8c13042..d4e18583ab7 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md @@ -11,20 +11,12 @@ Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm. -- [Architecture](#architecture) -- [Accessing Fleet in the Rancher UI](#accessing-fleet-in-the-rancher-ui) -- [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 +## Architecture For information about how Fleet works, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/architecture.md) -# Accessing Fleet in the Rancher UI +## Accessing Fleet in the Rancher UI 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/). @@ -45,31 +37,31 @@ Follow the steps below to access Continuous Delivery in the Rancher UI: 1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI. -# Windows Support +## Windows Support _Available as of v2.5.6_ For details on support for clusters with Windows nodes, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md) -# GitHub Repository +## GitHub Repository The Fleet Helm charts are available [here.](https://github.com/rancher/fleet/releases/latest) -# Using Fleet Behind a Proxy +## Using Fleet Behind a Proxy _Available as of v2.5.8_ For details on using Fleet behind a proxy, see [this page.](../../../explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md) -# Helm Chart Dependencies +## 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 +## Troubleshooting --- * **Known Issue:** Fleet becomes inoperable after a restore using the [backup-restore-operator](../backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place. @@ -88,6 +80,6 @@ By default, user-defined secrets are not backed up in Fleet. It is necessary to --- -# Documentation +## Documentation The Fleet documentation is at [https://fleet.rancher.io/.](https://fleet.rancher.io/) diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md index 63f2a4300db..8e8b60ed0fd 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/deploy-apps-across-clusters/multi-cluster-apps.md @@ -13,29 +13,14 @@ Any Helm charts from a global catalog can be used to deploy and manage multi-clu After creating a multi-cluster application, you can program a global DNS entry to make it easier to access the application. -- [Prerequisites](#prerequisites) -- [Launching a multi-cluster app](#launching-a-multi-cluster-app) -- [Multi-cluster app configuration options](#multi-cluster-app-configuration-options) - - [Targets](#targets) - - [Upgrades](#upgrades) - - [Roles](#roles) -- [Application configuration options](#application-configuration-options) - - [Using a questions.yml file](#using-a-questions-yml-file) - - [Key value pairs for native Helm charts](#key-value-pairs-for-native-helm-charts) - - [Members](#members) - - [Overriding application configuration options for specific projects](#overriding-application-configuration-options-for-specific-projects) -- [Upgrading multi-cluster app roles and projects](#upgrading-multi-cluster-app-roles-and-projects) -- [Multi-cluster application management](#multi-cluster-application-management) -- [Deleting a multi-cluster application](#deleting-a-multi-cluster-application) - -# Prerequisites +## Prerequisites To create a multi-cluster app in Rancher, you must have at least one of the following permissions: - A [project-member role](../../advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-roles) in the target cluster(s), which gives you the ability to create, read, update, and delete the workloads - A [cluster owner role](../../advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#cluster-roles) for the clusters(s) that include the target project(s) -# Launching a Multi-Cluster App +## Launching a Multi-Cluster App 1. From the **Global** view, choose **Apps** in the navigation bar. Click **Launch**. @@ -57,7 +42,7 @@ To create a multi-cluster app in Rancher, you must have at least one of the foll **Result**: Your application is deployed to your chosen namespace. You can view the application status from the project's: -# Multi-cluster App Configuration Options +## Multi-cluster App Configuration Options Rancher has divided the configuration option for the multi-cluster application into several sections. @@ -89,7 +74,7 @@ When launching the application, Rancher will confirm if you have these permissio > **Note:** There are some applications like _Grafana_ or _Datadog_ that require access to specific cluster-scoped resources. These applications will require the _Cluster_ role. If you find out later that the application requires cluster roles, the multi-cluster application can be upgraded to update the roles. -# Application Configuration Options +## Application Configuration Options For each Helm chart, there are a list of desired answers that must be entered in order to successfully deploy the chart. When entering answers, you must format them using the syntax rules found in [Using Helm: The format and limitations of –set](https://helm.sh/docs/intro/using_helm/#the-format-and-limitations-of---set), as Rancher passes them as `--set` flags to Helm. @@ -133,7 +118,7 @@ The ability to use the same configuration to deploy the same application across - **Answer**: Enter the answer that you want to be used instead. -# Upgrading Multi-Cluster App Roles and Projects +## Upgrading Multi-Cluster App Roles and Projects - **Changing Roles on an existing Multi-Cluster app** The creator and any users added with the access-type "owner" to a multi-cluster app, can upgrade its Roles. When adding a new Role, we check if the user has that exact role in all current target projects. These checks allow the same relaxations for global admins, cluster owners and project-owners as described in the installation section for the field `Roles`. @@ -143,7 +128,7 @@ The creator and any users added with the access-type "owner" to a multi-cluster 2. We do not do these membership checks when removing target projects. This is because the caller's permissions could have with respect to the target project, or the project could have been deleted and hence the caller wants to remove it from targets list. -# Multi-Cluster Application Management +## Multi-Cluster Application Management One of the benefits of using a multi-cluster application as opposed to multiple individual applications of the same type, is the ease of management. Multi-cluster applications can be cloned, upgraded or rolled back. @@ -155,7 +140,7 @@ One of the benefits of using a multi-cluster application as opposed to multiple * **Upgrade**: Upgrade your multi-cluster application to change some part of the configuration. When performing an upgrade for multi-cluster application, the [upgrade strategy](#upgrades) can be modified if you have the correct [access type](#members). * **Rollback**: Rollback your application to a specific version. If after an upgrade, there are issues for your multi-cluster application for one or more of your [targets](#targets), Rancher has stored up to 10 versions of the multi-cluster application. Rolling back a multi-cluster application reverts the application for **all** target clusters and projects, not just the targets(s) affected by the upgrade issue. -# Deleting a Multi-Cluster Application +## Deleting a Multi-Cluster Application 1. From the **Global** view, choose **Apps** in the navigation bar. diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md index af64ebac09d..eecc5dd54c0 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md @@ -7,7 +7,7 @@ aliases: There are three roles that can be assigned to nodes: `etcd`, `controlplane` and `worker`. -# Separating Worker Nodes from Nodes with Other Roles +## Separating Worker Nodes from Nodes with Other Roles When designing your cluster(s), you have two options: @@ -23,7 +23,7 @@ Therefore, each node should have one of the following role configurations: * Both `etcd` and `controlplane` * `worker` -# Recommended Number of Nodes with Each Role +## Recommended Number of Nodes with Each Role The cluster should have: @@ -71,6 +71,6 @@ You may have noticed that our [Kubernetes Install](../../../../pages-for-subhead * It maintains multiple instances of the master components by having multiple `controlplane` nodes. * No other workloads than Rancher itself should be created on this cluster. -# References +## References * [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components) diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md index f0648253622..e21d277b69b 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/google-compute-engine.md @@ -16,7 +16,7 @@ If you are using Calico, 1. Go to the cluster view in the Rancher UI, and click **⋮ > Edit.** 1. Click **Edit as YAML,** and enter the following configuration: - ``` + ```yaml rancher_kubernetes_engine_config: cloud_provider: name: gce @@ -38,7 +38,7 @@ If you are using Canal or Flannel, 1. Go to the cluster view in the Rancher UI, and click **⋮ > Edit.** 1. Click **Edit as YAML,** and enter the following configuration: - ``` + ```yaml rancher_kubernetes_engine_config: cloud_provider: name: gce diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md index 778d225382a..7bfe48abc99 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/create-a-digitalocean-cluster.md @@ -58,7 +58,7 @@ You can access your cluster after its state is updated to **Active.** - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Optional Next Steps +## Optional Next Steps After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster: diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md index f657c8ca476..8da3db7ae96 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md @@ -18,7 +18,7 @@ For details on configuring RKE Kubernetes clusters in Rancher, refer to the [clu - [Preparation in vSphere](#preparation-in-vsphere) - [Creating a vSphere Cluster](#creating-a-vsphere-cluster) -# Preparation in vSphere +## Preparation in vSphere This section describes the requirements for setting up vSphere so that Rancher can provision VMs and clusters. @@ -48,7 +48,7 @@ The free ESXi license does not support API access. The vSphere servers must have If you have a cluster with DRS enabled, setting up [VM-VM Affinity Rules](https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate ESXi hosts when they are assigned to different node pools. This practice ensures that the failure of a single physical machine does not affect the availability of those planes. -# Creating a vSphere Cluster +## Creating a vSphere Cluster The a vSphere cluster is created in Rancher depends on the Rancher version. @@ -102,7 +102,7 @@ You can access your cluster after its state is updated to **Active.** - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Optional Next Steps +## Optional Next Steps After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster: diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md index cb28379daec..d53b4330118 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md @@ -12,14 +12,8 @@ This page describes the requirements for the Rancher managed Kubernetes clusters > If Rancher is installed on a high-availability Kubernetes cluster, the Rancher server three-node cluster and downstream clusters have different requirements. For Rancher installation requirements, refer to the node requirements in the [installation section.](../../../pages-for-subheaders/installation-requirements.md) -Make sure the nodes for the Rancher server fulfill the following requirements: -- [Operating systems and container runtime requirements](#operating-systems-and-container-runtime-requirements) -- [Hardware Requirements](#hardware-requirements) -- [Networking Requirements](#networking-requirements) -- [Optional: Security Considerations](#optional-security-considerations) - -# Operating Systems and Container Runtime Requirements +## Operating Systems and Container Runtime Requirements Rancher should work with any modern Linux distribution and any modern Docker version. Linux is required for the etcd and controlplane nodes of all downstream clusters. Worker nodes may run Linux or [Windows Server.](#windows-nodes) @@ -35,12 +29,12 @@ For information on how to install Docker, refer to the official [Docker document Some distributions of Linux derived from RHEL, including Oracle Linux, may have default firewall rules that block communication with Helm. We recommend disabling firewalld. For Kubernetes 1.19, firewalld must be turned off. ->**Note:** In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity: -> -> ``` - systemctl disable nm-cloud-setup.service nm-cloud-setup.timer - reboot - ``` +**Note:** In RHEL 8.4, two extra services are included on the NetworkManager: `nm-cloud-setup.service` and `nm-cloud-setup.timer`. These services add a routing table that interferes with the CNI plugin's configuration. If these services are enabled, you must disable them using the command below, and then reboot the node to restore connectivity: + +``` +systemctl disable nm-cloud-setup.service nm-cloud-setup.timer +reboot +``` ### SUSE Linux Nodes @@ -101,7 +95,7 @@ Nodes with Windows Server must run Docker Enterprise Edition. Windows nodes can be used for worker nodes only. See [Configuring Custom Clusters for Windows](../../../pages-for-subheaders/use-windows-clusters.md) -# Hardware Requirements +## Hardware Requirements 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. @@ -111,7 +105,7 @@ For hardware recommendations for large Kubernetes clusters, refer to the officia For hardware recommendations for etcd clusters in production, refer to the official [etcd documentation.](https://etcd.io/docs/v3.4.0/op-guide/hardware/) -# Networking Requirements +## Networking Requirements For a production cluster, we recommend that you restrict traffic by opening only the ports defined in the port requirements below. @@ -123,7 +117,7 @@ For a breakdown of the port requirements for etcd nodes, controlplane nodes, and Details on which ports are used in each situation are found under [Downstream Cluster Port Requirements](../../../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md#downstream-kubernetes-cluster-nodes). -# Optional: Security Considerations +## Optional: Security Considerations If you want to provision a Kubernetes cluster that is compliant with the CIS (Center for Internet Security) Kubernetes Benchmark, we recommend to following our hardening guide to configure your nodes before installing Kubernetes. diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md index 4ed3da94ccb..a4e00b17b67 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/register-existing-clusters.md @@ -14,14 +14,8 @@ 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) -- [Prerequisites](#prerequisites) -- [Registering a Cluster](#registering-a-cluster) -- [Management Capabilities for Registered Clusters](#management-capabilities-for-registered-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 +## Prerequisites @@ -82,7 +76,7 @@ EKS clusters must have at least one managed node group to be imported into Ranch -# Registering a Cluster +## Registering a Cluster 1. From the **Clusters** page, click **Add Cluster**. 2. Under **Register an existing Kubernetes cluster**, click the type of Kubernetes cluster you want to register. @@ -150,7 +144,7 @@ resource "rancher2_cluster" "my-eks-to-import" { } ``` -# Management Capabilities for Registered Clusters +## Management Capabilities for Registered Clusters The control that Rancher has to manage a registered cluster depends on the type of cluster. @@ -242,7 +236,7 @@ The capabilities for registered EKS clusters are listed in the table on [this pa -# Configuring K3s Cluster Upgrades +## 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. @@ -255,7 +249,7 @@ In the K3s documentation, controlplane nodes are called server nodes. These node 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 +## 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. @@ -280,7 +274,7 @@ To prevent issues when upgrading, the [Kubernetes upgrade best practices](https: -# Annotating Registered Clusters +## 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. diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md index 73e4c883aa4..ead7ef97024 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/gke.md @@ -14,14 +14,8 @@ import TabItem from '@theme/TabItem'; -- [Prerequisites](#prerequisites) -- [Provisioning a GKE Cluster](#provisioning-a-gke-cluster) -- [Private Clusters](#private-clusters) -- [Configuration Reference](#configuration-reference) -- [Updating Kubernetes Version](#updating-kubernetes-version) -- [Syncing](#syncing) -# Prerequisites +## Prerequisites Some setup in Google Kubernetes Engine is required. @@ -48,7 +42,7 @@ To create a new project, refer to the Google cloud documentation [here.](https:/ To get the project ID of an existing project, refer to the Google cloud documentation [here.](https://cloud.google.com/resource-manager/docs/creating-managing-projects#identifying_projects) -# Provisioning a GKE Cluster +## Provisioning a GKE Cluster >**Note** >Deploying to GKE will incur charges. @@ -87,21 +81,21 @@ You can access your cluster after its state is updated to **Active.** - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Private Clusters +## Private Clusters Private GKE clusters are supported. Note: This advanced setup can require more steps during the cluster provisioning process. For details, see [this section.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/gke-cluster-configuration/gke-private-clusters.md) -# Configuration Reference +## Configuration Reference For details on configuring GKE clusters in Rancher, see [this page.](../../../../pages-for-subheaders/gke-cluster-configuration.md) -# Updating Kubernetes Version +## Updating Kubernetes Version The Kubernetes version of a cluster can be upgraded to any version available in the region or zone fo the GKE cluster. Upgrading the master Kubernetes version does not automatically upgrade worker nodes. Nodes can be upgraded independently. >**Note** >GKE has removed basic authentication in 1.19+. In order to upgrade a cluster to 1.19+, basic authentication must be disabled in the Google Cloud. Otherwise, an error will appear in Rancher when an upgrade to 1.19+ is attempted. You can follow the [Google documentation](https://cloud.google.com/kubernetes-engine/docs/how-to/api-server-authentication#disabling_authentication_with_a_static_password). After this, the Kubernetes version can be updated to 1.19+ via Rancher. -# Syncing +## Syncing The GKE provisioner can synchronize the state of a GKE cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../../../../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md) @@ -110,7 +104,7 @@ For information on configuring the refresh interval, see [this section.](../../. -# Prerequisites +## Prerequisites Some setup in Google Kubernetes Engine is required. @@ -131,7 +125,7 @@ The service account requires the following roles: >**Note** >Deploying to GKE will incur charges. -# Create the GKE Cluster +## Create the GKE Cluster Use Rancher to set up and configure your Kubernetes cluster. diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md index 05969b923b0..59318535175 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/huawei.md @@ -42,7 +42,7 @@ You can access your cluster after its state is updated to **Active.** - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# Huawei CCE Configuration +## Huawei CCE Configuration |Settings|Description| |---|---| @@ -61,7 +61,7 @@ You can access your cluster after its state is updated to **Active.** **Note:** If you are editing the cluster in the `cluster.yml` instead of the Rancher UI, note that cluster configuration directives must be nested under the `rancher_kubernetes_engine_config` directive in `cluster.yml`. For more information, refer to the section on [the config file structure.](cluster-provisioning/rke-clusters/options/#config-file-structure-in-rancher-v2-3-0) -# Node Configuration +## Node Configuration |Settings|Description| |---|---| diff --git a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md index e4f22b37d05..a32242944c0 100644 --- a/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md +++ b/versioned_docs/version-2.5/how-to-guides/new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md @@ -70,7 +70,7 @@ The secret has to be created in the same namespace where the workload gets deplo Below is an example `pod.yml` for a workload that uses an image from a private registry. In this example, the pod uses an image from Quay.io, and the .yml specifies the path to the image. The pod authenticates with the registry using credentials stored in a Kubernetes secret called `testquay`, which is specified in `spec.imagePullSecrets` in the `name` field: -``` +```yaml apiVersion: v1 kind: Pod metadata: diff --git a/versioned_docs/version-2.5/pages-for-subheaders/about-rke1-templates.md b/versioned_docs/version-2.5/pages-for-subheaders/about-rke1-templates.md index 2d4f471a6f8..48bbd44721b 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/about-rke1-templates.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/about-rke1-templates.md @@ -28,7 +28,7 @@ The core features of RKE templates allow DevOps and security teams to: - Control which users can create templates - Require users to create clusters from a template -# Configurable Settings +## Configurable Settings RKE templates can be created in the Rancher UI or defined in YAML format. They can define all the same parameters that can be specified when you use Rancher to provision custom nodes or nodes from an infrastructure provider: @@ -44,7 +44,7 @@ RKE templates can be created in the Rancher UI or defined in YAML format. They c The [add-on section](#add-ons) of an RKE template is especially powerful because it allows a wide range of customization options. -# Scope of RKE Templates +## Scope of RKE Templates RKE templates are supported for Rancher-provisioned clusters. The templates can be used to provision custom clusters or clusters that are launched by an infrastructure provider. @@ -55,7 +55,7 @@ RKE templates can be created from scratch to pre-define cluster configuration. T The settings of an existing cluster can be [saved as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) This creates a new template and binds the cluster settings to the template, so that the cluster can only be upgraded if the [template is updated](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#updating-a-template), and the cluster is upgraded to [use a newer version of the template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) The new template can also be used to create new clusters. -# Example Scenarios +## Example Scenarios When an organization has both basic and advanced Rancher users, administrators might want to give the advanced users more options for cluster creation, while restricting the options for basic users. These [example scenarios](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md) describe how an organization could use templates to standardize cluster creation. @@ -67,7 +67,7 @@ Some of the example scenarios include the following: - **Updating template settings:** If an organization's security and DevOps teams decide to embed best practices into the required settings for new clusters, those best practices could change over time. If the best practices change, [a template can be updated to a new revision](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#updating-templates-and-clusters-created-with-them) and clusters created from the template can [upgrade to the new version](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/manage-rke1-templates.md#upgrading-a-cluster-to-use-a-new-template-revision) of the template. - **Sharing ownership of a template:** When a template owner no longer wants to maintain a template, or wants to share ownership of the template, this scenario describes how [template ownership can be shared.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/example-use-cases.md#allowing-other-users-to-control-and-share-a-template) -# Template Management +## Template Management When you create an RKE template, it is available in the Rancher UI from the **Global** view under **Tools > RKE Templates.** When you create a template, you become the template owner, which gives you permission to revise and share the template. You can share the RKE templates with specific users or groups, and you can also make it public. @@ -90,7 +90,7 @@ The documents in this section explain the details of RKE template management: An [example YAML configuration file for a template](../reference-guides/rke1-template-example-yaml.md) is provided for reference. -# Applying Templates +## Applying Templates You can [create a cluster from a template](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#creating-a-cluster-from-an-rke-template) that you created, or from a template that has been [shared with you.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/access-or-share-templates.md) @@ -100,11 +100,11 @@ RKE templates can be created from scratch to pre-define cluster configuration. T You can [save the configuration of an existing cluster as an RKE template.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/apply-templates.md#converting-an-existing-cluster-to-use-an-rke-template) Then the cluster's settings can only be changed if the template is updated. -# Standardizing Hardware +## Standardizing Hardware RKE templates are designed to standardize Kubernetes and Rancher settings. If you want to standardize your infrastructure as well, you use RKE templates [in conjunction with other tools](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-rke1-templates/infrastructure.md). -# YAML Customization +## YAML Customization If you define an RKE template as a YAML file, you can modify this [example RKE template YAML](../reference-guides/rke1-template-example-yaml.md). The YAML in the RKE template uses the same customization that Rancher uses when creating an RKE cluster, but since the YAML is located within the context of a Rancher provisioned cluster, you will need to nest the RKE template customization under the `rancher_kubernetes_engine_config` directive in the YAML. diff --git a/versioned_docs/version-2.5/pages-for-subheaders/amazon-eks-permissions.md b/versioned_docs/version-2.5/pages-for-subheaders/amazon-eks-permissions.md index 60d6b4258fd..9d010cd2dc5 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/amazon-eks-permissions.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/amazon-eks-permissions.md @@ -8,19 +8,8 @@ aliases: --- Amazon EKS provides a managed control plane for your Kubernetes cluster. Amazon EKS runs the Kubernetes control plane instances across multiple Availability Zones to ensure high availability. Rancher provides an intuitive user interface for managing and deploying the Kubernetes clusters you run in Amazon EKS. With this guide, you will use Rancher to quickly and easily launch an Amazon EKS Kubernetes cluster in your AWS account. For more information on Amazon EKS, see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html). -- [Prerequisites in Amazon Web Services](#prerequisites-in-amazon-web-services) - - [Amazon VPC](#amazon-vpc) - - [IAM Policies](#iam-policies) -- [Create the EKS Cluster](#create-the-eks-cluster) -- [EKS Cluster Configuration Reference](#eks-cluster-configuration-reference) -- [Architecture](#architecture) -- [AWS Service Events](#aws-service-events) -- [Security and Compliance](#security-and-compliance) -- [Tutorial](#tutorial) -- [Minimum EKS Permissions](#minimum-eks-permissions) -- [Syncing](#syncing) -- [Troubleshooting](#troubleshooting) -# Prerequisites in Amazon Web Services + +## Prerequisites in Amazon Web Services >**Note** >Deploying to Amazon AWS will incur charges. For more information, refer to the [EKS pricing page](https://aws.amazon.com/eks/pricing/). @@ -46,7 +35,7 @@ Rancher needs access to your AWS account in order to provision and administer yo For more detailed information on IAM policies for EKS, refer to the official [documentation on Amazon EKS IAM Policies, Roles, and Permissions](https://docs.aws.amazon.com/eks/latest/userguide/IAM_policies.html). -# Create the EKS Cluster +## Create the EKS Cluster Use Rancher to set up and configure your Kubernetes cluster. @@ -73,11 +62,11 @@ You can access your cluster after its state is updated to **Active.** - `Default`, containing the `default` namespace - `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces -# EKS Cluster Configuration Reference +## EKS Cluster Configuration Reference For the full list of EKS cluster configuration options, see [this page.](../reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration.md) -# Architecture +## Architecture The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two Kubernetes clusters: one created by RKE and another created by EKS. @@ -85,31 +74,31 @@ The figure below illustrates the high-level architecture of Rancher 2.x. The fig ![Architecture](/img/rancher-architecture-rancher-api-server.svg) -# AWS Service Events +## AWS Service Events To find information on any AWS Service events, please see [this page](https://status.aws.amazon.com/). -# Security and Compliance +## Security and Compliance By default only the IAM user or role that created a cluster has access to it. Attempting to access the cluster with any other user or role without additional configuration will lead to an error. In Rancher, this means using a credential that maps to a user or role that was not used to create the cluster will cause an unauthorized error. For example, an EKSCtl cluster will not register in Rancher unless the credentials used to register the cluster match the role or user used by EKSCtl. Additional users and roles can be authorized to access a cluster by being added to the aws-auth configmap in the kube-system namespace. For a more in-depth explanation and detailed instructions, please see this [documentation](https://aws.amazon.com/premiumsupport/knowledge-center/amazon-eks-cluster-access/). For more information on security and compliance with your Amazon EKS Kubernetes cluster, please see this [documentation](https://docs.aws.amazon.com/eks/latest/userguide/shared-responsibilty.html). -# Tutorial +## Tutorial This [tutorial](https://aws.amazon.com/blogs/opensource/managing-eks-clusters-rancher/) on the AWS Open Source Blog will walk you through how to set up an EKS cluster with Rancher, deploy a publicly accessible app to test the cluster, and deploy a sample project to track real-time geospatial data using a combination of other open-source software such as Grafana and InfluxDB. -# Minimum EKS Permissions +## Minimum EKS Permissions See [this page](../reference-guides/amazon-eks-permissions/minimum-eks-permissions.md) for the minimum set of permissions necessary to use all functionality of the EKS driver in Rancher. -# Syncing +## Syncing The EKS provisioner can synchronize the state of an EKS cluster between Rancher and the provider. For an in-depth technical explanation of how this works, see [Syncing.](../reference-guides/cluster-configuration/rancher-server-configuration/sync-clusters.md) For information on configuring the refresh interval, refer to [this section.](../reference-guides/cluster-configuration/rancher-server-configuration/eks-cluster-configuration.md#configuring-the-refresh-interval) -# Troubleshooting +## Troubleshooting If your changes were overwritten, it could be due to the way the cluster data is synced with EKS. Changes shouldn't be made to the cluster from another source, such as in the EKS console, and in Rancher within a five-minute span. For information on how this works and how to configure the refresh interval, refer to [Syncing.](#syncing) diff --git a/versioned_docs/version-2.5/pages-for-subheaders/backup-restore-and-disaster-recovery.md b/versioned_docs/version-2.5/pages-for-subheaders/backup-restore-and-disaster-recovery.md index 971d98e8656..c234903f94d 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/backup-restore-and-disaster-recovery.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/backup-restore-and-disaster-recovery.md @@ -14,20 +14,7 @@ The backup-restore operator needs to be installed in the local cluster, and only > When restoring a backup into a new Rancher setup, the version of the new setup should be the same as the one where the backup is made. -- [Changes in Rancher v2.5](#changes-in-rancher-v2-5) - - [Backup and Restore for Rancher v2.5 installed with Docker](#backup-and-restore-for-rancher-v2-5-installed-with-docker) -- [How Backups and Restores Work](#how-backups-and-restores-work) -- [Installing the rancher-backup Operator](#installing-the-rancher-backup-operator) - - [Installing rancher-backup with the Rancher UI](#installing-rancher-backup-with-the-rancher-ui) - - [Installing rancher-backup with the Helm CLI](#installing-rancher-backup-with-the-helm-cli) - - [RBAC](#rbac) -- [Backing up Rancher](#backing-up-rancher) -- [Restoring Rancher](#restoring-rancher) -- [Migrating Rancher to a New Cluster](#migrating-rancher-to-a-new-cluster) -- [Default Storage Location Configuration](#default-storage-location-configuration) - - [Example values.yaml for the rancher-backup Helm Chart](#example-values-yaml-for-the-rancher-backup-helm-chart) - -# Changes in Rancher v2.5 +## Changes in Rancher v2.5 The new `rancher-backup` operator allows Rancher to be backed up and restored on any Kubernetes cluster. This application is a Helm chart, and it can be deployed through the Rancher **Apps & Marketplace** page, or by using the Helm CLI. @@ -41,7 +28,7 @@ In Rancher v2.5, it is now supported to install Rancher hosted Kubernetes cluste For Rancher installed with Docker, refer to the same steps used up till 2.5 for [backups](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-docker-installed-rancher.md) and [restores.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-docker-installed-rancher.md) -# How Backups and Restores Work +## How Backups and Restores Work The `rancher-backup` operator introduces three custom resources: Backups, Restores, and ResourceSets. The following cluster-scoped custom resource definitions are added to the cluster: @@ -59,7 +46,7 @@ When a Restore custom resource is created, the operator accesses the backup .tar The Backup and Restore custom resources can be created in the Rancher UI, or by using `kubectl apply`. -# Installing the rancher-backup Operator +## Installing the rancher-backup Operator 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.*) @@ -99,19 +86,19 @@ Only the rancher admins and the local cluster’s cluster-owner can: * Perform a backup or restore by creating a Backup CR and Restore CR respectively * List backups/restores performed so far -# Backing up Rancher +## Backing up Rancher A backup is performed by creating a Backup custom resource. For a tutorial, refer to [this page.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) -# Restoring Rancher +## Restoring Rancher A restore is performed by creating a Restore custom resource. For a tutorial, refer to [this page.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/restore-rancher.md) -# Migrating Rancher to a New Cluster +## Migrating Rancher to a New Cluster A migration is performed by following [these steps.](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/migrate-rancher-to-new-cluster.md) -# Default Storage Location Configuration +## Default Storage Location Configuration Configure a storage location where all backups are saved by default. You will have the option to override this with each backup, but will be limited to using an S3-compatible or Minio object store. diff --git a/versioned_docs/version-2.5/pages-for-subheaders/cis-scans.md b/versioned_docs/version-2.5/pages-for-subheaders/cis-scans.md index 02ddc4ba02c..4df6d184306 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/cis-scans.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/cis-scans.md @@ -14,16 +14,7 @@ Rancher can run a security scan to check whether Kubernetes is deployed accordin The `rancher-cis-benchmark` app leverages kube-bench, an open-source tool from Aqua Security, to check clusters for CIS Kubernetes Benchmark compliance. Also, to generate a cluster-wide report, the application utilizes Sonobuoy for report aggregation. -- [Changes in Rancher v2.5](#changes-in-rancher-v2-5) -- [About the CIS Benchmark](#about-the-cis-benchmark) -- [About the Generated Report](#about-the-generated-report) -- [Test Profiles](#test-profiles) -- [About Skipped and Not Applicable Tests](#about-skipped-and-not-applicable-tests) -- [Roles-based Access Control](#roles-based-access-control) -- [Configuration](#configuration) -- [How-to Guides](#how-to-guides) - -# Changes in Rancher v2.5 +## Changes in Rancher v2.5 We now support running CIS scans on any Kubernetes cluster, including hosted Kubernetes providers such as EKS, AKS, and GKE. Previously it was only supported to run CIS scans on RKE Kubernetes clusters. @@ -89,7 +80,7 @@ The `rancher-cis-benchmark` supports the CIS 1.5 Benchmark version. > **Note:** CIS v1 cannot run on a cluster when CIS v2 is deployed. In other words, after `rancher-cis-benchmark` is installed, you can't run scans by going to the Cluster Manager view in the Rancher UI and clicking Tools > CIS Scans. -# About the CIS Benchmark +## About the CIS Benchmark The Center for Internet Security is a 501(c\)(3) non-profit organization, formed in October 2000, with a mission to "identify, develop, validate, promote, and sustain best practice solutions for cyber defense and build and lead communities to enable an environment of trust in cyberspace". The organization is headquartered in East Greenbush, New York, with members including large corporations, government agencies, and academic institutions. @@ -98,7 +89,7 @@ CIS Benchmarks are best practices for the secure configuration of a target syste The official Benchmark documents are available through the CIS website. The sign-up form to access the documents is here. -# About the Generated Report +## About the Generated Report Each scan generates a report can be viewed in the Rancher UI and can be downloaded in CSV format. @@ -129,7 +120,7 @@ The report contains the following information: Refer to the [table in the cluster hardening guide](./rancher-security.md) for information on which versions of Kubernetes, the Benchmark, Rancher, and our cluster hardening guide correspond to each other. Also refer to the hardening guide for configuration files of CIS-compliant clusters and information on remediating failed tests. -# Test Profiles +## Test Profiles The following profiles are available: @@ -172,7 +163,7 @@ The EKS and GKE cluster scan profiles are based on CIS Benchmark versions that a In order to pass the "Hardened" profile, you will need to follow the steps on the [hardening guide](./rancher-security.md#rancher-hardening-guide) and use the `cluster.yml` defined in the hardening guide to provision a hardened cluster. -# About Skipped and Not Applicable Tests +## About Skipped and Not Applicable Tests For a list of skipped and not applicable tests, refer to [this page](../explanations/integrations-in-rancher/cis-scans/skipped-and-not-applicable-tests.md). @@ -180,14 +171,14 @@ For now, only user-defined skipped tests are marked as skipped in the generated Any skipped tests that are defined as being skipped by one of the default profiles are marked as not applicable. -# Roles-based Access Control +## Roles-based Access Control For information about permissions, refer to [this page](../explanations/integrations-in-rancher/cis-scans/rbac-for-cis-scans.md). -# Configuration +## Configuration For more information about configuring the custom resources for the scans, profiles, and benchmark versions, refer to [this page](../explanations/integrations-in-rancher/cis-scans/configuration-reference.md). -# How-to Guides +## How-to Guides Please refer [here](../pages-for-subheaders/cis-scan-guides.md) for how-to guides on CIS scans. \ No newline at end of file diff --git a/versioned_docs/version-2.5/pages-for-subheaders/configuration-options.md b/versioned_docs/version-2.5/pages-for-subheaders/configuration-options.md index 6814b2a16f8..9e26e643105 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/configuration-options.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/configuration-options.md @@ -6,14 +6,6 @@ aliases: - /rancher/v2.x/en/istio/v2.5/configuration-reference/ --- -- [Egress Support](#egress-support) -- [Enabling Automatic Sidecar Injection](#enabling-automatic-sidecar-injection) -- [Overlay File](#overlay-file) -- [Selectors and Scrape Configs](#selectors-and-scrape-configs) -- [Enable Istio with Pod Security Policies](#enable-istio-with-pod-security-policies) -- [Additional Steps for Installing Istio on an RKE2 Cluster](#additional-steps-for-installing-istio-on-an-rke2-cluster) -- [Additional Steps for Project Network Isolation](#additional-steps-for-project-network-isolation) - ### Egress Support By default the Egress gateway is disabled, but can be enabled on install or upgrade through the values.yaml or via the [overlay file](#overlay-file). diff --git a/versioned_docs/version-2.5/pages-for-subheaders/configure-shibboleth-saml.md b/versioned_docs/version-2.5/pages-for-subheaders/configure-shibboleth-saml.md index ff837c911a3..f7bdf272f9c 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/configure-shibboleth-saml.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/configure-shibboleth-saml.md @@ -13,16 +13,6 @@ If you also configure OpenLDAP as the back end to Shibboleth, it will return a S > The instructions in this section assume that you understand how Rancher, Shibboleth, and OpenLDAP work together. For a more detailed explanation of how it works, refer to [this page.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-authentication/configure-shibboleth-saml/about-group-permissions.md) -This section covers the following topics: - -- [Setting up Shibboleth in Rancher](#setting-up-shibboleth-in-rancher) - - [Shibboleth Prerequisites](#shibboleth-prerequisites) - - [Configure Shibboleth in Rancher](#configure-shibboleth-in-rancher) - - [SAML Provider Caveats](#saml-provider-caveats) -- [Setting up OpenLDAP in Rancher](#setting-up-openldap-in-rancher) - - [OpenLDAP Prerequisites](#openldap-prerequisites) - - [Configure OpenLDAP in Rancher](#configure-openldap-in-rancher) - - [Troubleshooting](#troubleshooting) # Setting up Shibboleth in Rancher diff --git a/versioned_docs/version-2.5/pages-for-subheaders/fleet-gitops-at-scale.md b/versioned_docs/version-2.5/pages-for-subheaders/fleet-gitops-at-scale.md index a88bf411ea1..bbf71000cf1 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/fleet-gitops-at-scale.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/fleet-gitops-at-scale.md @@ -8,20 +8,12 @@ Fleet is GitOps at scale. Fleet is designed to manage up to a million clusters. Fleet is a separate project from Rancher, and can be installed on any Kubernetes cluster with Helm. -- [Architecture](../explanations/integrations-in-rancher/fleet-gitops-at-scale/architecture.md) -- [Accessing Fleet in the Rancher UI](#accessing-fleet-in-the-rancher-ui) -- [Windows Support](../explanations/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md) -- [GitHub Repository](#github-repository) -- [Use Fleet Behind a Proxy](../explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md) -- [Helm Chart Dependencies](#helm-chart-dependencies) -- [Troubleshooting](#troubleshooting) -- [Documentation](#documentation) -# Architecture +## Architecture For information about how Fleet works, see [this page](../explanations/integrations-in-rancher/fleet-gitops-at-scale/architecture.md). -# Accessing Fleet in the Rancher UI +## Accessing Fleet in the Rancher UI 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/). @@ -45,29 +37,29 @@ Follow the steps below to access Continuous Delivery in the Rancher UI: 1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI. -# Windows Support +## Windows Support _Available as of v2.5.6_ For details on support for clusters with Windows nodes, see [this page](../explanations/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md). -# GitHub Repository +## GitHub Repository The Fleet Helm charts are available [here](https://github.com/rancher/fleet/releases/tag/v0.3.10). -# Using Fleet Behind a Proxy +## Using Fleet Behind a Proxy _Available as of v2.5.8_ For details on using Fleet behind a proxy, see [this page](../explanations/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md). -# Helm Chart Dependencies +## 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 +## Troubleshooting - **Known Issue**: Fleet becomes inoperable after a restore using the [backup-restore-operator](../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place. @@ -85,7 +77,7 @@ The Helm chart in the git repository must include its dependencies in the charts - **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 +## Documentation The Fleet documentation is at https://fleet.rancher.io/. diff --git a/versioned_docs/version-2.5/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md b/versioned_docs/version-2.5/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md index 62c391961ed..4ba65074bd5 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/install-upgrade-on-a-kubernetes-cluster.md @@ -16,9 +16,6 @@ import TabItem from '@theme/TabItem'; In this section, you'll learn how to deploy Rancher on a Kubernetes cluster using the Helm CLI. -- [Prerequisites](#prerequisites) -- [Install the Rancher Helm Chart](#install-the-rancher-helm-chart) - # Prerequisites - [Kubernetes Cluster](#kubernetes-cluster) diff --git a/versioned_docs/version-2.5/pages-for-subheaders/istio.md b/versioned_docs/version-2.5/pages-for-subheaders/istio.md index 146db64d148..322f20063f1 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/istio.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/istio.md @@ -23,17 +23,8 @@ After [setting up istio](istio-setup-guide.md) you can leverage Istio's control Istio needs to be set up by a `cluster-admin` before it can be used in a project. -- [What's New in Rancher v2.5](#what-s-new-in-rancher-v2-5) -- [Tools Bundled with Istio](#tools-bundled-with-istio) -- [Prerequisites](#prerequisites) -- [Setup Guide](#setup-guide) -- [Remove Istio](#remove-istio) -- [Migrate from Previous Istio Version](#migrate-from-previous-istio-version) -- [Accessing Visualizations](#accessing-visualizations) -- [Architecture](#architecture) -- [Additional steps for installing Istio on an RKE2 cluster](#additional-steps-for-installing-istio-on-an-rke2-cluster) -# What's New in Rancher v2.5 +## What's New in Rancher v2.5 The overall architecture of Istio has been simplified. A single component, Istiod, has been created by combining Pilot, Citadel, Galley and the sidecar injector. Node Agent functionality has also been merged into istio-agent. @@ -45,7 +36,7 @@ Istio has migrated away from Helm as a way to install Istio and now provides ins This Helm chart will be available via the Apps and Marketplace in the UI. A user that has access to the Rancher Chart's catalog will need to set up Istio before it can be used in the project. -# Tools Bundled with Istio +## Tools Bundled with Istio Our [Istio](https://istio.io/) installer wraps the istioctl binary commands in a handy Helm chart, including an overlay file option to allow complex customization. @@ -65,21 +56,21 @@ Our Istio installer includes a quick-start, all-in-one installation of [Jaeger,] Note that this is not a production-qualified deployment of Jaeger. This deployment uses an in-memory storage component, while a persistent storage component is recommended for production. For more information on which deployment strategy you may need, refer to the [Jaeger documentation.](https://www.jaegertracing.io/docs/latest/operator/#production-strategy) -# Prerequisites +## Prerequisites Before enabling Istio, we recommend that you confirm that your Rancher worker nodes have enough [CPU and memory](../explanations/integrations-in-rancher/istio/cpu-and-memory-allocations.md) to run all of the components of Istio. If you are installing Istio on RKE2 cluster, some additional steps are required. For details, see [this section.](#additional-steps-for-installing-istio-on-an-rke2-cluster) -# Setup Guide +## Setup Guide Refer to the [setup guide](istio-setup-guide.md) for instructions on how to set up Istio and use it in a project. -# Remove Istio +## Remove Istio To remove Istio components from a cluster, namespace, or workload, refer to the section on [uninstalling Istio.](../explanations/integrations-in-rancher/istio/disable-istio.md) -# Migrate From Previous Istio Version +## Migrate From Previous Istio Version There is no upgrade path for Istio versions less than 1.7.x. To successfully install Istio in the **Cluster Explorer**, you will need to disable your existing Istio in the **Cluster Manager**. @@ -87,7 +78,7 @@ If you have a significant amount of additional Istio CRDs you might consider man Another option is to manually uninstall istio resources one at a time, but leave the resources that are supported in both versions of Istio and that will not be installed by the newest version. This method is more likely to result in issues installing the new version, but could be a good option depending on your situation. -# Accessing Visualizations +## Accessing Visualizations > By default, only cluster-admins have access to Kiali. For instructions on how to allow admin, edit or views roles to access them, see [this section.](../explanations/integrations-in-rancher/istio/rbac-for-istio.md) @@ -101,7 +92,7 @@ By default, all namespace will picked up by prometheus and make data available f Your access to the visualizations depend on your role. Grafana and Prometheus are only available for `cluster-admin` roles. The Kiali UI is available only to `cluster-admin` by default, but `cluster-admin` can allow other roles to access them by editing the Istio values.yaml. -# Architecture +## Architecture Istio installs a service mesh that uses [Envoy](https://www.envoyproxy.io/learn/service-mesh) sidecar proxies to intercept traffic to each workload. These sidecars intercept and manage service-to-service communication, allowing fine-grained observation and control over traffic within the cluster. @@ -123,6 +114,6 @@ By default, each Rancher-provisioned cluster has one NGINX ingress controller al By default the Egress gateway is disabled, but can be enabled on install or upgrade through the values.yaml or via the [overlay file](./configuration-options.md#overlay-file). -# Additional Steps for Installing Istio on an RKE2 Cluster +## Additional Steps for Installing Istio on an RKE2 Cluster To install Istio on an RKE2 cluster, follow the steps in [this section.](../explanations/integrations-in-rancher/istio/configuration-options/install-istio-on-rke2-cluster.md) diff --git a/versioned_docs/version-2.5/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md b/versioned_docs/version-2.5/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md index 4b83df5ba60..7a0776224b9 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md @@ -15,19 +15,6 @@ This section assumes a basic familiarity with Docker and Kubernetes. For a brief For a conceptual overview of how the Rancher server provisions clusters and what tools it uses to provision them, refer to the [architecture](rancher-manager-architecture.md) page. -This section covers the following topics: - - - -- [Cluster Management Capabilities by Cluster Type](#cluster-management-capabilities-by-cluster-type) -- [Setting up clusters in a hosted Kubernetes provider](#setting-up-clusters-in-a-hosted-kubernetes-provider) -- [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) - - - ### Cluster Management Capabilities by Cluster Type The following table summarizes the options and settings available for each cluster type: @@ -36,7 +23,7 @@ import ClusterCapabilitiesTable from '../shared-files/_cluster-capabilities-tabl -# Setting up Clusters in a Hosted Kubernetes Provider +## Setting up Clusters in a Hosted Kubernetes Provider In this scenario, Rancher does not provision Kubernetes because it is installed by providers such as Google Kubernetes Engine (GKE), Amazon Elastic Container Service for Kubernetes, or Azure Kubernetes Service. @@ -44,7 +31,7 @@ If you use a Kubernetes provider such as Google GKE, Rancher integrates with its For more information, refer to the section on [hosted Kubernetes clusters.](set-up-clusters-from-hosted-kubernetes-providers.md) -# Launching Kubernetes with Rancher +## Launching Kubernetes with Rancher Rancher uses the [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) as a library when provisioning Kubernetes on your own nodes. RKE is Rancher’s own lightweight Kubernetes installer. @@ -76,7 +63,7 @@ You can bring any nodes you want to Rancher and use them to create a cluster. These nodes include on-prem bare metal servers, cloud-hosted virtual machines, or on-prem virtual machines. -# Registering Existing Clusters +## Registering Existing Clusters The cluster registration feature replaces the feature to import clusters. diff --git a/versioned_docs/version-2.5/pages-for-subheaders/logging.md b/versioned_docs/version-2.5/pages-for-subheaders/logging.md index df9d0199d72..03fd61e1b69 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/logging.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/logging.md @@ -19,22 +19,8 @@ The [Banzai Cloud Logging operator](https://banzaicloud.com/docs/one-eye/logging For an overview of the changes in v2.5, see [this section.](../explanations/integrations-in-rancher/logging/logging-architecture.md#changes-in-rancher-v25) For information about migrating from Logging V1, see [this page.](../explanations/integrations-in-rancher/logging/migrate-to-rancher-v2.5+-logging.md) -- [Enabling Logging](#enabling-logging) -- [Uninstall Logging](#uninstall-logging) -- [Architecture](#architecture) -- [Role-based Access Control](#role-based-access-control) -- [Configuring the Logging Custom Resources](#configuring-the-logging-custom-resources) - - [Flows and ClusterFlows](#flows-and-clusterflows) - - [Outputs and ClusterOutputs](#outputs-and-clusteroutputs) -- [Configuring the Logging Helm Chart](#configuring-the-logging-helm-chart) - - [Windows Support](#windows-support) - - [Working with a Custom Docker Root Directory](#working-with-a-custom-docker-root-directory) - - [Working with Taints and Tolerations](#working-with-taints-and-tolerations) - - [Logging V2 with SELinux](#logging-v2-with-selinux) - - [Additional Logging Sources](#additional-logging-sources) -- [Troubleshooting](#troubleshooting) -# Enabling Logging +## Enabling Logging You can enable the logging for a Rancher managed cluster by going to the Apps page and installing the logging app. @@ -45,7 +31,7 @@ You can enable the logging for a Rancher managed cluster by going to the Apps pa **Result:** The logging app is deployed in the `cattle-logging-system` namespace. -# Uninstall Logging +## Uninstall Logging 1. From the **Cluster Explorer**, click **Apps & Marketplace**. 1. Click **Installed Apps**. @@ -55,17 +41,17 @@ You can enable the logging for a Rancher managed cluster by going to the Apps pa **Result** `rancher-logging` is uninstalled. -# Architecture +## Architecture For more information about how the logging application works, see [this section.](../explanations/integrations-in-rancher/logging/logging-architecture.md) -# Role-based Access Control +## Role-based Access Control Rancher logging has two roles, `logging-admin` and `logging-view`. For more information on how and when to use these roles, see [this page.](../explanations/integrations-in-rancher/logging/rbac-for-logging.md) -# Configuring Logging Custom Resources +## Configuring Logging Custom Resources To manage `Flows,` `ClusterFlows`, `Outputs`, and `ClusterOutputs`, go to the **Cluster Explorer** in the Rancher UI. In the upper left corner, click **Cluster Explorer > Logging**. @@ -77,7 +63,7 @@ For help with configuring `Flows` and `ClusterFlows`, see [this page.](../explan For help with configuring `Outputs` and `ClusterOutputs`, see [this page.](../explanations/integrations-in-rancher/logging/custom-resource-configuration/outputs-and-clusteroutputs.md) -# Configuring the Logging Helm Chart +## Configuring the Logging Helm Chart For a list of options that can be configured when the logging application is installed or upgraded, see [this page.](../explanations/integrations-in-rancher/logging/logging-helm-chart-options.md) @@ -124,7 +110,7 @@ For information on enabling the logging application for SELinux-enabled nodes, s By default, Rancher collects logs for control plane components and node components for all cluster types. In some cases additional logs can be collected. For details, see [this section.](../explanations/integrations-in-rancher/logging/logging-helm-chart-options.md#additional-logging-sources) -# Troubleshooting +## Troubleshooting ### The `cattle-logging` Namespace Being Recreated diff --git a/versioned_docs/version-2.5/pages-for-subheaders/monitoring-and-alerting.md b/versioned_docs/version-2.5/pages-for-subheaders/monitoring-and-alerting.md index 10747e33cf8..aaf0e72f7d7 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/monitoring-and-alerting.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/monitoring-and-alerting.md @@ -10,13 +10,6 @@ aliases: Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster. -- [Features](#features) -- [How Monitoring Works](#how-monitoring-works) -- [Default Components and Deployments](#default-components-and-deployments) -- [Role-based Access Control](#role-based-access-control) -- [Guides](#guides) -- [Windows Cluster Support](#windows-cluster-support) -- [Known Issues](#known-issues) ### Features diff --git a/versioned_docs/version-2.5/pages-for-subheaders/pipelines.md b/versioned_docs/version-2.5/pages-for-subheaders/pipelines.md index 4ebd22e8b15..a8831ef5670 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/pipelines.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/pipelines.md @@ -27,19 +27,6 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins >**Note:** Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses. -This section covers the following topics: - -- [Concepts](#concepts) -- [How Pipelines Work](#how-pipelines-work) -- [Roles-based Access Control for Pipelines](#roles-based-access-control-for-pipelines) -- [Setting up Pipelines](#setting-up-pipelines) - - [Configure version control providers](#1-configure-version-control-providers) - - [Configure repositories](#2-configure-repositories) - - [Configure the pipeline](#3-configure-the-pipeline) -- [Pipeline Configuration Reference](#pipeline-configuration-reference) -- [Running your Pipelines](#running-your-pipelines) -- [Triggering a Pipeline](#triggering-a-pipeline) - - [Modifying the Event Triggers for the Repository](#modifying-the-event-triggers-for-the-repository) # Concepts diff --git a/versioned_docs/version-2.5/pages-for-subheaders/rancher-security.md b/versioned_docs/version-2.5/pages-for-subheaders/rancher-security.md index 9f727040e1f..ba2ce241353 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/rancher-security.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/rancher-security.md @@ -24,16 +24,7 @@ aliases: Security is at the heart of all Rancher features. From integrating with all the popular authentication tools and services, to an enterprise grade [RBAC capability,](manage-role-based-access-control-rbac.md) Rancher makes your Kubernetes clusters even more secure. -On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters: - -- [Running a CIS security scan on a Kubernetes cluster](#running-a-cis-security-scan-on-a-kubernetes-cluster) -- [SELinux RPM](#selinux-rpm) -- [Guide to hardening Rancher installations](#rancher-hardening-guide) -- [The CIS Benchmark and self-assessment](#the-cis-benchmark-and-self-assessment) -- [Third-party penetration test reports](#third-party-penetration-test-reports) -- [Rancher Security Advisories and CVEs](#rancher-security-advisories-and-cves) -- [Kubernetes Security Best Practices](#kubernetes-security-best-practices) - +On this page, we provide security related documentation along with resources to help you secure your Rancher installation and your downstream Kubernetes clusters. ### Running a CIS Security Scan on a Kubernetes Cluster Rancher leverages [kube-bench](https://github.com/aquasecurity/kube-bench) to run a security scan to check whether Kubernetes is deployed according to security best practices as defined in the [CIS](https://www.cisecurity.org/cis-benchmarks/) (Center for Internet Security) Kubernetes Benchmark. diff --git a/versioned_docs/version-2.5/pages-for-subheaders/rancher-v2.5-hardening-guides.md b/versioned_docs/version-2.5/pages-for-subheaders/rancher-v2.5-hardening-guides.md index dc4466fc6be..42786d17a3a 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/rancher-v2.5-hardening-guides.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/rancher-v2.5-hardening-guides.md @@ -6,14 +6,7 @@ weight: 1 Rancher v2.5 introduced the capability to deploy Rancher on any Kubernetes cluster. For that reason, we now provide separate security hardening guides for Rancher deployments on each of Rancher's Kubernetes distributions. -- [Rancher Kubernetes Distributions](#rancher-kubernetes-distributions) -- [Hardening Guides and Benchmark Versions](#hardening-guides-and-benchmark-versions) - - [RKE Guides](#rke-guides) - - [RKE2 Guides](#rke2-guides) - - [K3s Guides](#k3s) -- [Rancher with SELinux](#rancher-with-selinux) - -# Rancher Kubernetes Distributions +## Rancher Kubernetes Distributions Rancher has the following Kubernetes distributions: @@ -23,7 +16,7 @@ Rancher has the following Kubernetes distributions: To harden a Kubernetes cluster outside of Rancher's distributions, refer to your Kubernetes provider docs. -# Hardening Guides and Benchmark Versions +## Hardening Guides and Benchmark Versions These guides have been tested along with the Rancher v2.5 release. Each self-assessment guide is accompanied with a hardening guide and tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can choose to use the existing guides until a newer version is added. @@ -48,7 +41,7 @@ Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening G Kubernetes v1.17, v1.18, & v1.19 | CIS v1.5 | [Link](https://rancher.com/docs/k3s/latest/en/security/self_assessment/) | [Link](https://rancher.com/docs/k3s/latest/en/security/hardening_guide/) -# Rancher with SELinux +## Rancher with SELinux _Available as of v2.5.8_ diff --git a/versioned_docs/version-2.5/pages-for-subheaders/use-existing-nodes.md b/versioned_docs/version-2.5/pages-for-subheaders/use-existing-nodes.md index 8542a0f0a94..c653e041919 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/use-existing-nodes.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/use-existing-nodes.md @@ -21,13 +21,6 @@ This section describes how to set up a custom cluster. > >See [Configuring Custom Clusters for Windows](use-windows-clusters.md) before you start. - - -- [1. Provision a Linux Host](#1-provision-a-linux-host) -- [2. Create the Custom Cluster](#2-create-the-custom-cluster) -- [3. Amazon Only: Tag Resources](#3-amazon-only-tag-resources) - - ### 1. Provision a Linux Host diff --git a/versioned_docs/version-2.5/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md b/versioned_docs/version-2.5/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md index 99716f85537..57f11eef5c6 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/use-new-nodes-in-an-infra-provider.md @@ -12,19 +12,6 @@ One benefit of installing Kubernetes on node pools hosted by an infrastructure p The available cloud providers to create a node template are decided based on active [node drivers](use-new-nodes-in-an-infra-provider.md#node-drivers). -This section covers the following topics: - -- [Node templates](#node-templates) - - [Node labels](#node-labels) - - [Node taints](#node-taints) - - [Administrator control of node templates](#administrator-control-of-node-templates) -- [Node pools](#node-pools) - - [Node pool taints](#node-pool-taints) - - [About node auto-replace](#about-node-auto-replace) - - [Enabling node auto-replace](#enabling-node-auto-replace) - - [Disabling node auto-replace](#disabling-node-auto-replace) -- [Cloud credentials](#cloud-credentials) -- [Node drivers](#node-drivers) # Node Templates diff --git a/versioned_docs/version-2.5/pages-for-subheaders/use-windows-clusters.md b/versioned_docs/version-2.5/pages-for-subheaders/use-windows-clusters.md index 8c1686e8ea0..d0292c27d5a 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/use-windows-clusters.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/use-windows-clusters.md @@ -23,14 +23,6 @@ For the full list of requirements, see [this section.](#requirements-for-windows For a summary of Kubernetes features supported in Windows, see the Kubernetes documentation on [supported functionality and limitations for using Kubernetes with Windows](https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#supported-functionality-and-limitations) or the [guide for scheduling Windows containers in Kubernetes](https://kubernetes.io/docs/setup/production-environment/windows/user-guide-windows-containers/). -This guide covers the following topics: - - - -- [Requirements](#requirements-for-windows-clusters) -- [Tutorial: How to Create a Cluster with Windows Support](#tutorial-how-to-create-a-cluster-with-windows-support) -- [Configuration for Storage Classes in Azure](#configuration-for-storage-classes-in-azure) - # Requirements for Windows Clusters @@ -156,13 +148,6 @@ When you provision a cluster with Rancher on existing nodes, you will add nodes To set up a cluster with support for Windows nodes and containers, you will need to complete the tasks below. - - -1. [Provision Hosts](#1-provision-hosts) -1. [Create the Cluster on Existing Nodes](#2-create-the-cluster-on-existing-nodes) -1. [Add Nodes to the Cluster](#3-add-nodes-to-the-cluster) -1. [Optional: Configuration for Azure Files](#4-optional-configuration-for-azure-files) - # 1. Provision Hosts diff --git a/versioned_docs/version-2.5/pages-for-subheaders/vsphere.md b/versioned_docs/version-2.5/pages-for-subheaders/vsphere.md index a0e9c073fb2..6ab183c78ee 100644 --- a/versioned_docs/version-2.5/pages-for-subheaders/vsphere.md +++ b/versioned_docs/version-2.5/pages-for-subheaders/vsphere.md @@ -47,15 +47,15 @@ In this YouTube video, we demonstrate how to set up a node template with the new -# Creating a vSphere Cluster +## Creating a vSphere Cluster In [this section,](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/vsphere/provision-kubernetes-clusters-in-vsphere.md) you'll learn how to use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in vSphere. -# Provisioning Storage +## Provisioning Storage For an example of how to provision storage in vSphere using Rancher, refer to [this section.](../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/provisioning-storage-examples/vsphere-storage.md) In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](vsphere-cloud-provider.md) -# Enabling the vSphere Cloud Provider +## Enabling the vSphere Cloud Provider When a cloud provider is set up in Rancher, the Rancher server can automatically provision new infrastructure for the cluster, including new nodes or persistent storage devices. diff --git a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/backup-configuration.md b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/backup-configuration.md index 006df3337d4..884d460d4ed 100644 --- a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/backup-configuration.md +++ b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/backup-configuration.md @@ -11,18 +11,8 @@ The Backup Create page lets you configure a schedule, enable encryption and spec ![](/img/backup_restore/backup/backup.png) -- [Schedule](#schedule) -- [Encryption](#encryption) -- [Storage Location](#storage-location) - - [S3](#s3) - - [Example S3 Storage Configuration](#example-s3-storage-configuration) - - [Example MinIO Configuration](#example-minio-configuration) - - [Example credentialSecret](#example-credentialsecret) - - [IAM Permissions for EC2 Nodes to Access S3](#iam-permissions-for-ec2-nodes-to-access-s3) -- [Examples](#examples) - -# Schedule +## Schedule Select the first option to perform a one-time backup, or select the second option to schedule recurring backups. Selecting **Recurring Backups** lets you configure following two fields: @@ -38,7 +28,7 @@ Select the first option to perform a one-time backup, or select the second optio | `schedule` | Provide the cron string for scheduling recurring backups. | | `retentionCount` | Provide the number of backup files to be retained. | -# Encryption +## Encryption The rancher-backup gathers resources by making calls to the kube-apiserver. Objects returned by apiserver are decrypted, so even if [encryption At rest](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) is enabled, even the encrypted objects gathered by the backup will be in plaintext. @@ -74,7 +64,7 @@ In the example command above, the name `encryptionconfig` can be changed to anyt | ---------------- | ---------------- | | `encryptionConfigSecretName` | Provide the name of the Secret from `cattle-resources-system` namespace, that contains the encryption config file. | -# Storage Location +## Storage Location ![](/img/backup_restore/backup/storageLocation.png) @@ -181,6 +171,6 @@ To allow a node to access S3, follow the instructions in the [AWS documentation] After the role is created, and you have attached the corresponding instance profile to your EC2 instance(s), the `credentialSecretName` directive can be left empty in the Backup custom resource. -# Examples +## Examples For example Backup custom resources, refer to [this page.](examples.md#backup) diff --git a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/examples.md b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/examples.md index ef3370c454a..ca8c133c549 100644 --- a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/examples.md +++ b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/examples.md @@ -12,25 +12,7 @@ The default backup storage location is configured when the `rancher-backup` oper Encrypted backups can only be restored if the Restore custom resource uses the same encryption configuration secret that was used to create the backup. -- [Backup](#backup) - - [Backup in the default location with encryption](#backup-in-the-default-location-with-encryption) - - [Recurring backup in the default location](#recurring-backup-in-the-default-location) - - [Encrypted recurring backup in the default location](#encrypted-recurring-backup-in-the-default-location) - - [Encrypted backup in Minio](#encrypted-backup-in-minio) - - [Backup in S3 using AWS credential secret](#backup-in-s3-using-aws-credential-secret) - - [Recurring backup in S3 using AWS credential secret](#recurring-backup-in-s3-using-aws-credential-secret) - - [Backup from EC2 nodes with IAM permission to access S3](#backup-from-ec2-nodes-with-iam-permission-to-access-s3) -- [Restore](#restore) - - [Restore using the default backup file location](#restore-using-the-default-backup-file-location) - - [Restore for Rancher migration](#restore-for-rancher-migration) - - [Restore from encrypted backup](#restore-from-encrypted-backup) - - [Restore an encrypted backup from Minio](#restore-an-encrypted-backup-from-minio) - - [Restore from backup using an AWS credential secret to access S3](#restore-from-backup-using-an-aws-credential-secret-to-access-s3) - - [Restore from EC2 nodes with IAM permissions to access S3](#restore-from-ec2-nodes-with-iam-permissions-to-access-s3) -- [Example Credential Secret for Storing Backups in S3](#example-credential-secret-for-storing-backups-in-s3) -- [Example EncryptionConfiguration](#example-encryptionconfiguration) - -# Backup +## Backup This section contains example Backup custom resources. @@ -154,7 +136,7 @@ spec: encryptionConfigSecretName: encryptionconfig ``` -# Restore +## Restore This section contains example Restore custom resources. diff --git a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/restore-configuration.md b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/restore-configuration.md index d39d508c591..c769ac77c4d 100644 --- a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/restore-configuration.md +++ b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/restore-configuration.md @@ -11,15 +11,8 @@ The Restore Create page lets you provide details of the backup to restore from ![](/img/backup_restore/restore/restore.png) -- [Backup Source](#backup-source) - - [An Existing Backup Config](#an-existing-backup-config) - - [The default storage target](#the-default-storage-target) - - [An S3-compatible object store](#an-s3-compatible-object-store) -- [Encryption](#encryption) -- [Prune during restore](#prune-during-restore) -- [Getting the Backup Filename from S3](#getting-the-backup-filename-from-s3) -# Backup Source +## Backup Source Provide details of the backup file and its storage location, which the operator will then use to perform the restore. Select from the following options to provide these details @@ -46,7 +39,7 @@ Select this option if no default storage location is configured at the operator- ![](/img/backup_restore/restore/s3store.png) -# Encryption +## Encryption If the backup was created with encryption enabled, its file will have `.enc` suffix. Choosing such a Backup, or providing a backup filename with `.enc` suffix will display another dropdown named **Encryption Config Secret**. @@ -63,7 +56,7 @@ The `Encryption Config Secret` dropdown will filter out and list only those Secr > **Important** This field should only be set if the backup was created with encryption enabled. Providing the incorrect encryption config will cause the restore to fail. -# Prune During Restore +## Prune During Restore * **Prune**: In order to fully restore Rancher from a backup, and to go back to the exact state it was at when the backup was performed, we need to delete any additional resources that were created by Rancher after the backup was taken. The operator does so if the **Prune** flag is enabled. Prune is enabled by default and it is recommended to keep it enabled. * **Delete Timeout**: This is the amount of time the operator will wait while deleting a resource before editing the resource to remove finalizers and attempt deletion again. @@ -73,7 +66,7 @@ This field should only be set if the backup was created with encryption enabled. | `prune` | Delete the resources managed by Rancher that are not present in the backup (Recommended). | | `deleteTimeoutSeconds` | Amount of time the operator will wait while deleting a resource before editing the resource to remove finalizers and attempt deletion again. | -# Getting the Backup Filename from S3 +## Getting the Backup Filename from S3 This is the name of the backup file that the `rancher-backup` operator will use to perform the restore. diff --git a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/storage-configuration.md b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/storage-configuration.md index df3aeac5b87..4b4b702396e 100644 --- a/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/storage-configuration.md +++ b/versioned_docs/version-2.5/reference-guides/backup-restore-configuration/storage-configuration.md @@ -11,15 +11,8 @@ Configure a storage location where all backups are saved by default. You will ha Only one storage location can be configured at the operator level. -- [Storage Location Configuration](#storage-location-configuration) - - [No Default Storage Location](#no-default-storage-location) - - [S3-compatible Object Store](#s3-compatible-object-store) - - [Use an existing StorageClass](#existing-storageclass) - - [Use an existing PersistentVolume](#existing-persistent-volume) -- [Encryption](#encryption) -- [Example values.yaml for the rancher-backup Helm Chart](#example-values-yaml-for-the-rancher-backup-helm-chart) -# Storage Location Configuration +## Storage Location Configuration ### No Default Storage Location @@ -55,7 +48,7 @@ Select an existing Persistent Volume (PV) that will be used to store your backup It is highly recommended to use a Persistent Volume with a reclaim policy of "Retain". Otherwise if the PVC created by the `rancher-backup` chart gets deleted (either during app upgrade, or accidentally), the PV will get deleted too, which means all backups saved in it will get deleted. -# Example values.yaml for the rancher-backup Helm Chart +## Example values.yaml for the rancher-backup Helm Chart The documented `values.yaml` file that can be used to configure `rancher-backup` operator when the Helm CLI is used can be found in the [backup-restore-operator repository.](https://github.com/rancher/backup-restore-operator/blob/release/v1.0/charts/rancher-backup/values.yaml) diff --git a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md index 1efc247af0f..6974b1e4500 100644 --- a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md +++ b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/logging-best-practices.md @@ -12,7 +12,7 @@ In this guide, we recommend best practices for cluster-level logging and applica - [Application Logging](#application-logging) - [General Best Practices](#general-best-practices) -# Changes in Logging in Rancher v2.5 +## Changes in Logging in Rancher v2.5 Before Rancher v2.5, logging in Rancher has historically been a pretty static integration. There were a fixed list of aggregators to choose from (ElasticSearch, Splunk, Kafka, Fluentd and Syslog), and only two configuration points to choose (Cluster-level and Project-level). @@ -20,7 +20,7 @@ Logging in 2.5 has been completely overhauled to provide a more flexible experie "Under the hood", Rancher logging uses the Banzai Cloud logging operator. We provide manageability of this operator (and its resources), and tie that experience in with managing your Rancher clusters. -# Cluster-level Logging +## Cluster-level Logging ### Cluster-wide Scraping @@ -38,7 +38,7 @@ Currently (as of v2.5.1) the logs from RKE containers are collected, but are not A future release of Rancher will include the source container name which will enable filtering of these component logs. Once that change is made, you will be able to customize a _ClusterFlow_ to retrieve **only** the Kubernetes component logs, and direct them to an appropriate output. -# Application Logging +## Application Logging Best practice not only in Kubernetes but in all container-based applications is to direct application logs to `stdout`/`stderr`. The container runtime will then trap these logs and do **something** with them - typically writing them to a file. Depending on the container runtime (and its configuration), these logs can end up in any number of locations. @@ -54,7 +54,7 @@ The goal of setting up a streaming sidecar is to take log files that are written To set this up, edit your workload resource (e.g. Deployment) and add the following sidecar definition: -``` +```yaml ... containers: - args: @@ -74,7 +74,7 @@ This will add a container to your workload definition that will now stream the c This log stream is then automatically collected according to any _Flows_ or _ClusterFlows_ you have setup. You may also wish to consider creating a _Flow_ specifically for this log file by targeting the name of the container. See example: -``` +```yaml ... spec: match: @@ -85,7 +85,7 @@ spec: ``` -# General Best Practices +## General Best Practices - Where possible, output structured log entries (e.g. `syslog`, JSON). This makes handling of the log entry easier as there are already parsers written for these formats. - Try to provide the name of the application that is creating the log entry, in the entry itself. This can make troubleshooting easier as Kubernetes objects do not always carry the name of the application as the object name. For instance, a pod ID may be something like `myapp-098kjhsdf098sdf98` which does not provide much information about the application running inside the container. diff --git a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md index d934db04043..2587d5657aa 100644 --- a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md +++ b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-managed-clusters/monitoring-best-practices.md @@ -10,19 +10,12 @@ Configuring sensible monitoring and alerting rules is vital for running any prod The [Rancher monitoring documentation](../../../pages-for-subheaders/monitoring-and-alerting.md) describes how you can set up a complete Prometheus and Grafana stack. Out of the box this will scrape monitoring data from all system and Kubernetes components in your cluster and provide sensible dashboards and alerts for them to get started. But for a reliable setup, you also need to monitor your own workloads and adapt Prometheus and Grafana to your own specific use cases and cluster sizes. This document aims to give you best practices for this. -- [What to Monitor](#what-to-monitor) -- [Configuring Prometheus Resource Usage](#configuring-prometheus-resource-usage) -- [Scraping Custom Workloads](#scraping-custom-workloads) -- [Monitoring in a (Micro)Service Architecture](#monitoring-in-a-micro-service-architecture) -- [Real User Monitoring](#real-user-monitoring) -- [Security Monitoring](#security-monitoring) -- [Setting up Alerts](#setting-up-alerts) -# What to Monitor +## What to Monitor Kubernetes itself, as well as applications running inside of it, form a distributed system where different components interact with each other. For the whole system and each individual component, you have to ensure performance, availability, reliability and scalability. A good resource with more details and information is Google's free [Site Reliability Engineering Book](https://landing.google.com/sre/sre-book/), especially the chapter about [Monitoring distributed systems](https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/). -# Configuring Prometheus Resource Usage +## Configuring Prometheus Resource Usage When installing the integrated monitoring stack, Rancher allows to configure several settings that are dependent on the size of your cluster and the workloads running in it. This chapter covers these in more detail. @@ -66,7 +59,7 @@ Prometheus is not meant to store metrics for a long amount of time, but should o In order to store some, or all metrics for a long time, you can leverage Prometheus' [remote read/write](https://prometheus.io/docs/prometheus/latest/storage/#remote-storage-integrations) capabilities to connect it to storage systems like [Thanos](https://thanos.io/), [InfluxDB](https://www.influxdata.com/), [M3DB](https://www.m3db.io/), or others. You can find an example setup in this [blog post](https://rancher.com/blog/2020/prometheus-metric-federation). -# Scraping Custom Workloads +## Scraping Custom Workloads While the integrated Rancher Monitoring already scrapes system metrics from a cluster's nodes and system components, the custom workloads that you deploy on Kubernetes should also be scraped for data. For that you can configure Prometheus to do an HTTP request to an endpoint of your applications in a certain interval. These endpoints should then return their metrics in a Prometheus format. @@ -94,23 +87,23 @@ To still get metrics for these use cases, you can set up [prometheus-pushgateway Sometimes it is useful to monitor workloads from the outside. For this, you can use the [Prometheus blackbox-exporter](https://github.com/prometheus/blackbox_exporter) which allows probing any kind of endpoint over HTTP, HTTPS, DNS, TCP and ICMP. -# Monitoring in a (Micro)Service Architecture +## Monitoring in a (Micro)Service Architecture If you have a (micro)service architecture where multiple individual workloads within your cluster are communicating with each other, it is really important to have detailed metrics and traces about this traffic to understand how all these workloads are communicating with each other and where a problem or bottleneck may be. Of course you can monitor all this internal traffic in all your workloads and expose these metrics to Prometheus. But this can quickly become quite work intensive. Service Meshes like Istio, which can be installed with [a click](../../../pages-for-subheaders/istio.md) in Rancher, can do this automatically and provide rich telemetry about the traffic between all services. -# Real User Monitoring +## Real User Monitoring Monitoring the availability and performance of all your internal workloads is vitally important to run stable, reliable and fast applications. But these metrics only show you parts of the picture. To get a complete view it is also necessary to know how your end users are actually perceiving it. For this you can look into various [Real user monitoring solutions](https://en.wikipedia.org/wiki/Real_user_monitoring). -# Security Monitoring +## Security Monitoring In addition to monitoring workloads to detect performance, availability or scalability problems, the cluster and the workloads running into it should also be monitored for potential security problems. A good starting point is to frequently run and alert on [CIS Scans](../../../pages-for-subheaders/cis-scans.md) which check if the cluster is configured according to security best practices. For the workloads, you can have a look at Kubernetes and Container security solutions like [Falco](https://falco.org/), [Aqua Kubernetes Security](https://www.aquasec.com/solutions/kubernetes-container-security/), [SysDig](https://sysdig.com/). -# Setting up Alerts +## Setting up Alerts Getting all the metrics into a monitoring systems and visualizing them in dashboards is great, but you also want to be pro-actively alerted if something goes wrong. diff --git a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md index 3eef461d748..681283e4654 100644 --- a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md +++ b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md @@ -9,17 +9,12 @@ aliases: This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware. -- [1. Load Balancer Considerations](#1-load-balancer-considerations) -- [2. VM Considerations](#2-vm-considerations) -- [3. Network Considerations](#3-network-considerations) -- [4. Storage Considerations](#4-storage-considerations) -- [5. Backups and Disaster Recovery](#5-backups-and-disaster-recovery)
Solution Overview
![Solution Overview](/img/rancher-on-prem-vsphere.svg) -# 1. Load Balancer Considerations +## 1. Load Balancer Considerations A load balancer is required to direct traffic to the Rancher workloads residing on the RKE nodes. @@ -45,7 +40,7 @@ Avoid implementing a software load balancer within the management cluster. Configure appropriate Firewall / ACL rules to only expose access to Rancher -# 2. VM Considerations +## 2. VM Considerations ### Size the VM's According to Rancher Documentation @@ -67,7 +62,7 @@ Doing so will ensure node VM's are spread across multiple datastores - preventin It’s important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double-checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node. -# 3. Network Considerations +## 3. Network Considerations ### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes @@ -77,13 +72,13 @@ Deploy etcd members within a single data center where possible to avoid latency Each node used should have a static IP configured. In the case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated. -# 4. Storage Considerations +## 4. Storage Considerations ### Leverage SSD Drives for ETCD Nodes ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible. -# 5. Backups and Disaster Recovery +## 5. Backups and Disaster Recovery ### Perform Regular Management Cluster Backups diff --git a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md index a88e581c8ea..ea467591b22 100644 --- a/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md +++ b/versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md @@ -11,7 +11,7 @@ There are two recommended deployment strategies for a Rancher server that manage * [Hub and Spoke](#hub-and-spoke-strategy) * [Regional](#regional-strategy) -# Hub & Spoke Strategy +## Hub & Spoke Strategy --- In this deployment scenario, there is a single Rancher control plane managing Kubernetes clusters across the globe. The control plane would be run on a high-availability Kubernetes cluster, and there would be impact due to latencies. @@ -29,7 +29,7 @@ In this deployment scenario, there is a single Rancher control plane managing Ku * Subject to network latencies. * If the control plane goes out, global provisioning of new services is unavailable until it is restored. However, each Kubernetes cluster can continue to be managed individually. -# Regional Strategy +## Regional Strategy --- In the regional deployment model a control plane is deployed in close proximity to the compute nodes. diff --git a/versioned_docs/version-2.5/reference-guides/cli-with-rancher/kubectl-utility.md b/versioned_docs/version-2.5/reference-guides/cli-with-rancher/kubectl-utility.md index e249c2c809f..8de59255c26 100644 --- a/versioned_docs/version-2.5/reference-guides/cli-with-rancher/kubectl-utility.md +++ b/versioned_docs/version-2.5/reference-guides/cli-with-rancher/kubectl-utility.md @@ -2,10 +2,6 @@ title: kubectl Utility --- -- [kubectl](#kubectl) - - [kubectl Utility](#kubectl-utility) - - [Authentication with kubectl and kubeconfig Tokens with TTL](#authentication-with-kubectl-and-kubeconfig-tokens-with-ttl) - # kubectl Interact with Rancher using kubectl. diff --git a/versioned_docs/version-2.5/reference-guides/cli-with-rancher/rancher-cli.md b/versioned_docs/version-2.5/reference-guides/cli-with-rancher/rancher-cli.md index 4e0936b897d..e21ac3f90a6 100644 --- a/versioned_docs/version-2.5/reference-guides/cli-with-rancher/rancher-cli.md +++ b/versioned_docs/version-2.5/reference-guides/cli-with-rancher/rancher-cli.md @@ -3,15 +3,6 @@ title: Rancher CLI description: Interact with Rancher using command line interface (CLI) tools from your workstation. --- -- [Rancher CLI](#rancher-cli) - - [Download Rancher CLI](#download-rancher-cli) - - [Requirements](#requirements) - - [CLI Authentication](#cli-authentication) - - [Project Selection](#project-selection) - - [Commands](#commands) - - [Rancher CLI Help](#rancher-cli-help) - - [Limitations](#limitations) - The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI. ### Download Rancher CLI diff --git a/versioned_docs/version-2.5/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md b/versioned_docs/version-2.5/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md index b70a29b98d1..94b86294aa3 100644 --- a/versioned_docs/version-2.5/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md +++ b/versioned_docs/version-2.5/reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/vsphere.md @@ -9,14 +9,8 @@ aliases: The following node template configuration reference applies to Rancher v2.3.3+. -- [Account Access](#account-access) -- [Scheduling](#scheduling) -- [Instance Options](#instance-options) -- [Networks](#networks) -- [Node tags and custom attributes](#node-tags-and-custom-attributes) -- [cloud-init](#cloud-init) -# Account Access +## Account Access | Parameter | Required | Description | |:----------------------|:--------:|:-----| @@ -44,7 +38,7 @@ The fields in the **Scheduling** section should auto-populate with the data cent | Folder | | Name of a folder in the datacenter to create the VMs in. Must already exist. The VM folders in this dropdown menu directly correspond to your VM folders in vSphere. The folder name should be prefaced with `vm/` in your vSphere config file. | | Host | | The IP of the host system to schedule VMs in. Leave this field blank for a standalone ESXi or for a cluster with DRS (Distributed Resource Scheduler). If specified, the host system's pool will be used and the **Resource Pool** parameter will be ignored. | -# Instance Options +## Instance Options In the **Instance Options** section, configure the number of vCPUs, memory, and disk size for the VMs created by this template. @@ -72,11 +66,11 @@ Choose the way that the VM will be created: - **Clone an existing virtual machine:** In the **Virtual machine** field, choose an existing VM that the new VM will be cloned from. - **Install from boot2docker ISO:** Ensure that the **OS ISO URL** field contains the URL of a VMware ISO release for RancherOS (`rancheros-vmware.iso`). Note that this URL must be accessible from the nodes running your Rancher server installation. -# Networks +## Networks The node template now allows a VM to be provisioned with multiple networks. In the **Networks** field, you can now click **Add Network** to add any networks available to you in vSphere. -# Node Tags and Custom Attributes +## Node Tags and Custom Attributes Tags allow you to attach metadata to objects in the vSphere inventory to make it easier to sort and search for these objects. @@ -86,7 +80,7 @@ In the custom attributes, Rancher will let you select all the custom attributes > **Note:** Custom attributes are a legacy feature that will eventually be removed from vSphere. -# cloud-init +## cloud-init [Cloud-init](https://cloudinit.readthedocs.io/en/latest/) allows you to initialize your nodes by applying configuration on the first boot. This may involve things such as creating users, authorizing SSH keys or setting up the network. diff --git a/versioned_docs/version-2.5/reference-guides/installation-references/helm-chart-options.md b/versioned_docs/version-2.5/reference-guides/installation-references/helm-chart-options.md index f31433ffa4a..af770124b70 100644 --- a/versioned_docs/version-2.5/reference-guides/installation-references/helm-chart-options.md +++ b/versioned_docs/version-2.5/reference-guides/installation-references/helm-chart-options.md @@ -15,18 +15,8 @@ For help choosing a Helm chart version, refer to [this page.](../../getting-star For information on enabling experimental features, refer to [this page.](../../pages-for-subheaders/enable-experimental-features.md) -- [Common Options](#common-options) -- [Advanced Options](#advanced-options) -- [API Audit Log](#api-audit-log) -- [Setting Extra Environment Variables](#setting-extra-environment-variables) -- [TLS Settings](#tls-settings) -- [Customizing your Ingress](#customizing-your-ingress) -- [HTTP Proxy](#http-proxy) -- [Additional Trusted CAs](#additional-trusted-cas) -- [Private Registry and Air Gap Installs](#private-registry-and-air-gap-installs) -- [External TLS Termination](#external-tls-termination) -### Common Options +## Common Options | Option | Default Value | Description | | ------------------------- | ------------- | ---------------------------------------------------------------------------------- | @@ -38,7 +28,7 @@ For information on enabling experimental features, refer to [this page.](../../p
-### Advanced Options +## Advanced Options | Option | Default Value | Description | | ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | diff --git a/versioned_docs/version-2.5/reference-guides/kubernetes-concepts.md b/versioned_docs/version-2.5/reference-guides/kubernetes-concepts.md index 0741a45f73a..9c13e9e7a72 100644 --- a/versioned_docs/version-2.5/reference-guides/kubernetes-concepts.md +++ b/versioned_docs/version-2.5/reference-guides/kubernetes-concepts.md @@ -7,34 +7,24 @@ aliases: This page explains concepts related to Kubernetes that are important for understanding how Rancher works. The descriptions below provide a simplified interview of Kubernetes components. For more details, refer to the [official documentation on Kubernetes components.](https://kubernetes.io/docs/concepts/overview/components/) -This section covers the following topics: -- [About Docker](#about-docker) -- [About Kubernetes](#about-kubernetes) -- [What is a Kubernetes Cluster?](#what-is-a-kubernetes-cluster) -- [Roles for Nodes in Kubernetes Clusters](#roles-for-nodes-in-kubernetes-clusters) - - [etcd Nodes](#etcd-nodes) - - [Controlplane Nodes](#controlplane-nodes) - - [Worker Nodes](#worker-nodes) -- [About Helm](#about-helm) - -# About Docker +## About Docker Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](https://hub.docker.com) is the most popular public registry. Many organizations also set up private Docker registries. Docker is primarily used to manage containers on individual nodes. >**Note:** Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.x due to the success of Kubernetes. -# About Kubernetes +## About Kubernetes Kubernetes is the container cluster management standard. YAML files specify containers and other resources that form an application. Kubernetes performs functions such as scheduling, scaling, service discovery, health check, secret management, and configuration management. -# What is a Kubernetes Cluster? +## What is a Kubernetes Cluster? A cluster is a group of computers that work together as a single system. A _Kubernetes Cluster_ is a cluster that uses the [Kubernetes container-orchestration system](https://kubernetes.io/) to deploy, maintain, and scale Docker containers, allowing your organization to automate application operations. -# Roles for Nodes in Kubernetes Clusters +## Roles for Nodes in Kubernetes Clusters Each computing resource in a Kubernetes cluster is called a _node_. Nodes can be either bare-metal servers or virtual machines. Kubernetes classifies nodes into three types: _etcd_ nodes, _control plane_ nodes, and _worker_ nodes. @@ -65,7 +55,7 @@ Each [worker node](https://kubernetes.io/docs/concepts/architecture/nodes/) runs Worker nodes also run storage and networking drivers, and ingress controllers when required. You create as many worker nodes as necessary to run your [workloads](../pages-for-subheaders/workloads-and-pods.md). -# About Helm +## About Helm For high-availability installations of Rancher, Helm is the tool used to install Rancher on a Kubernetes cluster. diff --git a/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/helm-chart-options.md b/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/helm-chart-options.md index 22f0efb84f8..685be35b20d 100644 --- a/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/helm-chart-options.md +++ b/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/helm-chart-options.md @@ -3,15 +3,8 @@ title: Helm Chart Options weight: 8 --- -- [Configuring Resource Limits and Requests](#configuring-resource-limits-and-requests) -- [Trusted CA for Notifiers](#trusted-ca-for-notifiers) -- [Additional Scrape Configurations](#additional-scrape-configurations) -- [Configuring Applications Packaged within Monitoring V2](#configuring-applications-packaged-within-monitoring-v2) -- [Increase the Replicas of Alertmanager](#increase-the-replicas-of-alertmanager) -- [Configuring the Namespace for a Persistent Grafana Dashboard](#configuring-the-namespace-for-a-persistent-grafana-dashboard) - -# Configuring Resource Limits and Requests +## Configuring Resource Limits and Requests The resource requests and limits can be configured when installing `rancher-monitoring`. @@ -32,7 +25,7 @@ The default values in the table below are the minimum required resource limits a At least 50Gi storage is recommended. -# Trusted CA for Notifiers +## Trusted CA for Notifiers If you need to add a trusted CA to your notifier, follow these steps: @@ -43,7 +36,7 @@ If you need to add a trusted CA to your notifier, follow these steps: **Result:** The default Alertmanager custom resource will have access to your trusted CA. -# Additional Scrape Configurations +## Additional Scrape Configurations If the scrape configuration you want cannot be specified via a ServiceMonitor or PodMonitor at the moment, you can provide an `additionalScrapeConfigSecret` on deploying or upgrading `rancher-monitoring`. @@ -52,7 +45,7 @@ A [scrape_config section](https://prometheus.io/docs/prometheus/latest/configura An example of where this might be used is with Istio. For more information, see [this section.](https://rancher.com/docs/rancher/v2.5/en/istio/configuration-reference/selectors-and-scrape) -# Configuring Applications Packaged within Monitoring v2 +## Configuring Applications Packaged within Monitoring v2 We deploy kube-state-metrics and node-exporter with monitoring v2. Node exporter are deployed as DaemonSets. In the monitoring v2 helm chart, in the values.yaml, each of the things are deployed as sub charts. diff --git a/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/receivers.md b/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/receivers.md index fccdea7c916..7e526e25431 100644 --- a/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/receivers.md +++ b/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/receivers.md @@ -17,26 +17,8 @@ The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configurati > This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#3-how-alertmanager-works) -- [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui) -- [Receiver Configuration](#receiver-configuration) - - [Slack](#slack) - - [Email](#email) - - [PagerDuty](#pagerduty) - - [Opsgenie](#opsgenie) - - [Webhook](#webhook) - - [Custom](#custom) - - [Teams](#teams) - - [SMS](#sms) -- [Route Configuration](#route-configuration) - - [Receiver](#receiver) - - [Grouping](#grouping) - - [Matching](#matching) -- [Configuring Multiple Receivers](#configuring-multiple-receivers) -- [Example Alertmanager Config](examples.md#example-alertmanager-config) -- [Example Route Config for CIS Scan Alerts](#example-route-config-for-cis-scan-alerts) -- [Trusted CA for Notifiers](#trusted-ca-for-notifiers) -# Creating Receivers in the Rancher UI +## Creating Receivers in the Rancher UI _Available as of v2.5.4_ > **Prerequisites:** @@ -53,7 +35,7 @@ To create notification receivers in the Rancher UI, **Result:** Alerts can be configured to send notifications to the receiver(s). -# Receiver Configuration +## Receiver Configuration The notification integrations are configured with the `receiver`, which is explained in the [Prometheus documentation.](https://prometheus.io/docs/alerting/latest/configuration/#receiver) @@ -91,7 +73,7 @@ The following types of receivers can be configured in the Rancher UI: The custom receiver option can be used to configure any receiver in YAML that cannot be configured by filling out the other forms in the Rancher UI. -# Slack +## Slack | Field | Type | Description | |------|--------------|------| @@ -100,7 +82,7 @@ The custom receiver option can be used to configure any receiver in YAML that ca | Proxy URL | String | Proxy for the webhook notifications. | | Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | -# Email +## Email | Field | Type | Description | |------|--------------|------| @@ -117,7 +99,7 @@ SMTP options: | Username | String | Enter a username to authenticate with the SMTP server. | | Password | String | Enter a password to authenticate with the SMTP server. | -# PagerDuty +## PagerDuty | Field | Type | Description | |------|------|-------| @@ -126,7 +108,7 @@ SMTP options: | Proxy URL | String | Proxy for the PagerDuty notifications. | | Enable Send Resolved Alerts | Bool | Whether to send a follow-up notification if an alert has been resolved (e.g. [Resolved] High CPU Usage). | -# Opsgenie +## Opsgenie | Field | Description | |------|-------------| @@ -141,7 +123,7 @@ Opsgenie Responders: | Type | String | Schedule, Team, User, or Escalation. For more information on alert responders, refer to the [Opsgenie documentation.](https://docs.opsgenie.com/docs/alert-recipients-and-teams) | | Send To | String | Id, Name, or Username of the Opsgenie recipient. | -# Webhook +## Webhook | Field | Description | |-------|--------------| @@ -151,11 +133,11 @@ Opsgenie Responders: -# Custom +## Custom The YAML provided here will be directly appended to your receiver within the Alertmanager Config Secret. -# Teams +## Teams ### Enabling the Teams Receiver for Rancher Managed Clusters @@ -189,7 +171,7 @@ url: http://rancher-alerting-drivers-prom2teams.ns-1.svc:8089/v2/teams-instance- -# SMS +## SMS ### Enabling the SMS Receiver for Rancher Managed Clusters @@ -315,7 +297,7 @@ The Alertmanager must be configured in YAML, as shown in these [examples.](#exam -# Configuring Multiple Receivers +## Configuring Multiple Receivers By editing the forms in the Rancher UI, you can set up a Receiver resource with all the information Alertmanager needs to send alerts to your notification system. @@ -324,7 +306,7 @@ It is also possible to send alerts to multiple notification systems. One way is You can also set up multiple receivers by using the `continue` option for a route, so that the alerts sent to a receiver continue being evaluated in the next level of the routing tree, which could contain another receiver. -# Example Alertmanager Configs +## Example Alertmanager Configs ### Slack To set up notifications via Slack, the following Alertmanager Config YAML can be placed into the `alertmanager.yaml` key of the Alertmanager Config Secret, where the `api_url` should be updated to use your Webhook URL from Slack: @@ -371,7 +353,7 @@ receivers: - service_key: 'database-integration-key' ``` -# Example Route Config for CIS Scan Alerts +## Example Route Config for CIS Scan Alerts While configuring the routes for `rancher-cis-benchmark` alerts, you can specify the matching using the key-value pair `job: rancher-cis-scan`. @@ -396,6 +378,6 @@ spec: For more information on enabling alerting for `rancher-cis-benchmark`, see [this section.](../../pages-for-subheaders/cis-scan-guides.md#enabling-alerting-for-rancher-cis-benchmark) -# Trusted CA for Notifiers +## Trusted CA for Notifiers If you need to add a trusted CA to your notifier, follow the steps in [this section.](helm-chart-options.md#trusted-ca-for-notifiers) \ No newline at end of file diff --git a/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/routes.md b/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/routes.md index b7ea8f10584..3f673b4a6b5 100644 --- a/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/routes.md +++ b/versioned_docs/version-2.5/reference-guides/monitoring-v2-configuration/routes.md @@ -15,13 +15,9 @@ For more information about configuring routes, refer to the [official Alertmanag > This section assumes familiarity with how monitoring components work together. For more information, see [this section.](../../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md) -- [Route Restrictions](#route-restrictions) -- [Route Configuration](#route-configuration) - - [Receiver](#receiver) - - [Grouping](#grouping) - - [Matching](#matching) -# Route Restrictions + +## Route Restrictions Alertmanager proxies alerts for Prometheus based on its receivers and a routing tree that filters alerts to certain receivers based on labels. @@ -31,7 +27,7 @@ In the Rancher UI for configuring routes and receivers, you can configure routin Each receiver is for one or more notification providers. So if you know that every alert for Slack should also go to PagerDuty, you can configure both in the same receiver. -# Route Configuration +## Route Configuration ### Note on Labels and Annotations diff --git a/versioned_docs/version-2.5/reference-guides/pipelines/configure-persistent-data.md b/versioned_docs/version-2.5/reference-guides/pipelines/configure-persistent-data.md index 1552218591a..af00970c431 100644 --- a/versioned_docs/version-2.5/reference-guides/pipelines/configure-persistent-data.md +++ b/versioned_docs/version-2.5/reference-guides/pipelines/configure-persistent-data.md @@ -29,30 +29,31 @@ This section assumes that you understand how persistent storage works in Kuberne - **Add Volume > Use an existing persistent volume (claim)** 1. Complete the form that displays to choose a persistent volume for the internal Docker registry. + - + - 1. Enter a **Name** for the volume claim. - 1. Select a volume claim **Source**: - - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. - - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Select a volume claim **Source**: + - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. + - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - - + + - 1. Enter a **Name** for the volume claim. - 1. Choose a **Persistent Volume Claim** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Choose a **Persistent Volume Claim** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - + -1. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container. +4. From the **Mount Point** field, enter `/var/lib/registry`, which is the data storage path inside the Docker registry container. -1. Click **Upgrade**. +5. Click **Upgrade**. ### B. Configuring Persistent Data for Minio @@ -64,25 +65,26 @@ This section assumes that you understand how persistent storage works in Kuberne - **Add Volume > Use an existing persistent volume (claim)** 1. Complete the form that displays to choose a persistent volume for the internal Docker registry. + - + - 1. Enter a **Name** for the volume claim. - 1. Select a volume claim **Source**: - - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. - - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Select a volume claim **Source**: + - If you select **Use a Storage Class to provision a new persistent volume**, select a storage class and enter a **Capacity**. + - If you select **Use an existing persistent volume**, choose a **Persistent Volume** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - - + + - 1. Enter a **Name** for the volume claim. - 1. Choose a **Persistent Volume Claim** from the drop-down. - 1. From the **Customize** section, choose the read/write access for the volume. - 1. Click **Define**. + 1. Enter a **Name** for the volume claim. + 1. Choose a **Persistent Volume Claim** from the drop-down. + 1. From the **Customize** section, choose the read/write access for the volume. + 1. Click **Define**. - + 1. From the **Mount Point** field, enter `/data`, which is the data storage path inside the Minio container. diff --git a/versioned_docs/version-2.5/reference-guides/pipelines/pipeline-configuration.md b/versioned_docs/version-2.5/reference-guides/pipelines/pipeline-configuration.md index a1d62a92636..0a3b673a505 100644 --- a/versioned_docs/version-2.5/reference-guides/pipelines/pipeline-configuration.md +++ b/versioned_docs/version-2.5/reference-guides/pipelines/pipeline-configuration.md @@ -8,26 +8,8 @@ aliases: In this section, you'll learn how to configure pipelines. -- [Step Types](#step-types) -- [Step Type: Run Script](#step-type-run-script) -- [Step Type: Build and Publish Images](#step-type-build-and-publish-images) -- [Step Type: Publish Catalog Template](#step-type-publish-catalog-template) -- [Step Type: Deploy YAML](#step-type-deploy-yaml) -- [Step Type: Deploy Catalog App](#step-type-deploy-catalog-app) -- [Notifications](#notifications) -- [Timeouts](#timeouts) -- [Triggers and Trigger Rules](#triggers-and-trigger-rules) -- [Environment Variables](#environment-variables) -- [Secrets](#secrets) -- [Pipeline Variable Substitution Reference](#pipeline-variable-substitution-reference) -- [Global Pipeline Execution Settings](#global-pipeline-execution-settings) - - [Executor Quota](#executor-quota) - - [Resource Quota for Executors](#resource-quota-for-executors) - - [Custom CA](#custom-ca) -- [Persistent Data for Pipeline Components](#persistent-data-for-pipeline-components) -- [Example rancher-pipeline.yml](#example-rancher-pipeline-yml) -# Step Types +## Step Types Within each stage, you can add as many steps as you'd like. When there are multiple steps in one stage, they run concurrently. @@ -83,7 +65,7 @@ stages: pushRemote: true registry: reg.example.com ``` -# Step Type: Run Script +## Step Type: Run Script The **Run Script** step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience, you can use variables to refer to metadata of a pipeline execution. Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables. @@ -103,7 +85,7 @@ stages: image: golang shellScript: go build ``` -# Step Type: Build and Publish Images +## Step Type: Build and Publish Images The **Build and Publish Image** step builds and publishes a Docker image. This process requires a Dockerfile in your source code's repository to complete successfully. @@ -153,7 +135,7 @@ stages: PLUGIN_INSECURE: "true" ``` -# Step Type: Publish Catalog Template +## Step Type: Publish Catalog Template The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a git hosted chart repository. It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. Any variables in the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) is supported for any file in the chart folder. @@ -209,7 +191,7 @@ stages: sourceKey: DEPLOY_KEY ``` -# Step Type: Deploy YAML +## Step Type: Deploy YAML This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml). Please refer to the [pipeline variable substitution reference](#pipeline-variable-substitution-reference) for the list of available variables. @@ -232,7 +214,7 @@ stages: path: ./deployment.yaml ``` -# Step Type :Deploy Catalog App +## Step Type :Deploy Catalog App The **Deploy Catalog App** step deploys a catalog app in the project. It will install a new app if it is not present, or upgrade an existing one. @@ -278,7 +260,7 @@ stages: targetNamespace: test ``` -# Timeouts +## Timeouts By default, each pipeline execution has a timeout of 60 minutes. If the pipeline execution cannot complete within its timeout period, the pipeline is aborted. @@ -302,7 +284,7 @@ stages: timeout: 30 ``` -# Notifications +## Notifications You can enable notifications to any notifiers based on the build status of a pipeline. Before enabling notifications, Rancher recommends [setting up notifiers](../monitoring-v2-configuration/receivers.md) so it will be easy to add recipients immediately. @@ -350,7 +332,7 @@ notification: message: "my-message" ``` -# Triggers and Trigger Rules +## Triggers and Trigger Rules After you configure a pipeline, you can trigger it using different methods: @@ -374,12 +356,6 @@ If all conditions evaluate to `true`, then the pipeline/stage/step is executed. Wildcard character (`*`) expansion is supported in `branch` conditions. -This section covers the following topics: - -- [Configuring pipeline triggers](#configuring-pipeline-triggers) -- [Configuring stage triggers](#configuring-stage-triggers) -- [Configuring step triggers](#configuring-step-triggers) -- [Configuring triggers by YAML](#configuring-triggers-by-yaml) ### Configuring Pipeline Triggers @@ -475,7 +451,7 @@ branch: exclude: [ dev ] ``` -# Environment Variables +## Environment Variables When configuring a pipeline, certain [step types](#step-types) allow you to use environment variables to configure the step's script. @@ -512,7 +488,7 @@ stages: SECOND_KEY: VALUE2 ``` -# Secrets +## Secrets If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes [secrets](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md). @@ -555,7 +531,7 @@ stages: targetKey: ALIAS_ENV ``` -# Pipeline Variable Substitution Reference +## Pipeline Variable Substitution Reference For your convenience, the following variables are available for your pipeline configuration scripts. During pipeline executions, these variables are replaced by metadata. You can reference them in the form of `${VAR_NAME}`. @@ -574,7 +550,7 @@ Variable Name | Description `CICD_REGISTRY` | Address for the Docker registry for the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. `CICD_IMAGE` | Name of the image built from the previous publish image step, available in the Kubernetes manifest file of a `Deploy YAML` step. It does not contain the image tag.

[Example](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml) -# Global Pipeline Execution Settings +## Global Pipeline Execution Settings After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. These settings can be edited by selecting **Tools > Pipelines** in the navigation bar. @@ -637,12 +613,12 @@ If you want to use a version control provider with a certificate from a custom/i **Result:** Pipelines can be used and new pods will be able to work with the self-signed-certificate. -# Persistent Data for Pipeline Components +## Persistent Data for Pipeline Components The internal Docker registry and the Minio workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes. For details on setting up persistent storage for pipelines, refer to [this page.](configure-persistent-data.md) -# Example rancher-pipeline.yml +## Example rancher-pipeline.yml An example pipeline configuration file is on [this page.](example-yaml.md) diff --git a/versioned_docs/version-2.5/reference-guides/rancher-cluster-tools.md b/versioned_docs/version-2.5/reference-guides/rancher-cluster-tools.md index 2963ea73515..02d7cbf1de3 100644 --- a/versioned_docs/version-2.5/reference-guides/rancher-cluster-tools.md +++ b/versioned_docs/version-2.5/reference-guides/rancher-cluster-tools.md @@ -6,17 +6,7 @@ aliases: - /rancher/v2.x/en/cluster-admin/tools/ --- -Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories: - - - -- [Logging](#logging) -- [Monitoring and Alerts](#monitoring-and-alerts) -- [Istio](#istio) -- [OPA Gatekeeper](#opa-gatekeeper) -- [CIS Scans](#cis-scans) - - +Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. # Logging diff --git a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md index 0f3b2d2a680..d7ab9541ac8 100644 --- a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -7,15 +7,6 @@ aliases: Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) -This section covers the following topics: - -- [Separation of Rancher and User Clusters](#separation-of-rancher-and-user-clusters) -- [Why HA is Better for Rancher in Production](#why-ha-is-better-for-rancher-in-production) -- [Recommended Load Balancer Configuration for Kubernetes Installations](#recommended-load-balancer-configuration-for-kubernetes-installations) -- [Environment for Kubernetes Installations](#environment-for-kubernetes-installations) -- [Recommended Node Roles for Kubernetes Installations](#recommended-node-roles-for-kubernetes-installations) -- [Architecture for an Authorized Cluster Endpoint](#architecture-for-an-authorized-cluster-endpoint) - # Separation of Rancher and User Clusters A user cluster is a downstream Kubernetes cluster that runs your apps and services. diff --git a/versioned_docs/version-2.5/reference-guides/rancher-project-tools.md b/versioned_docs/version-2.5/reference-guides/rancher-project-tools.md index c58397fcce3..7ad8a13f8a3 100644 --- a/versioned_docs/version-2.5/reference-guides/rancher-project-tools.md +++ b/versioned_docs/version-2.5/reference-guides/rancher-project-tools.md @@ -5,14 +5,7 @@ aliases: - /rancher/v2.x/en/project-admin/tools/ --- -Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories: - - -- [Notifiers and Alerts](#notifiers-and-alerts) -- [Logging](#logging) -- [Monitoring](#monitoring) - - +Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. ## Notifiers and Alerts diff --git a/versioned_docs/version-2.5/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md b/versioned_docs/version-2.5/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md index 3f00ec4fd77..d7358c29b62 100644 --- a/versioned_docs/version-2.5/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md +++ b/versioned_docs/version-2.5/reference-guides/rancher-security/selinux-rpm/about-rancher-selinux.md @@ -8,7 +8,7 @@ The `rancher-selinux` RPM only contains policies for the [rancher-logging applic The `rancher-selinux` GitHub repository is [here.](https://github.com/rancher/rancher-selinux) -# Installing the rancher-selinux RPM +## Installing the rancher-selinux RPM :::note Requirement: @@ -53,7 +53,7 @@ Install the RPM: yum -y install rancher-selinux ``` -# Configuring the Logging Application to Work with SELinux +## Configuring the Logging Application to Work with SELinux :::note Requirement: diff --git a/versioned_docs/version-2.5/reference-guides/rke1-template-example-yaml.md b/versioned_docs/version-2.5/reference-guides/rke1-template-example-yaml.md index ff9f76e0b6c..a8461993993 100644 --- a/versioned_docs/version-2.5/reference-guides/rke1-template-example-yaml.md +++ b/versioned_docs/version-2.5/reference-guides/rke1-template-example-yaml.md @@ -1,5 +1,5 @@ --- -title: Example YAML +title: RKE1 Example YAML weight: 60 aliases: - /rancher/v2.x/en/admin-settings/rke-templates/example-yaml/ diff --git a/versioned_docs/version-2.5/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md b/versioned_docs/version-2.5/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md index 593fb2f4bfd..4b7171724f8 100644 --- a/versioned_docs/version-2.5/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md +++ b/versioned_docs/version-2.5/troubleshooting/kubernetes-components/troubleshooting-etcd-nodes.md @@ -7,25 +7,8 @@ aliases: This section contains commands and tips for troubleshooting nodes with the `etcd` role. -This page covers the following topics: -- [Checking if the etcd Container is Running](#checking-if-the-etcd-container-is-running) -- [etcd Container Logging](#etcd-container-logging) -- [etcd Cluster and Connectivity Checks](#etcd-cluster-and-connectivity-checks) - - [Check etcd Members on all Nodes](#check-etcd-members-on-all-nodes) - - [Check Endpoint Status](#check-endpoint-status) - - [Check Endpoint Health](#check-endpoint-health) - - [Check Connectivity on Port TCP/2379](#check-connectivity-on-port-tcp-2379) - - [Check Connectivity on Port TCP/2380](#check-connectivity-on-port-tcp-2380) -- [etcd Alarms](#etcd-alarms) -- [etcd Space Errors](#etcd-space-errors) -- [Log Level](#log-level) -- [etcd Content](#etcd-content) - - [Watch Streaming Events](#watch-streaming-events) - - [Query etcd Directly](#query-etcd-directly) -- [Replacing Unhealthy etcd Nodes](#replacing-unhealthy-etcd-nodes) - -# Checking if the etcd Container is Running +## Checking if the etcd Container is Running The container for etcd should have status **Up**. The duration shown after **Up** is the time the container has been running. @@ -39,7 +22,7 @@ CONTAINER ID IMAGE COMMAND CREAT 605a124503b9 rancher/coreos-etcd:v3.2.18 "/usr/local/bin/et..." 2 hours ago Up 2 hours etcd ``` -# etcd Container Logging +## etcd Container Logging The logging of the container can contain information on what the problem could be. @@ -54,7 +37,7 @@ docker logs etcd | `rafthttp: request cluster ID mismatch` | The node with the etcd instance logging `rafthttp: request cluster ID mismatch` is trying to join a cluster that has already been formed with another peer. The node should be removed from the cluster, and re-added. | | `rafthttp: failed to find member` | The cluster state (`/var/lib/etcd`) contains wrong information to join the cluster. The node should be removed from the cluster, the state directory should be cleaned and the node should be re-added. -# etcd Cluster and Connectivity Checks +## etcd Cluster and Connectivity Checks The address where etcd is listening depends on the address configuration of the host etcd is running on. If an internal address is configured for the host etcd is running on, the endpoint for `etcdctl` needs to be specified explicitly. If any of the commands respond with `Error: context deadline exceeded`, the etcd instance is unhealthy (either quorum is lost or the instance is not correctly joined in the cluster) @@ -179,7 +162,7 @@ Validating connection to https://IP:2380/version {"etcdserver":"3.2.18","etcdcluster":"3.2.0"} ``` -# etcd Alarms +## etcd Alarms etcd will trigger alarms, for instance when it runs out of space. @@ -200,7 +183,7 @@ memberID:x alarm:NOSPACE memberID:x alarm:NOSPACE ``` -# etcd Space Errors +## etcd Space Errors Related error messages are `etcdserver: mvcc: database space exceeded` or `applying raft message exceeded backend quota`. Alarm `NOSPACE` will be triggered. @@ -300,7 +283,7 @@ docker exec etcd etcdctl alarm disarm docker exec etcd etcdctl alarm list ``` -# Log Level +## Log Level The log level of etcd can be changed dynamically via the API. You can configure debug logging using the commands below. @@ -326,7 +309,7 @@ Command when using etcd version lower than 3.3.x (Kubernetes 1.13.x and lower) a docker run --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro appropriate/curl -s -XPUT -d '{"Level":"INFO"}' --cacert $(docker exec etcd printenv ETCDCTL_CACERT) --cert $(docker exec etcd printenv ETCDCTL_CERT) --key $(docker exec etcd printenv ETCDCTL_KEY) $(docker exec etcd printenv ETCDCTL_ENDPOINT)/config/local/log ``` -# etcd Content +## etcd Content If you want to investigate the contents of your etcd, you can either watch streaming events or you can query etcd directly, see below for examples. @@ -362,6 +345,6 @@ You can process the data to get a summary of count per key, using the command be docker exec etcd etcdctl get /registry --prefix=true --keys-only | grep -v ^$ | awk -F'/' '{ if ($3 ~ /cattle.io/) {h[$3"/"$4]++} else { h[$3]++ }} END { for(k in h) print h[k], k }' | sort -nr ``` -# Replacing Unhealthy etcd Nodes +## Replacing Unhealthy etcd Nodes When a node in your etcd cluster becomes unhealthy, the recommended approach is to fix or remove the failed or unhealthy node before adding a new etcd node to the cluster. diff --git a/versioned_docs/version-2.5/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md b/versioned_docs/version-2.5/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md index 2b23884dd8d..2ea4cf628ba 100644 --- a/versioned_docs/version-2.5/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md +++ b/versioned_docs/version-2.5/troubleshooting/other-troubleshooting-tips/kubernetes-resources.md @@ -9,31 +9,8 @@ The commands/steps listed on this page can be used to check the most important K 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) - - [Get node conditions](#get-node-conditions) -- [Kubernetes leader election](#kubernetes-leader-election) - - [Kubernetes controller manager leader](#kubernetes-controller-manager-leader) - - [Kubernetes scheduler leader](#kubernetes-scheduler-leader) -- [Ingress controller](#ingress-controller) - - [Pod details](#pod-details) - - [Pod container logs](#pod-container-logs) - - [Namespace events](#namespace-events) - - [Debug logging](#debug-logging) - - [Check configuration](#check-configuration) -- [Rancher agents](#rancher-agents) - - [cattle-node-agent](#cattle-node-agent) - - [cattle-cluster-agent](#cattle-cluster-agent) -- [Jobs and pods](#jobs-and-pods) - - [Check that pods or jobs have status Running/Completed](#check-that-pods-or-jobs-have-status-running-completed) - - [Describe pod](#describe-pod) - - [Pod container logs](#pod-container-logs) - - [Describe job](#describe-job) - - [Logs from the containers of pods of the job](#logs-from-the-containers-of-pods-of-the-job) - - [Evicted pods](#evicted-pods) - - [Job does not complete](#job-does-not-complete) -# Nodes +## Nodes ### Get nodes @@ -78,7 +55,7 @@ Example output: worker-0: DiskPressure:True ``` -# Kubernetes leader election +## Kubernetes leader election ### Kubernetes Controller Manager leader @@ -98,7 +75,7 @@ kubectl -n kube-system get endpoints kube-scheduler -o jsonpath='{.metadata.anno {"holderIdentity":"controlplane-0_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","leaseDurationSeconds":15,"acquireTime":"2018-12-27T08:59:45Z","renewTime":"2018-12-27T09:44:57Z","leaderTransitions":0}> ``` -# Ingress Controller +## Ingress Controller The default Ingress Controller is NGINX and is deployed as a DaemonSet in the `ingress-nginx` namespace. The pods are only scheduled to nodes with the `worker` role. @@ -206,7 +183,7 @@ Check logging of cattle-cluster-agent pod: kubectl -n cattle-system logs -l app=cattle-cluster-agent ``` -# Jobs and Pods +## Jobs and Pods ### Check that pods or jobs have status **Running**/**Completed**