Add cattle-logging ns recreation troubleshooting #3064

This commit is contained in:
Catherine Luse
2021-04-05 17:10:07 -07:00
parent bd8c3e323a
commit 76efcfa39c
+34 -18
View File
@@ -62,7 +62,7 @@ Rancher logging has two roles, `logging-admin` and `logging-view`.
- `logging-admin` gives users full access to namespaced flows and outputs
- `logging-view` allows users to *view* namespaced flows and outputs, and cluster flows and outputs
> **Why choose one role over the other?** Edit access to cluster flow and cluster output resources is powerful. Any user with it has edit access for all logs in the cluster.
> **Why choose one role over the other?** Edit access to cluster flow and cluster output resources is powerful. Any user with it has edit access for all logs in the cluster.
In Rancher, the cluster administrator role is the only role with full access to all `rancher-logging` resources. Cluster members are not able to edit or read any logging resources. Project owners and members have the following privileges:
@@ -122,7 +122,7 @@ metadata:
spec:
globalOutputRefs:
- "example-es"
```
```
We should now see our configured index with logs in it.
@@ -158,7 +158,7 @@ spec:
containers:
- name: generator
image: paynejacob/loggenerator:latest
```
```
With `coolapp` running, we will follow a similar path as when we created a cluster output. However, unlike cluster outputs, we create our output in our application's namespace.
@@ -282,13 +282,6 @@ Let's break down what is happening here. First, we create a deployment of a cont
> **Note on syslog** Official `syslog` support is coming in Rancher v2.5.4. However, this example still provides an overview on using unsupported plugins.
# Working with a Custom Docker Root Directory
_Applies to v2.5.6+_
If using a custom Docker root directory, you can set `global.dockerRootDirectory` in `values.yaml`.
This will ensure that the Logging CRs created will use your specified path rather than the default Docker `data-root` location.
# Working with Taints and Tolerations
"Tainting" a Kubernetes node causes pods to repel running on that node.
@@ -314,7 +307,7 @@ spec:
- key: cattle.io/os
operator: "Equal"
value: "linux"
effect: NoSchedule
effect: NoSchedule
nodeSelector:
kubernetes.io/os: linux
```
@@ -322,13 +315,6 @@ spec:
In the above example, we ensure that our pod only runs on Linux nodes, and we add a `toleration` for the taint we have on all of our Linux nodes.
You can do the same with Rancher's existing taints, or with your own custom ones.
# Working with a Custom Docker Root Directory
_Applies to v2.5.6+_
If using a custom Docker root directory, you can set `global.dockerRootDirectory` in `values.yaml`.
This will ensure that the Logging CRs created will use your specified path rather than the default Docker `data-root` location.
### Windows Support
Clusters with Windows workers support exporting logs from Linux nodes, but Windows node logs are currently unable to be exported.
@@ -354,3 +340,33 @@ However, if you would like to add tolerations for *only* the `fluentbit` contain
fluentbit_tolerations:
# insert tolerations list for fluentbit containers only...
```
# Troubleshooting
### The `cattle-logging` Namespace Being Recreated
If your cluster previously deployed logging from the Cluster Manager UI, you may encounter an issue where its `cattle-logging` namespace is continually being recreated.
The solution is to delete all `clusterloggings.management.cattle.io` and `projectloggings.management.cattle.io` custom resources from the cluster specific namespace in the management cluster.
The existence of these custom resources causes Rancher to create the `cattle-logging` namespace in the downstream cluster if it does not exist.
The cluster namespace matches the cluster ID, so we need to find the cluster ID for each cluster.
1. In your web browser, navigate to your cluster(s) in either the Cluster Manager UI or the Cluster Explorer UI.
2. Copy the `<cluster-id>` portion from one of the URLs below. The `<cluster-id>` portion is the cluster namespace name.
```bash
# Cluster Management UI
https://<your-url>/c/<cluster-id>/
# Cluster Explorer UI (Dashboard)
https://<your-url>/dashboard/c/<cluster-id>/
```
Now that we have the `<cluster-id>` namespace, we can delete the CRs that cause `cattle-logging` to be continually recreated.
*Warning:* ensure that logging, the version installed from the Cluster Manager UI, is not currently in use.
```bash
kubectl delete clusterloggings.management.cattle.io -n <cluster-id>
kubectl delete projectloggings.management.cattle.io -n <cluster-id>
```