mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-27 05:28:22 +00:00
Add v2.14 preview docs (#2212)
This commit is contained in:
Lucas Saintarbor
+12
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: 自定义资源配置
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/logging/custom-resource-configuration"/>
|
||||
</head>
|
||||
|
||||
通过以下自定义资源配置 logging：
|
||||
|
||||
- [Flow 和 ClusterFlow](flows-and-clusterflows.md)
|
||||
- [Output 和 ClusterOutput](outputs-and-clusteroutputs.md)
|
||||
+75
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: Flows 和 ClusterFlows
|
||||
---
|
||||
|
||||
有关如何配置 `Flow` 和 `ClusterFlow` 的完整详细信息，请参阅 [Logging Operator 文档](https://kube-logging.github.io/docs/configuration/flow/)。
|
||||
|
||||
有关如何解决 Logging 缓冲区的内存问题，请参阅 [Rancher 与 Logging 服务的集成：故障排除](../logging.md#日志缓冲区导致-pod-过载)。
|
||||
|
||||
## Flows
|
||||
|
||||
`Flow` 定义要收集和过滤哪些日志，以及将日志发送到哪个 Output。
|
||||
|
||||
`Flow` 是一个命名空间资源。换言之，只有部署了该 Flow 的命名空间日志才能被 `Flow` 收集。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `Flow`。
|
||||
|
||||
有关 `Flow` 自定义资源的更多详细信息，请参阅 [FlowSpec](https://kube-logging.github.io/docs/configuration/crds/v1beta1/flow_types/)。
|
||||
|
||||
### Matches
|
||||
|
||||
匹配语句用于选择从哪些容器中拉取日志。
|
||||
|
||||
你可以指定 match 语句，然后根据 Kubernetes 标签、容器和主机名来选择或排除日志。匹配语句会按照定义和处理的顺序进行评估，直到应用了第一个匹配的选择/排除规则。
|
||||
|
||||
你可以通过填写 Rancher UI 中的 `Flow` 或 `ClusterFlow` 表单来配置匹配。
|
||||
|
||||
使用 match 语句的详细示例，请参阅[日志路由的官方文档](https://kube-logging.github.io/docs/configuration/log-routing/)。
|
||||
|
||||
### Filters
|
||||
|
||||
你可以在 `Flow` 中定义一个或多个过滤器。过滤器可以对日志执行各种操作，例如，添加其他数据、转换日志或解析记录中的值。`Flow` 中的过滤器会按定义的顺序应用。
|
||||
|
||||
有关 Logging Operator 支持的过滤器列表，请参阅 [Fluentd 过滤器的官方文档](https://kube-logging.github.io/docs/configuration/plugins/filters/)。
|
||||
|
||||
过滤器需要在 YAML 中配置。
|
||||
|
||||
### Outputs
|
||||
|
||||
此 `Output` 会接收来自 `Flow` 的日志。由于 `Flow` 是一个命名空间资源，因此 `Output` 必须与 `Flow` 位于相同的命名空间中。
|
||||
|
||||
在 Rancher UI 中填写 `Flow` 或 `ClusterFlow` 表单时，你可以引用`Output`。
|
||||
|
||||
## ClusterFlows
|
||||
|
||||
为 `ClusterFlow` 配置匹配、过滤器和 `Output` 的方式与 `Flow` 的配置方式相同。主要区别在于 `ClusterFlow` 是集群级别的，并且可以跨所有命名空间配置日志收集。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `ClusterFlow`。
|
||||
|
||||
`ClusterFlow` 选择集群中所有命名空间的日志后，集群的日志会被收集并记录到所选的 `ClusterOutput`。
|
||||
|
||||
## YAML 示例
|
||||
|
||||
以下示例 `Flow` 转换了默认命名空间的日志消息，并将日志发送到 S3 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: flow-sample
|
||||
namespace: default
|
||||
spec:
|
||||
filters:
|
||||
- parser:
|
||||
remove_key_name_field: true
|
||||
parse:
|
||||
type: nginx
|
||||
- tag_normaliser:
|
||||
format: ${namespace_name}.${pod_name}.${container_name}
|
||||
localOutputRefs:
|
||||
- s3-output
|
||||
match:
|
||||
- select:
|
||||
labels:
|
||||
app: nginx
|
||||
```
|
||||
+295
@@ -0,0 +1,295 @@
|
||||
---
|
||||
title: Outputs 和 ClusterOutputs
|
||||
---
|
||||
|
||||
有关如何配置 `Flow` 和 `ClusterFlow` 的完整详细信息，请参阅 [Logging Operator 文档](https://kube-logging.github.io/docs/configuration/flow/)。
|
||||
|
||||
有关如何解决 Logging 缓冲区的内存问题，请参阅 [Rancher 与 Logging 服务的集成：故障排除](../logging.md#日志缓冲区导致-pod-过载)。
|
||||
|
||||
## Outputs
|
||||
|
||||
`Output` 资源定义了你的 `Flow` 可以发送日志消息的位置。`Output` 是 Logging `Flow` 的最后阶段。
|
||||
|
||||
`Output` 是命名空间资源，换言之，只有同一命名空间内的 `Flow` 可以访问它。
|
||||
|
||||
你可以在这些定义中使用密文，但这些密文也必须位于同一命名空间中。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `Output`。
|
||||
|
||||
有关 `Output` 自定义资源的更多详细信息，请参阅 [OutputSpec](https://kube-logging.github.io/docs/configuration/crds/v1beta1/output_types/)。
|
||||
|
||||
Rancher UI 提供了用于配置以下类型 `Output` 的表单：
|
||||
|
||||
- Amazon ElasticSearch
|
||||
- Azure Storage
|
||||
- Cloudwatch
|
||||
- Datadog
|
||||
- Elasticsearch
|
||||
- File
|
||||
- Fluentd
|
||||
- GCS
|
||||
- Kafka
|
||||
- Kinesis Stream
|
||||
- LogDNA
|
||||
- LogZ
|
||||
- Loki
|
||||
- New Relic
|
||||
- Splunk
|
||||
- SumoLogic
|
||||
- Syslog
|
||||
|
||||
Rancher UI 提供了用于配置 `Output` 类型、目标和访问凭证（如果适用）的表单。
|
||||
|
||||
有关 Logging Operator 支持的日志插件配置示例，请参阅 [Logging Operator 文档](https://kube-logging.github.io/docs/configuration/plugins/outputs/)。
|
||||
|
||||
## ClusterOutputs
|
||||
|
||||
`ClusterOutput` 定义了一个没有命名空间限制的 `Output`。只有在与 Logging Operator 部署在同一命名空间中时，它才能生效。
|
||||
|
||||
你可以通过在 Rancher UI 中填写表单来配置 `ClusterOutput`。
|
||||
|
||||
有关 `ClusterOutput` 自定义资源的更多详细信息，请参阅 [ClusterOutput](https://kube-logging.github.io/docs/configuration/crds/v1beta1/clusteroutput_types/)。
|
||||
|
||||
## YAML 示例
|
||||
|
||||
安装 Logging 后，你可以参考以下示例来构建你自己的 Logging 流水线：
|
||||
|
||||
- [ClusterOutput 设为 ElasticSearch](#clusteroutput-设为-elasticsearch)
|
||||
- [Output 设为 Splunk](#output-设为-splunk)
|
||||
- [Output 设为 Syslog](#output-设为-syslog)
|
||||
- [不支持的 Output](#不支持的-output)
|
||||
|
||||
### ClusterOutput 设为 ElasticSearch
|
||||
|
||||
假设你想将集群中的所有日志发送到 `elasticsearch` 集群。首先，创建一个集群 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-es"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
elasticsearch:
|
||||
host: elasticsearch.example.com
|
||||
port: 9200
|
||||
scheme: http
|
||||
```
|
||||
|
||||
在与 Operator 相同的命名空间（`cattle-logging-system`）中，我们创建了这个 `ClusterOutput`（没有 elasticsearch 配置）。每次创建 `ClusterFlow` 或 `ClusterOutput` 时，我们都必须将其放在 `cattle-logging-system` 命名空间中。
|
||||
|
||||
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `ClusterOutput`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-es"
|
||||
```
|
||||
|
||||
现在，我们应该能看到配置的包含日志的索引。
|
||||
|
||||
|
||||
### Output 设为 Splunk
|
||||
|
||||
有时候，你的应用程序团队可能只想将某个命名空间的日志发送到 `splunk` 服务器。对于这种情况，你可以使用命名空间范围的 `Output` 和 `Flow`。
|
||||
|
||||
在开始之前，先设置该团队的应用程序 `coolapp`。
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: devteam
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: coolapp
|
||||
namespace: devteam
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
replicas: 2
|
||||
selector:
|
||||
matchLabels:
|
||||
app: coolapp
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: coolapp
|
||||
spec:
|
||||
containers:
|
||||
- name: generator
|
||||
image: paynejacob/loggenerator:latest
|
||||
```
|
||||
|
||||
`coolapp` 运行时，我们将使用与创建 `ClusterOutput` 时类似的路径。但是，我们不使用 `ClusterOutput`，而是在应用程序的命名空间中创建 `Output`。
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Output
|
||||
metadata:
|
||||
name: "devteam-splunk"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
splunkHec:
|
||||
hec_host: splunk.example.com
|
||||
hec_port: 8088
|
||||
protocol: http
|
||||
```
|
||||
|
||||
然后，再次为 `Output` 提供一些日志：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: Flow
|
||||
metadata:
|
||||
name: "devteam-logs"
|
||||
namespace: "devteam"
|
||||
spec:
|
||||
localOutputRefs:
|
||||
- "devteam-splunk"
|
||||
```
|
||||
|
||||
|
||||
### Output 设为 Syslog
|
||||
|
||||
假设你想将集群中的所有日志发送到 `syslog` 服务器。首先，我们创建一个 `ClusterOutput`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: "example-syslog"
|
||||
namespace: "cattle-logging-system"
|
||||
spec:
|
||||
syslog:
|
||||
buffer:
|
||||
timekey: 30s
|
||||
timekey_use_utc: true
|
||||
timekey_wait: 10s
|
||||
flush_interval: 5s
|
||||
format:
|
||||
type: json
|
||||
app_name_field: test
|
||||
host: syslog.example.com
|
||||
insecure: true
|
||||
port: 514
|
||||
transport: tcp
|
||||
```
|
||||
|
||||
配置日志的目的位置后，我们可以尝试将所有日志都配置到该 `Output`：
|
||||
|
||||
```yaml
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: "all-logs"
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- "example-syslog"
|
||||
```
|
||||
|
||||
### 不支持的 Output
|
||||
|
||||
对于最后一个示例，我们创建一个 `Output` 来将日志写入到不是开箱即用的目标位置：
|
||||
|
||||
:::note Syslog 注意事项：
|
||||
|
||||
`Syslog` 是受支持的 `Output`。但是，此示例仍提供了不受支持的插件概述。
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: syslog-config
|
||||
namespace: cattle-logging-system
|
||||
type: Opaque
|
||||
stringData:
|
||||
fluent-bit.conf: |
|
||||
[INPUT]
|
||||
Name forward
|
||||
Port 24224
|
||||
|
||||
[OUTPUT]
|
||||
Name syslog
|
||||
InstanceName syslog-output
|
||||
Match *
|
||||
Addr syslog.example.com
|
||||
Port 514
|
||||
Cluster ranchers
|
||||
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: fluentbit-syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
selector:
|
||||
matchLabels:
|
||||
output: syslog
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
output: syslog
|
||||
spec:
|
||||
containers:
|
||||
- name: fluentbit
|
||||
image: paynejacob/fluent-bit-out-syslog:latest
|
||||
ports:
|
||||
- containerPort: 24224
|
||||
volumeMounts:
|
||||
- mountPath: "/fluent-bit/etc/"
|
||||
name: configuration
|
||||
volumes:
|
||||
- name: configuration
|
||||
secret:
|
||||
secretName: syslog-config
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: syslog-forwarder
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
selector:
|
||||
output: syslog
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 24224
|
||||
targetPort: 24224
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterFlow
|
||||
metadata:
|
||||
name: all-logs
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
globalOutputRefs:
|
||||
- syslog
|
||||
---
|
||||
apiVersion: logging.banzaicloud.io/v1beta1
|
||||
kind: ClusterOutput
|
||||
metadata:
|
||||
name: syslog
|
||||
namespace: cattle-logging-system
|
||||
spec:
|
||||
forward:
|
||||
servers:
|
||||
- host: "syslog-forwarder.cattle-logging-system"
|
||||
require_ack_response: false
|
||||
ignore_network_errors_at_startup: false
|
||||
```
|
||||
|
||||
现在，我们分解这里的内容。首先，我们创建一个容器 Deployment，该容器具有额外的 `syslog` 插件并支持转发自另一个 `fluentd` 的日志。接下来，我们创建一个配置为 Deployment 转发器的 `Output`。然后，Deployment `fluentd` 会将所有日志转发到配置的 `syslog` 目标。
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: 架构
|
||||
---
|
||||
|
||||
本节介绍了 Rancher Logging 应用程序的架构。
|
||||
|
||||
有关 Logging Operator 工作原理的更多详细信息，请参阅[官方文档](https://kube-logging.github.io/docs/#architecture)。
|
||||
|
||||
## Logging Operator 工作原理
|
||||
|
||||
Logging Operator 自动部署和配置 Kubernetes 日志流水线。它会在每个节点上部署和配置一个 Fluent Bit DaemonSet，从而收集节点文件系统中的容器和应用程序日志。
|
||||
|
||||
Fluent Bit 查询 Kubernetes API 并使用 pod 的元数据来丰富日志，然后将日志和元数据都传输到 Fluentd。Fluentd 会接收和过滤日志并将日志传输到多个`Output`。
|
||||
|
||||
以下自定义资源用于定义了如何过滤日志并将日志发送到 `Output`：
|
||||
|
||||
- `Flow` 是一个命名空间自定义资源，它使用过滤器和选择器将日志消息路由到对应的 `Output`。
|
||||
- `ClusterFlow` 用于路由集群级别的日志消息。
|
||||
- `Output` 是一个命名空间资源，用于定义发送日志消息的位置。
|
||||
- `ClusterOutput` 定义了一个所有 `Flow` 和 `ClusterFlow` 都可用的 `Output`。
|
||||
|
||||
每个 `Flow` 都必须引用一个 `Output`，而每个 `ClusterFlow` 都必须引用一个 `ClusterOutput`。
|
||||
|
||||
[Logging Operator 文档](https://kube-logging.github.io/docs/#architecture)中的下图显示了新的 Logging 架构：
|
||||
|
||||
<figcaption>Logging Operator 如何与 Fluentd 和 Fluent Bit 一起使用</figcaption>
|
||||
|
||||
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
---
|
||||
title: rancher-logging Helm Chart 选项
|
||||
---
|
||||
|
||||
## 启用/禁用 Windows 节点 Logging
|
||||
|
||||
要启用或禁用 Windows 节点 Logging，你可以在 `values.yaml` 中将 `global.cattle.windows.enabled` 设置为 `true` 或 `false`。
|
||||
|
||||
默认情况下，如果使用 Cluster Dashboard UI 在 Windows 集群上安装了 Logging 应用程序，Windows 节点的 Logging 就会启用。
|
||||
|
||||
在这种情况下，将 `global.cattle.windows.enabled` 设置为 `false` 会禁用集群上的 Windows 节点 Logging。
|
||||
禁用后，仍会从 Windows 集群中的 Linux 节点收集日志。
|
||||
|
||||
:::note
|
||||
|
||||
目前存在一个[问题](https://github.com/rancher/rancher/issues/32325)，在 Windows 集群中禁用 Windows Logging 后执行 `helm upgrade` 时不会删除 Windows nodeAgent。在这种情况下，如果已安装 Windows nodeAgents，用户可能需要手动卸载它们。
|
||||
|
||||
:::
|
||||
|
||||
## 使用自定义 Docker 根目录
|
||||
|
||||
如果使用了自定义 Docker 根目录，你可以在 `values.yaml` 中设置 `global.dockerRootDirectory`。
|
||||
|
||||
这将确保创建的 Logging CR 使用你指定的路径，而不是使用默认的 Docker `data-root` 位置。
|
||||
|
||||
请注意，这只影响 Linux 节点。
|
||||
|
||||
如果集群中有任何 Windows 节点，则更改将不适用于这些节点。
|
||||
|
||||
## 为自定义污点添加 NodeSelector 设置和容忍度
|
||||
|
||||
你可以添加 `nodeSelector` 设置，并通过编辑 Logging Helm Chart 值来添加其他`容忍度`。有关详细信息，请参阅[此页面](taints-and-tolerations.md)。
|
||||
|
||||
## 启用 Logging 应用程序以使用 SELinux
|
||||
|
||||
:::note 要求：
|
||||
|
||||
Logging v2 已在 RHEL/CentOS 7 和 8 上使用 SELinux 进行了测试。
|
||||
|
||||
:::
|
||||
|
||||
[安全增强型 Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) 是对 Linux 的安全增强。被政府机构使用之后，SELinux 已成为行业标准，并在 CentOS 7 和 8 上默认启用。
|
||||
|
||||
要配合使用 Logging V2 与 SELinux，我们建议你根据[此说明](../../reference-guides/rancher-security/selinux-rpm/selinux-rpm.md)安装 `rancher-selinux` RPM。
|
||||
|
||||
然后，在安装 Logging 应用程序时，在 `values.yaml` 中将 `global.seLinux.enabled` 更改为 `true`，使 Chart 支持 SELinux。
|
||||
|
||||
## 其他日志来源
|
||||
|
||||
默认情况下，Rancher 会收集所有类型集群的 [controlplane 组件](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components)和[节点组件](https://kubernetes.io/docs/concepts/overview/components/#node-components)的日志。
|
||||
|
||||
在某些情况下，Rancher 也能收集其他的日志。
|
||||
|
||||
下表总结了每种节点类型可以收集的其他日志来源：
|
||||
|
||||
| 日志来源 | Linux 节点（包括在 Windows 集群中） | Windows 节点 |
|
||||
| --- | --- | ---|
|
||||
| RKE2 | ✓ | |
|
||||
| K3s | ✓ | |
|
||||
| AKS | ✓ | |
|
||||
| EKS | ✓ | |
|
||||
| GKE | ✓ | |
|
||||
|
||||
要将托管 Kubernetes 的提供商作为额外的日志来源，在安装或升级 Logging Helm Chart 时，请启用 **Enable enhanced cloud provider logging** 选项。
|
||||
|
||||
启用后，Rancher 会收集提供商开放可用的所有其他节点和 controlplane 日志，不同提供商可能有所不同。
|
||||
|
||||
如果你已经使用了云提供商的日志解决方案，例如 AWS CloudWatch 或 Google Cloud Operations Suite（以前称为 Stackdriver），由于原生解决方案可以不受限制地访问所有日志，因此你无需启用此选项。
|
||||
|
||||
## Systemd 配置
|
||||
|
||||
在 Rancher Logging 中，你必须为 K3s 和 RKE2 Kubernetes 发行版配置 `SystemdLogPath`。
|
||||
|
||||
K3s 和 RKE2 Kubernetes 发行版将日志写入到 journald，它是 systemd 的子系统，用于日志记录。要收集这些日志，你需要定义 `systemdLogPath`。默认路径是 `run/log/journal`，但某些 Linux 发行版不默认使用该路径。例如，Ubuntu 默认使用 `var/log/journal`。要确定你的 `systemdLogPath` 配置，请参阅以下步骤。
|
||||
|
||||
**Systemd 配置步骤：**
|
||||
|
||||
* 在其中一个节点上运行 `cat /etc/systemd/journald.conf | grep -E ^\#?Storage | cut -d"=" -f2`。
|
||||
* 如果返回 `persistent`，则你的 `systemdLogPath` 是 `/var/log/journal`。
|
||||
* 如果返回 `volatile`，则你的 `systemdLogPath` 是 `/run/log/journal`。
|
||||
* 如果返回 `auto`，则检查 `/var/log/journal` 是否存在。
|
||||
* 如果 `/var/log/journal` 存在，则使用 `/var/log/journal`。
|
||||
* 如果 `/var/log/journal` 不存在，则使用 `/run/log/journal`。
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
如果返回的值不包括在上述描述中，Rancher Logging 将无法收集 controlplane 日志。要解决此问题，你需要在每个 controlplane 节点上执行以下操作。
|
||||
|
||||
* 在 journald.conf 中设置 `Storage=volatile`。
|
||||
* 重启主机。
|
||||
* 将 `systemdLogPath` 设置为 `/run/log/journal`。
|
||||
|
||||
:::
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
---
|
||||
title: Rancher Logging 集成
|
||||
description: Rancher 集成了主流的日志服务。了解集成日志服务的要求和优势，并在你的集群上启用 Logging。
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/zh/integrations-in-rancher/logging"/>
|
||||
</head>
|
||||
|
||||
现在，Rancher 的日志管理由 [Logging operator](https://kube-logging.github.io/docs/) 提供支持，它取代了以前的内部解决方案。
|
||||
|
||||
## 启用 Logging
|
||||
|
||||
你可以转到**应用**页面并安装 Logging 应用程序，从而为 Rancher 管理的集群启用 Logging：
|
||||
|
||||
1. 转到要安装 Logging 的集群，然后单击 **Apps**。
|
||||
1. 点击 **Logging** 应用。
|
||||
1. 滚动到 Helm Chart README 的底部，然后单击**安装**。
|
||||
|
||||
**结果**：Logging 应用已部署到 `cattle-logging-system` 命名空间中。
|
||||
|
||||
## 卸载 Logging
|
||||
|
||||
1. 转到要安装 Logging 的集群，然后单击 **Apps**。
|
||||
1. 点击**已安装的应用**。
|
||||
1. 转到 `cattle-logging-system` 命名空间并选中 `rancher-logging` 和 `rancher-logging-crd` 框。
|
||||
1. 单击**删除**。
|
||||
1. 确认**删除**。
|
||||
|
||||
**结果**：已卸载 `rancher-logging`。
|
||||
|
||||
## 架构
|
||||
|
||||
有关 Logging 应用程序工作原理的更多信息，请参阅[本节](logging-architecture.md)。
|
||||
|
||||
## RBAC
|
||||
|
||||
Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`。有关如何以及何时使用这些角色的更多信息，请参阅[此页面](rbac-for-logging.md)。
|
||||
|
||||
## 配置 Logging 自定义资源
|
||||
|
||||
要管理 `Flows`、`ClusterFlows`、`Outputs` 和 `ClusterOutputs`：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
2. 在**集群**页面上，转到要配置 Logging 自定义资源的集群，然后单击 **Explore**。
|
||||
3. 在左侧导航栏中，单击 **Logging**。
|
||||
|
||||
### Flows 和 ClusterFlows
|
||||
|
||||
有关配置 `Flows` 和 `ClusterFlows` 的帮助，请参阅[此页面](custom-resource-configuration/flows-and-clusterflows.md)。
|
||||
|
||||
### Outputs 和 ClusterOutputs
|
||||
|
||||
有关配置 `Outputs` 和 `ClusterOutputs` 的帮助，请参阅[此页面](custom-resource-configuration/outputs-and-clusteroutputs.md)。
|
||||
|
||||
## 配置 Logging Helm Chart
|
||||
|
||||
有关在安装或升级 Logging 应用程序时可配置的选项，请参阅[此页面](logging-helm-chart-options.md)。
|
||||
|
||||
### Windows 支持
|
||||
|
||||
你可以从 Windows 节点[启用 Logging](logging-helm-chart-options.md#启用禁用-windows-节点-logging)。
|
||||
|
||||
### 使用自定义 Docker 根目录
|
||||
|
||||
有关使用自定义 Docker 根目录的详细信息，请参阅[本节](logging-helm-chart-options.md#使用自定义-docker-根目录)。
|
||||
|
||||
### 处理污点和容忍度
|
||||
|
||||
有关如何在 Logging 应用程序中使用污点和容忍度的信息，请参阅[此页面](taints-and-tolerations.md)。
|
||||
|
||||
### 在 SELinux 上使用 Logging V2
|
||||
|
||||
有关在启用了 SELinux 的节点上使用 Logging 应用程序的信息，请参阅[本节](logging-helm-chart-options.md#启用-logging-应用程序以使用-selinux)。
|
||||
|
||||
### 其他日志来源
|
||||
|
||||
默认情况下，Rancher 会收集所有类型集群的 controlplane 组件和节点组件的日志。在某些情况下，也会收集其他日志。有关详细信息，请参阅[本节](logging-helm-chart-options.md#其他日志来源)。
|
||||
|
||||
## 故障排除
|
||||
|
||||
### 日志缓冲区导致 Pod 过载
|
||||
|
||||
根据你的配置，默认缓冲区大小可能太大并导致 Pod 故障。减少负载的一种方法是降低记录器的刷新间隔。这可以防止日志溢出缓冲区。你还可以添加更多刷新线程来处理大量日志试图同时填充缓冲区的情况。
|
||||
|
||||
有关如何配置日志缓冲区来满足企业需求的更完整说明，请参阅[缓冲区](https://kube-logging.github.io/docs/configuration/plugins/outputs/buffer/)和 [Fluentd 配置](https://kube-logging.github.io/docs/logging-infrastructure/fluentd/)的官方 Logging Operator 文档。
|
||||
|
||||
### `cattle-logging` 命名空间正在重新创建
|
||||
|
||||
如果你的集群之前在旧版 Rancher UI 的全局视图中部署了 Logging，`cattle-logging` 命名空间可能会不断被重新创建。
|
||||
|
||||
要解决这个问题，你可以将所有 `clusterloggings.management.cattle.io` 和 `projectloggings.management.cattle.io` 自定义资源从管理集群中针对该集群的命名空间中删除。
|
||||
这些自定义资源会导致 Rancher 在下游集群中创建 `cattle-logging` 命名空间（如果不存在）。
|
||||
|
||||
集群命名空间与集群 ID 匹配，因此我们需要找到每个集群的集群 ID。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 在**集群**页面上，转到要获取 ID 的集群，然后单击 **Explore**。
|
||||
2. 从以下其中一个 URL 中复制 `<cluster-id>` 的内容。`<cluster-id>` 是集群命名空间名称。
|
||||
|
||||
```bash
|
||||
# Cluster Management UI
|
||||
https://<your-url>/c/<cluster-id>/
|
||||
|
||||
# Cluster Dashboard
|
||||
https://<your-url>/dashboard/c/<cluster-id>/
|
||||
```
|
||||
|
||||
现在我们有了 `<cluster-id>` 命名空间，我们可以删除导致 `cattle-logging` 不断重新创建的自定义资源。
|
||||
*警告*：请确保当前未使用 Logging （从旧版 Rancher UI 全局视图中安装的版本）。
|
||||
|
||||
```bash
|
||||
kubectl delete crd clusterloggings.management.cattle.io -n <cluster-id>
|
||||
kubectl delete crd projectloggings.management.cattle.io -n <cluster-id>
|
||||
```
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: Logging 的 RBAC
|
||||
---
|
||||
|
||||
Rancher Logging 有两个角色，分别是 `logging-admin` 和 `logging-view`。
|
||||
|
||||
- `logging-admin` 允许用户完全访问命名空间的 `Flow` 和 `Output`。
|
||||
- `logging-view` 允许用户*查看*命名空间的 `Flow` 和 `Output`，以及 `ClusterFlow` 和 `ClusterOutput`。
|
||||
|
||||
:::note 为什么选择一个角色而不是另一个角色？
|
||||
|
||||
`ClusterFlow` 和 `ClusterOutput` 资源的编辑权限非常强大。任何拥有该权限的用户都能编辑集群中的所有日志。
|
||||
|
||||
:::
|
||||
|
||||
在 Rancher 中，集群管理员角色是唯一可以完全访问所有 `rancher-logging` 资源的角色。集群成员无法编辑或读取任何 Logging 资源。项目所有者和成员具有以下权限：
|
||||
|
||||
| 项目所有者 | 项目成员 |
|
||||
--- | ---
|
||||
| 能够在其项目命名空间中创建命名空间级别的 `Flow` 和 `Output` | 只能查看项目命名空间中的 `Flow` 和 `Output` |
|
||||
| 可以从项目命名空间中收集任何日志 | 无法在其项目命名空间中收集任何日志 |
|
||||
|
||||
如果项目所有者和项目成员需要使用 Logging，他们需要在项目中至少有*一个*命名空间。如果没有，他们可能看不到顶部导航下拉列表中的 Logging 按钮。
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: 处理污点和容忍度
|
||||
---
|
||||
|
||||
在 Kubernetes 节点上添加污点会导致 pod 排斥在该节点上运行。
|
||||
|
||||
除非 pod 对该节点的污点具有`容忍度`（toleration），否则 Pod 将在集群中的其他节点上运行。
|
||||
|
||||
[污点和容忍度](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)可以与 `PodSpec` 中的 `nodeSelector` [字段](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)一起使用，从而实现*相反的*污点效果。
|
||||
|
||||
`nodeSelector` 可以使 pod 被吸引到某类节点。
|
||||
|
||||
两者都能让 pod 选择在哪个节点上运行。
|
||||
|
||||
- [Rancher 日志堆栈中的默认实现](#rancher-日志堆栈中的默认实现)
|
||||
- [为自定义污点添加 NodeSelector 设置和容忍度](#为自定义污点添加-nodeselector-设置和容忍度)
|
||||
|
||||
## Rancher 日志堆栈中的默认实现
|
||||
|
||||
默认情况下，Rancher 使用 `cattle.io/os=linux` 来将污点应用到所有 Linux 节点，而不影响 Windows 节点。
|
||||
日志堆栈 pod 具有针对此污点的`容忍度`，因此它们能够运行在 Linux 节点上。
|
||||
此外，大多数日志堆栈 pod 仅在 Linux 上运行，并添加了 `nodeSelector` 以确保它们在 Linux 节点上运行。
|
||||
|
||||
此示例 Pod YAML 文件显示了与容忍度一起使用的 nodeSelector：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
# metadata...
|
||||
spec:
|
||||
# containers...
|
||||
tolerations:
|
||||
- key: cattle.io/os
|
||||
operator: "Equal"
|
||||
value: "linux"
|
||||
effect: NoSchedule
|
||||
nodeSelector:
|
||||
kubernetes.io/os: linux
|
||||
```
|
||||
|
||||
在上面的示例中，我们确保了的 pod 仅在 Linux 节点上运行，并且为所有 Linux 节点上的污点添加了`容忍度`。
|
||||
|
||||
你可以对 Rancher 现有的污点或你自己的自定义污点执行相同的操作。
|
||||
|
||||
## 为自定义污点添加 NodeSelector 设置和容忍度
|
||||
|
||||
如果要添加你自己的 `nodeSelector` 设置，或者要为其他污点添加 `容忍度`，你可以将以下内容传递给 Chart 的值：
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
# insert tolerations...
|
||||
nodeSelector:
|
||||
# insert nodeSelector...
|
||||
```
|
||||
|
||||
这些值会将这两个设置添加到 `fluentd`、`fluentbit`和 `logging-operator` 容器中。
|
||||
本质上，这些是日志堆栈中所有 pod 的全局设置。
|
||||
|
||||
但是，如果你想*仅*为 `fluentbit` 容器添加容忍度，你可以将以下内容添加到 Chart 的值中：
|
||||
|
||||
```yaml
|
||||
fluentbit_tolerations:
|
||||
# insert tolerations list for fluentbit containers only...
|
||||
```
|
||||
Reference in New Issue
Block a user