规划用于日志存储的 Infra 节点

本指南介绍在专用 Kubernetes infra 节点上运行 Logging 存储组件时需要考虑的规划事项。

目标

隔离资源：避免与业务工作负载争用资源。
确保稳定性：减少驱逐和调度冲突。
简化管理：通过一致的调度规则集中管理 infra 组件。

配置放置位置

存储侧工作负载（Razor、aggregate-vector 和一次性 schema-migrations Job）由 log-storage-operator 根据 PlatformLogForward 派生。请通过插件安装表单或底层的 ModuleInfo 设置其放置规则；不要直接修改生成的 Deployment。

对于 Alauda Container Platform Log Storage Management（ClickHouse 或 OpenSearch 后端），请使用 operator 安装表单中的 Advanced Configuration 部分设置节点选择器和容忍度。请参阅安装。
对于 Alauda Container Platform Log Collector（DaemonSet），请在采集器集群上使用插件安装表单；同样适用 Advanced Configuration 部分。
对于 Alauda Container Platform Log Storage for Elasticsearch（旧版），请在该插件的 ACP 4.3 文档中通过 spec.valuesOverride.ait/chart-alauda-log-center.global.nodeSelector 和 spec.valuesOverride.ait/chart-alauda-log-center.global.tolerations 配置放置规则。

不要将修改生成的 StatefulSet、Deployment 或 ClickHouseInstallation 资源作为在 infra 节点上放置 Logging 存储工作负载的标准方式。

配置放置规则前

根据 Cluster Node Planning 规划 infra 节点。
确认存储是否使用 LocalVolume 或具有 spec.nodeAffinity 的其他 PV。
确保所选 infra 节点同时满足调度规则和存储放置约束。

INFO

在 Alauda OS 节点上，本地存储路径位于 /var/cpaas 下，例如 /var/cpaas/data/clickhouse 或 /var/cpaas/data/nevermore。这些节点是不可变的，传统操作系统的目录结构 /cpaas 在这些节点上不可写入。规划 infra 节点时，请确保 /var/cpaas 路径由可在节点重新部署后仍然保留的持久磁盘提供支持，并注意这些节点上的 pv.spec.local.path 将引用 /var/cpaas 路径，而不是以下示例中显示的 /cpaas 路径。有关各插件参数，请参阅安装。

检查 Local PV 和 nodeAffinity

如果组件使用本地存储（例如 TopoLVM、Local PV），请确认 PV 是否具有 spec.nodeAffinity。如果有，请执行以下任一操作：

将 pv.spec.nodeAffinity 引用的所有节点添加到 infra 节点组，或
使用不带节点亲和性的存储类重新部署组件（例如 Ceph/RBD）。

示例（Elasticsearch）：

# 1) Get ES PVCs
kubectl get pvc -n cpaas-system | grep elastic

# 2) Inspect one PV
kubectl get pv elasticsearch-log-node-pv-192.168.135.243 -o yaml

如果 PV 显示：

spec:
  local:
    path: /cpaas/data/elasticsearch/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - 192.168.135.243

则 Elasticsearch 数据已固定到节点 192.168.135.243。请确保该节点属于 infra 节点组，或迁移存储。

同样的原则适用于任何使用节点绑定本地存储的 Logging 存储组件。

历史 Kafka 和 Zookeeper 节点

Kafka 以 KRaft 模式运行，不会部署 Zookeeper。但是，从早期版本升级的集群可能仍在使用历史 Kafka 和 Zookeeper 节点标签。请确保带有历史标签的任何 Kafka 或 Zookeeper 节点也包含在 infra 节点组中：

kubectl get nodes -l kafka=true
kubectl get nodes -l zk=true
# Add the listed nodes into infra nodes as above.

新配置的集群只需要 kafka 标签；不会使用 zk 标签。

故障排除

常见问题和修复方法：

问题	诊断	解决方案
Pod 卡在 Pending 状态	`kubectl describe pod <pod> \| grep Events`	添加容忍度或调整选择器
污点/容忍度不匹配	`kubectl describe node <node> \| grep Taints`	为工作负载添加匹配的容忍度
资源不足	`kubectl top nodes -l node-role.kubernetes.io/infra`	扩容 infra 节点或调整资源请求

错误示例：

Events:
  Warning  FailedScheduling  2m  default-scheduler  0/3 nodes are available:
  3 node(s) had untolerated taint {node-role.kubernetes.io/infra: true}

修复方法：在插件配置中添加匹配的容忍度，并确保所选 infra 节点同时满足所需的存储放置约束。

#规划用于日志存储的 Infra 节点

#目录

#目标

#配置放置位置

#配置放置规则前

#检查 Local PV 和 nodeAffinity

#历史 Kafka 和 Zookeeper 节点

#故障排除