mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-29 14:38:50 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Roles for Nodes in Kubernetes
|
||||
weight: 1
|
||||
---
|
||||
|
||||
This section describes the roles for etcd nodes, controlplane nodes, and worker nodes in Kubernetes, and how the roles work together in a cluster.
|
||||
|
||||
This diagram is applicable to Kubernetes clusters [launched with Rancher using RKE.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/).
|
||||
|
||||
<br/>
|
||||
<sup>Lines show the traffic flow between components. Colors are used purely for visual aid</sup>
|
||||
|
||||
# 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.
|
||||
|
||||
>**Note:** Nodes with the `etcd` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
|
||||
# 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.
|
||||
|
||||
>**Note:** Nodes with the `controlplane` role are shown as `Unschedulable` in the UI, meaning no pods will be scheduled to these nodes by default.
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
The Kubernetes API server (`kube-apiserver`) scales horizontally. Each node with the role `controlplane` will be added to the NGINX proxy on the nodes with components that need to access the Kubernetes API server. This means that if a node becomes unreachable, the local NGINX proxy on the node will forward the request to another Kubernetes API server in the list.
|
||||
|
||||
### kube-controller-manager
|
||||
|
||||
The Kubernetes controller manager uses leader election using an endpoint in Kubernetes. One instance of the `kube-controller-manager` 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).
|
||||
|
||||
### kube-scheduler
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
* [Kubernetes: Node Components](https://kubernetes.io/docs/concepts/overview/components/#node-components)
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: Checklist for Production-Ready Clusters
|
||||
weight: 2
|
||||
---
|
||||
|
||||
In this section, we recommend best practices for creating the production-ready Kubernetes clusters that will run your apps and services.
|
||||
|
||||
For a list of requirements for your cluster, including the requirements for OS/Docker, hardware, and networking, refer to the section on [node requirements.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements)
|
||||
|
||||
This is a shortlist of best practices that we strongly recommend for all production clusters.
|
||||
|
||||
For a full list of all the best practices that we recommend, refer to the [best practices section.]({{<baseurl>}}/rancher/v2.6/en/best-practices)
|
||||
|
||||
### Node Requirements
|
||||
|
||||
* Make sure your nodes fulfill all of the [node requirements,]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/) including the port requirements.
|
||||
|
||||
### Back up etcd
|
||||
|
||||
* Enable etcd snapshots. Verify that snapshots are being created, and run a disaster recovery scenario to verify the snapshots are valid. etcd is the location where the state of your cluster is stored, and losing etcd data means losing your cluster. Make sure you configure recurring snapshots of etcd for your cluster(s), and make sure the snapshots are stored externally (off the node) as well.
|
||||
|
||||
### Cluster Architecture
|
||||
|
||||
* Nodes should have one of the following role configurations:
|
||||
* `etcd`
|
||||
* `controlplane`
|
||||
* `etcd` and `controlplane`
|
||||
* `worker` (the `worker` role should not be used or added on nodes with the `etcd` or `controlplane` role)
|
||||
* Have at least three nodes with the role `etcd` to survive losing one node. Increase this count for higher node fault toleration, and spread them across (availability) zones to provide even better fault tolerance.
|
||||
* Assign two or more nodes the `controlplane` role for master component high availability.
|
||||
* Assign two or more nodes the `worker` role for workload rescheduling upon node failure.
|
||||
|
||||
For more information on what each role is used for, refer to the [section on roles for nodes in Kubernetes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/nodes-and-roles)
|
||||
|
||||
For more information about the
|
||||
number of nodes for each Kubernetes role, refer to the section on [recommended architecture.]({{<baseurl>}}/rancher/v2.6/en/overview/architecture-recommendations/)
|
||||
|
||||
### Logging and Monitoring
|
||||
|
||||
* Configure alerts/notifiers for Kubernetes components (System Service).
|
||||
* Configure logging for cluster analysis and post-mortems.
|
||||
|
||||
### Reliability
|
||||
|
||||
* Perform load tests on your cluster to verify that its hardware can support your workloads.
|
||||
|
||||
### Networking
|
||||
|
||||
* Minimize network latency. Rancher recommends minimizing latency between the etcd nodes. The default setting for `heartbeat-interval` is `500`, and the default setting for `election-timeout` is `5000`. These [settings for etcd tuning](https://coreos.com/etcd/docs/latest/tuning.html) allow etcd to run in most networks (except really high latency networks).
|
||||
* Cluster nodes should be located within a single region. Most cloud providers provide multiple availability zones within a region, which can be used to create higher availability for your cluster. Using multiple availability zones is fine for nodes with any role. If you are using [Kubernetes Cloud Provider]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/cloud-providers/) resources, consult the documentation for any restrictions (i.e. zone storage restrictions).
|
||||
+74
@@ -0,0 +1,74 @@
|
||||
---
|
||||
title: Recommended Cluster Architecture
|
||||
weight: 1
|
||||
---
|
||||
|
||||
There are three roles that can be assigned to nodes: `etcd`, `controlplane` and `worker`.
|
||||
|
||||
# Separating Worker Nodes from Nodes with Other Roles
|
||||
|
||||
When designing your cluster(s), you have two options:
|
||||
|
||||
* Use dedicated nodes for each role. This ensures resource availability for the components needed for the specified role. It also strictly isolates network traffic between each of the roles according to the [port requirements]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/node-requirements/#networking-requirements).
|
||||
* Assign the `etcd` and `controlplane` roles to the same nodes. These nodes must meet the hardware requirements for both roles.
|
||||
|
||||
In either case, the `worker` role should not be used or added to nodes with the `etcd` or `controlplane` role.
|
||||
|
||||
Therefore, each node should have one of the following role configurations:
|
||||
|
||||
* `etcd`
|
||||
* `controlplane`
|
||||
* Both `etcd` and `controlplane`
|
||||
* `worker`
|
||||
|
||||
# Recommended Number of Nodes with Each Role
|
||||
|
||||
The cluster should have:
|
||||
|
||||
- At least three nodes with the role `etcd` to survive losing one node. Increase this count for higher node fault toleration, and spread them across (availability) zones to provide even better fault tolerance.
|
||||
- At least two nodes with the role `controlplane` for master component high availability.
|
||||
- At least two nodes with the role `worker` for workload rescheduling upon node failure.
|
||||
|
||||
For more information on what each role is used for, refer to the [section on roles for nodes in Kubernetes.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/production/nodes-and-roles)
|
||||
|
||||
|
||||
### Number of Controlplane Nodes
|
||||
|
||||
Adding more than one node with the `controlplane` role makes every master component highly available.
|
||||
|
||||
### Number of etcd Nodes
|
||||
|
||||
The number of nodes that you can lose at once while maintaining cluster availability is determined by the number of nodes assigned the `etcd` role. For a cluster with n members, the minimum is (n/2)+1. Therefore, we recommend creating an `etcd` node in 3 different availability zones within a region to survive the loss of one availability zone. If you use only two zones, you can only survive the loss of the zone where you don't lose the majority of nodes.
|
||||
|
||||
| Nodes with `etcd` role | Majority | Failure Tolerance |
|
||||
|--------------|------------|-------------------|
|
||||
| 1 | 1 | 0 |
|
||||
| 2 | 2 | 0 |
|
||||
| 3 | 2 | **1** |
|
||||
| 4 | 3 | 1 |
|
||||
| 5 | 3 | **2** |
|
||||
| 6 | 4 | 2 |
|
||||
| 7 | 4 | **3** |
|
||||
| 8 | 5 | 3 |
|
||||
| 9 | 5 | **4** |
|
||||
|
||||
References:
|
||||
|
||||
* [Official etcd documentation on optimal etcd cluster size](https://etcd.io/docs/v3.4.0/faq/#what-is-failure-tolerance)
|
||||
* [Official Kubernetes documentation on operating etcd clusters for Kubernetes](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)
|
||||
|
||||
### Number of Worker Nodes
|
||||
|
||||
Adding more than one node with the `worker` role will make sure your workloads can be rescheduled if a node fails.
|
||||
|
||||
### Why Production Requirements are Different for the Rancher Cluster and the Clusters Running Your Applications
|
||||
|
||||
You may have noticed that our [Kubernetes Install]({{<baseurl>}}/rancher/v2.6/en/installation/install-rancher-on-k8s/) instructions do not meet our definition of a production-ready cluster, as there are no dedicated nodes for the `worker` role. However, for your Rancher installation, this three node cluster is valid, 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.
|
||||
|
||||
# References
|
||||
|
||||
* [Kubernetes: Master Components](https://kubernetes.io/docs/concepts/overview/components/#master-components)
|
||||
Reference in New Issue
Block a user