mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Fix order of headings (#1465)
* Fix 'title out of sequence' errors fixed Dockershim.md * fixed deprecated-features.md * fixed install-and-configure-kubectl.md * fixed rancher-is-no-longer-needed.md * fixed security.md * fixed technical-items.md + spacing, duplicate section, admonitions * fixed telemetry.md * fixed upgrades.md * fixed upgrade-kubernetes-without-upgrading-rancher.md * fixed air-gapped-upgrades.md * fixed dockershim.md * fixed docker-install-commands.md * fixed install-kubernetes.md * fixed infrastructure-private-registry.md * fixed install-rancher-ha * fixed manage-namespaces and tune-etcd-for-large-installs.md * fixed cis-scans/configuration-reference.md * fixed custom-benchmark.md * fixed supportconfig.md * fixed harvester/overview.md * fixed logging-architecture.md * fixed logging-helm-chart-options.md + rm'd unnecessary annotation title * fixed taints-and-tolerances.md * fixed longhorn/overview.md * fixed neuvector/overview.md * fixed monitoring-and-alerting * fixed rancher-cli.md * fixed cluster-configuration.md * fixed monitoring-v2-configuration/examples.md * fixed servicemonitors-and-podmonitors.md * fixed other-troubleshooting-tips/dns.md
This commit is contained in:
@@ -6,11 +6,11 @@ title: Deprecated Features in Rancher
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
|
||||
</head>
|
||||
|
||||
### What is Rancher's deprecation policy?
|
||||
## What is Rancher's deprecation policy?
|
||||
|
||||
We have published our official deprecation policy in the support [terms of service](https://rancher.com/support-maintenance-terms).
|
||||
|
||||
### Where can I find out which features have been deprecated in Rancher?
|
||||
## Where can I find out which features have been deprecated in Rancher?
|
||||
|
||||
Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:
|
||||
|
||||
@@ -33,6 +33,6 @@ Rancher will publish deprecated features as part of the [release notes](https://
|
||||
| [2.7.1](https://github.com/rancher/rancher/releases/tag/v2.7.1) | Jan 24, 2023 |
|
||||
| [2.7.0](https://github.com/rancher/rancher/releases/tag/v2.7.0) | Nov 16, 2022 |
|
||||
|
||||
### What can I expect when a feature is marked for deprecation?
|
||||
## What can I expect when a feature is marked for deprecation?
|
||||
|
||||
In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
|
||||
@@ -18,7 +18,7 @@ enable_cri_dockerd: true
|
||||
|
||||
For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher even after the removal of in-tree Dockershim in Kubernetes 1.24.
|
||||
|
||||
### FAQ
|
||||
## FAQ
|
||||
|
||||
<br/>
|
||||
|
||||
|
||||
@@ -8,11 +8,11 @@ title: Installing and Configuring kubectl
|
||||
|
||||
`kubectl` is a CLI utility for running commands against Kubernetes clusters. It's required for many maintenance and administrative tasks in Rancher 2.x.
|
||||
|
||||
### Installation
|
||||
## Installation
|
||||
|
||||
See [kubectl Installation](https://kubernetes.io/docs/tasks/tools/install-kubectl/) for installation on your operating system.
|
||||
|
||||
### Configuration
|
||||
## Configuration
|
||||
|
||||
When you create a Kubernetes cluster with RKE, RKE creates a `kube_config_cluster.yml` in the local directory that contains credentials to connect to your new cluster with tools like `kubectl` or `helm`.
|
||||
|
||||
|
||||
@@ -7,15 +7,15 @@ title: Security FAQ
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/security"/>
|
||||
</head>
|
||||
|
||||
### Is there a Hardening Guide?
|
||||
## Is there a Hardening Guide?
|
||||
|
||||
The Hardening Guide is located in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
|
||||
|
||||
### Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?
|
||||
## Have hardened Rancher Kubernetes clusters been evaluated by the CIS Kubernetes Benchmark? Where can I find the results?
|
||||
|
||||
We have run the CIS Kubernetes benchmark against a hardened Rancher Kubernetes cluster. The results of that assessment can be found in the main [Security](../reference-guides/rancher-security/rancher-security.md) section.
|
||||
|
||||
### How does Rancher verify communication with downstream clusters, and what are some associated security concerns?
|
||||
## How does Rancher verify communication with downstream clusters, and what are some associated security concerns?
|
||||
|
||||
Communication between the Rancher server and downstream clusters is performed through agents. Rancher uses either a registered certificate authority (CA) bundle or the local trust store to verify communication between Rancher agents and the Rancher server. Using a CA bundle for verification is more strict, as only the certificates based on that bundle are trusted. If TLS verification for a explicit CA bundle fails, Rancher may fall back to using the local trust store for verifying future communication. Any CA within the local trust store can then be used to generate a valid certificate.
|
||||
|
||||
|
||||
@@ -6,9 +6,10 @@ title: Technical FAQ
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/technical-items"/>
|
||||
</head>
|
||||
|
||||
### How can I reset the administrator password?
|
||||
## How can I reset the administrator password?
|
||||
|
||||
Docker install:
|
||||
|
||||
Docker Install:
|
||||
```
|
||||
$ docker exec -ti <container_id> reset-password
|
||||
New password for default administrator (user-xxxxx):
|
||||
@@ -16,6 +17,7 @@ New password for default administrator (user-xxxxx):
|
||||
```
|
||||
|
||||
Kubernetes install (Helm):
|
||||
|
||||
```
|
||||
$ KUBECONFIG=./kube_config_cluster.yml
|
||||
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher --no-headers | head -1 | awk '{ print $1 }') -c rancher -- reset-password
|
||||
@@ -23,10 +25,10 @@ New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
|
||||
## I deleted/deactivated the last admin, how can I fix it?
|
||||
|
||||
Docker install:
|
||||
|
||||
### I deleted/deactivated the last admin, how can I fix it?
|
||||
Docker Install:
|
||||
```
|
||||
$ docker exec -ti <container_id> ensure-default-admin
|
||||
New default administrator (user-xxxxx)
|
||||
@@ -35,38 +37,39 @@ New password for default administrator (user-xxxxx):
|
||||
```
|
||||
|
||||
Kubernetes install (Helm):
|
||||
|
||||
```
|
||||
$ KUBECONFIG=./kube_config_cluster.yml
|
||||
$ kubectl --kubeconfig $KUBECONFIG -n cattle-system exec $(kubectl --kubeconfig $KUBECONFIG -n cattle-system get pods -l app=rancher | grep '1/1' | head -1 | awk '{ print $1 }') -- ensure-default-admin
|
||||
New password for default administrator (user-xxxxx):
|
||||
<new_password>
|
||||
```
|
||||
### How can I enable debug logging?
|
||||
## How can I enable debug logging?
|
||||
|
||||
See [Troubleshooting: Logging](../troubleshooting/other-troubleshooting-tips/logging.md)
|
||||
|
||||
### My ClusterIP does not respond to ping
|
||||
## My ClusterIP does not respond to ping
|
||||
|
||||
ClusterIP is a virtual IP, which will not respond to ping. Best way to test if the ClusterIP is configured correctly, is by using `curl` to access the IP and port to see if it responds.
|
||||
|
||||
### Where can I manage Node Templates?
|
||||
## Where can I manage Node Templates?
|
||||
|
||||
Node Templates can be accessed by opening your account menu (top right) and selecting `Node Templates`.
|
||||
|
||||
### Why is my Layer-4 Load Balancer in `Pending` state?
|
||||
## Why is my Layer-4 Load Balancer in `Pending` state?
|
||||
|
||||
The Layer-4 Load Balancer is created as `type: LoadBalancer`. In Kubernetes, this needs a cloud provider or controller that can satisfy these requests, otherwise these will be in `Pending` state forever. More information can be found on [Cloud Providers](../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/set-up-cloud-providers/set-up-cloud-providers.md) or [Create External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/)
|
||||
|
||||
### Where is the state of Rancher stored?
|
||||
## Where is the state of Rancher stored?
|
||||
|
||||
- Docker Install: in the embedded etcd of the `rancher/rancher` container, located at `/var/lib/rancher`.
|
||||
- Kubernetes install: in the etcd of the RKE cluster created to run Rancher.
|
||||
|
||||
### How are the supported Docker versions determined?
|
||||
## 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/CHANGELOG-1.10.md#external-dependencies) in the Kubernetes release CHANGELOG.md.
|
||||
|
||||
### How can I access nodes created by Rancher?
|
||||
## How can I access nodes created by Rancher?
|
||||
|
||||
SSH keys to access the nodes created by Rancher can be downloaded via the **Nodes** view. Choose the node which you want to access and click on the vertical ⋮ button at the end of the row, and choose **Download Keys** as shown in the picture below.
|
||||
|
||||
@@ -78,14 +81,14 @@ Unzip the downloaded zip file, and use the file `id_rsa` to connect to you host.
|
||||
$ ssh -i id_rsa user@ip_of_node
|
||||
```
|
||||
|
||||
### How can I automate task X in Rancher?
|
||||
## How can I automate task X in Rancher?
|
||||
|
||||
The UI consists of static files, and works based on responses of the API. That means every action/task that you can execute in the UI, can be automated via the API. There are 2 ways to do this:
|
||||
|
||||
* Visit `https://your_rancher_ip/v3` and browse the API options.
|
||||
* Capture the API calls when using the UI (Most commonly used for this is [Chrome Developer Tools](https://developers.google.com/web/tools/chrome-devtools/#network) but you can use anything you like)
|
||||
|
||||
### The IP address of a node changed, how can I recover?
|
||||
## The IP address of a node changed, how can I recover?
|
||||
|
||||
A node is required to have a static IP configured (or a reserved IP via DHCP). If the IP of a node has changed, you will have to remove it from the cluster and readd it. After it is removed, Rancher will update the cluster to the correct state. If the cluster is no longer in `Provisioning` state, the node is removed from the cluster.
|
||||
|
||||
@@ -93,11 +96,11 @@ When the IP address of the node changed, Rancher lost connection to the node, so
|
||||
|
||||
When the node is removed from the cluster, and the node is cleaned, you can readd the node to the cluster.
|
||||
|
||||
### How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
## How can I add more arguments/binds/environment variables to Kubernetes components in a Rancher Launched Kubernetes cluster?
|
||||
|
||||
You can add more arguments/binds/environment variables via the [Config File](../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#rke-cluster-config-file-reference) option in Cluster Options. For more information, see the [Extra Args, Extra Binds, and Extra Environment Variables](https://rancher.com/docs/rke/latest/en/config-options/services/services-extras/) in the RKE documentation or browse the [Example Cluster.ymls](https://rancher.com/docs/rke/latest/en/example-yamls/).
|
||||
|
||||
### How do I check if my certificate chain is valid?
|
||||
## How do I check if my certificate chain is valid?
|
||||
|
||||
Use the `openssl verify` command to validate your certificate chain:
|
||||
|
||||
@@ -138,7 +141,7 @@ subject= /C=GB/ST=England/O=Alice Ltd/CN=rancher.yourdomain.com
|
||||
issuer= /C=GB/ST=England/O=Alice Ltd/CN=Alice Intermediate CA
|
||||
```
|
||||
|
||||
### How do I check `Common Name` and `Subject Alternative Names` in my server certificate?
|
||||
## How do I check `Common Name` and `Subject Alternative Names` in my server certificate?
|
||||
|
||||
Although technically an entry in `Subject Alternative Names` is required, having the hostname in both `Common Name` and as entry in `Subject Alternative Names` gives you maximum compatibility with older browser/applications.
|
||||
|
||||
@@ -156,7 +159,7 @@ openssl x509 -noout -in cert.pem -text | grep DNS
|
||||
DNS:rancher.my.org
|
||||
```
|
||||
|
||||
### Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?
|
||||
## Why does it take 5+ minutes for a pod to be rescheduled when a node has failed?
|
||||
|
||||
This is due to a combination of the following default Kubernetes settings:
|
||||
|
||||
@@ -175,6 +178,6 @@ In Kubernetes v1.13, the `TaintBasedEvictions` feature is enabled by default. Se
|
||||
* `default-not-ready-toleration-seconds`: Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.
|
||||
* `default-unreachable-toleration-seconds`: Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.
|
||||
|
||||
### Can I use keyboard shortcuts in the UI?
|
||||
## Can I use keyboard shortcuts in the UI?
|
||||
|
||||
Yes, most parts of the UI can be reached using keyboard shortcuts. For an overview of the available shortcuts, press `?` anywhere in the UI.
|
||||
|
||||
@@ -6,11 +6,11 @@ title: Telemetry FAQ
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/telemetry"/>
|
||||
</head>
|
||||
|
||||
### What is Telemetry?
|
||||
## What is Telemetry?
|
||||
|
||||
Telemetry collects aggregate information about the size of Rancher installations, versions of components used, and which features are used. This information is used by Rancher Labs to help make the product better and is not shared with third-parties.
|
||||
|
||||
### What information is collected?
|
||||
## What information is collected?
|
||||
|
||||
No specific identifying information like usernames, passwords, or the names or addresses of user resources will ever be collected.
|
||||
|
||||
@@ -24,12 +24,12 @@ The primary things collected include:
|
||||
- The image name & version of Rancher that is running.
|
||||
- A unique randomly-generated identifier for this installation.
|
||||
|
||||
### Can I see the information that is being sent?
|
||||
## Can I see the information that is being sent?
|
||||
|
||||
If Telemetry is enabled, you can go to `https://<your rancher server>/v1-telemetry` in your installation to see the current data.
|
||||
|
||||
If Telemetry is not enabled, the process that collects the data is not running, so there is nothing being collected to look at.
|
||||
|
||||
### How do I turn it on or off?
|
||||
## How do I turn it on or off?
|
||||
|
||||
After initial setup, an administrator can go to the `Settings` page in the `Global` section of the UI and click Edit to change the `telemetry-opt` setting to either `in` or `out`.
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ These instructions assume you have already followed the instructions for a Kuber
|
||||
|
||||
:::
|
||||
|
||||
### Rancher Helm Upgrade Options
|
||||
## Rancher Helm Upgrade Options
|
||||
|
||||
To upgrade with Helm, apply the same options that you used when installing Rancher. Refer to the reference table below to replace each placeholder. Rancher needs to be configured to use the private registry in order to provision any Rancher launched Kubernetes clusters or Rancher tools.
|
||||
|
||||
|
||||
-3
@@ -12,7 +12,6 @@ For the instructions to upgrade Rancher installed with Docker, refer to [this pa
|
||||
|
||||
To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
### Access to kubeconfig
|
||||
@@ -49,7 +48,6 @@ For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cl
|
||||
|
||||
Follow the steps to upgrade Rancher server:
|
||||
|
||||
|
||||
### 1. Back up Your Kubernetes Cluster that is Running Rancher Server
|
||||
|
||||
Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher.
|
||||
@@ -119,7 +117,6 @@ If you are installing Rancher in an air-gapped environment, skip the rest of thi
|
||||
|
||||
:::
|
||||
|
||||
|
||||
Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
|
||||
|
||||
```
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ Starting with version 1.24, the above defaults to true.
|
||||
|
||||
For users looking to use another container runtime, Rancher has the edge-focused K3s and datacenter-focused RKE2 Kubernetes distributions that use containerd as the default runtime. Imported RKE2 and K3s Kubernetes clusters can then be upgraded and managed through Rancher going forward.
|
||||
|
||||
### FAQ
|
||||
## FAQ
|
||||
|
||||
<br/>
|
||||
|
||||
|
||||
-2
@@ -143,8 +143,6 @@ docker run -d --restart=unless-stopped \
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
||||
:::note
|
||||
|
||||
If you don't intend to send telemetry data, opt out [telemetry](../../../../faq/telemetry.md) during the initial login.
|
||||
|
||||
+13
-13
@@ -25,7 +25,7 @@ We recommend setting up the following infrastructure for a high-availability ins
|
||||
- **A DNS record** to map a URL to the load balancer. This will become the Rancher server URL, and downstream Kubernetes clusters will need to reach it.
|
||||
- **A private image registry** to distribute container images to your machines.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
## 1. Set up Linux Nodes
|
||||
|
||||
These hosts will be disconnected from the internet, but require being able to connect with your private registry.
|
||||
|
||||
@@ -33,7 +33,7 @@ Make sure that your nodes fulfill the general installation requirements for [OS,
|
||||
|
||||
For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.
|
||||
|
||||
### 2. Set up External Datastore
|
||||
## 2. Set up External Datastore
|
||||
|
||||
The ability to run Kubernetes using a datastore other than etcd sets K3s apart from other Kubernetes distributions. This feature provides flexibility to Kubernetes operators. The available options allow you to select a datastore that best fits your use case.
|
||||
|
||||
@@ -49,7 +49,7 @@ For an example of one way to set up the database, refer to this [tutorial](../..
|
||||
|
||||
For the complete list of options that are available for configuring a K3s cluster datastore, refer to the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/datastore/)
|
||||
|
||||
### 3. Set up the Load Balancer
|
||||
## 3. Set up the Load Balancer
|
||||
|
||||
You will also need to set up a load balancer to direct traffic to the Rancher replica on both nodes. That will prevent an outage of any single node from taking down communications to the Rancher management server.
|
||||
|
||||
@@ -72,7 +72,7 @@ Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance
|
||||
|
||||
:::
|
||||
|
||||
### 4. Set up the DNS Record
|
||||
## 4. Set up the DNS Record
|
||||
|
||||
Once you have set up your load balancer, you will need to create a DNS record to send traffic to this load balancer.
|
||||
|
||||
@@ -82,7 +82,7 @@ You will need to specify this hostname in a later step when you install Rancher,
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
### 5. Set up a Private Image Registry
|
||||
## 5. Set up a Private Image Registry
|
||||
|
||||
Rancher supports air gap installs using a private registry. You must have your own private registry or other means of distributing container images to your machines.
|
||||
|
||||
@@ -106,13 +106,13 @@ To install the Rancher management server on a high-availability RKE cluster, we
|
||||
|
||||
These nodes must be in the same region/data center. You may place these servers in separate availability zones.
|
||||
|
||||
### Why three nodes?
|
||||
## Why Three Nodes?
|
||||
|
||||
In an RKE cluster, Rancher server data is stored on etcd. This etcd database runs on all three nodes.
|
||||
|
||||
The etcd database requires an odd number of nodes so that it can always elect a leader with a majority of the etcd cluster. If the etcd database cannot elect a leader, etcd can suffer from [split brain](https://www.quora.com/What-is-split-brain-in-distributed-systems), requiring the cluster to be restored from backup. If one of the three etcd nodes fails, the two remaining nodes can elect a leader because they have the majority of the total number of etcd nodes.
|
||||
|
||||
### 1. Set up Linux Nodes
|
||||
## 1. Set up Linux Nodes
|
||||
|
||||
These hosts will be disconnected from the internet, but require being able to connect with your private registry.
|
||||
|
||||
@@ -120,7 +120,7 @@ Make sure that your nodes fulfill the general installation requirements for [OS,
|
||||
|
||||
For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.
|
||||
|
||||
### 2. Set up the Load Balancer
|
||||
## 2. Set up the Load Balancer
|
||||
|
||||
You will also need to set up a load balancer to direct traffic to the Rancher replica on both nodes. That will prevent an outage of any single node from taking down communications to the Rancher management server.
|
||||
|
||||
@@ -143,7 +143,7 @@ Do not use this load balancer (i.e, the `local` cluster Ingress) to load balance
|
||||
|
||||
:::
|
||||
|
||||
### 3. Set up the DNS Record
|
||||
## 3. Set up the DNS Record
|
||||
|
||||
Once you have set up your load balancer, you will need to create a DNS record to send traffic to this load balancer.
|
||||
|
||||
@@ -153,7 +153,7 @@ You will need to specify this hostname in a later step when you install Rancher,
|
||||
|
||||
For a how-to guide for setting up a DNS record to route domain traffic to an Amazon ELB load balancer, refer to the [official AWS documentation.](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer)
|
||||
|
||||
### 4. Set up a Private Image Registry
|
||||
## 4. Set up a Private Image Registry
|
||||
|
||||
Rancher supports air gap installs using a secure private registry. You must have your own private registry or other means of distributing container images to your machines.
|
||||
|
||||
@@ -176,7 +176,7 @@ If you need to create a private registry, refer to the documentation pages for y
|
||||
|
||||
:::
|
||||
|
||||
### 1. Set up a Linux Node
|
||||
## 1. Set up a Linux Node
|
||||
|
||||
This host will be disconnected from the Internet, but needs to be able to connect to your private registry.
|
||||
|
||||
@@ -184,7 +184,7 @@ Make sure that your node fulfills the general installation requirements for [OS,
|
||||
|
||||
For an example of one way to set up Linux nodes, refer to this [tutorial](../../../../how-to-guides/new-user-guides/infrastructure-setup/nodes-in-amazon-ec2.md) for setting up nodes as instances in Amazon EC2.
|
||||
|
||||
### 2. Set up a Private Docker Registry
|
||||
## 2. Set up a Private Docker Registry
|
||||
|
||||
Rancher supports air gap installs using a private registry on your bastion server. You must have your own private registry or other means of distributing container images to your machines.
|
||||
|
||||
@@ -193,4 +193,4 @@ If you need help with creating a private registry, please refer to the [official
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### [Next: Collect and Publish Images to your Private Registry](publish-images.md)
|
||||
## [Next: Collect and Publish Images to your Private Registry](publish-images.md)
|
||||
|
||||
+20
-16
@@ -30,7 +30,8 @@ In this guide, we are assuming you have created your nodes in your air gapped en
|
||||
3. [Install K3s](#3-install-k3s)
|
||||
4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)
|
||||
|
||||
### 1. Prepare Images Directory
|
||||
## 1. Prepare Images Directory
|
||||
|
||||
Obtain the images tar file for your architecture from the [releases](https://github.com/k3s-io/k3s/releases) page for the version of K3s you will be running.
|
||||
|
||||
Place the tar file in the `images` directory before starting K3s on each node, for example:
|
||||
@@ -40,7 +41,8 @@ sudo mkdir -p /var/lib/rancher/k3s/agent/images/
|
||||
sudo cp ./k3s-airgap-images-$ARCH.tar /var/lib/rancher/k3s/agent/images/
|
||||
```
|
||||
|
||||
### 2. Create Registry YAML
|
||||
## 2. Create Registry YAML
|
||||
|
||||
Create the registries.yaml file at `/etc/rancher/k3s/registries.yaml`. This will tell K3s the necessary details to connect to your private registry.
|
||||
|
||||
The registries.yaml file should look like this before plugging in the necessary information:
|
||||
@@ -66,7 +68,7 @@ Note, at this time only secure registries are supported with K3s (SSL with custo
|
||||
|
||||
For more information on private registries configuration file for K3s, refer to the [K3s documentation.](https://rancher.com/docs/k3s/latest/en/installation/private-registry/)
|
||||
|
||||
### 3. Install K3s
|
||||
## 3. Install K3s
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [Rancher Support Matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
|
||||
|
||||
@@ -98,7 +100,7 @@ K3s additionally provides a `--resolv-conf` flag for kubelets, which may help wi
|
||||
|
||||
:::
|
||||
|
||||
### 4. Save and Start Using the kubeconfig File
|
||||
## 4. Save and Start Using the kubeconfig File
|
||||
|
||||
When you installed K3s on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/k3s/k3s.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
|
||||
|
||||
@@ -138,7 +140,7 @@ kubectl --kubeconfig ~/.kube/config/k3s.yaml get pods --all-namespaces
|
||||
|
||||
For more information about the `kubeconfig` file, refer to the [K3s documentation](https://rancher.com/docs/k3s/latest/en/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
|
||||
## Note on Upgrading
|
||||
|
||||
Upgrading an air-gap environment can be accomplished in the following manner:
|
||||
|
||||
@@ -151,14 +153,15 @@ Upgrading an air-gap environment can be accomplished in the following manner:
|
||||
|
||||
In this guide, we are assuming you have created your nodes in your air-gapped environment and have a secure Docker private registry on your bastion server.
|
||||
|
||||
### Installation Outline
|
||||
## Installation Outline
|
||||
|
||||
1. [Create RKE2 configuration](#1-create-rke2-configuration)
|
||||
2. [Create Registry YAML](#2-create-registry-yaml)
|
||||
3. [Install RKE2](#3-install-rke2)
|
||||
4. [Save and Start Using the kubeconfig File](#4-save-and-start-using-the-kubeconfig-file)
|
||||
|
||||
### 1. Create RKE2 configuration
|
||||
## 1. Create RKE2 configuration
|
||||
|
||||
Create the config.yaml file at `/etc/rancher/rke2/config.yaml`. This will contain all the configuration options necessary to create a highly available RKE2 cluster.
|
||||
|
||||
On the first server the minimum config is:
|
||||
@@ -186,7 +189,8 @@ RKE2 additionally provides a `resolv-conf` option for kubelets, which may help w
|
||||
|
||||
:::
|
||||
|
||||
### 2. Create Registry YAML
|
||||
## 2. Create Registry YAML
|
||||
|
||||
Create the registries.yaml file at `/etc/rancher/rke2/registries.yaml`. This will tell RKE2 the necessary details to connect to your private registry.
|
||||
|
||||
The registries.yaml file should look like this before plugging in the necessary information:
|
||||
@@ -210,7 +214,7 @@ configs:
|
||||
|
||||
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
|
||||
## 3. Install RKE2
|
||||
|
||||
Rancher needs to be installed on a supported Kubernetes version. To find out which versions of Kubernetes are supported for your Rancher version, refer to the [support maintenance terms.](https://rancher.com/support-maintenance-terms/)
|
||||
|
||||
@@ -239,7 +243,7 @@ systemctl start rke2-server.service
|
||||
|
||||
For more information, refer to the [RKE2 documentation](https://docs.rke2.io/install/airgap).
|
||||
|
||||
### 4. Save and Start Using the kubeconfig File
|
||||
## 4. Save and Start Using the kubeconfig File
|
||||
|
||||
When you installed RKE2 on each Rancher server node, a `kubeconfig` file was created on the node at `/etc/rancher/rke2/rke2.yaml`. This file contains credentials for full access to the cluster, and you should save this file in a secure location.
|
||||
|
||||
@@ -279,7 +283,7 @@ 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.
|
||||
|
||||
### Note on Upgrading
|
||||
## Note on Upgrading
|
||||
|
||||
Upgrading an air-gap environment can be accomplished in the following manner:
|
||||
|
||||
@@ -301,7 +305,7 @@ Certified version(s) of RKE based on the Rancher version can be found in the [Ra
|
||||
|
||||
:::
|
||||
|
||||
### 2. Create an RKE Config File
|
||||
## 2. Create an RKE Config File
|
||||
|
||||
From a system that can access ports 22/TCP and 6443/TCP on the Linux host node(s) that you set up in a previous step, use the sample below to create a new file named `rancher-cluster.yml`.
|
||||
|
||||
@@ -352,7 +356,7 @@ private_registries:
|
||||
is_default: true
|
||||
```
|
||||
|
||||
### 3. Run RKE
|
||||
## 3. Run RKE
|
||||
|
||||
After configuring `rancher-cluster.yml`, bring up your Kubernetes cluster:
|
||||
|
||||
@@ -360,7 +364,7 @@ After configuring `rancher-cluster.yml`, bring up your Kubernetes cluster:
|
||||
rke up --config ./rancher-cluster.yml
|
||||
```
|
||||
|
||||
### 4. Save Your Files
|
||||
## 4. Save Your Files
|
||||
|
||||
:::note Important:
|
||||
|
||||
@@ -383,8 +387,8 @@ The "rancher-cluster" parts of the two latter file names are dependent on how yo
|
||||
|
||||
:::
|
||||
|
||||
### Issues or errors?
|
||||
## Issues or Errors?
|
||||
|
||||
See the [Troubleshooting](../../install-upgrade-on-a-kubernetes-cluster/troubleshooting.md) page.
|
||||
|
||||
### [Next: Install Rancher](install-rancher-ha.md)
|
||||
## [Next: Install Rancher](install-rancher-ha.md)
|
||||
|
||||
+1
-1
@@ -192,7 +192,7 @@ Placeholder | Description
|
||||
|
||||
**Optional**: To install a specific Rancher version, set the `rancherImageTag` value, example: `--set rancherImageTag=v2.5.8`
|
||||
|
||||
#### Option B: Certificates From Files using Kubernetes Secrets
|
||||
#### Option B: Certificates From Files Using Kubernetes Secrets
|
||||
|
||||
##### 1. Create secrets
|
||||
|
||||
|
||||
+2
-2
@@ -36,7 +36,7 @@ Administrators might configure the RKE metadata settings to do the following:
|
||||
- Change the metadata URL that Rancher uses to sync the metadata, which is useful for air gap setups if you need to sync Rancher locally instead of with GitHub
|
||||
- Prevent Rancher from auto-syncing the metadata, which is one way to prevent new and unsupported Kubernetes versions from being available in Rancher
|
||||
|
||||
### Refresh Kubernetes Metadata
|
||||
## Refresh Kubernetes Metadata
|
||||
|
||||
The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)
|
||||
|
||||
@@ -74,7 +74,7 @@ If you don't have an air gap setup, you don't need to specify the URL where Ranc
|
||||
|
||||
However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
|
||||
|
||||
### Air Gap Setups
|
||||
## Air Gap Setups
|
||||
|
||||
Rancher relies on a periodic refresh of the `rke-metadata-config` to download new Kubernetes version metadata if it is supported with the current version of the Rancher server. For a table of compatible Kubernetes and Rancher versions, refer to the [service terms section.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)
|
||||
|
||||
|
||||
+2
-2
@@ -10,7 +10,7 @@ When Rancher is used to manage [a large infrastructure](../../getting-started/in
|
||||
|
||||
The etcd data set is automatically cleaned up on a five minute interval by Kubernetes. There are situations, e.g. deployment thrashing, where enough events could be written to etcd and deleted before garbage collection occurs and cleans things up causing the keyspace to fill up. If you see `mvcc: database space exceeded` errors, in the etcd logs or Kubernetes API server logs, you should consider increasing the keyspace size. This can be accomplished by setting the [quota-backend-bytes](https://etcd.io/docs/v3.5/op-guide/maintenance/#space-quota) setting on the etcd servers.
|
||||
|
||||
### Example: This snippet of the RKE cluster.yml file increases the keyspace size to 5GB
|
||||
## Example: This Snippet of the RKE Cluster.yml file Increases the Keyspace Size to 5GB
|
||||
|
||||
```yaml
|
||||
# RKE cluster.yml
|
||||
@@ -21,7 +21,7 @@ services:
|
||||
quota-backend-bytes: 5368709120
|
||||
```
|
||||
|
||||
## Scaling etcd disk performance
|
||||
## Scaling etcd Disk Performance
|
||||
|
||||
You can follow the recommendations from [the etcd docs](https://etcd.io/docs/v3.5/tuning/#disk) on how to tune the disk priority on the host.
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ If you create a namespace with `kubectl`, it may be unusable because `kubectl` d
|
||||
|
||||
:::
|
||||
|
||||
### Creating Namespaces
|
||||
## Creating Namespaces
|
||||
|
||||
Create a new namespace to isolate apps and resources in a project.
|
||||
|
||||
@@ -50,7 +50,7 @@ When working with project resources that you can assign to a namespace (i.e., [w
|
||||
|
||||
**Result:** Your namespace is added to the project. You can begin assigning cluster resources to the namespace.
|
||||
|
||||
### Moving Namespaces to Another Project
|
||||
## Moving Namespaces to Another Project
|
||||
|
||||
Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.
|
||||
|
||||
@@ -71,7 +71,7 @@ Cluster admins and members may occasionally need to move a namespace to another
|
||||
|
||||
**Result:** Your namespace is moved to a different project (or is unattached from all projects). If any project resources are attached to the namespace, the namespace releases them and then attached resources from the new project.
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
## Editing Namespace Resource Quotas
|
||||
|
||||
You can always override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
|
||||
|
||||
|
||||
+3
-3
@@ -14,7 +14,7 @@ To configure the custom resources, go to the **Cluster Dashboard** To configure
|
||||
1. On the **Clusters** page, go to the cluster where you want to configure CIS scans and click **Explore**.
|
||||
1. In the left navigation bar, click **CIS Benchmark**.
|
||||
|
||||
### Scans
|
||||
## Scans
|
||||
|
||||
A scan is created to trigger a CIS scan on the cluster based on the defined profile. A report is created after the scan is completed.
|
||||
|
||||
@@ -31,7 +31,7 @@ spec:
|
||||
scanProfileName: rke-profile-hardened
|
||||
```
|
||||
|
||||
### Profiles
|
||||
## Profiles
|
||||
|
||||
A profile contains the configuration for the CIS scan, which includes the benchmark version to use and any specific tests to skip in that benchmark.
|
||||
|
||||
@@ -66,7 +66,7 @@ spec:
|
||||
- "1.1.21"
|
||||
```
|
||||
|
||||
### Benchmark Versions
|
||||
## Benchmark Versions
|
||||
|
||||
A benchmark version is the name of benchmark to run using `kube-bench`, as well as the valid configuration parameters for that benchmark.
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ When a cluster scan is run, you need to select a Profile which points to a speci
|
||||
|
||||
Follow all the steps below to add a custom Benchmark Version and run a scan using it.
|
||||
|
||||
### 1. Prepare the Custom Benchmark Version ConfigMap
|
||||
## 1. Prepare the Custom Benchmark Version ConfigMap
|
||||
|
||||
To create a custom benchmark version, first you need to create a ConfigMap containing the benchmark version's config files and upload it to your Kubernetes cluster where you want to run the scan.
|
||||
|
||||
@@ -42,7 +42,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom
|
||||
kubectl create configmap -n <namespace> foo --from-file=<path to directory foo>
|
||||
```
|
||||
|
||||
### 2. Add a Custom Benchmark Version to a Cluster
|
||||
## 2. Add a Custom Benchmark Version to a Cluster
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to add a custom benchmark and click **Explore**.
|
||||
@@ -54,7 +54,7 @@ To prepare a custom benchmark version ConfigMap, suppose we want to add a custom
|
||||
1. Add the minimum and maximum Kubernetes version limits applicable, if any.
|
||||
1. Click **Create**.
|
||||
|
||||
### 3. Create a New Profile for the Custom Benchmark Version
|
||||
## 3. Create a New Profile for the Custom Benchmark Version
|
||||
|
||||
To run a scan using your custom benchmark version, you need to add a new Profile pointing to this benchmark version.
|
||||
|
||||
@@ -66,7 +66,7 @@ To run a scan using your custom benchmark version, you need to add a new Profile
|
||||
1. Choose the Benchmark Version from the dropdown.
|
||||
1. Click **Create**.
|
||||
|
||||
### 4. Run a Scan Using the Custom Benchmark Version
|
||||
## 4. Run a Scan Using the Custom Benchmark Version
|
||||
|
||||
Once the Profile pointing to your custom benchmark version `foo` has been created, you can create a new Scan to run the custom test configs in the Benchmark Version.
|
||||
|
||||
|
||||
+3
-3
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Supportconfig bundle
|
||||
title: Supportconfig Bundle
|
||||
---
|
||||
|
||||
<head>
|
||||
@@ -12,7 +12,7 @@ These bundles can be created through Rancher or through direct access to the clu
|
||||
|
||||
> **Note:** Only admin users can generate/download supportconfig bundles, regardless of method.
|
||||
|
||||
### Accessing through Rancher
|
||||
## Accessing Through Rancher
|
||||
|
||||
First, click on the hamburger menu. Then click the `Get Support` button.
|
||||
|
||||
@@ -24,7 +24,7 @@ In the next page, click on the `Generate Support Config` button.
|
||||
|
||||

|
||||
|
||||
### Accessing without rancher
|
||||
## Accessing Without Rancher
|
||||
|
||||
First, generate a kubeconfig for the cluster that Rancher is installed on.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ This section summarizes the architecture of the Rancher logging application.
|
||||
|
||||
For more details about how the Logging operator works, see the [official documentation.](https://kube-logging.github.io/docs/#architecture)
|
||||
|
||||
### How the Logging Operator Works
|
||||
## How the Logging Operator Works
|
||||
|
||||
The Logging operator automates the deployment and configuration of a Kubernetes logging pipeline. It deploys and configures a Fluent Bit DaemonSet on every node to collect container and application logs from the node file system.
|
||||
|
||||
|
||||
+6
-6
@@ -6,7 +6,7 @@ title: rancher-logging Helm Chart Options
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/logging/logging-helm-chart-options"/>
|
||||
</head>
|
||||
|
||||
### Enable/Disable Windows Node Logging
|
||||
## Enable/Disable Windows Node Logging
|
||||
|
||||
You can enable or disable Windows node logging by setting `global.cattle.windows.enabled` to either `true` or `false` in the `values.yaml`.
|
||||
|
||||
@@ -21,7 +21,7 @@ Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists whe
|
||||
|
||||
:::
|
||||
|
||||
### Working with a Custom Docker Root Directory
|
||||
## Working with a Custom Docker Root Directory
|
||||
|
||||
If using a custom Docker root directory, you can set `global.dockerRootDirectory` in `values.yaml`.
|
||||
|
||||
@@ -31,11 +31,11 @@ Note that this only affects Linux nodes.
|
||||
|
||||
If there are any Windows nodes in the cluster, the change will not be applicable to those nodes.
|
||||
|
||||
### Adding NodeSelector Settings and Tolerations for Custom Taints
|
||||
## Adding NodeSelector Settings and Tolerations for Custom Taints
|
||||
|
||||
You can add your own `nodeSelector` settings and add `tolerations` for additional taints by editing the logging Helm chart values. For details, see [this page.](taints-and-tolerations.md)
|
||||
|
||||
### Enabling the Logging Application to Work with SELinux
|
||||
## Enabling the Logging Application to Work with SELinux
|
||||
|
||||
:::note Requirements:
|
||||
|
||||
@@ -49,7 +49,7 @@ To use Logging v2 with SELinux, we recommend installing the `rancher-selinux` RP
|
||||
|
||||
Then, when installing the logging application, configure the chart to be SELinux aware by changing `global.seLinux.enabled` to `true` in the `values.yaml`.
|
||||
|
||||
### Additional Logging Sources
|
||||
## Additional Logging Sources
|
||||
|
||||
By default, Rancher collects logs for [control plane components](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components) and [node components](https://kubernetes.io/docs/concepts/overview/components/#node-components) for all cluster types.
|
||||
|
||||
@@ -72,7 +72,7 @@ When enabled, Rancher collects all additional node and control plane logs the pr
|
||||
|
||||
If you're already using a cloud provider's own logging solution such as AWS CloudWatch or Google Cloud operations suite (formerly Stackdriver), it is not necessary to enable this option as the native solution will have unrestricted access to all logs.
|
||||
|
||||
### Systemd Configuration
|
||||
## Systemd Configuration
|
||||
|
||||
In Rancher logging, `SystemdLogPath` must be configured for K3s and RKE2 Kubernetes distributions.
|
||||
|
||||
|
||||
+2
-2
@@ -20,7 +20,7 @@ Both provide choice for the what node(s) the pod will run on.
|
||||
- [Adding NodeSelector Settings and Tolerations for Custom Taints](#adding-nodeselector-settings-and-tolerations-for-custom-taints)
|
||||
|
||||
|
||||
### Default Implementation in Rancher's Logging Stack
|
||||
## Default Implementation in Rancher's Logging Stack
|
||||
|
||||
By default, Rancher taints all Linux nodes with `cattle.io/os=linux`, and does not taint Windows nodes.
|
||||
The logging stack pods have `tolerations` for this taint, which enables them to run on Linux nodes.
|
||||
@@ -47,7 +47,7 @@ In the above example, we ensure that our pod only runs on Linux nodes, and we ad
|
||||
|
||||
You can do the same with Rancher's existing taints, or with your own custom ones.
|
||||
|
||||
### Adding NodeSelector Settings and Tolerations for Custom Taints
|
||||
## Adding NodeSelector Settings and Tolerations for Custom Taints
|
||||
|
||||
If you would like to add your own `nodeSelector` settings, or if you would like to add `tolerations` for additional taints, you can pass the following to the chart's values.
|
||||
|
||||
|
||||
+1
-2
@@ -15,7 +15,7 @@ For information on V1 monitoring and alerting, available in Rancher v2.2 up to v
|
||||
|
||||
Using the `rancher-monitoring` application, you can quickly deploy leading open-source monitoring and alerting solutions onto your cluster.
|
||||
|
||||
### Features
|
||||
## Features
|
||||
|
||||
Prometheus lets you view metrics from your Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or Grafana, which is an analytics viewing platform deployed along with Prometheus.
|
||||
|
||||
@@ -97,7 +97,6 @@ To be able to fully deploy Monitoring V2 for Windows, all of your Windows hosts
|
||||
|
||||
For more details on how to upgrade wins on existing Windows hosts, see [Windows cluster support for Monitoring V2.](windows-support.md).
|
||||
|
||||
|
||||
## Known Issues
|
||||
|
||||
There is a [known issue](https://github.com/rancher/rancher/issues/28787#issuecomment-693611821) that K3s clusters require more than the allotted default memory. If you enable monitoring on a K3s cluster, set `prometheus.prometheusSpec.resources.memory.limit` to 2500 Mi and `prometheus.prometheusSpec.resources.memory.request` to 1750 Mi.
|
||||
|
||||
@@ -9,7 +9,7 @@ description: Interact with Rancher using command line interface (CLI) tools from
|
||||
|
||||
The Rancher CLI (Command Line Interface) is a unified tool that you can use to interact with Rancher. With this tool, you can operate Rancher using a command line rather than the GUI.
|
||||
|
||||
### Download Rancher CLI
|
||||
## Download Rancher CLI
|
||||
|
||||
The binary can be downloaded directly from the UI.
|
||||
|
||||
@@ -17,14 +17,14 @@ The binary can be downloaded directly from the UI.
|
||||
1. At the bottom of the navigation sidebar menu, click **About**.
|
||||
1. Under the **CLI Downloads section**, there are links to download the binaries for Windows, Mac, and Linux. You can also check the [releases page for our CLI](https://github.com/rancher/cli/releases) for direct downloads of the binary.
|
||||
|
||||
### Requirements
|
||||
## Requirements
|
||||
|
||||
After you download the Rancher CLI, you need to make a few configurations. Rancher CLI requires:
|
||||
|
||||
- Your Rancher Server URL, which is used to connect to Rancher Server.
|
||||
- An API Bearer Token, which is used to authenticate with Rancher. For more information about obtaining a Bearer Token, see [Creating an API Key](../user-settings/api-keys.md).
|
||||
|
||||
### CLI Authentication
|
||||
## CLI Authentication
|
||||
|
||||
Before you can use Rancher CLI to control your Rancher Server, you must authenticate using an API Bearer Token. Log in using the following command (replace `<BEARER_TOKEN>` and `<SERVER_URL>` with your information):
|
||||
|
||||
@@ -34,7 +34,7 @@ $ ./rancher login https://<SERVER_URL> --token <BEARER_TOKEN>
|
||||
|
||||
If Rancher Server uses a self-signed certificate, Rancher CLI prompts you to continue with the connection.
|
||||
|
||||
### Project Selection
|
||||
## Project Selection
|
||||
|
||||
Before you can perform any commands, you must select a Rancher project to perform those commands against. To select a [project](../../how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces.md) to work on, use the command `./rancher context switch`. When you enter this command, a list of available projects displays. Enter a number to choose your project.
|
||||
|
||||
@@ -58,7 +58,7 @@ INFO[0005] Saving config to /Users/markbishop/.ranchcli2.json
|
||||
|
||||
Ensure you can run `rancher kubectl get pods` successfully.
|
||||
|
||||
### Commands
|
||||
## Commands
|
||||
|
||||
The following commands are available for use in Rancher CLI.
|
||||
|
||||
@@ -86,13 +86,12 @@ The following commands are available for use in Rancher CLI.
|
||||
| `token` | Authenticates and generates new kubeconfig token. |
|
||||
| `help, [h]` | Shows a list of commands or help for one command. |
|
||||
|
||||
|
||||
### Rancher CLI Help
|
||||
## Rancher CLI Help
|
||||
|
||||
Once logged into Rancher Server using the CLI, enter `./rancher --help` for a list of commands.
|
||||
|
||||
All commands accept the `--help` flag, which documents each command's usage.
|
||||
|
||||
### Limitations
|
||||
## Limitations
|
||||
|
||||
The Rancher CLI **cannot** be used to install [dashboard apps or Rancher feature charts](../../how-to-guides/new-user-guides/helm-charts-in-rancher/helm-charts-in-rancher.md).
|
||||
|
||||
+2
-2
@@ -10,7 +10,7 @@ After you provision a Kubernetes cluster using Rancher, you can still edit optio
|
||||
|
||||
For information on editing cluster membership, go to [this page.](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/add-users-to-clusters.md)
|
||||
|
||||
### Cluster Configuration References
|
||||
## Cluster Configuration References
|
||||
|
||||
The cluster configuration options depend on the type of Kubernetes cluster:
|
||||
|
||||
@@ -21,7 +21,7 @@ The cluster configuration options depend on the type of Kubernetes cluster:
|
||||
- [GKE Cluster Configuration](rancher-server-configuration/gke-cluster-configuration/gke-cluster-configuration.md)
|
||||
- [AKS Cluster Configuration](rancher-server-configuration/aks-cluster-configuration.md)
|
||||
|
||||
### Cluster Management Capabilities by Cluster Type
|
||||
## Cluster Management Capabilities by Cluster Type
|
||||
|
||||
The options and settings available for an existing cluster change based on the method that you used to provision it.
|
||||
|
||||
|
||||
@@ -6,15 +6,15 @@ title: Monitoring Configuration Examples
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/monitoring-v2-configuration/examples"/>
|
||||
</head>
|
||||
|
||||
### ServiceMonitor
|
||||
## ServiceMonitor
|
||||
|
||||
See the official prometheus-operator GitHub repo for an example [ServiceMonitor](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml) YAML.
|
||||
|
||||
### PodMonitor
|
||||
## PodMonitor
|
||||
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/getting-started/#using-podmonitors) for an example PodMonitor and an example Prometheus resource that refers to a PodMonitor.
|
||||
|
||||
### PrometheusRule
|
||||
## PrometheusRule
|
||||
|
||||
A PrometheusRule contains the alerting and recording rules that you would usually place in a [Prometheus rule file](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/).
|
||||
|
||||
@@ -22,6 +22,6 @@ For a more fine-grained approach, the `ruleSelector` field on a Prometheus resou
|
||||
|
||||
See the [Prometheus Operator documentation](https://prometheus-operator.dev/docs/user-guides/alerting/) for an example PrometheusRule.
|
||||
|
||||
### Alertmanager Config
|
||||
## Alertmanager Config
|
||||
|
||||
See the Rancher docs page on Receivers for an example [Alertmanager config](./receivers.md#example-alertmanager-configs).
|
||||
|
||||
+2
-2
@@ -18,7 +18,7 @@ This section assumes familiarity with how monitoring components work together. F
|
||||
|
||||
:::
|
||||
|
||||
### ServiceMonitors
|
||||
## ServiceMonitors
|
||||
|
||||
This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how groups of Kubernetes services should be monitored.
|
||||
|
||||
@@ -28,7 +28,7 @@ Any Services in your cluster that match the labels located within the ServiceMon
|
||||
|
||||
For more information about how ServiceMonitors work, refer to the [Prometheus Operator documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)
|
||||
|
||||
### PodMonitors
|
||||
## PodMonitors
|
||||
|
||||
This pseudo-CRD maps to a section of the Prometheus custom resource configuration. It declaratively specifies how group of pods should be monitored.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Make sure you configured the correct kubeconfig (for example, `export KUBECONFIG
|
||||
|
||||
Before running the DNS checks, check the [default DNS provider](../../reference-guides/cluster-configuration/rancher-server-configuration/rke1-cluster-configuration.md#default-dns-provider) for your cluster and make sure that [the overlay network is functioning correctly](networking.md#check-if-overlay-network-is-functioning-correctly) as this can also be the reason why DNS resolution (partly) fails.
|
||||
|
||||
### Check if DNS pods are running
|
||||
## Check if DNS pods are running
|
||||
|
||||
```
|
||||
kubectl -n kube-system get pods -l k8s-app=kube-dns
|
||||
@@ -30,7 +30,7 @@ NAME READY STATUS RESTARTS AGE
|
||||
kube-dns-5fd74c7488-h6f7n 3/3 Running 0 4m13s
|
||||
```
|
||||
|
||||
### Check if the DNS service is present with the correct cluster-ip
|
||||
## Check if the DNS service is present with the correct cluster-ip
|
||||
|
||||
```
|
||||
kubectl -n kube-system get svc -l k8s-app=kube-dns
|
||||
@@ -41,7 +41,7 @@ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
service/kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP 4m13s
|
||||
```
|
||||
|
||||
### Check if domain names are resolving
|
||||
## Check if domain names are resolving
|
||||
|
||||
Check if internal cluster names are resolving (in this example, `kubernetes.default`), the IP shown after `Server:` should be the same as the `CLUSTER-IP` from the `kube-dns` service.
|
||||
|
||||
@@ -132,15 +132,15 @@ command terminated with exit code 1
|
||||
|
||||
Cleanup the alpine DaemonSet by running `kubectl delete ds/dnstest`.
|
||||
|
||||
### CoreDNS specific
|
||||
## CoreDNS specific
|
||||
|
||||
#### Check CoreDNS logging
|
||||
### Check CoreDNS logging
|
||||
|
||||
```
|
||||
kubectl -n kube-system logs -l k8s-app=kube-dns
|
||||
```
|
||||
|
||||
#### Check configuration
|
||||
### Check configuration
|
||||
|
||||
CoreDNS configuration is stored in the configmap `coredns` in the `kube-system` namespace.
|
||||
|
||||
@@ -148,7 +148,7 @@ CoreDNS configuration is stored in the configmap `coredns` in the `kube-system`
|
||||
kubectl -n kube-system get configmap coredns -o go-template={{.data.Corefile}}
|
||||
```
|
||||
|
||||
#### Check upstream nameservers in resolv.conf
|
||||
### Check upstream nameservers in resolv.conf
|
||||
|
||||
By default, the configured nameservers on the host (in `/etc/resolv.conf`) will be used as upstream nameservers for CoreDNS. You can check this file on the host or run the following Pod with `dnsPolicy` set to `Default`, which will inherit the `/etc/resolv.conf` from the host it is running on.
|
||||
|
||||
@@ -156,7 +156,7 @@ By default, the configured nameservers on the host (in `/etc/resolv.conf`) will
|
||||
kubectl run -i --restart=Never --rm test-${RANDOM} --image=ubuntu --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"dnsPolicy":"Default"}}' -- sh -c 'cat /etc/resolv.conf'
|
||||
```
|
||||
|
||||
#### Enable query logging
|
||||
### Enable query logging
|
||||
|
||||
Enabling query logging can be done by enabling the [log plugin](https://coredns.io/plugins/log/) in the Corefile configuration in the configmap `coredns`. You can do so by using `kubectl -n kube-system edit configmap coredns` or use the command below to replace the configuration in place:
|
||||
|
||||
@@ -166,9 +166,9 @@ kubectl get configmap -n kube-system coredns -o json | sed -e 's_loadbalance_log
|
||||
|
||||
All queries will now be logged and can be checked using the command in [Check CoreDNS logging](#check-coredns-logging).
|
||||
|
||||
### kube-dns specific
|
||||
## kube-dns specific
|
||||
|
||||
#### Check upstream nameservers in kubedns container
|
||||
### Check upstream nameservers in kubedns container
|
||||
|
||||
By default, the configured nameservers on the host (in `/etc/resolv.conf`) will be used as upstream nameservers for kube-dns. Sometimes the host will run a local caching DNS nameserver, which means the address in `/etc/resolv.conf` will point to an address in the loopback range (`127.0.0.0/8`) which will be unreachable by the container. In case of Ubuntu 18.04, this is done by `systemd-resolved`. We detect if `systemd-resolved` is running, and will automatically use the `/etc/resolv.conf` file with the correct upstream nameservers (which is located at `/run/systemd/resolve/resolv.conf`).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user