mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-29 14:38:50 +00:00
Add cattle-logging ns recreation troubleshooting #3064
This commit is contained in:
@@ -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-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
|
- `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:
|
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:
|
spec:
|
||||||
globalOutputRefs:
|
globalOutputRefs:
|
||||||
- "example-es"
|
- "example-es"
|
||||||
```
|
```
|
||||||
|
|
||||||
We should now see our configured index with logs in it.
|
We should now see our configured index with logs in it.
|
||||||
|
|
||||||
@@ -158,7 +158,7 @@ spec:
|
|||||||
containers:
|
containers:
|
||||||
- name: generator
|
- name: generator
|
||||||
image: paynejacob/loggenerator:latest
|
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.
|
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.
|
> **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
|
# Working with Taints and Tolerations
|
||||||
|
|
||||||
"Tainting" a Kubernetes node causes pods to repel running on that node.
|
"Tainting" a Kubernetes node causes pods to repel running on that node.
|
||||||
@@ -314,7 +307,7 @@ spec:
|
|||||||
- key: cattle.io/os
|
- key: cattle.io/os
|
||||||
operator: "Equal"
|
operator: "Equal"
|
||||||
value: "linux"
|
value: "linux"
|
||||||
effect: NoSchedule
|
effect: NoSchedule
|
||||||
nodeSelector:
|
nodeSelector:
|
||||||
kubernetes.io/os: linux
|
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.
|
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.
|
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
|
### Windows Support
|
||||||
|
|
||||||
Clusters with Windows workers support exporting logs from Linux nodes, but Windows node logs are currently unable to be exported.
|
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:
|
fluentbit_tolerations:
|
||||||
# insert tolerations list for fluentbit containers only...
|
# 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>
|
||||||
|
```
|
||||||
|
|||||||
Reference in New Issue
Block a user