mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Merge branch 'main' into broken-links-4
This commit is contained in:
@@ -15,7 +15,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
|
||||
|
||||
- **Registered clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
|
||||
- **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../pages-for-subheaders/rancher-manager-architecture.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
|
||||
### What if I don't want Rancher anymore?
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, thi
|
||||
|
||||
### How are the supported Docker versions determined?
|
||||
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
|
||||
### How can I access nodes created by Rancher?
|
||||
|
||||
|
||||
+4
-4
@@ -178,7 +178,7 @@ tls-san:
|
||||
- loadbalancer-dns-domain.com
|
||||
```
|
||||
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha/).
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha).
|
||||
|
||||
:::note
|
||||
|
||||
@@ -208,7 +208,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration/)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
|
||||
### 3. Install RKE2
|
||||
|
||||
@@ -237,7 +237,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
``
|
||||
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap/).
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).
|
||||
|
||||
### 4. Save and Start Using the kubeconfig File
|
||||
|
||||
@@ -277,7 +277,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
|
||||
### Note on Upgrading
|
||||
|
||||
|
||||
+1
-1
@@ -85,7 +85,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
```
|
||||
|
||||
For more information on installing RKE2 see the [RKE2 installation docs](https://docs.rke2.io/install/).
|
||||
For more information on installing RKE2 see the [RKE2 documentation](https://docs.rke2.io).
|
||||
|
||||
To have a look at your cluster run:
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ For information about how Fleet works, see [this page.](../../../integrations-in
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
|
||||
|
||||
@@ -28,7 +28,7 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
|
||||
@@ -119,7 +119,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
|
||||
### 4. Check the Health of Your Cluster Pods
|
||||
|
||||
|
||||
+1
-1
@@ -31,7 +31,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl
|
||||
|
||||
### 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,](../../../../pages-for-subheaders/rancher-manager-architecture.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.
|
||||
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.
|
||||
|
||||
During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.
|
||||
|
||||
|
||||
+1
-1
@@ -47,7 +47,7 @@ Rancher will discover and show resources created by `kubectl`. However, these re
|
||||
|
||||
This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)
|
||||
|
||||
This method is only available for RKE, RKE2, and K3s clusters that have the [authorized cluster endpoint](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled. When Rancher creates the cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page](authorized-cluster-endpoint.md).
|
||||
This method is only available for RKE, RKE2, and K3s clusters that have the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled. When Rancher creates the cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page](authorized-cluster-endpoint.md).
|
||||
|
||||
On RKE2 and K3s clusters, you need to [manually enable](../../kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) authorized cluster endpoints.
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ You can update any clusters using a template from the **Apps > Installed Apps**
|
||||
- In order to show in the form for creating new clusters, the cluster template's Helm chart must have the `catalog.cattle.io/type:cluster-template` annotation.
|
||||
- In order to use a template as part of continuous delivery/GitOps, the cluster template needs to be deployed in the `fleet-local` namespace of the `local` cluster.
|
||||
- All values must be set in the `values.yaml` of the template.
|
||||
- Fleet repositories must follow the guidelines on [this page.](http://fleet.rancher.io/gitrepo-structure/) For RKE2 cluster templates, that means a `fleet.yaml` file must be added to the repository.
|
||||
- Fleet repositories must follow the guidelines on [this page.](http://fleet.rancher.io/gitrepo-structure) For RKE2 cluster templates, that means a `fleet.yaml` file must be added to the repository.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
@@ -45,4 +45,4 @@ To rotate keys in the Rancher UI:
|
||||

|
||||
|
||||
|
||||
>**Note:** For more information on RKE2 secrets encryption config, please see the [RKE2 docs](https://docs.rke2.io/security/secrets_encryption/).
|
||||
>**Note:** For more information on RKE2 secrets encryption config, please see the [RKE2 docs](https://docs.rke2.io/security/secrets_encryption).
|
||||
@@ -13,7 +13,7 @@ For information about how Fleet works, see [this page](../integrations-in-ranche
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continuous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continuous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
|
||||
|
||||
@@ -31,7 +31,7 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ Note that in Rancher v2.6.5, RKE2 provisioning became GA.
|
||||
|
||||
### Requirements
|
||||
|
||||
If you use RKE2 to set up a cluster, your nodes must meet the [requirements](https://docs.rke2.io/install/requirements/) for nodes in downstream user clusters.
|
||||
If you use RKE2 to set up a cluster, your nodes must meet the [requirements](https://docs.rke2.io/install/requirements) for nodes in downstream user clusters.
|
||||
|
||||
### Launching Kubernetes on New Nodes in an Infrastructure Provider
|
||||
|
||||
|
||||
+1
-1
@@ -106,7 +106,7 @@ Add additional hostnames or IPv4/IPv6 addresses as Subject Alternative Names on
|
||||
|
||||
Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
+1
-1
@@ -125,7 +125,7 @@ The authorized cluster endpoint only works on Rancher-launched Kubernetes cluste
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
+12
-12
@@ -104,11 +104,11 @@ Out of the box, Rancher is compatible with the following network providers:
|
||||
|
||||
\* When using [project network isolation](#project-network-isolation) in the [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium), it is possible to enable cross-node ingress routing. Click the [CNI provider docs](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium) to learn more.
|
||||
|
||||
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options/).
|
||||
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options).
|
||||
|
||||
##### Dual-stack Networking
|
||||
|
||||
[Dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
|
||||
[Dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
|
||||
|
||||
###### Additional Configuration {#dual-stack-additional-config}
|
||||
|
||||
@@ -140,13 +140,13 @@ Project network isolation is available if you are using any RKE2 network plugin
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/#coredns) for additional CoreDNS configurations.
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#coredns) for additional CoreDNS configurations.
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/#nginx-ingress-controller) for additional configuration options.
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking/#nginx-ingress-controller) for additional configuration options.
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
@@ -156,7 +156,7 @@ Each cloud provider capable of launching a cluster using RKE2 can collect metric
|
||||
|
||||
### Add-On Config
|
||||
|
||||
Additional Kubernetes manifests, managed as an [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts) for details.
|
||||
Additional Kubernetes manifests, managed as an [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm#automatically-deploying-manifests-and-helm-charts) for details.
|
||||
|
||||
### Agent Environment Vars
|
||||
|
||||
@@ -166,7 +166,7 @@ Option to set environment variables for [Rancher agents](https://rancher.com/doc
|
||||
|
||||
#### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore/#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
#### Metrics
|
||||
|
||||
@@ -180,7 +180,7 @@ IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
|
||||
|
||||
##### Dual-stack Networking
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium` or `multus,cilium` as your [container network](#container-network) interface provider.
|
||||
|
||||
@@ -190,7 +190,7 @@ IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
|
||||
|
||||
##### Dual-stack Networking
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network) interface provider.
|
||||
|
||||
@@ -216,13 +216,13 @@ Authorized Cluster Endpoint can be used to directly access the Kubernetes API se
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration/).
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
|
||||
### Upgrade Strategy
|
||||
|
||||
@@ -316,7 +316,7 @@ chartValues:
|
||||
```
|
||||
### machineGlobalConfig
|
||||
|
||||
The RKE2/K3s configurations are nested under the `machineGlobalConfig` directive. Any configuration change made here will apply to every node. The configuration options available in the [standalone version of RKE2](https://docs.rke2.io/install/install_options/server_config/) can be applied here.
|
||||
The RKE2/K3s configurations are nested under the `machineGlobalConfig` directive. Any configuration change made here will apply to every node. The configuration options available in the [standalone version of RKE2](https://docs.rke2.io/reference/server_config) can be applied here.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -99,7 +99,7 @@ For more best practices for downstream clusters, refer to the [production checkl
|
||||
|
||||
## Architecture for an Authorized Cluster Endpoint (ACE)
|
||||
|
||||
If you are using an [authorized cluster endpoint (ACE),](../../pages-for-subheaders/rancher-manager-architecture.md#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 an [authorized cluster endpoint (ACE),](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#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](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) and [API keys](../user-settings/api-keys.md#creating-an-api-key) for more information.
|
||||
|
||||
|
||||
@@ -6,6 +6,10 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2023-22648](https://github.com/rancher/rancher/security/advisories/GHSA-vf6j-6739-78m8) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, in which permission changes in Azure AD are not reflected to users until they logout and log back into the Rancher UI. | 31 May 2023 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2022-43760](https://github.com/rancher/rancher/security/advisories/GHSA-46v3-ggjg-qq3x) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI. | 31 May 2023 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2020-10676](https://github.com/rancher/rancher/security/advisories/GHSA-8vhc-hwhc-cpj4) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, in which users with update privileges on a namespace, can move that namespace into a project they don't have access to. | 31 May 2023 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2023-22647](https://github.com/rancher/rancher/security/advisories/GHSA-p976-h52c-26p6) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, where Standard users or above are able to elevate their permissions to Administrator in the local cluster. | 31 May 2023 | Rancher [v2.7.4](https://github.com/rancher/rancher/releases/tag/v2.7.4) |
|
||||
| [CVE-2023-22651](https://github.com/rancher/rancher/security/advisories/GHSA-6m9f-pj6w-w87g) | The Rancher admissions webhook may become misconfigured due to a failure in the webhook's update logic. The admissions webhook enforces validation rules and security checks before resources are admitted into the Kubernetes cluster. When the webhook is operating in a degraded state, it no longer validates any resources, which can result in severe privilege escalations and data corruption. | 24 April 2023 | Rancher [v2.7.3](https://github.com/rancher/rancher/releases/tag/v2.7.3) |
|
||||
| [CVE-2022-43758](https://github.com/rancher/rancher/security/advisories/GHSA-34p5-jp77-fcrc) | An issue was discovered in Rancher from versions 2.5.0 up to and including 2.5.16, 2.6.0 up to and including 2.6.9 and 2.7.0, where a command injection vulnerability is present in the Rancher Git package. This package uses the underlying Git binary available in the Rancher container image to execute Git operations. Specially crafted commands, when not properly disambiguated, can cause confusion when executed through Git, resulting in command injection in the underlying Rancher host. | 24 January 2023 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1), [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) and [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43757](https://github.com/rancher/rancher/security/advisories/GHSA-cq4p-vp5q-4522) | This issue affects Rancher versions from 2.5.0 up to and including 2.5.16, from 2.6.0 up to and including 2.6.9 and 2.7.0. It was discovered that the security advisory [CVE-2021-36782](https://github.com/advisories/GHSA-g7j7-h4q8-8w2f), previously released by Rancher, missed addressing some sensitive fields, secret tokens, encryption keys, and SSH keys that were still being stored in plaintext directly on Kubernetes objects like `Clusters`. The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners` and `Project Members` of that cluster. | 24 January 2023 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1), [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) and [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
|
||||
@@ -6,4 +6,4 @@ title: About rke2-selinux
|
||||
|
||||
The `rke2-selinux` GitHub repository is [here.](https://github.com/rancher/rke2-selinux)
|
||||
|
||||
For more information about installing RKE2 on SELinux-enabled hosts, see the [RKE2 documentation.](https://docs.rke2.io/install/methods/#rpm)
|
||||
For more information about installing RKE2 on SELinux-enabled hosts, see the [RKE2 documentation.](https://docs.rke2.io/install/methods#rpm)
|
||||
@@ -33,7 +33,7 @@ Users may opt to enable [token hashing](../about-the-api/api-tokens.md).
|
||||
|
||||
Expiration period will be bound by `v3/settings/auth-token-max-ttl-minutes`. If it exceeds the max-ttl, API key will be created with max-ttl as the expiration period.
|
||||
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) for more information.
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information.
|
||||
|
||||
4. Click **Create**.
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ ClusterIP 是一个虚拟 IP,不会响应 ping。要测试 ClusterIP 是否配
|
||||
|
||||
### 支持的 Docker 版本是如何确定的?
|
||||
|
||||
我们遵循上游 Kubernetes 版本验证过的 Docker 版本。如果需要获取验证过的版本,请查看 Kubernetes 版本 CHANGELOG.md 中的 [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies)。
|
||||
我们遵循上游 Kubernetes 版本验证过的 Docker 版本。如果需要获取验证过的版本,请查看 Kubernetes 版本 CHANGELOG.md 中的 [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies)。
|
||||
|
||||
### 如何访问 Rancher 创建的节点?
|
||||
|
||||
|
||||
+4
-4
@@ -175,7 +175,7 @@ tls-san:
|
||||
- loadbalancer-dns-domain.com
|
||||
```
|
||||
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/ha/)。
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/ha)。
|
||||
|
||||
:::note
|
||||
|
||||
@@ -205,7 +205,7 @@ configs:
|
||||
ca_file: <镜像仓库所用的 CA 文件路径>
|
||||
```
|
||||
|
||||
有关 RKE2 的私有镜像仓库配置文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/install/containerd_registry_configuration/)。
|
||||
有关 RKE2 的私有镜像仓库配置文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/install/containerd_registry_configuration)。
|
||||
|
||||
### 3. 安装 RKE2
|
||||
|
||||
@@ -234,7 +234,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
``
|
||||
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/airgap/)。
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/airgap)。
|
||||
|
||||
### 4. 保存并开始使用 kubeconfig 文件
|
||||
|
||||
@@ -274,7 +274,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access/)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
|
||||
### 升级注意事项
|
||||
|
||||
|
||||
+1
-1
@@ -77,7 +77,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
```
|
||||
|
||||
有关安装 RKE2 的更多信息,请参阅 [RKE2 安装文档](https://docs.rke2.io/install/)。
|
||||
有关安装 RKE2 的更多信息,请参阅 [RKE2 安装文档](https://docs.rke2.io)。
|
||||
|
||||
如需查看集群,请运行以下命令:
|
||||
|
||||
|
||||
+2
-2
@@ -13,7 +13,7 @@ Fleet 是一个独立于 Rancher 的项目,你可以使用 Helm 将它安装
|
||||
|
||||
## 在 Rancher UI 中访问 Fleet
|
||||
|
||||
Fleet 预装在 Rancher 中,通过 Rancher UI 中的**持续交付**选项管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting/)。
|
||||
Fleet 预装在 Rancher 中,通过 Rancher UI 中的**持续交付**选项管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting)。
|
||||
|
||||
用户可以通过遵循 **gitops** 的实践,利用持续交付将应用部署到 git 仓库中的 Kubernetes 集群,而无需任何手动操作。
|
||||
|
||||
@@ -28,7 +28,7 @@ Fleet 预装在 Rancher 中,通过 Rancher UI 中的**持续交付**选项管
|
||||
|
||||
1. 单击左侧导航栏上的 **Git 仓库**将 git 仓库部署到当前工作空间中的集群中。
|
||||
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add/)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
|
||||
1. 部署 git 仓库后,你可以通过 Rancher UI 监控应用。
|
||||
|
||||
|
||||
+1
-1
@@ -119,7 +119,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access/)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
|
||||
### 4. 检查集群 Pod 的健康状况
|
||||
|
||||
|
||||
+1
-1
@@ -84,7 +84,7 @@ RKE2 集群模板的示例仓库在[这里](https://github.com/rancher/cluster-t
|
||||
- 为了以创建新集群的形式显示,集群模板的 Helm Chart 必须具有 `catalog.cattle.io/type:cluster-template` 注释。
|
||||
- 为了将模板用作持续交付/GitOps 的一部分,集群模板需要部署在`本地`集群的 `fleet-local` 命名空间中。
|
||||
- 所有值都必须在模板的 `values.yaml` 中设置。
|
||||
- Fleet 仓库必须遵循此处的[准则](http://fleet.rancher.io/gitrepo-structure/)。对于 RKE2 集群模板,则必须把 `fleet.yaml` 文件添加到仓库。
|
||||
- Fleet 仓库必须遵循此处的[准则](http://fleet.rancher.io/gitrepo-structure)。对于 RKE2 集群模板,则必须把 `fleet.yaml` 文件添加到仓库。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -45,4 +45,4 @@ _**v2.6.7 新功能**_
|
||||

|
||||
|
||||
|
||||
> **注意**:有关 RKE2 密文加密配置的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/security/secrets_encryption/)。
|
||||
> **注意**:有关 RKE2 密文加密配置的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/security/secrets_encryption)。
|
||||
+2
-2
@@ -13,7 +13,7 @@ Fleet 是一个独立于 Rancher 的项目,你可以使用 Helm 将它安装
|
||||
|
||||
## 在 Rancher UI 中访问 Fleet
|
||||
|
||||
Fleet 预装在 Rancher 中,可以通过 Rancher UI 中的**持续交付**选项进行管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting/)。
|
||||
Fleet 预装在 Rancher 中,可以通过 Rancher UI 中的**持续交付**选项进行管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting)。
|
||||
|
||||
用户可以通过遵循 **gitops** 的实践,利用持续交付将应用部署到 git 仓库中的 Kubernetes 集群,而无需任何手动操作。
|
||||
|
||||
@@ -31,7 +31,7 @@ Fleet 预装在 Rancher 中,可以通过 Rancher UI 中的**持续交付**选
|
||||
|
||||
1. 单击左侧导航栏上的 **Git 仓库**将 git 仓库部署到当前工作空间中的集群中。
|
||||
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add/)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets/)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
|
||||
1. 部署 git 仓库后,你可以通过 Rancher UI 监控应用。
|
||||
|
||||
|
||||
+1
-1
@@ -46,7 +46,7 @@ Rancher 2.6 支持直接使用 Rancher UI 配置 [RKE2](https://docs.rke2.io/)
|
||||
|
||||
### 要求
|
||||
|
||||
如果你使用 RKE2 建立集群,节点必须满足下游集群的[节点要求](https://docs.rke2.io/install/requirements/)。
|
||||
如果你使用 RKE2 建立集群,节点必须满足下游集群的[节点要求](https://docs.rke2.io/install/requirements)。
|
||||
|
||||
### 在云厂商的新节点上启动 Kubernetes
|
||||
|
||||
|
||||
+11
-11
@@ -104,11 +104,11 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
\* 在 [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium) 中使用[项目网络隔离](#项目网络隔离)时,你可以开启跨节点入口路由。详情请参见 [CNI 提供商文档](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium)。
|
||||
|
||||
有关不同网络提供商以及如何配置它们的更多详细信息,请查阅 [RKE2 文档](https://docs.rke2.io/install/network_options/)。
|
||||
有关不同网络提供商以及如何配置它们的更多详细信息,请查阅 [RKE2 文档](https://docs.rke2.io/install/network_options)。
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
所有 CNI 网络插件都支持[双栈](https://docs.rke2.io/install/network_options/#dual-stack-configuration)网络。要在双栈模式下配置 RKE2,请为你的[集群 CIDR](#集群-cidr) 和/或 [Service CIDR](#service-cidr) 设置有效的 IPv4/IPv6 CIDR。
|
||||
所有 CNI 网络插件都支持[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)网络。要在双栈模式下配置 RKE2,请为你的[集群 CIDR](#集群-cidr) 和/或 [Service CIDR](#service-cidr) 设置有效的 IPv4/IPv6 CIDR。
|
||||
|
||||
###### 额外配置 {#dual-stack-additional-config}
|
||||
|
||||
@@ -140,13 +140,13 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下,[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS,则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置,请参阅 [RKE2 文档](https://docs.rke2.io/networking/#coredns)。
|
||||
默认情况下,[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS,则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置,请参阅 [RKE2 文档](https://docs.rke2.io/networking#coredns)。
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用,并且你使用没有原生负载均衡功能的云提供商来托管主机,请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking/#nginx-ingress-controller)。
|
||||
如果你想使用高可用性配置来发布应用,并且你使用没有原生负载均衡功能的云提供商来托管主机,请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
|
||||
有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking/#nginx-ingress-controller)。
|
||||
有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
@@ -156,7 +156,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
### 附加配置
|
||||
|
||||
集群启动时将应用的其他 Kubernetes 清单,会作为[附加组件](https://kubernetes.io/docs/concepts/cluster-administration/addons/)来管理。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts)。
|
||||
集群启动时将应用的其他 Kubernetes 清单,会作为[附加组件](https://kubernetes.io/docs/concepts/cluster-administration/addons/)来管理。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/helm#automatically-deploying-manifests-and-helm-charts)。
|
||||
|
||||
### Agent 环境变量
|
||||
|
||||
@@ -166,7 +166,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
#### 自动快照
|
||||
|
||||
启用或禁用定期 etcd 快照的选项。如果启用,用户可以配置快照的频率。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/backup_restore/#creating-snapshots)。请注意,如果使用 RKE2,快照会存储在每个 etcd 节点上,这与 RKE1 不同(RKE1 每个集群只存储一个快照)。
|
||||
启用或禁用定期 etcd 快照的选项。如果启用,用户可以配置快照的频率。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/backup_restore#creating-snapshots)。请注意,如果使用 RKE2,快照会存储在每个 etcd 节点上,这与 RKE1 不同(RKE1 每个集群只存储一个快照)。
|
||||
|
||||
#### 指标
|
||||
|
||||
@@ -180,7 +180,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options/#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
|
||||
使用 `cilium` 或 `multus,cilium` 作为[容器网络](#容器网络)接口提供商时,你需要进行[附加配置](#dual-stack-additional-config)。
|
||||
|
||||
@@ -190,7 +190,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options/#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
|
||||
使用 `cilium` 或 `multus,cilium` 作为[容器网络](#容器网络)接口提供商时,你需要进行[附加配置](#dual-stack-additional-config)。
|
||||
|
||||
@@ -222,7 +222,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
### 镜像仓库
|
||||
|
||||
选择要从中拉取 Rancher 镜像的镜像仓库。有关更多详细信息和配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/install/containerd_registry_configuration/)。
|
||||
选择要从中拉取 Rancher 镜像的镜像仓库。有关更多详细信息和配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/install/containerd_registry_configuration)。
|
||||
|
||||
### 升级策略
|
||||
|
||||
@@ -316,7 +316,7 @@ chartValues:
|
||||
```
|
||||
### machineGlobalConfig
|
||||
|
||||
RKE2/K3s 配置嵌套在 `machineGlobalConfig` 参数下。在这里所做的任何配置更改都将应用到每个节点。你可以在此处应用[RKE2 的独立版本](https://docs.rke2.io/install/install_options/server_config/)中可用的配置选项。
|
||||
RKE2/K3s 配置嵌套在 `machineGlobalConfig` 参数下。在这里所做的任何配置更改都将应用到每个节点。你可以在此处应用[RKE2 的独立版本](https://docs.rke2.io/reference/server_config)中可用的配置选项。
|
||||
|
||||
示例:
|
||||
|
||||
|
||||
+1
-1
@@ -6,4 +6,4 @@ title: 关于 rke2-selinux
|
||||
|
||||
`rke2-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rke2-selinux)。
|
||||
|
||||
有关在启用 SELinux 的主机上安装 RKE2 的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/methods/#rpm)。
|
||||
有关在启用 SELinux 的主机上安装 RKE2 的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/methods#rpm)。
|
||||
@@ -60,7 +60,7 @@ ClusterIP 是一个虚拟 IP,不会响应 ping。要测试 ClusterIP 是否配
|
||||
|
||||
### 支持的 Docker 版本是如何确定的?
|
||||
|
||||
我们遵循上游 Kubernetes 版本验证过的 Docker 版本。如果需要获取验证过的版本,请查看 Kubernetes 版本 CHANGELOG.md 中的 [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies)。
|
||||
我们遵循上游 Kubernetes 版本验证过的 Docker 版本。如果需要获取验证过的版本,请查看 Kubernetes 版本 CHANGELOG.md 中的 [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies)。
|
||||
|
||||
### 如何访问 Rancher 创建的节点?
|
||||
|
||||
|
||||
+4
-4
@@ -175,7 +175,7 @@ tls-san:
|
||||
- loadbalancer-dns-domain.com
|
||||
```
|
||||
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/ha/)。
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/ha)。
|
||||
|
||||
:::note
|
||||
|
||||
@@ -205,7 +205,7 @@ configs:
|
||||
ca_file: <镜像仓库所用的 CA 文件路径>
|
||||
```
|
||||
|
||||
有关 RKE2 的私有镜像仓库配置文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/install/containerd_registry_configuration/)。
|
||||
有关 RKE2 的私有镜像仓库配置文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/install/containerd_registry_configuration)。
|
||||
|
||||
### 3. 安装 RKE2
|
||||
|
||||
@@ -234,7 +234,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
``
|
||||
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/airgap/)。
|
||||
有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/airgap)。
|
||||
|
||||
### 4. 保存并开始使用 kubeconfig 文件
|
||||
|
||||
@@ -274,7 +274,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access/)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
|
||||
### 升级注意事项
|
||||
|
||||
|
||||
+3
-3
@@ -2,7 +2,7 @@
|
||||
title: 使用 Feet 进行持续交付
|
||||
---
|
||||
|
||||
使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。Fleet 非常轻量,可以很好地用于[单个集群](https://fleet.rancher.io/single-cluster-install/),但是在你达到[大规模](https://fleet.rancher.io/multi-cluster-install/)时,它能发挥更强的实力。此处的大规模指的是大量集群、大量部署、或组织中存在大量团队的情况。
|
||||
使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。Fleet 非常轻量,可以很好地用于[单个集群](https://fleet.rancher.io/single-cluster-install),但是在你达到[大规模](https://fleet.rancher.io/multi-cluster-install)时,它能发挥更强的实力。此处的大规模指的是大量集群、大量部署、或组织中存在大量团队的情况。
|
||||
|
||||
Fleet 是一个独立于 Rancher 的项目,你可以使用 Helm 将它安装在任何 Kubernetes 集群上。
|
||||
|
||||
@@ -13,7 +13,7 @@ Fleet 是一个独立于 Rancher 的项目,你可以使用 Helm 将它安装
|
||||
|
||||
## 在 Rancher UI 中访问 Fleet
|
||||
|
||||
Fleet 预装在 Rancher 中,通过 Rancher UI 中的**持续交付**选项管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting/)。
|
||||
Fleet 预装在 Rancher 中,通过 Rancher UI 中的**持续交付**选项管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting)。
|
||||
|
||||
用户可以通过遵循 **gitops** 的实践,利用持续交付将应用部署到 git 仓库中的 Kubernetes 集群,而无需任何手动操作。
|
||||
|
||||
@@ -28,7 +28,7 @@ Fleet 预装在 Rancher 中,通过 Rancher UI 中的**持续交付**选项管
|
||||
|
||||
1. 单击左侧导航栏上的 **Git 仓库**将 git 仓库部署到当前工作空间中的集群中。
|
||||
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add/)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
|
||||
1. 部署 git 仓库后,你可以通过 Rancher UI 监控应用。
|
||||
|
||||
|
||||
+1
-1
@@ -119,7 +119,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access/)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
有关 `kubeconfig` 文件的详情,请参见 [RKE2 官方文档](https://docs.rke2.io/cluster_access)或 [ Kubernetes 官方文档](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/)中关于使用 `kubeconfig` 文件管理集群访问的部分。
|
||||
|
||||
### 4. 检查集群 Pod 的健康状况
|
||||
|
||||
|
||||
+1
-1
@@ -108,7 +108,7 @@ RKE2 集群模板的示例仓库在[这里](https://github.com/rancher/cluster-t
|
||||
- 为了以创建新集群的形式显示,集群模板的 Helm Chart 必须具有 `catalog.cattle.io/type:cluster-template` 注释。
|
||||
- 为了将模板用作持续交付/GitOps 的一部分,集群模板需要部署在`本地`集群的 `fleet-local` 命名空间中。
|
||||
- 所有值都必须在模板的 `values.yaml` 中设置。
|
||||
- Fleet 仓库必须遵循此处的[准则](http://fleet.rancher.io/gitrepo-structure/)。对于 RKE2 集群模板,则必须把 `fleet.yaml` 文件添加到仓库。
|
||||
- Fleet 仓库必须遵循此处的[准则](http://fleet.rancher.io/gitrepo-structure)。对于 RKE2 集群模板,则必须把 `fleet.yaml` 文件添加到仓库。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -45,4 +45,4 @@ _**v2.6.7 新功能**_
|
||||

|
||||
|
||||
|
||||
> **注意**:有关 RKE2 密文加密配置的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/security/secrets_encryption/)。
|
||||
> **注意**:有关 RKE2 密文加密配置的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/security/secrets_encryption)。
|
||||
+3
-3
@@ -2,7 +2,7 @@
|
||||
title: 使用 Feet 进行持续交付
|
||||
---
|
||||
|
||||
使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。此外,它非常轻量,因此也非常适用于[单个集群](https://fleet.rancher.io/single-cluster-install/)。但是,它在[大规模](https://fleet.rancher.io/multi-cluster-install/)场景下的功能更加强大。大规模指的是大量集群、大量部署或大量团队。
|
||||
使用 Fleet 的持续交付是大规模的 GitOps。你可以使用 Fleet 管理多达一百万个集群。此外,它非常轻量,因此也非常适用于[单个集群](https://fleet.rancher.io/single-cluster-install)。但是,它在[大规模](https://fleet.rancher.io/multi-cluster-install)场景下的功能更加强大。大规模指的是大量集群、大量部署或大量团队。
|
||||
|
||||
Fleet 是一个独立于 Rancher 的项目,你可以使用 Helm 将它安装在任何 Kubernetes 集群上。
|
||||
|
||||
@@ -13,7 +13,7 @@ Fleet 是一个独立于 Rancher 的项目,你可以使用 Helm 将它安装
|
||||
|
||||
## 在 Rancher UI 中访问 Fleet
|
||||
|
||||
Fleet 预装在 Rancher 中,可以通过 Rancher UI 中的**持续交付**选项进行管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting/)。
|
||||
Fleet 预装在 Rancher 中,可以通过 Rancher UI 中的**持续交付**选项进行管理。有关持续交付和 Fleet 故障排除技巧的更多信息,请参阅[此处](https://fleet.rancher.io/troubleshooting)。
|
||||
|
||||
用户可以通过遵循 **gitops** 的实践,利用持续交付将应用部署到 git 仓库中的 Kubernetes 集群,而无需任何手动操作。
|
||||
|
||||
@@ -31,7 +31,7 @@ Fleet 预装在 Rancher 中,可以通过 Rancher UI 中的**持续交付**选
|
||||
|
||||
1. 单击左侧导航栏上的 **Git 仓库**将 git 仓库部署到当前工作空间中的集群中。
|
||||
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add/)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
1. 选择你的 [git 仓库](https://fleet.rancher.io/gitrepo-add)和[目标集群/集群组](https://fleet.rancher.io/gitrepo-targets)。你还可以单击左侧导航栏中的**集群组**在 UI 中创建集群组。
|
||||
|
||||
1. 部署 git 仓库后,你可以通过 Rancher UI 监控应用。
|
||||
|
||||
|
||||
+1
-1
@@ -46,7 +46,7 @@ Rancher 2.6 支持直接使用 Rancher UI 配置 [RKE2](https://docs.rke2.io/)
|
||||
|
||||
### 要求
|
||||
|
||||
如果你使用 RKE2 建立集群,节点必须满足下游集群的[节点要求](https://docs.rke2.io/install/requirements/)。
|
||||
如果你使用 RKE2 建立集群,节点必须满足下游集群的[节点要求](https://docs.rke2.io/install/requirements)。
|
||||
|
||||
### 在云厂商的新节点上启动 Kubernetes
|
||||
|
||||
|
||||
+11
-11
@@ -104,11 +104,11 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
\* 在 [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium) 中使用[项目网络隔离](#项目网络隔离)时,你可以开启跨节点入口路由。详情请参见 [CNI 提供商文档](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium)。
|
||||
|
||||
有关不同网络提供商以及如何配置它们的更多详细信息,请查阅 [RKE2 文档](https://docs.rke2.io/install/network_options/)。
|
||||
有关不同网络提供商以及如何配置它们的更多详细信息,请查阅 [RKE2 文档](https://docs.rke2.io/install/network_options)。
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
所有 CNI 网络插件都支持[双栈](https://docs.rke2.io/install/network_options/#dual-stack-configuration)网络。要在双栈模式下配置 RKE2,请为你的[集群 CIDR](#集群-cidr) 和/或 [Service CIDR](#service-cidr) 设置有效的 IPv4/IPv6 CIDR。
|
||||
所有 CNI 网络插件都支持[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)网络。要在双栈模式下配置 RKE2,请为你的[集群 CIDR](#集群-cidr) 和/或 [Service CIDR](#service-cidr) 设置有效的 IPv4/IPv6 CIDR。
|
||||
|
||||
###### 额外配置 {#dual-stack-additional-config}
|
||||
|
||||
@@ -140,13 +140,13 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
默认情况下,[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS,则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置,请参阅 [RKE2 文档](https://docs.rke2.io/networking/#coredns)。
|
||||
默认情况下,[CoreDNS](https://coredns.io/) 会安装为默认 DNS 提供程序。如果未安装 CoreDNS,则必须自己安装备用 DNS 提供程序。有关其他 CoreDNS 配置,请参阅 [RKE2 文档](https://docs.rke2.io/networking#coredns)。
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
如果你想使用高可用性配置来发布应用,并且你使用没有原生负载均衡功能的云提供商来托管主机,请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking/#nginx-ingress-controller)。
|
||||
如果你想使用高可用性配置来发布应用,并且你使用没有原生负载均衡功能的云提供商来托管主机,请启用此选项以在集群中使用 NGINX Ingress。有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
|
||||
有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking/#nginx-ingress-controller)。
|
||||
有关其他配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/networking#nginx-ingress-controller)。
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
@@ -156,7 +156,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
### 附加配置
|
||||
|
||||
集群启动时将应用的其他 Kubernetes 清单,会作为[附加组件](https://kubernetes.io/docs/concepts/cluster-administration/addons/)来管理。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts)。
|
||||
集群启动时将应用的其他 Kubernetes 清单,会作为[附加组件](https://kubernetes.io/docs/concepts/cluster-administration/addons/)来管理。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/helm#automatically-deploying-manifests-and-helm-charts)。
|
||||
|
||||
### Agent 环境变量
|
||||
|
||||
@@ -166,7 +166,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
#### 自动快照
|
||||
|
||||
启用或禁用定期 etcd 快照的选项。如果启用,用户可以配置快照的频率。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/backup_restore/#creating-snapshots)。请注意,如果使用 RKE2,快照会存储在每个 etcd 节点上,这与 RKE1 不同(RKE1 每个集群只存储一个快照)。
|
||||
启用或禁用定期 etcd 快照的选项。如果启用,用户可以配置快照的频率。有关详细信息,请参阅 [RKE2 文档](https://docs.rke2.io/backup_restore#creating-snapshots)。请注意,如果使用 RKE2,快照会存储在每个 etcd 节点上,这与 RKE1 不同(RKE1 每个集群只存储一个快照)。
|
||||
|
||||
#### 指标
|
||||
|
||||
@@ -180,7 +180,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options/#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
|
||||
使用 `cilium` 或 `multus,cilium` 作为[容器网络](#容器网络)接口提供商时,你需要进行[附加配置](#dual-stack-additional-config)。
|
||||
|
||||
@@ -190,7 +190,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
##### 双栈网络
|
||||
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options/#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
要配置[双栈](https://docs.rke2.io/install/network_options#dual-stack-configuration)模式,请输入有效的 IPv4/IPv6 CIDR。例如 `10.42.0.0/16,2001:cafe:42:0::/56`。
|
||||
|
||||
使用 `cilium` 或 `multus,cilium` 作为[容器网络](#容器网络)接口提供商时,你需要进行[附加配置](#dual-stack-additional-config)。
|
||||
|
||||
@@ -222,7 +222,7 @@ Rancher 与以下开箱即用的网络提供商兼容:
|
||||
|
||||
### 镜像仓库
|
||||
|
||||
选择要从中拉取 Rancher 镜像的镜像仓库。有关更多详细信息和配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/install/containerd_registry_configuration/)。
|
||||
选择要从中拉取 Rancher 镜像的镜像仓库。有关更多详细信息和配置选项,请参阅 [RKE2 文档](https://docs.rke2.io/install/containerd_registry_configuration)。
|
||||
|
||||
### 升级策略
|
||||
|
||||
@@ -316,7 +316,7 @@ chartValues:
|
||||
```
|
||||
### machineGlobalConfig
|
||||
|
||||
RKE2/K3s 配置嵌套在 `machineGlobalConfig` 参数下。在这里所做的任何配置更改都将应用到每个节点。你可以在此处应用[RKE2 的独立版本](https://docs.rke2.io/install/install_options/server_config/)中可用的配置选项。
|
||||
RKE2/K3s 配置嵌套在 `machineGlobalConfig` 参数下。在这里所做的任何配置更改都将应用到每个节点。你可以在此处应用[RKE2 的独立版本](https://docs.rke2.io/reference/server_config)中可用的配置选项。
|
||||
|
||||
示例:
|
||||
|
||||
|
||||
+1
-1
@@ -6,4 +6,4 @@ title: 关于 rke2-selinux
|
||||
|
||||
`rke2-selinux` 的 GitHub 仓库在[这里](https://github.com/rancher/rke2-selinux)。
|
||||
|
||||
有关在启用 SELinux 的主机上安装 RKE2 的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/methods/#rpm)。
|
||||
有关在启用 SELinux 的主机上安装 RKE2 的更多信息,请参阅 [RKE2 文档](https://docs.rke2.io/install/methods#rpm)。
|
||||
@@ -15,7 +15,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
|
||||
|
||||
- **Imported clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was imported into Rancher.
|
||||
- **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../pages-for-subheaders/rancher-manager-architecture.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
|
||||
### What if I don't want Rancher anymore?
|
||||
|
||||
|
||||
@@ -83,7 +83,7 @@ The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, thi
|
||||
|
||||
### How are the supported Docker versions determined?
|
||||
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
|
||||
### How can I access nodes created by Rancher?
|
||||
|
||||
|
||||
@@ -45,6 +45,6 @@ As of CLI [v2.4.10](https://github.com/ranchquick-start-guide/cli/releases/tag/v
|
||||
|
||||
_**Current Known Issues**_
|
||||
|
||||
1. If [authorized cluster endpoint](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) is enabled for RKE clusters to [authenticate directly with downstream cluster](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) and Rancher server goes down, all kubectl calls will fail after the kubeconfig token expires. No new kubeconfig tokens can be generated if Rancher server isn't accessible.
|
||||
1. If [authorized cluster endpoint](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) is enabled for RKE clusters to [authenticate directly with downstream cluster](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) and Rancher server goes down, all kubectl calls will fail after the kubeconfig token expires. No new kubeconfig tokens can be generated if Rancher server isn't accessible.
|
||||
2. If a kubeconfig token is deleted from Rancher [API tokens](../../reference-guides/about-the-api/api-tokens.md#deleting-tokens) page, and the token is still cached, cli won't ask you to login again until the token expires or is deleted.
|
||||
`kubectl` calls will result into an error like `error: You must be logged in to the server (the server has asked for the client to provide credentials`. Tokens can be deleted using `rancher token delete`.
|
||||
|
||||
+1
-1
@@ -34,7 +34,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl
|
||||
|
||||
### 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,](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 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.
|
||||
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) which is only available for [RKE clusters.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 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.
|
||||
|
||||
During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.
|
||||
|
||||
|
||||
+1
-1
@@ -43,7 +43,7 @@ Rancher will discover and show resources created by `kubectl`. However, these re
|
||||
|
||||
This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)
|
||||
|
||||
This method is only available for RKE clusters that have the [authorized cluster endpoint](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled. When Rancher creates this RKE cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page.](authorized-cluster-endpoint.md)
|
||||
This method is only available for RKE clusters that have the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled. When Rancher creates this RKE cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page.](authorized-cluster-endpoint.md)
|
||||
|
||||
We recommend that as a best practice, you should set up this method to access your RKE cluster, so that just in case you can’t connect to Rancher, you can still access the cluster.
|
||||
|
||||
|
||||
+1
-1
@@ -91,7 +91,7 @@ Authorized Cluster Endpoint can be used to directly access the Kubernetes API se
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
+1
-1
@@ -109,6 +109,6 @@ For more best practices for downstream clusters, refer to the [production checkl
|
||||
|
||||
## Architecture for an Authorized Cluster Endpoint
|
||||
|
||||
If you are using an [authorized cluster endpoint,](../../pages-for-subheaders/rancher-manager-architecture.md#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 an [authorized cluster endpoint,](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#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](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) and [API keys](../user-settings/api-keys.md#creating-an-api-key) for more information.
|
||||
@@ -28,7 +28,7 @@ API Keys are composed of four components:
|
||||
_Available as of v2.4.6_
|
||||
Expiration period will be bound by `v3/settings/auth-token-max-ttl-minutes`. If it exceeds the max-ttl, API key will be created with max-ttl as the expiration period.
|
||||
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) for more information.
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information.
|
||||
|
||||
4. Click **Create**.
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ Authorized Cluster Endpoint can be used to directly access the Kubernetes API se
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../../reference-guides/rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
|
||||
|
||||
- **Registered clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
|
||||
- **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
|
||||
- **RKE clusters:** Please note that you will no longer be able to manage the individual Kubernetes components or perform any upgrades on them after the deletion of the Rancher server. However, you can still access the cluster to manage your workloads. To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../pages-for-subheaders/rancher-manager-architecture.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
- **RKE clusters:** Please note that you will no longer be able to manage the individual Kubernetes components or perform any upgrades on them after the deletion of the Rancher server. However, you can still access the cluster to manage your workloads. To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
|
||||
### What if I don't want Rancher anymore?
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, thi
|
||||
|
||||
### How are the supported Docker versions determined?
|
||||
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
|
||||
### How can I access nodes created by Rancher?
|
||||
|
||||
|
||||
+1
-1
@@ -32,7 +32,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl
|
||||
|
||||
### 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,](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 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.
|
||||
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) which is only available for [RKE clusters.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 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.
|
||||
|
||||
During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.
|
||||
|
||||
|
||||
+1
-1
@@ -42,7 +42,7 @@ Rancher will discover and show resources created by `kubectl`. However, these re
|
||||
|
||||
This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)
|
||||
|
||||
This method is only available for RKE clusters that have the [authorized cluster endpoint](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled. When Rancher creates this RKE cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page.](authorized-cluster-endpoint.md)
|
||||
This method is only available for RKE clusters that have the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled. When Rancher creates this RKE cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page.](authorized-cluster-endpoint.md)
|
||||
|
||||
We recommend that as a best practice, you should set up this method to access your RKE cluster, so that just in case you can’t connect to Rancher, you can still access the cluster.
|
||||
|
||||
|
||||
+2
-2
@@ -15,7 +15,7 @@ For information about how Fleet works, see [this page.](../../../explanations/in
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher v2.5. Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).
|
||||
Fleet comes preinstalled in Rancher v2.5. Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
@@ -30,7 +30,7 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
|
||||
+1
-1
@@ -119,7 +119,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
|
||||
### 4. Check the Health of Your Cluster Pods
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ For information about how Fleet works, see [this page](../explanations/integrati
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher v2.5. Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).
|
||||
Fleet comes preinstalled in Rancher v2.5. Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
@@ -33,7 +33,7 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
|
||||
+1
-1
@@ -99,6 +99,6 @@ For more best practices for downstream clusters, refer to the [production checkl
|
||||
|
||||
## Architecture for an Authorized Cluster Endpoint
|
||||
|
||||
If you are using an [authorized cluster endpoint,](../../pages-for-subheaders/rancher-manager-architecture.md#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 an [authorized cluster endpoint,](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#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](../../how-to-guides/advanced-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) and [API keys](../user-settings/api-keys.md#creating-an-api-key) for more information.
|
||||
|
||||
+1
-1
@@ -6,4 +6,4 @@ title: About rke2-selinux
|
||||
|
||||
The `rke2-selinux` GitHub repository is [here.](https://github.com/rancher/rke2-selinux)
|
||||
|
||||
For more information about installing RKE2 on SELinux-enabled hosts, see the [RKE2 documentation.](https://docs.rke2.io/install/methods/#rpm)
|
||||
For more information about installing RKE2 on SELinux-enabled hosts, see the [RKE2 documentation.](https://docs.rke2.io/install/methods#rpm)
|
||||
@@ -27,7 +27,7 @@ API Keys are composed of four components:
|
||||
|
||||
Expiration period will be bound by `v3/settings/auth-token-max-ttl-minutes`. If it exceeds the max-ttl, API key will be created with max-ttl as the expiration period.
|
||||
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) for more information.
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information.
|
||||
|
||||
4. Click **Create**.
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ The capability to access a downstream cluster without Rancher depends on the typ
|
||||
|
||||
- **Registered clusters:** The cluster will be unaffected and you can access the cluster using the same methods that you did before the cluster was registered into Rancher.
|
||||
- **Hosted Kubernetes clusters:** If you created the cluster in a cloud-hosted Kubernetes provider such as EKS, GKE, or AKS, you can continue to manage the cluster using your provider's cloud credentials.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../pages-for-subheaders/rancher-manager-architecture.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
- **RKE clusters:** To access an [RKE cluster,](../pages-for-subheaders/launch-kubernetes-with-rancher.md) the cluster must have the [authorized cluster endpoint](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled, and you must have already downloaded the cluster's kubeconfig file from the Rancher UI. (The authorized cluster endpoint is enabled by default for RKE clusters.) With this endpoint, you can access your cluster with kubectl directly instead of communicating through the Rancher server's [authentication proxy.](../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#1-the-authentication-proxy) For instructions on how to configure kubectl to use the authorized cluster endpoint, refer to the section about directly accessing clusters with [kubectl and the kubeconfig file.](../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md#authenticating-directly-with-a-downstream-cluster) These clusters will use a snapshot of the authentication as it was configured when Rancher was removed.
|
||||
|
||||
### What if I don't want Rancher anymore?
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, thi
|
||||
|
||||
### How are the supported Docker versions determined?
|
||||
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
We follow the validated Docker versions for upstream Kubernetes releases. The validated versions can be found under [External Dependencies](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
|
||||
### How can I access nodes created by Rancher?
|
||||
|
||||
|
||||
+4
-4
@@ -178,7 +178,7 @@ tls-san:
|
||||
- loadbalancer-dns-domain.com
|
||||
```
|
||||
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha/).
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/ha).
|
||||
|
||||
:::note
|
||||
|
||||
@@ -208,7 +208,7 @@ configs:
|
||||
ca_file: <path to the ca file used in the registry>
|
||||
```
|
||||
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration/)
|
||||
For more information on private registries configuration file for RKE2, refer to the [RKE2 documentation.](https://docs.rke2.io/install/containerd_registry_configuration)
|
||||
|
||||
### 3. Install RKE2
|
||||
|
||||
@@ -237,7 +237,7 @@ systemctl enable rke2-server.service
|
||||
systemctl start rke2-server.service
|
||||
``
|
||||
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap/).
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).
|
||||
|
||||
### 4. Save and Start Using the kubeconfig File
|
||||
|
||||
@@ -277,7 +277,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
|
||||
### Note on Upgrading
|
||||
|
||||
|
||||
+2
-2
@@ -13,7 +13,7 @@ For information about how Fleet works, see [this page.](../../../integrations-in
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
|
||||
|
||||
@@ -28,7 +28,7 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
|
||||
+1
-1
@@ -119,7 +119,7 @@ users:
|
||||
kubectl --kubeconfig ~/.kube/config/rke2.yaml get pods --all-namespaces
|
||||
```
|
||||
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access/) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
For more information about the `kubeconfig` file, refer to the [RKE2 documentation](https://docs.rke2.io/cluster_access) or the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) about organizing cluster access using `kubeconfig` files.
|
||||
|
||||
### 4. Check the Health of Your Cluster Pods
|
||||
|
||||
|
||||
+1
-1
@@ -31,7 +31,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl
|
||||
|
||||
### 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,](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 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.
|
||||
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) which is only available for [RKE clusters.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md) 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.
|
||||
|
||||
During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.
|
||||
|
||||
|
||||
+1
-1
@@ -47,7 +47,7 @@ Rancher will discover and show resources created by `kubectl`. However, these re
|
||||
|
||||
This section intended to help you set up an alternative method to access an [RKE cluster.](../../../../pages-for-subheaders/launch-kubernetes-with-rancher.md)
|
||||
|
||||
This method is only available for RKE, RKE2, and K3s clusters that have the [authorized cluster endpoint](../../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) enabled. When Rancher creates the cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page](authorized-cluster-endpoint.md).
|
||||
This method is only available for RKE, RKE2, and K3s clusters that have the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) enabled. When Rancher creates the cluster, it generates a kubeconfig file that includes additional kubectl context(s) for accessing your cluster. This additional context allows you to use kubectl to authenticate with the downstream cluster without authenticating through Rancher. For a longer explanation of how the authorized cluster endpoint works, refer to [this page](authorized-cluster-endpoint.md).
|
||||
|
||||
On RKE2 and K3s clusters, you need to [manually enable](../../kubernetes-clusters-in-rancher-setup/register-existing-clusters.md#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) authorized cluster endpoints.
|
||||
|
||||
|
||||
+1
-1
@@ -108,7 +108,7 @@ You can update any clusters using a template from the **Apps & Marketplace > Ins
|
||||
- In order to show in the form for creating new clusters, the cluster template's Helm chart must have the `catalog.cattle.io/type:cluster-template` annotation.
|
||||
- In order to use a template as part of continuous delivery/GitOps, the cluster template needs to be deployed in the `fleet-local` namespace of the `local` cluster.
|
||||
- All values must be set in the `values.yaml` of the template.
|
||||
- Fleet repositories must follow the guidelines on [this page.](http://fleet.rancher.io/gitrepo-structure/) For RKE2 cluster templates, that means a `fleet.yaml` file must be added to the repository.
|
||||
- Fleet repositories must follow the guidelines on [this page.](http://fleet.rancher.io/gitrepo-structure) For RKE2 cluster templates, that means a `fleet.yaml` file must be added to the repository.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
+1
-1
@@ -45,4 +45,4 @@ To rotate keys in the Rancher UI:
|
||||

|
||||
|
||||
|
||||
>**Note:** For more information on RKE2 secrets encryption config, please see the [RKE2 docs](https://docs.rke2.io/security/secrets_encryption/).
|
||||
>**Note:** For more information on RKE2 secrets encryption config, please see the [RKE2 docs](https://docs.rke2.io/security/secrets_encryption).
|
||||
@@ -13,7 +13,7 @@ For information about how Fleet works, see [this page](../integrations-in-ranche
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continuous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting/).
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continuous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
|
||||
|
||||
@@ -31,7 +31,7 @@ Follow the steps below to access Continuous Delivery in the Rancher UI:
|
||||
|
||||
1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace.
|
||||
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
1. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ Note that in Rancher v2.6.5, RKE2 provisioning became GA.
|
||||
|
||||
### Requirements
|
||||
|
||||
If you use RKE2 to set up a cluster, your nodes must meet the [requirements](https://docs.rke2.io/install/requirements/) for nodes in downstream user clusters.
|
||||
If you use RKE2 to set up a cluster, your nodes must meet the [requirements](https://docs.rke2.io/install/requirements) for nodes in downstream user clusters.
|
||||
|
||||
### Launching Kubernetes on New Nodes in an Infrastructure Provider
|
||||
|
||||
|
||||
+1
-1
@@ -106,7 +106,7 @@ Add additional hostnames or IPv4/IPv6 addresses as Subject Alternative Names on
|
||||
|
||||
Authorized Cluster Endpoint can be used to directly access the Kubernetes API server, without requiring communication through Rancher.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
+1
-1
@@ -125,7 +125,7 @@ The authorized cluster endpoint only works on Rancher-launched Kubernetes cluste
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
|
||||
+12
-12
@@ -104,11 +104,11 @@ Out of the box, Rancher is compatible with the following network providers:
|
||||
|
||||
\* When using [project network isolation](#project-network-isolation) in the [Cilium CNI](../../../faq/container-network-interface-providers.md#cilium), it is possible to enable cross-node ingress routing. Click the [CNI provider docs](../../../faq/container-network-interface-providers.md#ingress-routing-across-nodes-in-cilium) to learn more.
|
||||
|
||||
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options/).
|
||||
For more details on the different networking providers and how to configure them, please view our [RKE2 documentation](https://docs.rke2.io/install/network_options).
|
||||
|
||||
##### Dual-stack Networking
|
||||
|
||||
[Dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
|
||||
[Dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) networking is supported for all CNI providers. To configure RKE2 in dual-stack mode, set valid IPv4/IPv6 CIDRs for your [Cluster CIDR](#cluster-cidr) and/or [Service CIDR](#service-cidr).
|
||||
|
||||
###### Additional Configuration {#dual-stack-additional-config}
|
||||
|
||||
@@ -140,13 +140,13 @@ Project network isolation is available if you are using any RKE2 network plugin
|
||||
|
||||
#### CoreDNS
|
||||
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/#coredns) for additional CoreDNS configurations.
|
||||
By default, [CoreDNS](https://coredns.io/) is installed as the default DNS provider. If CoreDNS is not installed, an alternate DNS provider must be installed yourself. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#coredns) for additional CoreDNS configurations.
|
||||
|
||||
#### NGINX Ingress
|
||||
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking/#nginx-ingress-controller) for additional configuration options.
|
||||
If you want to publish your applications in a high-availability configuration, and you're hosting your nodes with a cloud-provider that doesn't have a native load-balancing feature, enable this option to use NGINX Ingress within the cluster. Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking/#nginx-ingress-controller) for additional configuration options.
|
||||
Refer to the [RKE2 documentation](https://docs.rke2.io/networking#nginx-ingress-controller) for additional configuration options.
|
||||
|
||||
#### Metrics Server
|
||||
|
||||
@@ -156,7 +156,7 @@ Each cloud provider capable of launching a cluster using RKE2 can collect metric
|
||||
|
||||
### Add-On Config
|
||||
|
||||
Additional Kubernetes manifests, managed as an [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm/#automatically-deploying-manifests-and-helm-charts) for details.
|
||||
Additional Kubernetes manifests, managed as an [Add-on](https://kubernetes.io/docs/concepts/cluster-administration/addons/), to apply to the cluster on startup. Refer to the [RKE2 documentation](https://docs.rke2.io/helm#automatically-deploying-manifests-and-helm-charts) for details.
|
||||
|
||||
### Agent Environment Vars
|
||||
|
||||
@@ -166,7 +166,7 @@ Option to set environment variables for [Rancher agents](https://rancher.com/doc
|
||||
|
||||
#### Automatic Snapshots
|
||||
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore/#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
Option to enable or disable recurring etcd snapshots. If enabled, users have the option to configure the frequency of snapshots. For details, refer to the [RKE2 documentation](https://docs.rke2.io/backup_restore#creating-snapshots). Note that with RKE2, snapshots are stored on each etcd node. This varies from RKE1 which only stores one snapshot per cluster.
|
||||
|
||||
#### Metrics
|
||||
|
||||
@@ -180,7 +180,7 @@ IPv4 and/or IPv6 network CIDRs to use for pod IPs (default: 10.42.0.0/16).
|
||||
|
||||
##### Dual-stack Networking
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium` or `multus,cilium` as your [container network](#container-network) interface provider.
|
||||
|
||||
@@ -190,7 +190,7 @@ IPv4/IPv6 network CIDRs to use for service IPs (default: 10.43.0.0/16).
|
||||
|
||||
##### Dual-stack Networking
|
||||
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options/#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
To configure [dual-stack](https://docs.rke2.io/install/network_options#dual-stack-configuration) mode, enter a valid IPv4/IPv6 CIDR. For example `10.42.0.0/16,2001:cafe:42:0::/56`.
|
||||
|
||||
[Additional configuration](#dual-stack-additional-config) is required when using `cilium ` or `multus,cilium` as your [container network](#container-network) interface provider.
|
||||
|
||||
@@ -216,13 +216,13 @@ Authorized Cluster Endpoint can be used to directly access the Kubernetes API se
|
||||
|
||||
This is enabled by default in Rancher-launched Kubernetes clusters, using the IP of the node with the `controlplane` role and the default Kubernetes self signed certificates.
|
||||
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint)
|
||||
For more detail on how an authorized cluster endpoint works and why it is used, refer to the [architecture section.](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint)
|
||||
|
||||
We recommend using a load balancer with the authorized cluster endpoint. For details, refer to the [recommended architecture section.](../../rancher-manager-architecture/architecture-recommendations.md#architecture-for-an-authorized-cluster-endpoint)
|
||||
|
||||
### Registries
|
||||
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration/).
|
||||
Select the image repository to pull Rancher images from. For more details and configuration options, see the [RKE2 documentation](https://docs.rke2.io/install/containerd_registry_configuration).
|
||||
|
||||
### Upgrade Strategy
|
||||
|
||||
@@ -316,7 +316,7 @@ chartValues:
|
||||
```
|
||||
### machineGlobalConfig
|
||||
|
||||
The RKE2/K3s configurations are nested under the `machineGlobalConfig` directive. Any configuration change made here will apply to every node. The configuration options available in the [standalone version of RKE2](https://docs.rke2.io/install/install_options/server_config/) can be applied here.
|
||||
The RKE2/K3s configurations are nested under the `machineGlobalConfig` directive. Any configuration change made here will apply to every node. The configuration options available in the [standalone version of RKE2](https://docs.rke2.io/reference/server_config) can be applied here.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
+1
-1
@@ -99,7 +99,7 @@ For more best practices for downstream clusters, refer to the [production checkl
|
||||
|
||||
## Architecture for an Authorized Cluster Endpoint (ACE)
|
||||
|
||||
If you are using an [authorized cluster endpoint (ACE),](../../pages-for-subheaders/rancher-manager-architecture.md#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 an [authorized cluster endpoint (ACE),](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#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](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) and [API keys](../user-settings/api-keys.md#creating-an-api-key) for more information.
|
||||
|
||||
|
||||
+4
@@ -6,6 +6,10 @@ Rancher is committed to informing the community of security issues in our produc
|
||||
|
||||
| ID | Description | Date | Resolution |
|
||||
|----|-------------|------|------------|
|
||||
| [CVE-2023-22648](https://github.com/rancher/rancher/security/advisories/GHSA-vf6j-6739-78m8) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, in which permission changes in Azure AD are not reflected to users until they logout and log back into the Rancher UI. | 31 May 2023 | Rancher [v2.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [CVE-2022-43760](https://github.com/rancher/rancher/security/advisories/GHSA-46v3-ggjg-qq3x) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, where multiple Cross-Site Scripting (XSS) vulnerabilities can be exploited via the Rancher UI. | 31 May 2023 | Rancher [v2.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [CVE-2020-10676](https://github.com/rancher/rancher/security/advisories/GHSA-8vhc-hwhc-cpj4) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, in which users with update privileges on a namespace, can move that namespace into a project they don't have access to. | 31 May 2023 | Rancher [v2.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [CVE-2023-22647](https://github.com/rancher/rancher/security/advisories/GHSA-p976-h52c-26p6) | An issue was discovered in Rancher versions up to and including 2.6.12 and 2.7.3, where Standard users or above are able to elevate their permissions to Administrator in the local cluster. | 31 May 2023 | Rancher [v2.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) |
|
||||
| [CVE-2022-43759](https://github.com/rancher/rancher/security/advisories/GHSA-7m72-mh5r-6j3r) | An issue was discovered in Rancher versions from 2.5.0 up to and including 2.5.16 and from 2.6.0 up to and including 2.6.9, where an authorization logic flaw allows privilege escalation via project role template binding (PRTB) and `-promoted` roles. | 24 January 2023 | Rancher [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) and [v2.5.17]( https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43758](https://github.com/rancher/rancher/security/advisories/GHSA-34p5-jp77-fcrc) | An issue was discovered in Rancher from versions 2.5.0 up to and including 2.5.16, 2.6.0 up to and including 2.6.9 and 2.7.0, where a command injection vulnerability is present in the Rancher Git package. This package uses the underlying Git binary available in the Rancher container image to execute Git operations. Specially crafted commands, when not properly disambiguated, can cause confusion when executed through Git, resulting in command injection in the underlying Rancher host. | 24 January 2023 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1), [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) and [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
| [CVE-2022-43757](https://github.com/rancher/rancher/security/advisories/GHSA-cq4p-vp5q-4522) | This issue affects Rancher versions from 2.5.0 up to and including 2.5.16, from 2.6.0 up to and including 2.6.9 and 2.7.0. It was discovered that the security advisory [CVE-2021-36782](https://github.com/advisories/GHSA-g7j7-h4q8-8w2f), previously released by Rancher, missed addressing some sensitive fields, secret tokens, encryption keys, and SSH keys that were still being stored in plaintext directly on Kubernetes objects like `Clusters`. The exposed credentials are visible in Rancher to authenticated `Cluster Owners`, `Cluster Members`, `Project Owners` and `Project Members` of that cluster. | 24 January 2023 | Rancher [v2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1), [v2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) and [v2.5.17](https://github.com/rancher/rancher/releases/tag/v2.5.17) |
|
||||
|
||||
+1
-1
@@ -6,4 +6,4 @@ title: About rke2-selinux
|
||||
|
||||
The `rke2-selinux` GitHub repository is [here.](https://github.com/rancher/rke2-selinux)
|
||||
|
||||
For more information about installing RKE2 on SELinux-enabled hosts, see the [RKE2 documentation.](https://docs.rke2.io/install/methods/#rpm)
|
||||
For more information about installing RKE2 on SELinux-enabled hosts, see the [RKE2 documentation.](https://docs.rke2.io/install/methods#rpm)
|
||||
@@ -33,7 +33,7 @@ Users may opt to enable [token hashing](../about-the-api/api-tokens.md).
|
||||
|
||||
Expiration period will be bound by `v3/settings/auth-token-max-ttl-minutes`. If it exceeds the max-ttl, API key will be created with max-ttl as the expiration period.
|
||||
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../pages-for-subheaders/rancher-manager-architecture.md#4-authorized-cluster-endpoint) for more information.
|
||||
A scope will limit the API key so that it will only work against the Kubernetes API of the specified cluster. If the cluster is configured with an Authorized Cluster Endpoint, you will be able to use a scoped token directly against the cluster's API without proxying through the Rancher server. See [Authorized Cluster Endpoints](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information.
|
||||
|
||||
4. Click **Create**.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user