mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Convert h1 to h2 (2.5)
This commit is contained in:
@@ -12,14 +12,14 @@ Throughout the installation instructions, there will be _tabs_ for each installa
|
||||
|
||||
> **Important:** If you install Rancher following the Docker installation guide, there is no upgrade path to transition your Docker Installation to a Kubernetes Installation.
|
||||
|
||||
# Installation Outline
|
||||
## Installation Outline
|
||||
|
||||
1. [Set up infrastructure and private registry](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/infrastructure-private-registry.md)
|
||||
2. [Collect and publish images to your private registry](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/publish-images.md)
|
||||
3. [Set up a Kubernetes cluster (Skip this step for Docker installations)](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-kubernetes.md)
|
||||
4. [Install Rancher](../getting-started/installation-and-upgrade/other-installation-methods/air-gapped-helm-cli-install/install-rancher-ha.md)
|
||||
|
||||
# Upgrades
|
||||
## Upgrades
|
||||
|
||||
To upgrade Rancher with Helm CLI in an air gap environment, follow [this procedure.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades.md)
|
||||
|
||||
|
||||
@@ -10,8 +10,7 @@ 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)
|
||||
|
||||
|
||||
# Setting up Shibboleth in Rancher
|
||||
## Setting up Shibboleth in Rancher
|
||||
|
||||
### Shibboleth Prerequisites
|
||||
>
|
||||
@@ -69,7 +68,7 @@ If you configure Shibboleth without OpenLDAP, the following caveats apply due to
|
||||
|
||||
To enable searching for groups when assigning permissions in Rancher, you will need to configure a back end for the SAML provider that supports groups, such as OpenLDAP.
|
||||
|
||||
# Setting up OpenLDAP in Rancher
|
||||
## Setting up OpenLDAP in Rancher
|
||||
|
||||
If you also configure OpenLDAP as the back end to Shibboleth, it will return a SAML assertion to Rancher with user attributes that include groups. Then authenticated users will be able to access resources in Rancher that their groups have permissions for.
|
||||
|
||||
@@ -91,6 +90,6 @@ Configure the settings for the OpenLDAP server, groups and users. For help filli
|
||||
2. From the **Global** view, navigate to **Security** > **Authentication**
|
||||
3. Select **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed.
|
||||
|
||||
# Troubleshooting
|
||||
## Troubleshooting
|
||||
|
||||
If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging](../faq/technical-items.md#how-can-i-enable-debug-logging) in this documentation.
|
||||
|
||||
@@ -24,7 +24,7 @@ Because the API sets the actual value and the command line sets the default valu
|
||||
|
||||
For example, if you install Rancher, then set a feature flag to true with the Rancher API, then upgrade Rancher with a command that sets the feature flag to false, the default value will still be false, but the feature will still be enabled because it was set with the Rancher API. If you then deleted the set value (true) with the Rancher API, setting it to NULL, the default value (false) would take effect. See the [feature flags page](../reference-guides/installation-references/feature-flags.md) for more information.
|
||||
|
||||
# Enabling Features when Starting Rancher
|
||||
## Enabling Features when Starting Rancher
|
||||
|
||||
When you install Rancher, enable the feature you want with a feature flag. The command is different depending on whether you are installing Rancher on a single node or if you are doing a Kubernetes Installation of Rancher.
|
||||
|
||||
@@ -84,8 +84,7 @@ docker run -d -p 80:80 -p 443:443 \
|
||||
--features=<FEATURE-FLAG-NAME-1>=true,<FEATURE-FLAG-NAME-2>=true
|
||||
```
|
||||
|
||||
|
||||
# Enabling Features with the Rancher UI
|
||||
## Enabling Features with the Rancher UI
|
||||
|
||||
1. In the upper left corner, click **☰ > Global Settings**.
|
||||
1. Click **Feature Flags**.
|
||||
@@ -101,7 +100,7 @@ docker run -d -p 80:80 -p 443:443 \
|
||||
|
||||
**Result:** The feature is disabled.
|
||||
|
||||
# Enabling Features with the Rancher API
|
||||
## Enabling Features with the Rancher API
|
||||
|
||||
1. Go to `<RANCHER-SERVER-URL>/v3/features`.
|
||||
1. In the `data` section, you will see an array containing all of the features that can be turned on with feature flags. The name of the feature is in the `id` field. Click the name of the feature you want to enable.
|
||||
|
||||
@@ -8,7 +8,7 @@ import TabItem from '@theme/TabItem';
|
||||
<Tabs>
|
||||
<TabItem value="Rancher v2.5.8+">
|
||||
|
||||
# Changes in v2.5.8
|
||||
## Changes in v2.5.8
|
||||
|
||||
- We now support private GKE clusters. 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)
|
||||
- [Shared VPCs](https://cloud.google.com/vpc/docs/shared-vpc) are now supported.
|
||||
@@ -22,7 +22,7 @@ import TabItem from '@theme/TabItem';
|
||||
- Node pools can be added while configuring the GKE cluster
|
||||
- When provisioning a GKE cluster, you can now use reusable cloud credentials instead of using a service account token directly to create the cluster.
|
||||
|
||||
# Cluster Location
|
||||
## Cluster Location
|
||||
|
||||
| Value | Description |
|
||||
|--------|--------------|
|
||||
@@ -31,7 +31,7 @@ import TabItem from '@theme/TabItem';
|
||||
| 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
|
||||
|
||||
@@ -133,7 +133,7 @@ _Mutable: yes_
|
||||
|
||||
Enable control plane authorized networks to block untrusted non-GCP source IPs from accessing the Kubernetes master through HTTPS. If selected, additional authorized networks may be added. If the cluster is created with a public endpoint, this option is useful for locking down access to the public endpoint to only certain networks, such as the network where your Rancher service is running. If the cluster only has a private endpoint, this setting is required.
|
||||
|
||||
# Additional Options
|
||||
## Additional Options
|
||||
|
||||
### Cluster Addons
|
||||
|
||||
@@ -182,7 +182,7 @@ _Mutable: yes_
|
||||
|
||||
Set the start time for a 4 hour maintenance window. The time is specified in the UTC time zone using the HH:MM format. For more information, refer to [this page.](https://cloud.google.com/kubernetes-engine/docs/concepts/maintenance-windows-and-exclusions)
|
||||
|
||||
# Node Pools
|
||||
## Node Pools
|
||||
|
||||
In this section, enter details describing the configuration of each node in the node pool.
|
||||
|
||||
@@ -240,7 +240,7 @@ You can apply labels to the node pool, which applies the labels to all nodes in
|
||||
|
||||
Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)
|
||||
|
||||
# Group Details
|
||||
## Group Details
|
||||
|
||||
In this section, enter details describing the node pool.
|
||||
|
||||
@@ -306,13 +306,13 @@ The shorter the refresh window, the less likely any race conditions will occur,
|
||||
</TabItem>
|
||||
<TabItem value="Rancher before v2.5.8">
|
||||
|
||||
# Labels & Annotations
|
||||
## Labels & Annotations
|
||||
|
||||
Add Kubernetes [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) or [annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) to the cluster.
|
||||
|
||||
Invalid labels can prevent upgrades or can prevent Rancher from starting. For details on label syntax requirements, see the [Kubernetes documentation.](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)
|
||||
|
||||
# Kubernetes Options
|
||||
## Kubernetes Options
|
||||
|
||||
### Location Type
|
||||
Zonal or Regional. With GKE, you can create a cluster tailored to the availability requirements of your workload and your budget. By default, a cluster's nodes run in a single compute zone. When multiple zones are selected, the cluster's nodes will span multiple compute zones, while the controlplane is located in a single zone. Regional clusters increase the availability of the controlplane as well. For help choosing the type of cluster availability, refer to [these docs.](https://cloud.google.com/kubernetes-engine/docs/best-practices/scalability#choosing_a_regional_or_zonal_control_plane)
|
||||
|
||||
@@ -15,7 +15,7 @@ Cluster Autoscaler is designed to run on Kubernetes master nodes. It can run in
|
||||
|
||||
It's possible to run a customized deployment of Cluster Autoscaler on worker nodes, but extra care needs to be taken to ensure that Cluster Autoscaler remains up and running.
|
||||
|
||||
# Cloud Providers
|
||||
## Cloud Providers
|
||||
|
||||
Cluster Autoscaler provides support to distinct cloud providers. For more information, go to [cluster-autoscaler supported cloud providers.](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment)
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ RancherD is a single binary that first launches an RKE2 Kubernetes cluster, then
|
||||
- [Uninstall](#uninstall)
|
||||
- [RKE2 Documentation](#rke2-documentation)
|
||||
|
||||
# About RancherD Installs
|
||||
## About RancherD Installs
|
||||
|
||||
When RancherD is launched on a host, it first installs an RKE2 Kubernetes cluster, then deploys Rancher on the cluster as a Kubernetes daemonset.
|
||||
|
||||
@@ -29,7 +29,7 @@ In Part I of these instructions, you'll learn how to launch RancherD on a single
|
||||
|
||||
Part II explains how to convert the single-node Rancher installation into a high-availability installation. If the Rancher server will manage downstream Kubernetes clusters, it is important to follow these steps. A discussion of recommended architecture for highly available Rancher deployments can be found in our [Best Practices Guide.](./rancher-server.md)
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
### Node Requirements
|
||||
|
||||
@@ -38,6 +38,7 @@ RancherD must be launched on a Linux OS. At this time, only OSes that leverage s
|
||||
The Linux node needs to fulfill the [installation requirements](installation-requirements.md) for hardware and networking. Docker is not required for RancherD installs.
|
||||
|
||||
To install RancherD on SELinux Enforcing CentOS 8 nodes or RHEL 8 nodes, some [additional steps](installation-requirements.md#rancherd-on-selinux-enforcing-centos-8-or-rhel-8-nodes) are required.
|
||||
|
||||
### Root Access
|
||||
|
||||
Before running the installation commands, you will need to log in as root:
|
||||
@@ -71,7 +72,7 @@ The following should be taken into consideration when configuring the load balan
|
||||
- The Kubernetes API is served on port 6443, as normal.
|
||||
- In RancherD installs, the Rancher UI is served on port 8443 by default. (This is different from Helm chart installs, where port 443 is used by default.)
|
||||
|
||||
# Part I: Installing Rancher
|
||||
## Part I: Installing Rancher
|
||||
|
||||
### 1. Set up Configurations
|
||||
|
||||
@@ -170,7 +171,7 @@ This will give you the URL, username and password needed to log into Rancher. Fo
|
||||
|
||||
If Rancher will only manage the local Kubernetes cluster, the installation is complete.
|
||||
|
||||
# Part II: High Availability
|
||||
## Part II: High Availability
|
||||
|
||||
If you plan to use the Rancher server to manage downstream Kubernetes clusters, Rancher needs to be highly available. In these steps, you will add more nodes to achieve a high-availability cluster. Since Rancher is running as a daemonset, it will automatically launch on the nodes you add.
|
||||
|
||||
@@ -216,15 +217,15 @@ Repeat steps one and two for another Linux node, bringing the number of nodes in
|
||||
|
||||
**Result:** Rancher is highly available and the installation is complete.
|
||||
|
||||
# Upgrades
|
||||
## Upgrades
|
||||
|
||||
For information on upgrades and rollbacks, refer to [this page.](../getting-started/installation-and-upgrade/other-installation-methods/install-rancher-on-linux/upgrade-rancherd.md)
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
For information on how to configure certificates, node taints, Rancher Helm chart options, or RancherD CLI options, refer to the [configuration reference.](../reference-guides/cluster-configuration/rancher-server-configuration/rancherd-configuration-reference.md)
|
||||
|
||||
# Uninstall
|
||||
## Uninstall
|
||||
|
||||
To uninstall RancherD from your system, run the command below. This will shut down the process, remove the RancherD binary, and clean up files used by RancherD.
|
||||
|
||||
@@ -232,6 +233,6 @@ To uninstall RancherD from your system, run the command below. This will shut do
|
||||
rancherd-uninstall.sh
|
||||
```
|
||||
|
||||
# RKE2 Documentation
|
||||
## RKE2 Documentation
|
||||
|
||||
For more information on RKE2, the Kubernetes distribution used to provision the underlying cluster, refer to the documentation [here.](https://docs.rke2.io/)
|
||||
+2
-2
@@ -8,7 +8,7 @@ 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
|
||||
|
||||
- [Kubernetes Cluster](#kubernetes-cluster)
|
||||
- [CLI Tools](#cli-tools)
|
||||
@@ -42,7 +42,7 @@ To deploy Rancher v2.5 on a hosted Kubernetes cluster such as EKS, GKE, or AKS,
|
||||
|
||||
For an example of how to deploy an ingress on EKS, refer to [this section.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#5-install-an-ingress)
|
||||
|
||||
# Install the Rancher Helm Chart
|
||||
## Install the Rancher Helm Chart
|
||||
|
||||
Rancher is installed using the Helm package manager for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents.
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ description: Learn how to install Rancher in development and production environm
|
||||
|
||||
This section provides an overview of the architecture options of installing Rancher, describing advantages of each option.
|
||||
|
||||
# Terminology
|
||||
## Terminology
|
||||
|
||||
In this section,
|
||||
|
||||
@@ -15,7 +15,7 @@ In this section,
|
||||
- **RKE2** is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
- **RancherD** was an experimental tool for installing Rancher; a single binary that first launched an RKE2 Kubernetes cluster, then installed the Rancher server Helm chart on the cluster. It was available as part of Rancher v2.5.4 through v2.5.10 but is now deprecated and not available for recent releases.
|
||||
|
||||
# Changes to Installation in Rancher v2.5
|
||||
## Changes to Installation in Rancher v2.5
|
||||
|
||||
In Rancher v2.5, the Rancher management server can be installed on any Kubernetes cluster, including hosted clusters, such as Amazon EKS clusters.
|
||||
|
||||
@@ -23,7 +23,7 @@ For Docker installations, a local Kubernetes cluster is installed in the single
|
||||
|
||||
The `restrictedAdmin` Helm chart option was added. When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin)
|
||||
|
||||
# Overview of Installation Options
|
||||
## Overview of Installation Options
|
||||
|
||||
Rancher can be installed on these main architectures:
|
||||
|
||||
@@ -79,10 +79,11 @@ When the nodes in your Kubernetes cluster are running and fulfill the [node requ
|
||||
|
||||
For a longer discussion of Rancher architecture, refer to the [architecture overview,](rancher-manager-architecture.md) [recommendations for production-grade architecture,](../reference-guides/rancher-manager-architecture/architecture-recommendations.md) or our [best practices guide.](../reference-guides/best-practices/rancher-server/tips-for-running-rancher.md)
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
Before installing Rancher, make sure that your nodes fulfill all of the [installation requirements.](installation-requirements.md)
|
||||
|
||||
# Architecture Tip
|
||||
## Architecture Tip
|
||||
|
||||
For the best performance and greater security, we recommend a separate, dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](kubernetes-clusters-in-rancher-setup.md) for running your workloads.
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ For a list of best practices that we recommend for running the Rancher server in
|
||||
|
||||
The Rancher UI works best in Firefox or Chrome.
|
||||
|
||||
# Operating Systems and Container Runtime Requirements
|
||||
## Operating Systems and Container Runtime Requirements
|
||||
|
||||
Rancher should work with any modern Linux distribution.
|
||||
|
||||
@@ -101,11 +101,11 @@ Docker is required for Helm chart installs, and it can be installed by following
|
||||
|
||||
Docker is not required for RancherD installs.
|
||||
|
||||
# Hardware Requirements
|
||||
## Hardware Requirements
|
||||
|
||||
The following sections describe the CPU, memory, and disk requirements for the nodes where the Rancher server is installed.
|
||||
|
||||
# CPU and Memory
|
||||
## CPU and Memory
|
||||
|
||||
Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements. The requirements are different depending on if you are installing Rancher in a single container with Docker, or if you are installing Rancher on a Kubernetes cluster.
|
||||
|
||||
@@ -168,7 +168,7 @@ These CPU and memory requirements apply to a host with a [single-node](rancher-o
|
||||
| Small | Up to 5 | Up to 50 | 1 | 4 GB |
|
||||
| Medium | Up to 15 | Up to 200 | 2 | 8 GB |
|
||||
|
||||
# Ingress
|
||||
## Ingress
|
||||
|
||||
Each node in the Kubernetes cluster that Rancher is installed on should run an Ingress.
|
||||
|
||||
@@ -185,11 +185,11 @@ Currently, RKE2 deploys nginx-ingress as a deployment by default, so you will ne
|
||||
### Ingress for EKS
|
||||
For an example of how to deploy an nginx-ingress-controller with a LoadBalancer service, refer to [this section.](../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rancher-on-amazon-eks.md#5-install-an-ingress)
|
||||
|
||||
# Disks
|
||||
## Disks
|
||||
|
||||
Rancher performance depends on etcd in the cluster performance. To ensure optimal speed, we recommend always using SSD disks to back your Rancher management Kubernetes cluster. On cloud providers, you will also want to use the minimum size that allows the maximum IOPS. In larger clusters, consider using dedicated storage devices for etcd data and wal directories.
|
||||
|
||||
# Networking Requirements
|
||||
## Networking Requirements
|
||||
|
||||
This section describes the networking requirements for the node(s) where the Rancher server is installed.
|
||||
|
||||
@@ -201,7 +201,7 @@ Each node used should have a static IP configured, regardless of whether you are
|
||||
|
||||
To operate properly, Rancher requires a number of ports to be open on Rancher nodes and on downstream Kubernetes cluster nodes. [Port Requirements](../getting-started/installation-and-upgrade/installation-requirements/port-requirements.md) lists all the necessary ports for Rancher and Downstream Clusters for the different cluster types.
|
||||
|
||||
# RancherD on SELinux Enforcing CentOS 8 or RHEL 8 Nodes
|
||||
## RancherD on SELinux Enforcing CentOS 8 or RHEL 8 Nodes
|
||||
|
||||
Before installing Rancher on SELinux Enforcing CentOS 8 nodes or RHEL 8 nodes, you must install `container-selinux` and `iptables`:
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ This section describes how to enable Istio and start using it in your projects.
|
||||
|
||||
If you use Istio for traffic management, you will need to allow external traffic to the cluster. In that case, you will need to follow all of the steps below.
|
||||
|
||||
# Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
This guide assumes you have already [installed Rancher,](installation-and-upgrade.md) and you have already [provisioned a separate Kubernetes cluster](kubernetes-clusters-in-rancher-setup.md) on which you will install Istio.
|
||||
|
||||
@@ -14,8 +14,7 @@ The nodes in your cluster must meet the [CPU and memory requirements.](../explan
|
||||
|
||||
The workloads and services that you want to be controlled by Istio must meet [Istio's requirements.](https://istio.io/docs/setup/additional-setup/requirements/)
|
||||
|
||||
|
||||
# Install
|
||||
## Install
|
||||
|
||||
> **Quick Setup** 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)
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ This section includes troubleshooting tips in the following categories:
|
||||
- [Troubleshooting nginx-proxy Nodes](../troubleshooting/kubernetes-components/troubleshooting-nginx-proxy.md)
|
||||
- [Troubleshooting Worker Nodes and Generic Components](../troubleshooting/kubernetes-components/troubleshooting-worker-nodes-and-generic-components.md)
|
||||
|
||||
# Kubernetes Component Diagram
|
||||
## Kubernetes Component Diagram
|
||||
|
||||
<br/>
|
||||
<sup>Lines show the traffic flow between components. Colors are used purely for visual aid</sup>
|
||||
@@ -23,11 +23,11 @@ The monitoring application allows you to:
|
||||
- Defines precomputed, frequently needed or computationally expensive expressions as new time series based on metrics collected via Prometheus
|
||||
- Expose collected metrics from Prometheus to the Kubernetes Custom Metrics API via Prometheus Adapter for use in HPA
|
||||
|
||||
# How Monitoring Works
|
||||
## How Monitoring Works
|
||||
|
||||
For an explanation of how the monitoring components work together, see [this page.](../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md)
|
||||
|
||||
# Default Components and Deployments
|
||||
## Default Components and Deployments
|
||||
|
||||
### Built-in Dashboards
|
||||
|
||||
@@ -48,11 +48,11 @@ The monitoring application deploys some alerts by default. To see the default al
|
||||
|
||||
For a list of monitoring components exposed in the Rancher UI, along with common use cases for editing them, see [this section.](../explanations/integrations-in-rancher/monitoring-and-alerting/how-monitoring-works.md#components-exposed-in-the-rancher-ui)
|
||||
|
||||
# Role-based Access Control
|
||||
## Role-based Access Control
|
||||
|
||||
For information on configuring access to monitoring, see [this page.](../explanations/integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md)
|
||||
|
||||
# Guides
|
||||
## Guides
|
||||
|
||||
- [Enable monitoring](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/enable-monitoring.md)
|
||||
- [Uninstall monitoring](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/uninstall-monitoring.md)
|
||||
@@ -62,7 +62,7 @@ For information on configuring access to monitoring, see [this page.](../explana
|
||||
- [Debugging high memory usage](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/debug-high-memory-usage.md)
|
||||
- [Migrating from Monitoring V1 to V2](../how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5+-monitoring.md)
|
||||
|
||||
# Configuration
|
||||
## Configuration
|
||||
|
||||
### Configuring Monitoring Resources in Rancher
|
||||
|
||||
@@ -79,7 +79,7 @@ For information on configuring access to monitoring, see [this page.](../explana
|
||||
|
||||
For more information on `rancher-monitoring` chart options, including options to set resource limits and requests, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md)
|
||||
|
||||
# Windows Cluster Support
|
||||
## Windows Cluster Support
|
||||
|
||||
_Available as of v2.5.8_
|
||||
|
||||
@@ -89,9 +89,7 @@ To be able to fully deploy Monitoring V2 for Windows, all of your Windows hosts
|
||||
|
||||
For more details on how to upgrade wins on existing Windows hosts, refer to the section on [Windows cluster support for Monitoring V2.](../explanations/integrations-in-rancher/monitoring-and-alerting/windows-support.md)
|
||||
|
||||
|
||||
|
||||
# Known Issues
|
||||
## Known Issues
|
||||
|
||||
There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more default memory. If you are enabling monitoring on a K3s cluster, we recommend setting `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.
|
||||
|
||||
|
||||
+3
-4
@@ -6,19 +6,18 @@ This page captures some of the most important options for configuring Monitoring
|
||||
|
||||
For information on configuring custom scrape targets and rules for Prometheus, please refer to the upstream documentation for the [Prometheus Operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus Operator [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md) The Prometheus Operator documentation can help also you set up RBAC, Thanos, or custom configuration.
|
||||
|
||||
# Setting Resource Limits and Requests
|
||||
## Setting Resource Limits and Requests
|
||||
|
||||
The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](../reference-guides/monitoring-v2-configuration/helm-chart-options.md#configuring-resource-limits-and-requests)
|
||||
|
||||
>**Note:** On an idle cluster, Monitoring V2 has significantly higher CPU usage (up to 70%) as compared to Monitoring V1. To improve performance and achieve similar results as in Monitoring V1, turn off the Prometheus adapter.
|
||||
|
||||
# Prometheus Configuration
|
||||
## Prometheus Configuration
|
||||
|
||||
It is usually not necessary to directly edit the Prometheus custom resource.
|
||||
|
||||
Instead, to configure Prometheus to scrape custom metrics, you will only need to create a new ServiceMonitor or PodMonitor to configure Prometheus to scrape additional metrics.
|
||||
|
||||
|
||||
### ServiceMonitor and PodMonitor Configuration
|
||||
|
||||
For details, see [this page.](../reference-guides/monitoring-v2-configuration/servicemonitors-and-podmonitors.md)
|
||||
@@ -27,7 +26,7 @@ For details, see [this page.](../reference-guides/monitoring-v2-configuration/se
|
||||
|
||||
For more information about directly editing the Prometheus custom resource, which may be helpful in advanced use cases, see [this page.](../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheus.md)
|
||||
|
||||
# Alertmanager Configuration
|
||||
## Alertmanager Configuration
|
||||
|
||||
The Alertmanager custom resource usually doesn't need to be edited directly. For most common use cases, you can manage alerts by updating Routes and Receivers.
|
||||
|
||||
|
||||
@@ -24,11 +24,11 @@ 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.
|
||||
|
||||
|
||||
# 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.
|
||||
|
||||
@@ -54,7 +54,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.
|
||||
|
||||
@@ -62,7 +62,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:
|
||||
|
||||
@@ -202,7 +202,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:
|
||||
|
||||
@@ -220,8 +220,7 @@ The configuration reference also covers how to configure:
|
||||
- Environment variables
|
||||
- Secrets
|
||||
|
||||
|
||||
# Running your Pipelines
|
||||
## Running your Pipelines
|
||||
|
||||
Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** Find your pipeline and select the vertical **⋮ > Run**.
|
||||
|
||||
@@ -233,7 +232,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.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ In a lot of enterprise environments, servers or VMs running on premise do not ha
|
||||
|
||||
Alternatively, it is also possible to set up Rancher completely air-gapped without any Internet access. This process is described in detail in the [Rancher docs](air-gapped-helm-cli-install.md).
|
||||
|
||||
# Installation Outline
|
||||
## Installation Outline
|
||||
|
||||
1. [Set up infrastructure](../getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/set-up-infrastructure.md)
|
||||
2. [Set up a Kubernetes cluster](../getting-started/installation-and-upgrade/other-installation-methods/rancher-behind-an-http-proxy/install-kubernetes.md)
|
||||
|
||||
+3
-3
@@ -18,15 +18,15 @@ The Rancher backup operator can be used to migrate Rancher from the single Docke
|
||||
|
||||
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.
|
||||
|
||||
# Requirements for OS, Docker, Hardware, and Networking
|
||||
## Requirements for OS, Docker, Hardware, and Networking
|
||||
|
||||
Make sure that your node fulfills the general [installation requirements.](installation-requirements.md)
|
||||
|
||||
# 1. Provision Linux Host
|
||||
## 1. Provision Linux Host
|
||||
|
||||
Provision a single Linux host according to our [Requirements](installation-requirements.md) to launch your Rancher server.
|
||||
|
||||
# 2. Choose an SSL Option and Install Rancher
|
||||
## 2. Choose an SSL Option and Install Rancher
|
||||
|
||||
For security purposes, SSL (Secure Sockets Layer) is required when using Rancher. SSL secures all Rancher network communication, like when you login or interact with a cluster.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ To use this option you'll need access to servers you intend to use in your Kuber
|
||||
|
||||
This section describes how to set up a custom cluster.
|
||||
|
||||
# Creating a Cluster with Custom Nodes
|
||||
## Creating a Cluster with Custom Nodes
|
||||
|
||||
>**Want to use Windows hosts as Kubernetes workers?**
|
||||
>
|
||||
@@ -108,7 +108,7 @@ If you share resources between clusters, you can change the tag to:
|
||||
Key=kubernetes.io/cluster/CLUSTERID, Value=shared
|
||||
```
|
||||
|
||||
# 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:
|
||||
|
||||
|
||||
+4
-5
@@ -8,8 +8,7 @@ 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).
|
||||
|
||||
|
||||
# Node Templates
|
||||
## Node Templates
|
||||
|
||||
A node template is the saved configuration for the parameters to use when provisioning nodes in a specific cloud provider. These nodes can be launched from the UI. Rancher uses [Docker Machine](https://docs.docker.com/machine/) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher.
|
||||
|
||||
@@ -38,7 +37,7 @@ To access all node templates, an administrator will need to do the following:
|
||||
|
||||
**Result:** All node templates are listed and grouped by owner. The templates can be edited or cloned by clicking the **⋮.**
|
||||
|
||||
# Node Pools
|
||||
## Node Pools
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template](#node-templates).
|
||||
|
||||
@@ -102,7 +101,7 @@ You can disable node auto-replace from the Rancher UI with the following steps:
|
||||
|
||||
**Result:** Node auto-replace is disabled for the node pool.
|
||||
|
||||
# Cloud Credentials
|
||||
## Cloud Credentials
|
||||
|
||||
Node templates can use cloud credentials to store credentials for launching nodes in your cloud provider, which has some benefits:
|
||||
|
||||
@@ -114,6 +113,6 @@ Node templates can use cloud credentials to store credentials for launching node
|
||||
|
||||
After cloud credentials are created, the user can start [managing the cloud credentials that they created](../reference-guides/user-settings/manage-cloud-credentials.md).
|
||||
|
||||
# Node Drivers
|
||||
## Node Drivers
|
||||
|
||||
If you don't find the node driver that you want to use, you can see if it is available in Rancher's built-in [node drivers and activate it](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#activating-deactivating-node-drivers), or you can [add your own custom node driver](../how-to-guides/advanced-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#adding-custom-node-drivers).
|
||||
|
||||
@@ -20,8 +20,7 @@ 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/).
|
||||
|
||||
|
||||
# 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).
|
||||
|
||||
@@ -137,7 +136,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)
|
||||
|
||||
@@ -145,8 +144,7 @@ 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
|
||||
|
||||
To begin provisioning a cluster on existing nodes with Windows support, prepare your hosts.
|
||||
|
||||
@@ -170,7 +168,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.
|
||||
|
||||
@@ -185,7 +183,7 @@ The instructions for creating a Windows cluster on existing nodes are very simil
|
||||
|
||||
> **Important:** For <b>Host Gateway (L2bridge)</b> networking, it's best to use the same Layer 2 network for all nodes. Otherwise, you need to configure the route rules for them. For details, refer to the [documentation on configuring cloud-hosted VM routes.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/network-requirements-for-host-gateway.md#cloud-hosted-vm-routes-configuration) You will also need to [disable private IP address checks](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/use-windows-clusters/network-requirements-for-host-gateway.md#disabling-private-ip-address-checks) if you are using Amazon EC2, Google GCE, or Azure VM.
|
||||
|
||||
# 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.
|
||||
|
||||
@@ -263,6 +261,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)
|
||||
|
||||
@@ -4,11 +4,11 @@ title: Setting up the vSphere Cloud Provider
|
||||
|
||||
In this section, you'll learn how to set up a vSphere cloud provider for a Rancher managed RKE Kubernetes cluster in vSphere.
|
||||
|
||||
# In-tree Cloud Provider
|
||||
## In-tree Cloud Provider
|
||||
|
||||
To use the in-tree vSphere cloud provider, you will need to use an RKE configuration option. For details, refer to [this page.](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/vsphere/configure-in-tree-vsphere.md)
|
||||
|
||||
# Out-of-tree Cloud Provider
|
||||
## Out-of-tree Cloud Provider
|
||||
|
||||
_Available as of v2.5+_
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ A vSphere cluster may consist of multiple groups of VMs with distinct properties
|
||||
- [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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user