mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Adding changes to v2.14
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
This commit is contained in:
Sunil Singh
+1
-1
@@ -87,7 +87,7 @@ To enable draining each node during a cluster upgrade,
|
||||
1. On the **Clusters** page, go to the cluster you want to enable node draining and click **⋮ > Edit Config**.
|
||||
1. Click **⋮ > Edit**.
|
||||
1. In the **Upgrade Strategy** tab, go to the **Drain nodes** field and click **Yes**. Node draining is configured separately for control plane and worker nodes.
|
||||
1. Configure the options for how pods are deleted. For more information about each option, refer to [this section.](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md#aggressive-and-safe-draining-options)
|
||||
1. Configure the options for how pods are deleted. For more information about each option, refer to [this section.](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools.md#aggressive-and-safe-draining-options)
|
||||
1. Optionally, configure a grace period. The grace period is the timeout given to each pod for cleaning things up, so they will have chance to exit gracefully. Pods might need to finish any outstanding requests, roll back transactions or save state to some external storage. If this value is negative, the default value specified in the pod will be used.
|
||||
1. Optionally, configure a timeout, which is the amount of time the drain should continue to wait before giving up.
|
||||
1. Click **Save**.
|
||||
|
||||
@@ -47,7 +47,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
|
||||
|
||||
### Working with Cloud Infrastructure
|
||||
|
||||
- **Tracking nodes:** The Rancher API server tracks identities of all the [nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md) in all clusters.
|
||||
- **Tracking nodes:** The Rancher API server tracks identities of all the [nodes](../how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools.md) in all clusters.
|
||||
- **Setting up infrastructure:** When configured to use a cloud provider, Rancher can dynamically provision [new nodes](../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md) and [persistent storage](../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/create-kubernetes-persistent-storage.md) in the cloud.
|
||||
|
||||
### Cluster Visibility
|
||||
|
||||
+1
-1
@@ -14,7 +14,7 @@ If you want to standardize the hardware in your clusters, use RKE templates conj
|
||||
|
||||
### Node Templates
|
||||
|
||||
[Node templates](../../../../reference-guides/user-settings/manage-node-templates.md) are responsible for node configuration and node provisioning in Rancher. From your user profile, you can set up node templates to define which templates are used in each of your node pools. With node pools enabled, you can make sure you have the required number of nodes in each node pool, and ensure that all nodes in the pool are the same.
|
||||
Node templates are responsible for node configuration and node provisioning in Rancher. From your user profile, you can set up node templates to define which templates are used in each of your node pools. With node pools enabled, you can make sure you have the required number of nodes in each node pool, and ensure that all nodes in the pool are the same.
|
||||
|
||||
### Terraform
|
||||
|
||||
|
||||
+8
-14
@@ -33,27 +33,21 @@ For more information, refer to the section on [hosted Kubernetes clusters.](set-
|
||||
|
||||
## 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.
|
||||
Rancher uses [RKE2](https://docs.rke2.io/) or [K3s](https://docs.k3s.io/) as a library when provisioning Kubernetes on your own nodes. RKE2 is Rancher’s own lightweight Kubernetes installer.
|
||||
|
||||
In RKE clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform.
|
||||
In RKE2 clusters, Rancher manages the deployment of Kubernetes. These clusters can be deployed on any bare metal server, cloud provider, or virtualization platform.
|
||||
|
||||
These nodes can be dynamically provisioned through Rancher's UI, which calls [Docker Machine](https://github.com/docker/docs/blob/vnext-engine/machine/overview.md) to launch nodes on various cloud providers.
|
||||
If you already have a node that you want to add to an RKE2 cluster, you can add it to the cluster by running a Rancher RKE2 agent container on it.
|
||||
|
||||
If you already have a node that you want to add to an RKE cluster, you can add it to the cluster by running a Rancher agent container on it.
|
||||
|
||||
For more information, refer to the section on [RKE clusters.](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md)
|
||||
For more information, refer to [Launching Kubernetes with Rancher](../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
|
||||
|
||||
### Launching Kubernetes and Provisioning Nodes in an Infrastructure Provider
|
||||
|
||||
Rancher can dynamically provision nodes in infrastructure providers such as Amazon EC2, DigitalOcean, Azure, or vSphere, then install Kubernetes on them.
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates). This template defines the parameters used to launch nodes in your cloud providers.
|
||||
|
||||
One benefit of using nodes hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically replace it, thus maintaining the expected cluster configuration.
|
||||
|
||||
The cloud providers available for creating a node template are decided based on the [node drivers](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-drivers) active in the Rancher UI.
|
||||
|
||||
For more information, refer to the section on [nodes hosted by an infrastructure provider](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)
|
||||
For more information, refer to [Launching Kubernetes on New Nodes in an Infrastructure Provider](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)
|
||||
|
||||
### Launching Kubernetes on Existing Custom Nodes
|
||||
|
||||
@@ -71,10 +65,10 @@ Registering EKS clusters now provides additional benefits. For the most part, re
|
||||
|
||||
When you delete an EKS cluster that was created in Rancher, the cluster is destroyed. When you delete an EKS cluster that was registered in Rancher, it is disconnected from the Rancher server, but it still exists and you can still access it in the same way you did before it was registered in Rancher.
|
||||
|
||||
For more information, see [this page.](register-existing-clusters.md)
|
||||
For more information, refer to [Registering Existing Clusters](register-existing-clusters.md).
|
||||
|
||||
## 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)
|
||||
The most common way to programmatically deploy Kubernetes clusters through Rancher is by using the Rancher2 Terraform provider. Refer to the documentation for [creating clusters with Terraform](https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/cluster).
|
||||
|
||||
EKS, GKE, AKS clusters and RKE clusters can be created or imported with Terraform.
|
||||
EKS, GKE, and AKS clusters can be created or imported with Terraform.
|
||||
|
||||
+3
-34
@@ -9,7 +9,7 @@ title: Rancher Agents
|
||||
There are two different agent resources deployed on Rancher managed clusters:
|
||||
|
||||
- [cattle-cluster-agent](#cattle-cluster-agent)
|
||||
- [cattle-node-agent](#cattle-node-agent)
|
||||
- [rancher-system-agent](#rancher-system-agent)
|
||||
|
||||
For a conceptual overview of how the Rancher server provisions clusters and communicates with them, refer to the [architecture](../../../reference-guides/rancher-manager-architecture/rancher-manager-architecture.md).
|
||||
|
||||
@@ -17,9 +17,9 @@ For a conceptual overview of how the Rancher server provisions clusters and comm
|
||||
|
||||
The `cattle-cluster-agent` is used to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters. The `cattle-cluster-agent` is deployed using a Deployment resource.
|
||||
|
||||
### cattle-node-agent
|
||||
### rancher-system-agent
|
||||
|
||||
The `cattle-node-agent` is used to interact with nodes in a [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) cluster when performing cluster operations. Examples of cluster operations are upgrading Kubernetes version and creating/restoring etcd snapshots. The `cattle-node-agent` is deployed using a DaemonSet resource to make sure it runs on every node. The `cattle-node-agent` is used as fallback option to connect to the Kubernetes API of [Rancher Launched Kubernetes](launch-kubernetes-with-rancher.md) clusters when `cattle-cluster-agent` is unavailable.
|
||||
The `rancher-system-agent` is a daemon used to manage nodes in a Rancher provisioned RKE2/K3s Kubernetes cluster when performing cluster lifecycle operations. Examples of cluster operations include upgrading the Kubernetes version and creating/restoring etcd snapshots. The `rancher-system-agent` is designed to apply plans to the Rancher system and can support both local and remote plans.
|
||||
|
||||
### Requests
|
||||
|
||||
@@ -27,39 +27,12 @@ The `cattle-cluster-agent` pod does not define the default CPU and memory reques
|
||||
|
||||
To configure request values through the UI:
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Options** section.
|
||||
1. Expand the **Cluster Configuration** subsection.
|
||||
1. Configure your request values using the **CPU Requests** and **Memory Requests** fields as needed.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
1. When you [create](./launch-kubernetes-with-rancher.md) or edit an existing cluster, go to the **Cluster Configuration**.
|
||||
1. Select the **Cluster Agent** subsection.
|
||||
1. Configure your request values using the **CPU Reservation** and **Memory Reservation** fields as needed.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
If you prefer to configure via YAML, add the following snippet to your configuration file:
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE">
|
||||
|
||||
```yaml
|
||||
cluster_agent_deployment_customization:
|
||||
override_resource_requirements:
|
||||
requests:
|
||||
cpu: 50m
|
||||
memory: 100Mi
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE2/K3s">
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
clusterAgentDeploymentCustomization:
|
||||
@@ -69,9 +42,6 @@ spec:
|
||||
memory: 100Mi
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Scheduling rules
|
||||
|
||||
The `cattle-cluster-agent` uses either a fixed set of tolerations, or dynamically-added tolerations based on taints applied to the control plane nodes. This structure allows [Taint based Evictions](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-based-evictions) to work properly for `cattle-cluster-agent`.
|
||||
@@ -81,7 +51,6 @@ If control plane nodes are present in the cluster, the default tolerations will
|
||||
| Component | nodeAffinity nodeSelectorTerms | nodeSelector | Tolerations |
|
||||
| ---------------------- | ------------------------------------------ | ------------ | ------------------------------------------------------------------------------ |
|
||||
| `cattle-cluster-agent` | `beta.kubernetes.io/os:NotIn:windows` | none | **Note:** These are the default tolerations, and will be replaced by tolerations matching taints applied to controlplane nodes.<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/controlplane`<br/>`value:true`<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/control-plane`<br/>`operator:Exists`<br/><br/>`effect:NoSchedule`<br/>`key:node-role.kubernetes.io/master`<br/>`operator:Exists` |
|
||||
| `cattle-node-agent` | `beta.kubernetes.io/os:NotIn:windows` | none | `operator:Exists` |
|
||||
|
||||
The `cattle-cluster-agent` Deployment has preferred scheduling rules using `preferredDuringSchedulingIgnoredDuringExecution`, favoring to be scheduled on nodes with the `controlplane` node. When there are no controlplane nodes visible in the cluster (this is usually the case when using [Clusters from Hosted Kubernetes Providers](../kubernetes-clusters-in-rancher-setup/set-up-clusters-from-hosted-kubernetes-providers/set-up-clusters-from-hosted-kubernetes-providers.md)), you can add the label `cattle.io/cluster-agent=true` on a node to prefer scheduling the `cattle-cluster-agent` pod to that node.
|
||||
|
||||
|
||||
+1
-4
@@ -13,9 +13,6 @@ Rancher can provision nodes in AOS (AHV) and install Kubernetes on them. When cr
|
||||
|
||||
A Nutanix 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.
|
||||
|
||||
- [Creating a Nutanix Cluster](provision-kubernetes-clusters-in-aos.md#creating-a-nutanix-aos-cluster)
|
||||
- [Provisioning Storage](provision-kubernetes-clusters-in-aos.md)
|
||||
|
||||
## Creating a Nutanix Cluster
|
||||
|
||||
In [this section,](provision-kubernetes-clusters-in-aos.md) you'll learn how to use Rancher to install an [RKE2](https://docs.rke2.io/)/[K3s](https://docs.k3s.io/) Kubernetes cluster in Nutanix AOS.
|
||||
Refer to the [Provisioning Kubernetes Clusters in Nutanix AOS](provision-kubernetes-clusters-in-aos.md) to learn how to use Rancher to install an [RKE2](https://docs.rke2.io/)/[K3s](https://docs.k3s.io/) Kubernetes cluster in Nutanix AOS.
|
||||
+1
-88
@@ -6,91 +6,4 @@ title: Provisioning Kubernetes Clusters in Nutanix AOS
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/nutanix/provision-kubernetes-clusters-in-aos"/>
|
||||
</head>
|
||||
|
||||
To use Rancher to install an [RKE](https://rancher.com/docs/rke/latest/en/) Kubernetes cluster in Nutanix AOS (AHV):
|
||||
|
||||
1. Locate Rancher's built-in Nutanix [node driver and activate it](../../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#activatingdeactivating-node-drivers).
|
||||
|
||||
1. Create a node template, which Rancher will use to provision nodes in Nutanix AOS.
|
||||
|
||||
1. Create a Nutanix AOS cluster in Rancher. When configuring the new cluster, you will define node pools for it. Each node pool will have a Kubernetes role of etcd, controlplane, or worker. Rancher will install RKE Kubernetes on the new nodes, and it will set up each node with the Kubernetes role defined by the node pool.
|
||||
|
||||
For details on configuring the Nutanix AOS node template, refer to the [Nutanix AOS node template configuration reference.](../../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md)
|
||||
|
||||
For details on configuring RKE Kubernetes clusters in Rancher, refer to the cluster configuration reference.
|
||||
|
||||
- [Preparation in Nutanix AOS](#preparation-in-nutanix-aos)
|
||||
- [Creating a Nutanix AOS Cluster](#creating-a-nutanix-aos-cluster)
|
||||
|
||||
## Preparation in Nutanix AOS
|
||||
|
||||
The following sections describe the requirements for setting up Nutanix AOS so that Rancher can provision VMs and clusters.
|
||||
|
||||
:::note
|
||||
|
||||
The node templates are documented and tested with Nutanix AOS version 5.20.2 and 6.0.1.
|
||||
|
||||
:::
|
||||
|
||||
### Create Credentials in Nutanix AOS
|
||||
|
||||
Before proceeding to create a cluster, you must ensure that you have a [Nutanix Prism Central user account](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_0:wc-user-create-wc-t.html) with admin permissions. When you set up a node template, the template will need to use these credentials.
|
||||
|
||||
### Network Permissions
|
||||
|
||||
You must ensure that the hosts running the Rancher server are able to establish the following network connections:
|
||||
|
||||
- To the Nutanix Prism Central API (usually port 9440/TCP).
|
||||
- To port 22/TCP and 2376/TCP on the created VMs
|
||||
|
||||
See [Node Networking Requirements](../../../kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md#networking-requirements) for a detailed list of port requirements applicable for creating nodes on an infrastructure provider.
|
||||
|
||||
### VM-VM Anti-Affinity Policies
|
||||
|
||||
Setting up [VM-VM Anti-Affinity Policies](https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v6_1:ahv-vm-anti-affinity-t.html) is recommended. These rules allow VMs assigned the etcd and control-plane roles to operate on separate AHV 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 Nutanix AOS Cluster
|
||||
|
||||
1. [Create a node template ](#1-create-a-node-template)
|
||||
2. [Create a cluster with node pools using the node template](#2-create-a-cluster-with-node-pools-using-the-node-template)
|
||||
|
||||
### 1. Create a node template
|
||||
|
||||
Creating a [node template](../use-new-nodes-in-an-infra-provider.md#node-templates) for Nutanix AOS will allow Rancher to provision new nodes in Nutanix AOS. Node templates can be reused for other clusters.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Click **Create**.
|
||||
1. Click **Add Template**.
|
||||
1. Click **Nutanix**.
|
||||
1. Fill out a node template for Nutanix AOS. For help filling out the form, refer to the Nutanix AOS node template [configuration reference.](../../../../../reference-guides/cluster-configuration/downstream-cluster-configuration/node-template-configuration/nutanix.md).
|
||||
1. Click **Create**.
|
||||
|
||||
### 2. Create a cluster with node pools using the node template
|
||||
|
||||
Use Rancher to create a Kubernetes cluster in Nutanix AOS.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, click **Create**.
|
||||
1. Click **Nutanix**.
|
||||
1. Enter a **Cluster Name**, then click **Continue**.
|
||||
1. Use **Member Roles** to configure user authorization for the cluster. Click **Add Member** to add users who can access the cluster. Use the **Role** drop-down to set permissions for each user.
|
||||
1. Use **Cluster Options** to choose the version of Kubernetes that will be installed, what network provider will be used, and whether you want to enable project network isolation. To see more cluster options, click on **Show advanced options**. For help configuring the cluster, refer to the RKE cluster configuration reference.
|
||||
1. Add one or more node pools to your cluster. Each node pool uses a node template to provision new nodes. For more information about node pools, including best practices for assigning Kubernetes roles to the nodes, see [this section.](../use-new-nodes-in-an-infra-provider.md#node-pools)
|
||||
1. Review your options to confirm they're correct. Then click **Create**.
|
||||
|
||||
**Result:** Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
|
||||
|
||||
You can access your cluster after its state is updated to **Active**.
|
||||
|
||||
**Active** clusters are assigned two Projects:
|
||||
|
||||
- `Default`, containing the `default` namespace
|
||||
- `System`, containing the `cattle-system`, `traefik`, `kube-public`, and `kube-system` namespaces
|
||||
|
||||
## 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:
|
||||
|
||||
- **Access your cluster with the kubectl CLI:** Follow [these steps](../../../../new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#accessing-clusters-with-kubectl-from-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](../../../../new-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 Rancher. 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.
|
||||
To use Rancher to install an RKE2/K3s Kubernetes cluster in Nutanix AOS (AHV) refer to the [Nutanix documentation](https://portal.nutanix.com/page/documents/solutions/details?targetId=BP-2103-Rancher-SUSE-Nutanix:new-rke2-or-k3s-clusters-deployment.html).
|
||||
|
||||
+2
-124
@@ -6,130 +6,10 @@ title: Launching Kubernetes on New Nodes in an Infrastructure Provider
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider"/>
|
||||
</head>
|
||||
|
||||
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**.
|
||||
1. Click the name of the RKE or RKE2 cluster.
|
||||
|
||||
## RKE Clusters
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template](#node-templates). This node template defines the parameters you want to use to launch nodes in your infrastructure providers or cloud providers.
|
||||
|
||||
One benefit of installing Kubernetes on node pools hosted by an infrastructure provider is that if a node loses connectivity with the cluster, Rancher can automatically create another node to join the cluster to ensure that the count of the node pool is as expected.
|
||||
|
||||
The available cloud providers to create a node template are decided based on active [node drivers](#node-drivers).
|
||||
|
||||
### 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://github.com/docker/docs/blob/vnext-engine/machine/overview.md) to provision these nodes. The available cloud providers to create node templates are based on the active node drivers in Rancher.
|
||||
|
||||
After you create a node template in Rancher, it's saved so that you can use this template again to create node pools. Node templates are bound to your login. After you add a template, you can remove them from your user profile.
|
||||
|
||||
#### Node Labels
|
||||
|
||||
You can add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) on each node template, so that any nodes created from the node template will automatically have these labels on them.
|
||||
|
||||
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)
|
||||
|
||||
#### Node Taints
|
||||
|
||||
You can add [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on each node template, so that any nodes created from the node template will automatically have these taints on them.
|
||||
|
||||
Since taints can be added at a node template and node pool, if there is no conflict with the same key and effect of the taints, all taints will be added to the nodes. If there are taints with the same key and different effect, the taints from the node pool will override the taints from the node template.
|
||||
|
||||
#### Administrator Control of Node Templates
|
||||
|
||||
Administrators can control all node templates. Admins can now maintain all the node templates within Rancher. When a node template owner is no longer using Rancher, the node templates created by them can be managed by administrators so the cluster can continue to be updated and maintained.
|
||||
|
||||
To access all node templates, an administrator will need to do the following:
|
||||
When you [create an RKE2 cluster](../../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md#cluster-config-file-reference) using a machine config 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**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
|
||||
**Result:** All node templates are listed. The templates can be edited or cloned by clicking the **⋮**.
|
||||
|
||||
### Node Pools
|
||||
|
||||
Using Rancher, you can create pools of nodes based on a [node template](#node-templates).
|
||||
|
||||
A node template defines the configuration of a node, like what operating system to use, number of CPUs, and amount of memory.
|
||||
|
||||
The benefit of using a node pool is that if a node is destroyed or deleted, you can increase the number of live nodes to compensate for the node that was lost. The node pool helps you ensure that the count of the node pool is as expected.
|
||||
|
||||
Each node pool must have one or more nodes roles assigned.
|
||||
|
||||
Each node role (i.e. etcd, controlplane, and worker) should be assigned to a distinct node pool. Although it is possible to assign multiple node roles to a node pool, this should not be done for production clusters.
|
||||
|
||||
The recommended setup is to have:
|
||||
|
||||
- a node pool with the etcd node role and a count of three
|
||||
- a node pool with the controlplane node role and a count of at least two
|
||||
- a node pool with the worker node role and a count of at least two
|
||||
|
||||
**RKE1 downstream cluster nodes in an air-gapped environment:**
|
||||
|
||||
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.
|
||||
|
||||
<figcaption>**Engine Options Dropdown:**</figcaption>
|
||||
|
||||
|
||||
|
||||
#### Node Pool Taints
|
||||
|
||||
If you haven't defined [taints](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) on your node template, you can add taints for each node pool. The benefit of adding taints to a node pool is that you can change the node template without having to first ensure that the taint exists in the new template.
|
||||
|
||||
For each taint, they will automatically be added to any created node in the node pool. Therefore, if you add taints to a node pool that have existing nodes, the taints won't apply to existing nodes in the node pool, but any new node added into the node pool will get the taint.
|
||||
|
||||
When there are taints on the node pool and node template, if there is no conflict with the same key and effect of the taints, all taints will be added to the nodes. If there are taints with the same key and different effect, the taints from the node pool will override the taints from the node template.
|
||||
|
||||
#### About Node Auto-replace
|
||||
|
||||
If a node is in a node pool, Rancher can automatically replace unreachable nodes. Rancher will use the existing node template for the given node pool to recreate the node if it becomes inactive for a specified number of minutes.
|
||||
|
||||
:::caution
|
||||
|
||||
Self-healing node pools are designed to help you replace worker nodes for <b>stateless</b> applications. It is not recommended to enable node auto-replace on a node pool of master nodes or nodes with persistent volumes attached, because VMs are treated ephemerally. When a node in a node pool loses connectivity with the cluster, its persistent volumes are destroyed, resulting in data loss for stateful applications.
|
||||
|
||||
:::
|
||||
|
||||
Node auto-replace works on top of the Kubernetes node controller. The node controller periodically checks the status of all the nodes (configurable via the `--node-monitor-period` flag of the `kube-controller`). When a node is unreachable, the node controller will taint that node. When this occurs, Rancher will begin its deletion countdown. You can configure the amount of time Rancher waits to delete the node. If the taint is not removed before the deletion countdown ends, Rancher will proceed to delete the node object. Rancher will then provision a node in accordance with the set quantity of the node pool.
|
||||
|
||||
#### Enabling Node Auto-replace
|
||||
|
||||
When you create the node pool, you can specify the amount of time in minutes that Rancher will wait to replace an unresponsive node.
|
||||
|
||||
1. In the form for creating or editing a cluster, go to the **Node Pools** section.
|
||||
1. Go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter the number of minutes that Rancher should wait for a node to respond before replacing the node.
|
||||
1. Fill out the rest of the form for creating or editing the cluster.
|
||||
|
||||
**Result:** Node auto-replace is enabled for the node pool.
|
||||
|
||||
#### Disabling Node Auto-replace
|
||||
|
||||
You can disable node auto-replace from the Rancher UI with the following steps:
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to disable node auto-replace and click **⋮ > Edit Config**.
|
||||
1. In the **Node Pools** section, go to the node pool where you want to enable node auto-replace. In the **Recreate Unreachable After** field, enter 0.
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Node auto-replace is disabled for the node pool.
|
||||
|
||||
### Cloud Credentials
|
||||
|
||||
Node templates can use cloud credentials to store credentials for launching nodes in your cloud provider, which has some benefits:
|
||||
|
||||
- Credentials are stored as a Kubernetes secret, which is not only more secure, but it also allows you to edit a node template without having to enter your credentials every time.
|
||||
|
||||
- After the cloud credential is created, it can be re-used to create additional node templates.
|
||||
|
||||
- Multiple node templates can share the same cloud credential to create node pools. If your key is compromised or expired, the cloud credential can be updated in a single place, which allows all node templates that are using it to be updated at once.
|
||||
|
||||
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
|
||||
|
||||
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](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#activatingdeactivating-node-drivers), or you can [add your own custom node driver](../../authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md#adding-custom-node-drivers).
|
||||
1. Click the name of the RKE2 cluster.
|
||||
|
||||
## RKE2 Clusters
|
||||
|
||||
@@ -147,8 +27,6 @@ The RKE2 CLI exposes two roles, `server` and `agent`, which represent the Kubern
|
||||
|
||||
The same functionality of using `etcd`, `controlplane` and `worker` nodes is possible in the RKE2 CLI by using flags and node tainting to control where workloads and the Kubernetes master were scheduled. The reason those roles were not implemented as first-class roles in the RKE2 CLI is that RKE2 is conceptualized as a set of raw building blocks that are best leveraged through an orchestration system such as Rancher.
|
||||
|
||||
The implementation of the three node roles in Rancher means that Rancher managed RKE2 clusters are able to easily leverage all of the same architectural best practices that are recommended for RKE clusters.
|
||||
|
||||
In our [recommended cluster architecture](../../kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/recommended-cluster-architecture.md), we outline how many nodes of each role clusters should have:
|
||||
|
||||
- At least three nodes with the role etcd to survive losing one node
|
||||
|
||||
-15
@@ -25,21 +25,6 @@ After you download the kubeconfig file, you are able to use the kubeconfig file
|
||||
|
||||
If admins have [kubeconfig token generation turned off](../../../../api/api-tokens.md#disable-tokens-in-generated-kubeconfigs), the kubeconfig file requires that the [Rancher CLI](../../../../reference-guides/cli-with-rancher/rancher-cli.md) to be present in your PATH.
|
||||
|
||||
### Two Authentication Methods for RKE Clusters
|
||||
|
||||
If the cluster is not an [RKE cluster,](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) the kubeconfig file allows you to access the cluster in only one way: it lets you be authenticated with the Rancher server, then Rancher allows you to run kubectl commands on the cluster.
|
||||
|
||||
For RKE clusters, the kubeconfig file allows you to be authenticated in two ways:
|
||||
|
||||
- **Through the Rancher server authentication proxy:** Rancher's authentication proxy validates your identity, then connects you to the downstream cluster that you want to access.
|
||||
- **Directly with the downstream cluster's API server:** RKE clusters have an authorized cluster endpoint enabled by default. This endpoint allows you to access your downstream Kubernetes cluster with the kubectl CLI and a kubeconfig file, and it is enabled by default for RKE clusters. In this scenario, the downstream cluster's Kubernetes API server authenticates you by calling a webhook (the `kube-api-auth` microservice) that Rancher set up.
|
||||
|
||||
This second method, the capability to connect directly to the cluster's Kubernetes API server, is important because it lets you access your downstream cluster if you can't connect to Rancher.
|
||||
|
||||
To use the authorized cluster endpoint, you need to configure kubectl to use the extra kubectl context in the kubeconfig file that Rancher generates for you when the RKE cluster is created. This file can be downloaded from the cluster view in the Rancher UI, and the instructions for configuring kubectl are on [this page.](use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster)
|
||||
|
||||
These methods of communicating with downstream Kubernetes clusters are also explained in the [architecture page](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md) in the larger context of explaining how Rancher works and how Rancher communicates with downstream clusters.
|
||||
|
||||
### About the kube-api-auth Authentication Webhook
|
||||
|
||||
The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-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.
|
||||
|
||||
-3
@@ -64,9 +64,6 @@ In clusters that store data on GlusterFS volumes, you may experience an issue wh
|
||||
|
||||
In [Rancher Launched Kubernetes clusters](../../launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) that store data on iSCSI volumes, you may experience an issue where kubelets fail to automatically connect with iSCSI volumes. For details on resolving this issue, refer to [this page.](manage-persistent-storage/install-iscsi-volumes.md)
|
||||
|
||||
### hostPath Volumes
|
||||
Before you create a hostPath volume, you need to set up an [extra_bind](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/#extra-binds/) in your cluster configuration. This will mount the path as a volume in your kubelets, which can then be used for hostPath volumes in your workloads.
|
||||
|
||||
### Migrating VMware vSphere Cloud Provider from In-tree to Out-of-tree
|
||||
|
||||
Kubernetes is moving away from maintaining cloud providers in-tree. vSphere has an out-of-tree cloud provider that can be used by installing the vSphere cloud provider and cloud storage plugins.
|
||||
|
||||
+6
-12
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: Nodes and Node Pools
|
||||
title: Nodes and Machine Pools
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools"/>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools"/>
|
||||
</head>
|
||||
|
||||
After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab.
|
||||
After you launch a Kubernetes cluster in Rancher, you can manage individual nodes from the cluster's **Node** tab.
|
||||
|
||||
1. Click **☰** in the top left corner.
|
||||
1. Select **Cluster Management**.
|
||||
@@ -47,13 +47,7 @@ The following table lists which node options are available for each type of clus
|
||||
|
||||
### Nodes Hosted by an Infrastructure Provider
|
||||
|
||||
Node pools are available when you provision Rancher-launched Kubernetes clusters on nodes that are [hosted in an infrastructure provider.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)
|
||||
|
||||
Clusters provisioned using [one of the node pool options](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-pools) can be scaled up or down if the node pool is edited.
|
||||
|
||||
A node pool can also automatically maintain the node scale that's set during the initial cluster provisioning if [node auto-replace is enabled.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#about-node-auto-replace) This scale determines the number of active nodes that Rancher maintains for the cluster.
|
||||
|
||||
Rancher uses [node templates](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) to replace nodes in the node pool. Each node template uses cloud provider credentials to allow Rancher to set up the node in the infrastructure provider.
|
||||
Machine pools are available when you provision Rancher-launched Kubernetes clusters on nodes that are [hosted in an infrastructure provider.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md)
|
||||
|
||||
### Nodes Provisioned by Hosted Kubernetes Providers
|
||||
|
||||
@@ -82,7 +76,7 @@ Select this option to view the node's [API endpoints](../../../api/quickstart.md
|
||||
|
||||
Use **Delete** to remove defective nodes from the cloud provider.
|
||||
|
||||
When you the delete a defective node, Rancher can automatically replace it with an identically provisioned node if the node is in a node pool and [node auto-replace is enabled.](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#about-node-auto-replace)
|
||||
When you delete a defective node, Rancher can automatically replace it with an identically provisioned node if the node is in a machine pool and [auto-replace is enabled](../../../reference-guides/cluster-configuration/rancher-server-configuration/rke2-cluster-configuration.md#auto-replace).
|
||||
|
||||
:::tip
|
||||
|
||||
@@ -92,7 +86,7 @@ If your cluster is hosted by an infrastructure provider, and you want to scale y
|
||||
|
||||
## Scaling Nodes
|
||||
|
||||
For nodes hosted by an infrastructure provider, you can scale the number of nodes in each [node pool](../launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-pools) by using the scale controls. This option isn't available for other cluster types.
|
||||
For nodes hosted by an infrastructure provider, you can scale the number of nodes in each machine pool by using the scale controls. This option isn't available for other cluster types.
|
||||
|
||||
## SSH into a Node Hosted by an Infrastructure Provider
|
||||
|
||||
@@ -71,7 +71,7 @@ The following commands are available for use in Rancher CLI.
|
||||
| `login, [l]` | Logs into a Rancher Server. For an example, see [CLI Authentication](#cli-authentication). |
|
||||
| `machines, [machine]` | Performs operations on machines. |
|
||||
| `namespaces, [namespace]` | Performs operations on [namespaces](../../how-to-guides/new-user-guides/manage-namespaces.md). |
|
||||
| `nodes, [node]` | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-node-pools.md). |
|
||||
| `nodes, [node]` | Performs operations on [nodes](../../how-to-guides/new-user-guides/manage-clusters/nodes-and-machine-pools.md). |
|
||||
| `projects, [project]` | Performs operations on [projects](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md). |
|
||||
| `ps` | Displays [workloads](../../how-to-guides/new-user-guides/kubernetes-resources-setup/workloads-and-pods/workloads-and-pods.md) in a project. |
|
||||
| `server` | Performs operations for the server. |
|
||||
|
||||
+6
-6
@@ -8,7 +8,7 @@ title: 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.
|
||||
The below diagram shows how the cluster controllers, cluster agents, and Rancher system agent allow Rancher to control downstream clusters.
|
||||
|
||||
<figcaption>Communicating with Downstream Clusters</figcaption>
|
||||
|
||||
@@ -18,7 +18,7 @@ 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)
|
||||
3. [Rancher System Agent](#3-rancher-system-agent)
|
||||
4. [Authorized Cluster Endpoint](#4-authorized-cluster-endpoint)
|
||||
|
||||
## 1. The Authentication Proxy
|
||||
@@ -43,7 +43,7 @@ There is one cluster controller and one cluster agent for each downstream cluste
|
||||
- Configures access control policies to clusters and projects
|
||||
- Provisions clusters by calling the required Docker machine drivers and Kubernetes engines, such as 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.
|
||||
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 [Rancher system agent](#3-rancher-system-agent) instead.
|
||||
|
||||
The cluster agent, also called `cattle-cluster-agent`, is a component that runs in a downstream user cluster. It performs the following tasks:
|
||||
|
||||
@@ -52,11 +52,11 @@ The cluster agent, also called `cattle-cluster-agent`, is a component that runs
|
||||
- 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
|
||||
## 3. Rancher System Agent
|
||||
|
||||
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.
|
||||
If the cluster agent (also called `cattle-cluster-agent`) is not available, the Rancher system agent 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.
|
||||
The `rancher-system-agent` runs on every node in RKE2 and K3s Kubernetes clusters. 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
|
||||
|
||||
|
||||
+3
-16
@@ -6,16 +6,7 @@ title: Managing Cloud Credentials
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/user-settings/manage-cloud-credentials"/>
|
||||
</head>
|
||||
|
||||
When you create a cluster [hosted by an infrastructure provider](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md), [node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node.
|
||||
|
||||
Node templates can use cloud credentials to access the credential information required to provision nodes in the infrastructure providers. The same cloud credential can be used by multiple node templates. By using a cloud credential, you do not have to re-enter access keys for the same cloud provider. Cloud credentials are stored as Kubernetes secrets.
|
||||
|
||||
Cloud credentials are only used by node templates if there are fields marked as `password`. The default `active` node drivers have their account access fields marked as `password`, but there may be some `inactive` node drivers, which are not using them yet. These node drivers will not use cloud credentials.
|
||||
|
||||
You can create cloud credentials in two contexts:
|
||||
|
||||
- [During creation of a node template](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) for a cluster.
|
||||
- In the **User Settings**
|
||||
You can create cloud credentials in the **User Settings**.
|
||||
|
||||
Cloud credentials are bound to their creator's user profile. They **cannot** be shared between non-admin users. However, admins can view and manage the cloud credentials of other users.
|
||||
|
||||
@@ -29,23 +20,19 @@ Cloud credentials are bound to their creator's user profile. They **cannot** be
|
||||
1. Based on the selected cloud credential type, enter the required values to authenticate with the infrastructure provider.
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The cloud credential is created and can immediately be used to [create node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates).
|
||||
**Result:** The cloud credential is created.
|
||||
|
||||
## Updating a Cloud Credential
|
||||
|
||||
When access credentials are changed or compromised, updating a cloud credential allows you to rotate those credentials while keeping the same node template.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. Choose the cloud credential you want to edit and click the **⋮ > Edit Config**.
|
||||
1. Update the credential information and click **Save**.
|
||||
|
||||
**Result:** The cloud credential is updated with the new access credentials. All existing node templates using this cloud credential will automatically use the updated information whenever [new nodes are added](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
|
||||
**Result:** The cloud credential is updated with the new access credentials.
|
||||
|
||||
## Deleting a Cloud Credential
|
||||
|
||||
In order to delete cloud credentials, there must not be any node template associated with it. If you are unable to delete the cloud credential, [delete any node templates](manage-node-templates.md#deleting-a-node-template) that are still associated to that cloud credential.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **Cloud Credentials**.
|
||||
1. You can either individually delete a cloud credential or bulk delete.
|
||||
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: Managing Node Templates
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/user-settings/manage-node-templates"/>
|
||||
</head>
|
||||
|
||||
When you provision a cluster [hosted by an infrastructure provider](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md), [node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) are used to provision the cluster nodes. These templates use Docker Machine configuration options to define an operating system image and settings/parameters for the node. You can create node templates in two contexts:
|
||||
|
||||
- While [provisioning a node pool cluster](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
|
||||
- At any time, from your [user settings](user-settings.md).
|
||||
|
||||
When you create a node template, it is bound to your user profile. Node templates cannot be shared among users. You can delete stale node templates that you no longer user from your user settings.
|
||||
|
||||
## Creating a Node Template
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Click **Add Template**.
|
||||
1. Select one of the cloud providers available. Then follow the instructions on screen to configure the template.
|
||||
|
||||
**Result:** The template is configured. You can use the template later when you [provision a node pool cluster](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
|
||||
|
||||
## Updating a Node Template
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Choose the node template that you want to edit and click the **⋮ > Edit**.
|
||||
|
||||
:::note
|
||||
|
||||
The default `active` [node drivers](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/about-provisioning-drivers/manage-node-drivers.md) and any node driver, that has fields marked as `password`, are required to use [cloud credentials](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#cloud-credentials).
|
||||
|
||||
:::
|
||||
|
||||
1. Edit the required information and click **Save**.
|
||||
|
||||
**Result:** The node template is updated. All node pools using this node template will automatically use the updated information when new nodes are added.
|
||||
|
||||
## Cloning Node Templates
|
||||
|
||||
When creating new node templates from your user settings, you can clone an existing template and quickly update its settings rather than creating a new one from scratch. Cloning templates saves you the hassle of re-entering access keys for the cloud provider.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Find the template you want to clone. Then select **⋮ > Clone**.
|
||||
1. Complete the rest of the form.
|
||||
|
||||
**Result:** The template is cloned and configured. You can use the template later when you [provision a node pool cluster](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md).
|
||||
|
||||
## Deleting a Node Template
|
||||
|
||||
When you no longer use a node template, you can delete it from your user settings.
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Click **RKE1 Configuration > Node Templates**.
|
||||
1. Select one or more template from the list. Then click **Delete**. Confirm the delete when prompted.
|
||||
@@ -13,7 +13,6 @@ Within Rancher, each user has a number of settings associated with their login:
|
||||
The available user settings are:
|
||||
|
||||
- [API & Keys](api-keys.md): If you want to interact with Rancher programmatically, you need an API key. Follow the directions in this section to obtain a key.
|
||||
- [Cloud Credentials](manage-cloud-credentials.md): Manage cloud credentials [used by node templates](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/use-new-nodes-in-an-infra-provider/use-new-nodes-in-an-infra-provider.md#node-templates) to [provision nodes for clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
|
||||
- [Node Templates](manage-node-templates.md): Manage templates [used by Rancher to provision nodes for clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
|
||||
- [Cloud Credentials](manage-cloud-credentials.md): Manage cloud credentials used by machine pools to [provision nodes for clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md).
|
||||
- [Preferences](user-preferences.md): Sets superficial preferences for the Rancher UI.
|
||||
- Log Out: Ends your user session.
|
||||
|
||||
Reference in New Issue
Block a user