3.3. 增强了 Loki 的可靠性和性能
使用以下配置来确保生产环境中的 Loki 的可靠性和效率。
3.3.1. Loki pod 放置 复制链接链接已复制到粘贴板!
您可以通过在 pod 上使用容忍度或节点选择器来控制 Loki pod 在哪些节点上运行,并防止其他工作负载使用这些节点。
您可以使用 LokiStack 自定义资源 (CR) 将容限应用到日志存储 pod,并将污点应用到具有节点规格的节点。节点上的污点是一个 key:value 对,它指示节点排斥所有不允许污点的 pod。通过使用不在其他 pod 上的特定 key:value 对,可确保只有日志存储 pod 能够在该节点上运行。
带有节点选择器的 LokiStack 示例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
# ...
template:
compactor:
nodeSelector:
node-role.kubernetes.io/infra: ""
distributor:
nodeSelector:
node-role.kubernetes.io/infra: ""
gateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
indexGateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
ingester:
nodeSelector:
node-role.kubernetes.io/infra: ""
querier:
nodeSelector:
node-role.kubernetes.io/infra: ""
queryFrontend:
nodeSelector:
node-role.kubernetes.io/infra: ""
ruler:
nodeSelector:
node-role.kubernetes.io/infra: ""
# ...
带有节点选择器和容限的 LokiStack CR 示例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
# ...
template:
compactor:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
distributor:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
indexGateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
ingester:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
querier:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
queryFrontend:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
ruler:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
gateway:
nodeSelector:
node-role.kubernetes.io/infra: ""
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/infra
value: reserved
- effect: NoExecute
key: node-role.kubernetes.io/infra
value: reserved
# ...
要配置 LokiStack (CR) 的 nodeSelector 和 tolerations 字段,您可以使用 oc explain 命令查看特定资源的描述和字段:
$ oc explain lokistack.spec.template
输出示例
KIND: LokiStack
VERSION: loki.grafana.com/v1
RESOURCE: template <Object>
DESCRIPTION:
Template defines the resource/limits/tolerations/nodeselectors per
component
FIELDS:
compactor <Object>
Compactor defines the compaction component spec.
distributor <Object>
Distributor defines the distributor component spec.
...
如需更多信息,您可以添加一个特定字段:
$ oc explain lokistack.spec.template.compactor
输出示例
KIND: LokiStack
VERSION: loki.grafana.com/v1
RESOURCE: compactor <Object>
DESCRIPTION:
Compactor defines the compaction component spec.
FIELDS:
nodeSelector <map[string]string>
NodeSelector defines the labels required by a node to schedule the
component onto it.
...
3.3.2. 配置 Loki 以容忍节点故障 复制链接链接已复制到粘贴板!
在日志记录 5.8 及更新的版本中,Loki Operator 支持设置 pod 反关联性规则,以请求同一组件的 pod 调度到集群中的不同可用节点上。
关联性是 pod 的一个属性,用于控制它们希望调度到的节点。反关联性是 pod 的一个属性,用于阻止 pod 调度到某个节点上。
在 OpenShift Container Platform 中,可以借助 pod 关联性和 pod 反关联性来根据其他 pod 上的键/值标签限制 pod 有资格调度到哪些节点。
Operator 会为所有 Loki 组件设置默认、首选的 podAntiAffinity 规则,其中包括 compactor, distributor, gateway, indexGateway, ingester, querier, queryFrontend, 和 ruler 组件。
您可以通过在 requiredDuringSchedulingIgnoredDuringExecution 字段中配置所需的设置来覆盖 Loki 组件的首选 podAntiAffinity 设置:
ingester 组件的用户设置示例
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
# ...
template:
ingester:
podAntiAffinity:
# ...
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app.kubernetes.io/component: ingester
topologyKey: kubernetes.io/hostname
# ...
3.3.3. 使用 Loki 启用基于流的保留 复制链接链接已复制到粘贴板!
您可以根据日志流配置保留策略。您可以在全局范围内、每个租户或两者都设置保留规则。如果同时配置这两个,则租户规则会在全局规则之前应用。
如果没有在 s3 存储桶或 LokiStack 自定义资源 (CR) 中定义保留周期,则不会修剪日志,它们会永久保留在 s3 存储桶中,这可能会填满 s3 存储。
-
虽然日志记录版本 5.9 及更新的版本支持 schema
v12,但推荐使用 schemav13以获得将来的兼容性。 为了有效地进行日志修剪,请直接在对象存储供应商上配置保留策略。使用存储供应商的生命周期管理功能来确保自动删除旧日志。这也可避免从 Loki 额外处理并删除对 S3 的请求。
如果对象存储不支持生命周期策略,您必须将 LokiStack 配置为在内部强制保留。支持的保留周期最多为 30 天。
先决条件
- 有管理员权限。
- 已安装 Loki Operator。
-
已安装 OpenShift CLI(
oc)。
流程
要启用基于流的保留,请创建一个
LokiStackCR,并将它保存为 YAML 文件。在以下示例中,它名为lokistack.yaml。S3 的全局基于流的保留示例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: limits: global:1 retention:2 days: 20 streams: - days: 4 priority: 1 selector: '{kubernetes_namespace_name=~"test.+"}'3 - days: 1 priority: 1 selector: '{log_type="infrastructure"}' managementState: Managed replicationFactor: 1 size: 1x.small storage: schemas: - effectiveDate: "2020-10-11" version: v13 secret: name: logging-loki-s3 type: s3 storageClassName: gp3-csi tenants: mode: openshift-loggingS3 基于每个租户流的保留示例
apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki namespace: openshift-logging spec: limits: global: retention: days: 20 tenants:1 application: retention: days: 1 streams: - days: 4 selector: '{kubernetes_namespace_name=~"test.+"}'2 infrastructure: retention: days: 5 streams: - days: 1 selector: '{kubernetes_namespace_name=~"openshift-cluster.+"}' managementState: Managed replicationFactor: 1 size: 1x.small storage: schemas: - effectiveDate: "2020-10-11" version: v13 secret: name: logging-loki-s3 type: s3 storageClassName: gp3-csi tenants: mode: openshift-logging应用
LokiStackCR:$ oc apply -f lokistack.yaml
3.3.4. 配置 Loki 以容许 memberlist 创建失败 复制链接链接已复制到粘贴板!
在 OpenShift Container Platform 集群中,管理员通常使用非专用 IP 网络范围。因此,Loki memberlist 配置会失败,因为默认情况下,它只使用私有 IP 网络。
作为管理员,您可以为 memberlist 配置选择 pod 网络。您可以修改 LokiStack 自定义资源(CR)以使用 hashRing spec 中的 podIP 地址。要配置 LokiStack CR,请使用以下命令:
$ oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'
LokiStack 示例,使其包含 podIP
apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
name: logging-loki
namespace: openshift-logging
spec:
# ...
hashRing:
type: memberlist
memberlist:
instanceAddrType: podIP
# ...
3.3.5. 集群重启过程中的 LokiStack 行为 复制链接链接已复制到粘贴板!
当 OpenShift Container Platform 集群重启时,LokiStack ingestion 和查询路径将继续在可用于节点的可用 CPU 和内存资源中运行。这意味着 OpenShift Container Platform 集群更新过程中,LokiStack 没有停机。此行为通过使用 PodDisruptionBudget 资源来实现。Loki Operator 为 Loki 置备 PodDisruptionBudget 资源,它决定了每个组件必须可用的最少 pod 数量,以确保特定条件下正常操作。