为日志存储规划 Infra 节点

本指南说明了在专用 Kubernetes infra 节点上运行 Logging 存储插件时的规划注意事项。

目标

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

在哪里配置放置规则

对于 Alauda Container Platform Log Storage for Elasticsearch，请通过 Installation 中的 spec.valuesOverride.ait/chart-alauda-log-center.global.nodeSelector 和 spec.valuesOverride.ait/chart-alauda-log-center.global.tolerations 配置放置规则。
对于 Alauda Container Platform Log Storage for ClickHouse，请通过控制台中的 Advanced Configuration 配置放置规则，或通过 Installation 中的 spec.config.components.nodeSelector 和 spec.config.components.tolerations 进行配置。

不要通过 patch 生成的 StatefulSets、Deployments 或 ClickHouseInstallation 资源来作为在 infra 节点上放置 Logging 存储工作负载的标准方式。

在配置放置规则之前

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

INFO

在 Alauda OS 节点上，本地存储路径位于 /var/cpaas 下，例如 /var/cpaas/data/clickhouse 或 /var/cpaas/data/elasticsearch。这些节点是不可变的，并且传统操作系统的 /cpaas 目录布局在此处不可写。请规划 infra 节点，使 /var/cpaas 路径由在节点重新预配后仍然保留的持久化磁盘提供支持，并且这些节点上的 pv.spec.local.path 应引用 /var/cpaas 路径，而不是下方示例中显示的 /cpaas 路径。有关各插件的参数，请参见 Installation。

检查 Local PV 和 nodeAffinity

如果你的组件使用本地存储（例如 TopoLVM、local PV），请确认 PV 是否带有 spec.nodeAffinity。如果有，则需要：

将 pv.spec.nodeAffinity 中引用的所有节点都加入 infra 节点组，或者
使用不带 node affinity 的 storage class 重新部署组件（例如 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 和 ZooKeeper 节点也被标记/加上 taint，作为 infra 节点：

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

故障排查

常见问题及解决方法：

问题	诊断	解决方案
Pod 一直处于 Pending	`kubectl describe pod <pod> \| grep Events`	添加 tolerations 或调整 selector
taint/toleration 不匹配	`kubectl describe node <node> \| grep Taints`	为工作负载添加匹配的 tolerations
资源不足	`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}

修复方法：为插件配置添加匹配的 tolerations，并确保所选 infra 节点也满足所需的存储放置约束。

#为日志存储规划 Infra 节点

#目录

#目标

#在哪里配置放置规则

#在配置放置规则之前

#检查 Local PV 和 nodeAffinity

#历史 Kafka 和 ZooKeeper 节点

#故障排查