Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP]Modifying registered clusters documentation #3936

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions content/rancher/v2.5/en/cluster-provisioning/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@ This section covers the following topics:

<!-- TOC -->

- [User Personas associated with a Kubernetes installation](#user-personas-associated-with-a-kubernetes-installation)
- [Cluster Management Capabilities by Cluster Type](#cluster-management-capabilities-by-cluster-type)
- [Setting up clusters in a hosted Kubernetes provider](#setting-up-clusters-in-a-hosted-kubernetes-provider)
- [Launching Kubernetes with Rancher](#launching-kubernetes-with-rancher)
Expand All @@ -28,6 +29,14 @@ This section covers the following topics:

<!-- /TOC -->

### User Personas associated with a Kubernetes installation

Before we dive deep into the specifics of cluster management capabilities, it is essential to take a step back and understand the various personas associated with a Kubernetes installation based on the type of interaction.

The first persona is that of the administrator. With a focus on managing the overall health of the Kubernetes installation, typical administrative workloads may also include performing configuration and setup tasks.

Developer personas are end users of Kubernetes installations. By defining application resources and using core primitives to build, monitor, and troubleshoot scalable applications and tools, their workloads are typically aimed at exposing cloud native applications by using Kubernetes.

### Cluster Management Capabilities by Cluster Type

The following table summarizes the options and settings available for each cluster type:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ aliases:
- /rancher/v2.x/en/cluster-provisioning/registered-clusters/
---

The cluster registration feature replaced the feature to import clusters.
Along with importing clusters, as of v2.5, Rancher allows you to tie in closer with cloud APIs and manage your cluster by registering existing clusters.

The control that Rancher has to manage a registered cluster depends on the type of cluster. For details, see [Management Capabilities for Registered Clusters.](#management-capabilities-for-registered-clusters)

Expand Down Expand Up @@ -121,7 +121,7 @@ $ curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s -

### Configuring an Imported EKS Cluster with Terraform

You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.
You should define **only** the minimum fields that Rancher requires when importing an EKS cluster with Terraform. This is important as Rancher will overwrite what was in the EKS cluster with any config that the user has provided.

>**Warning:** Even a small difference between the current EKS cluster and a user-provided config could have unexpected results.

Expand Down Expand Up @@ -256,7 +256,7 @@ Also in the K3s documentation, nodes with the worker role are called agent nodes

# Debug Logging and Troubleshooting for Registered K3s Clusters

Nodes are upgraded by the system upgrade controller running in the downstream cluster. Based on the cluster configuration, Rancher deploys two [plans](https://github.com/rancher/system-upgrade-controller#example-upgrade-plan) to upgrade K3s nodes: one for controlplane nodes and one for workers. The system upgrade controller follows the plans and upgrades the nodes.
Nodes are upgraded by the system upgrade controller running in the downstream cluster. Based on the cluster configuration, Rancher deploys two [plans](https://github.com/rancher/system-upgrade-controller#example-upgrade-plan) to upgrade K3s nodes: one for controlplane nodes and one for workers. The system upgrade controller follows the plans and upgrades the nodes.

To enable debug logging on the system upgrade controller deployment, edit the [configmap](https://github.com/rancher/system-upgrade-controller/blob/50a4c8975543d75f1d76a8290001d87dc298bdb4/manifests/system-upgrade-controller.yaml#L32) to set the debug environment variable to true. Then restart the `system-upgrade-controller` pod.

Expand Down Expand Up @@ -326,4 +326,3 @@ To annotate a registered cluster,
1. Click **Save.**

**Result:** The annotation does not give the capabilities to the cluster, but it does indicate to Rancher that the cluster has those capabilities.

9 changes: 9 additions & 0 deletions content/rancher/v2.6/en/cluster-provisioning/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@ This section covers the following topics:

<!-- TOC -->

- [User Personas associated with a Kubernetes installation](#user-personas-associated-with-a-kubernetes-installation)
- [Cluster Management Capabilities by Cluster Type](#cluster-management-capabilities-by-cluster-type)
- [Setting up clusters in a hosted Kubernetes provider](#setting-up-clusters-in-a-hosted-kubernetes-provider)
- [Launching Kubernetes with Rancher](#launching-kubernetes-with-rancher)
Expand All @@ -24,6 +25,14 @@ This section covers the following topics:

<!-- /TOC -->

### User Personas associated with a Kubernetes installation

Before we dive deep into the specifics of cluster management capabilities, it is essential to take a step back and understand the various personas associated with a Kubernetes installation based on the type of interaction.

The first persona is that of the administrator. With a focus on managing the overall health of the Kubernetes installation, typical administrative workloads may also include performing configuration and setup tasks.

Developer personas are end users of Kubernetes installations. By defining application resources and using core primitives to build, monitor, and troubleshoot scalable applications and tools, their workloads are typically aimed at exposing cloud native applications by using Kubernetes.

### Cluster Management Capabilities by Cluster Type

The following table summarizes the options and settings available for each cluster type:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: Registering Existing Clusters
weight: 6
---

The cluster registration feature replaced the feature to import clusters.
Along with importing clusters, as of v2.5, Rancher allows you to tie in closer with cloud APIs and manage your cluster by registering existing clusters.

The control that Rancher has to manage a registered cluster depends on the type of cluster. For details, see [Management Capabilities for Registered Clusters.](#management-capabilities-for-registered-clusters)

Expand Down