mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 13:08:11 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
+113
@@ -0,0 +1,113 @@
|
||||
---
|
||||
title: Architecture Recommendations
|
||||
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.
|
||||
|
||||
If you have a Docker installation of Rancher, the node running the Rancher server should be separate from your downstream clusters.
|
||||
|
||||
If Rancher is intended to manage downstream Kubernetes clusters, the Kubernetes cluster that the Rancher server runs on should also be separate from the downstream user clusters.
|
||||
|
||||
|
||||
|
||||
# Why HA is Better for Rancher in Production
|
||||
|
||||
We recommend installing the Rancher server on a high-availability Kubernetes cluster, primarily because it protects the Rancher server data. In a high-availability installation, a load balancer serves as the single point of contact for clients, distributing network traffic across multiple servers in the cluster and helping to prevent any one server from becoming a point of failure.
|
||||
|
||||
We don't recommend installing Rancher in a single Docker container, because if the node goes down, there is no copy of the cluster data available on other nodes and you could lose the data on your Rancher server.
|
||||
|
||||
### K3s Kubernetes Cluster Installations
|
||||
|
||||
One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s is Rancher's CNCF certified Kubernetes distribution. It is easy to install and uses half the memory of Kubernetes, all in a binary of less than 100 MB. Another advantage of K3s is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
|
||||
|
||||
<figcaption>Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
### RKE Kubernetes Cluster Installations
|
||||
|
||||
In an RKE installation, the cluster data is replicated on each of three etcd nodes in the cluster, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
<figcaption>Architecture of an RKE Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
# Recommended Load Balancer Configuration for Kubernetes Installations
|
||||
|
||||
We recommend the following configurations for the load balancer and Ingress controllers:
|
||||
|
||||
* The DNS for Rancher should resolve to a Layer 4 load balancer (TCP).
|
||||
* The Load Balancer should forward port TCP/80 and TCP/443 to all 3 nodes in the Kubernetes cluster.
|
||||
* The Ingress controller will redirect HTTP to HTTPS and terminate SSL/TLS on port TCP/443.
|
||||
* The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Rancher installed on a Kubernetes cluster with layer 4 load balancer, depicting SSL termination at Ingress controllers</figcaption>
|
||||
|
||||
|
||||
# Environment for Kubernetes Installations
|
||||
|
||||
It is strongly recommended to install Rancher on a Kubernetes cluster on hosted infrastructure such as Amazon's EC2 or Google Compute Engine.
|
||||
|
||||
For the best performance and greater security, we recommend a 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]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/) for running your workloads.
|
||||
|
||||
# Recommended Node Roles for Kubernetes Installations
|
||||
|
||||
The below recommendations apply when Rancher is installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster.
|
||||
|
||||
### K3s Cluster Roles
|
||||
|
||||
In K3s clusters, there are two types of nodes: server nodes and agent nodes. Both servers and agents can have workloads scheduled on them. Server nodes run the Kubernetes master.
|
||||
|
||||
For the cluster running the Rancher management server, we recommend using two server nodes. Agent nodes are not required.
|
||||
|
||||
### RKE Cluster Roles
|
||||
|
||||
If Rancher is installed on an RKE Kubernetes cluster, the cluster should have three nodes, and each node should have all three Kubernetes roles: etcd, controlplane, and worker.
|
||||
|
||||
### Contrasting RKE Cluster Architecture for Rancher Server and for Downstream Kubernetes Clusters
|
||||
|
||||
Our recommendation for RKE node roles on the Rancher server cluster contrasts with our recommendations for the downstream user clusters that run your apps and services.
|
||||
|
||||
Rancher uses RKE as a library when provisioning downstream Kubernetes clusters. Note: The capability to provision downstream K3s clusters will be added in a future version of Rancher.
|
||||
|
||||
For downstream Kubernetes clusters, we recommend that each node in a user cluster should have a single role for stability and scalability.
|
||||
|
||||
|
||||
|
||||
RKE only requires at least one node with each role and does not require nodes to be restricted to one role. However, for the clusters that run your apps, we recommend separate roles for each node so that workloads on worker nodes don't interfere with the Kubernetes master or cluster data as your services scale.
|
||||
|
||||
We recommend that downstream user clusters should have at least:
|
||||
|
||||
- **Three nodes with only the etcd role** to maintain a quorum if one node is lost, making the state of your cluster highly available
|
||||
- **Two nodes with only the controlplane role** to make the master component highly available
|
||||
- **One or more nodes with only the worker role** to run the Kubernetes node components, as well as the workloads for your apps and services
|
||||
|
||||
With that said, it is safe to use all three roles on three nodes when setting up the Rancher server because:
|
||||
|
||||
* It allows one `etcd` node failure.
|
||||
* 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.
|
||||
|
||||
Because no additional workloads will be deployed on the Rancher server cluster, in most cases it is not necessary to use the same architecture that we recommend for the scalability and reliability of downstream clusters.
|
||||
|
||||
For more best practices for downstream clusters, refer to the [production checklist]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production) or our [best practices guide.]({{<baseurl>}}/rancher/v2.6/en/best-practices/)
|
||||
|
||||
# Architecture for an Authorized Cluster Endpoint (ACE)
|
||||
|
||||
If you are using an [authorized cluster endpoint (ACE),]({{<baseurl>}}/rancher/v2.6/en/overview/architecture/#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role.
|
||||
|
||||
If you are using private CA signed certificates on the load balancer, you have to supply the CA certificate, which will be included in the generated kubeconfig file to validate the certificate chain. See the documentation on [kubeconfig files]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) and [API keys]({{<baseurl>}}/rancher/v2.6/en/user-settings/api-keys/#creating-an-api-key) for more information.
|
||||
|
||||
As of Rancher v2.6.3, ACE support is available for registered RKE2 and K3s clusters. To view the manual steps to perform on the downstream cluster to enable the ACE, click [here]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters).
|
||||
@@ -0,0 +1,183 @@
|
||||
---
|
||||
title: Architecture
|
||||
weight: 1
|
||||
---
|
||||
|
||||
This section focuses on the Rancher server, its components, and how Rancher communicates with downstream Kubernetes clusters.
|
||||
|
||||
For information on the different ways that Rancher can be installed, refer to the [overview of installation options.]({{<baseurl>}}/rancher/v2.6/en/installation/#overview-of-installation-options)
|
||||
|
||||
For a list of main features of the Rancher API server, refer to the [overview section.]({{<baseurl>}}/rancher/v2.6/en/overview/#features-of-the-rancher-api-server)
|
||||
|
||||
For guidance about setting up the underlying infrastructure for the Rancher server, refer to the [architecture recommendations.]({{<baseurl>}}/rancher/v2.6/en/overview/architecture-recommendations)
|
||||
|
||||
> This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{<baseurl>}}/rancher/v2.6/en/overview/concepts) page.
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [Rancher server architecture](#rancher-server-architecture)
|
||||
- [Communicating with downstream user clusters](#communicating-with-downstream-user-clusters)
|
||||
- [The authentication proxy](#1-the-authentication-proxy)
|
||||
- [Cluster controllers and cluster agents](#2-cluster-controllers-and-cluster-agents)
|
||||
- [Node agents](#3-node-agents)
|
||||
- [Authorized cluster endpoint (ACE)](#4-authorized-cluster-endpoint-ace)
|
||||
- [Important files](#important-files)
|
||||
- [Tools for provisioning Kubernetes clusters](#tools-for-provisioning-kubernetes-clusters)
|
||||
- [Rancher server components and source code](#rancher-server-components-and-source-code)
|
||||
|
||||
# Rancher Server Architecture
|
||||
|
||||
The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment.
|
||||
|
||||
The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service).
|
||||
|
||||
For the best performance and security, we recommend a 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]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/) for running your workloads.
|
||||
|
||||
The diagram below shows how users can manipulate both [Rancher-launched Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) clusters and [hosted Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/) clusters through Rancher's authentication proxy:
|
||||
|
||||
<figcaption>Managing Kubernetes Clusters through Rancher's Authentication Proxy</figcaption>
|
||||
|
||||
|
||||
|
||||
You can install Rancher on a single node, or on a high-availability Kubernetes cluster.
|
||||
|
||||
A high-availability Kubernetes installation is recommended for production.
|
||||
|
||||
A Docker installation of Rancher is recommended only for development and testing purposes. The ability to migrate Rancher to a high-availability cluster depends on the Rancher version.
|
||||
|
||||
The Rancher backup operator can be used to migrate Rancher from the single Docker container install to an installation on a high-availability Kubernetes cluster. For details, refer to the documentation on [migrating Rancher to a new cluster]({{<baseurl>}}/rancher/v2.6/en/backups/migrating-rancher).
|
||||
|
||||
The Rancher server, regardless of the installation method, should always run on nodes that are separate from the downstream user clusters that it manages. If Rancher is installed on a high-availability Kubernetes cluster, it should run on a separate cluster from the cluster(s) it manages.
|
||||
|
||||
# Communicating with Downstream User Clusters
|
||||
|
||||
This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services.
|
||||
|
||||
The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters.
|
||||
|
||||
<figcaption>Communicating with Downstream Clusters</figcaption>
|
||||
|
||||
|
||||
|
||||
The following descriptions correspond to the numbers in the diagram above:
|
||||
|
||||
1. [The Authentication Proxy](#1-the-authentication-proxy)
|
||||
2. [Cluster Controllers and Cluster Agents](#2-cluster-controllers-and-cluster-agents)
|
||||
3. [Node Agents](#3-node-agents)
|
||||
4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)
|
||||
|
||||
### 1. The Authentication Proxy
|
||||
|
||||
In this diagram, a user named Bob wants to see all pods running on a downstream user cluster called User Cluster 1. From within Rancher, he can run a `kubectl` command to see
|
||||
the pods. Bob is authenticated through Rancher's authentication proxy.
|
||||
|
||||
The authentication proxy forwards all Kubernetes API calls to downstream clusters. It integrates with authentication services like local authentication, Active Directory, and GitHub. On every Kubernetes API call, the authentication proxy authenticates the caller and sets the proper Kubernetes impersonation headers before forwarding the call to Kubernetes masters.
|
||||
|
||||
Rancher communicates with Kubernetes clusters using a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/), which provides an identity for processes that run in a pod.
|
||||
|
||||
By default, Rancher generates a [kubeconfig file]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) that contains credentials for proxying through the Rancher server to connect to the Kubernetes API server on a downstream user cluster. The kubeconfig file (`kube_config_cluster.yml`) contains full access to the cluster.
|
||||
|
||||
### 2. Cluster Controllers and Cluster Agents
|
||||
|
||||
Each downstream user cluster has a cluster agent, which opens a tunnel to the corresponding cluster controller within the Rancher server.
|
||||
|
||||
There is one cluster controller and one cluster agent for each downstream cluster. Each cluster controller:
|
||||
|
||||
- Watches for resource changes in the downstream cluster
|
||||
- Brings the current state of the downstream cluster to the desired state
|
||||
- Configures access control policies to clusters and projects
|
||||
- Provisions clusters by calling the required Docker machine drivers and Kubernetes engines, such as RKE and GKE
|
||||
|
||||
By default, to enable Rancher to communicate with a downstream cluster, the cluster controller connects to the cluster agent. If the cluster agent is not available, the cluster controller can connect to a [node agent](#3-node-agents) instead.
|
||||
|
||||
The cluster agent, also called `cattle-cluster-agent`, is a component that runs in a downstream user cluster. It performs the following tasks:
|
||||
|
||||
- Connects to the Kubernetes API of Rancher-launched Kubernetes clusters
|
||||
- Manages workloads, pod creation and deployment within each cluster
|
||||
- Applies the roles and bindings defined in each cluster's global policies
|
||||
- Communicates between the cluster and Rancher server (through a tunnel to the cluster controller) about events, stats, node info, and health
|
||||
|
||||
### 3. Node Agents
|
||||
|
||||
If the cluster agent (also called `cattle-cluster-agent`) is not available, one of the node agents creates a tunnel to the cluster controller to communicate with Rancher.
|
||||
|
||||
The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) resource to make sure it runs on every node in a Rancher-launched Kubernetes cluster. It is used to interact with the nodes when performing cluster operations. Examples of cluster operations include upgrading the Kubernetes version and creating or restoring etcd snapshots.
|
||||
|
||||
### 4. Authorized Cluster Endpoint (ACE)
|
||||
|
||||
An authorized cluster endpoint allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.
|
||||
|
||||
> The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters) to provision the cluster. The ACE is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
|
||||
> The [ACE is available for registered RKE2 and K3s clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) as of Rancher v2.6.3.
|
||||
|
||||
There are two main reasons why a user might need the authorized cluster endpoint:
|
||||
|
||||
- To access a downstream user cluster while Rancher is down
|
||||
- To reduce latency in situations where the Rancher server and downstream cluster are separated by a long distance
|
||||
|
||||
The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the authorized cluster endpoint. When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
|
||||
|
||||
Like the authorized cluster endpoint, the `kube-api-auth` authentication service is also only available for Rancher-launched Kubernetes clusters.
|
||||
|
||||
> **Example scenario:** Let's say that the Rancher server is located in the United States, and User Cluster 1 is located in Australia. A user, Alice, also lives in Australia. Alice can manipulate resources in User Cluster 1 by using the Rancher UI, but her requests will have to be sent from Australia to the Rancher server in the United States, then be proxied back to Australia, where the downstream user cluster is. The geographical distance may cause significant latency, which Alice can reduce by using the authorized cluster endpoint.
|
||||
|
||||
With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.
|
||||
|
||||
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.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl)
|
||||
|
||||
# Important Files
|
||||
|
||||
The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster:
|
||||
|
||||
- `rancher-cluster.yml`: The RKE cluster configuration file.
|
||||
- `kube_config_cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down.
|
||||
- `rancher-cluster.rkestate`: The Kubernetes cluster state file. This file contains credentials for full access to the cluster. Note: This state file is only created when using RKE v0.2.0 or higher.
|
||||
|
||||
> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
|
||||
For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) documentation.
|
||||
|
||||
# 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.
|
||||
|
||||
### Rancher Launched Kubernetes for Nodes Hosted in an Infrastructure Provider
|
||||
|
||||
Rancher can dynamically provision nodes in a provider such as Amazon EC2, DigitalOcean, Azure, or vSphere, then install Kubernetes on them.
|
||||
|
||||
Rancher provisions this type of cluster using [RKE](https://github.com/rancher/rke) and [docker-machine.](https://github.com/rancher/machine)
|
||||
|
||||
### Rancher Launched Kubernetes for Custom Nodes
|
||||
|
||||
When setting up this type of cluster, Rancher installs Kubernetes on existing nodes, which creates a custom cluster.
|
||||
|
||||
Rancher provisions this type of cluster using [RKE.](https://github.com/rancher/rke)
|
||||
|
||||
### Hosted Kubernetes Providers
|
||||
|
||||
When setting up this type of cluster, Kubernetes is installed by providers such as Google Kubernetes Engine, Amazon Elastic Container Service for Kubernetes, or Azure Kubernetes Service.
|
||||
|
||||
Rancher provisions this type of cluster using [kontainer-engine.](https://github.com/rancher/kontainer-engine)
|
||||
|
||||
### Registered Kubernetes Clusters
|
||||
|
||||
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
|
||||
|
||||
This diagram shows each component that the Rancher server is composed of:
|
||||
|
||||
|
||||
|
||||
The GitHub repositories for Rancher can be found at the following links:
|
||||
|
||||
- [Main Rancher server repository](https://github.com/rancher/rancher)
|
||||
- [Rancher UI](https://github.com/rancher/ui)
|
||||
- [Rancher API UI](https://github.com/rancher/api-ui)
|
||||
- [Norman,](https://github.com/rancher/norman) Rancher's API framework
|
||||
- [Types](https://github.com/rancher/types)
|
||||
- [Rancher CLI](https://github.com/rancher/cli)
|
||||
- [Catalog applications](https://github.com/rancher/helm)
|
||||
|
||||
This is a partial list of the most important Rancher repositories. For more details about Rancher source code, refer to the section on [contributing to Rancher.]({{<baseurl>}}/rancher/v2.6/en/contributing/#repositories) To see all libraries and projects used in Rancher, see the [`go.mod` file](https://github.com/rancher/rancher/blob/master/go.mod) in the `rancher/rancher` repository.
|
||||
@@ -0,0 +1,72 @@
|
||||
---
|
||||
title: Kubernetes Concepts
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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?
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
A Kubernetes cluster consists of at least one etcd, controlplane, and worker node.
|
||||
|
||||
### etcd Nodes
|
||||
|
||||
Rancher uses etcd as a data store in both single node and high-availability installations. In Kubernetes, etcd is also a role for nodes that store the cluster state.
|
||||
|
||||
The state of a Kubernetes cluster is maintained in [etcd.](https://kubernetes.io/docs/concepts/overview/components/#etcd) The etcd nodes run the etcd database.
|
||||
|
||||
The etcd database component is a distributed key-value store used as Kubernetes storage for all cluster data, such as cluster coordination and state management. It is recommended to run etcd on multiple nodes so that there's always a backup available for failover.
|
||||
|
||||
Although you can run etcd on just one node, etcd requires a majority of nodes, a quorum, to agree on updates to the cluster state. The cluster should always contain enough healthy etcd nodes to form a quorum. For a cluster with n members, a quorum is (n/2)+1. For any odd-sized cluster, adding one node will always increase the number of nodes necessary for a quorum.
|
||||
|
||||
Three etcd nodes is generally sufficient for smaller clusters and five etcd nodes for large clusters.
|
||||
|
||||
### Controlplane Nodes
|
||||
|
||||
Controlplane nodes run the Kubernetes API server, scheduler, and controller manager. These nodes take care of routine tasks to ensure that your cluster maintains your configuration. Because all cluster data is stored on your etcd nodes, control plane nodes are stateless. You can run control plane on a single node, although three or more nodes are recommended for redundancy. Additionally, a single node can share the control plane and etcd roles.
|
||||
|
||||
### Worker Nodes
|
||||
|
||||
Each [worker node](https://kubernetes.io/docs/concepts/architecture/nodes/) runs the following:
|
||||
|
||||
- **Kubelets:** An agent that monitors the state of the node, ensuring your containers are healthy.
|
||||
- **Workloads:** The containers and pods that hold your apps, as well as other types of deployments.
|
||||
|
||||
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]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/workloads/).
|
||||
|
||||
# About Helm
|
||||
|
||||
For high-availability installations of Rancher, Helm is the tool used to install Rancher on a Kubernetes cluster.
|
||||
|
||||
Helm is the package management tool of choice for Kubernetes. Helm charts provide templating syntax for Kubernetes YAML manifest documents. With Helm we can create configurable deployments instead of just using static files. For more information about creating your own catalog of deployments, check out the docs at [https://helm.sh/](https://helm.sh).
|
||||
|
||||
For more information on service accounts and cluster role binding, refer to the [Kubernetes documentation.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
|
||||
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: Overview
|
||||
weight: 1
|
||||
---
|
||||
|
||||
Rancher is a container management platform built for organizations that deploy containers in production. Rancher makes it easy to run Kubernetes everywhere, meet IT requirements, and empower DevOps teams.
|
||||
|
||||
# Run Kubernetes Everywhere
|
||||
|
||||
Kubernetes has become the container orchestration standard. Most cloud and virtualization vendors now offer it as standard infrastructure. Rancher users have the choice of creating Kubernetes clusters with Rancher Kubernetes Engine (RKE) or cloud Kubernetes services, such as GKE, AKS, and EKS. Rancher users can also import and manage their existing Kubernetes clusters created using any Kubernetes distribution or installer.
|
||||
|
||||
# Meet IT Requirements
|
||||
|
||||
Rancher supports centralized authentication, access control, and monitoring for all Kubernetes clusters under its control. For example, you can:
|
||||
|
||||
- Use your Active Directory credentials to access Kubernetes clusters hosted by cloud vendors, such as GKE.
|
||||
- Setup and enforce access control and security policies across all users, groups, projects, clusters, and clouds.
|
||||
- View the health and capacity of your Kubernetes clusters from a single-pane-of-glass.
|
||||
|
||||
# Empower DevOps Teams
|
||||
|
||||
Rancher provides an intuitive user interface for DevOps engineers to manage their application workload. The user does not need to have in-depth knowledge of Kubernetes concepts to start using Rancher. Rancher catalog contains a set of useful DevOps tools. Rancher is certified with a wide selection of cloud native ecosystem products, including, for example, security tools, monitoring systems, container registries, and storage and networking drivers.
|
||||
|
||||
The following figure illustrates the role Rancher plays in IT and DevOps organizations. Each team deploys their applications on the public or private clouds they choose. IT administrators gain visibility and enforce policies across all users, clusters, and clouds.
|
||||
|
||||
|
||||
|
||||
# Features of the Rancher API Server
|
||||
|
||||
The Rancher API server is built on top of an embedded Kubernetes API server and an etcd database. It implements the following functionalities:
|
||||
|
||||
### Authorization and Role-Based Access Control
|
||||
|
||||
- **User management:** The Rancher API server [manages user identities]({{<baseurl>}}/rancher/v2.6/en/admin-settings/authentication/) that correspond to external authentication providers like Active Directory or GitHub, in addition to local users.
|
||||
- **Authorization:** The Rancher API server manages [access control]({{<baseurl>}}/rancher/v2.6/en/admin-settings/rbac/) and [security]({{<baseurl>}}/rancher/v2.6/en/admin-settings/pod-security-policies/) policies.
|
||||
|
||||
### Working with Kubernetes
|
||||
|
||||
- **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/upgrading-kubernetes)
|
||||
- **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{<baseurl>}}/rancher/v2.6/en/helm-charts/) that make it easy to repeatedly deploy applications.
|
||||
- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you to manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.6/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.6/en/k8s-in-rancher/)
|
||||
- **Pipelines:** Setting up a [pipeline]({{<baseurl>}}/rancher/v2.6/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
|
||||
- **Istio:** Our [integration with Istio]({{<baseurl>}}/rancher/v2.6/en/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.
|
||||
|
||||
### Working with Cloud Infrastructure
|
||||
|
||||
- **Tracking nodes:** The Rancher API server tracks identities of all the [nodes]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/nodes/) in all clusters.
|
||||
- **Setting up infrastructure:** When configured to use a cloud provider, Rancher can dynamically provision [new nodes]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/) and [persistent storage]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/volumes-and-storage/) in the cloud.
|
||||
|
||||
### Cluster Visibility
|
||||
|
||||
- **Logging:** Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
|
||||
- **Monitoring:** Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution.
|
||||
- **Alerting:** 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.
|
||||
|
||||
# Editing Downstream Clusters with Rancher
|
||||
|
||||
The options and settings available for an existing cluster change based on the method that you used to provision it. For example, only clusters [provisioned by RKE]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/) have **Cluster Options** available for editing.
|
||||
|
||||
After a cluster is created with Rancher, a cluster administrator can manage cluster membership, enable pod security policies, and manage node pools, among [other options.]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/editing-clusters/)
|
||||
|
||||
The following table summarizes the options and settings available for each cluster type:
|
||||
|
||||
{{% include file="/rancher/v2.6/en/cluster-provisioning/cluster-capabilities-table</summary>
|
||||
Reference in New Issue
Block a user