16. Kubernetes运维篇-日志收集

EFK日志收集-Fluentd

简介

此处EFK指的是Elasticsearch+Fluentd+Kibana,主要用于收集宿主机日志

组件介绍

Elasticsearch + Fluentd + Kibana(通常简称为EFK)是一个流行的日志管理和分析堆栈,它结合了Elasticsearch的强大搜索和分析能力、Fluentd的高效日志收集以及Kibana的数据可视化功能。

  1. Elasticsearch
    • 一个开源的搜索引擎,基于Lucene构建,用于存储、搜索和分析大量数据。
    • 提供了强大的全文搜索能力,以及复杂的搜索和分析功能。
    • 数据以JSON文档的形式存储,易于扩展和分布式部署。
  2. Fluentd
    • 一个开源的数据收集器,用于统一日志收集。
    • 通过插件系统支持多种数据源和输出,可以轻松地收集和转发日志数据。
    • 高效的数据处理能力,以及低资源消耗,使其成为日志收集的理想选择。
    • Fluentd通常用作日志收集的“胶水”,因为它能够将来自不同来源的数据统一格式化并转发到各种后端系统。
  3. Kibana
    • 一个开源的数据可视化和仪表盘工具,与Elasticsearch紧密集成。
    • 允许用户创建可视化的仪表盘,以直观地展示和分析存储在Elasticsearch中的数据。
    • 提供了丰富的可视化选项,包括图表、地图、热图等。

工作流程

  1. 日志收集:Fluentd部署在应用程序服务器上,负责收集日志数据。它可以配置为监控特定的日志文件,或者直接从应用程序中捕获日志。
  2. 数据转发:收集到的日志数据被Fluentd处理并转发到Elasticsearch集群。在这个过程中,Fluentd可以根据需要转换和格式化数据。
  3. 数据存储和分析:Elasticsearch接收来自Fluentd的数据,并将其索引存储起来。这使得数据可以快速检索和分析。
  4. 数据可视化:Kibana连接到Elasticsearch集群,允许用户通过创建仪表盘和可视化来探索和分析数据。

示意图

部署

创建EFK目录

mkdir -p /data/efk

下载yaml

yaml参考文件,需要酌情修改

  • Elasticsearch

es-service.yaml
es-statefulset.yaml

  • Kibana

kibana-service.yaml
kibana-deployment.yaml

  • Fluentd

fluentd-es-configmap.yaml
fluentd-es-daemonset.yaml

调整yaml

  1. 一定要根据先前学习内容调整yaml配置,如:
  2. 根据需要调整NameSpace;
  3. 根据需要调整镜像地址;
  4. 根据需要调整存储方式;
  5. 根据需要调整Pod名称;
  6. 调整Kibana可以外网访问;
  7. 调整Kibana的SERVER_BASEPATH为注释;

部署EFK服务

cd /data/efk/
kubectl create -f es-service.yaml -f es-statefulset.yaml
kubectl create -f kibana-service.yaml -f kibana-deployment.yaml
kubectl create -f fluentd-es-configmap.yaml -f fluentd-es-daemonset.yaml

查看EFK服务

  • 查看Estaticsearch
kubectl get pod -n efk-logs | grep estaticsearch
  • 查看Kibana
kubectl get pod -n efk-logs | grep kibana
  • 查看fluentd
kubectl get pod -n efk-logs | grep fluentd

EFK日志收集-Filebeat

简介

此处EFK指的是Elasticsearch+Filebeat+Kibana,主要用于收集容器日志

组件介绍

Elasticsearch + Filebeat + Kibana(通常简称为EFK或EFKB)是另一个流行的日志管理和分析堆栈,它结合了Elasticsearch的搜索和分析能力、Filebeat的轻量级日志转发功能以及Kibana的数据可视化。

  1. Elasticsearch
    • 一个开源的搜索引擎,基于Lucene构建,用于存储、搜索和分析大量数据。
    • 提供了强大的全文搜索能力,以及复杂的搜索和分析功能。
    • 数据以JSON文档的形式存储,易于扩展和分布式部署。
  2. Filebeat
    • 一个轻量级的日志转发器,属于Elastic Stack中的Beats系列。
    • 专为转发日志文件而设计,可以监控指定的日志文件或目录,并将日志事件发送到Elasticsearch或Logstash。
    • 由于其轻量级特性,Filebeat对系统资源的占用很小,非常适合部署在生产和边缘服务器上。
    • Filebeat具有模块化的设计,可以快速配置来收集特定应用程序的日志,如Apache、Nginx、MySQL等。
  3. Kibana
    • 一个开源的数据可视化和仪表盘工具,与Elasticsearch紧密集成。
    • 允许用户创建可视化的仪表盘,以直观地展示和分析存储在Elasticsearch中的数据。
    • 提供了丰富的可视化选项,包括图表、地图、热图等。

工作流程

  1. 日志收集:Filebeat部署在应用程序服务器上,负责收集日志文件中的数据。它可以配置为监控特定的日志文件或目录。
  2. 数据转发:Filebeat处理收集到的日志数据,并将其转发到Elasticsearch集群。在转发过程中,Filebeat会保留日志事件的元数据,如时间戳、标签和字段。
  3. 数据存储和分析:Elasticsearch接收来自Filebeat的数据,并将其索引存储起来,以便进行快速检索和分析。
  4. 数据可视化:Kibana连接到Elasticsearch集群,允许用户通过创建仪表盘和可视化来探索和分析数据。

示意图

部署

创建EFK目录

mkdir -p /data/efk/

下载yaml

yaml参考文件,需要酌情修改

  • Elasticsearch

es-service.yaml
es-statefulset.yaml

  • Kibana

kibana-service.yaml
kibana-deployment.yaml

  • Filebeat

filebeat-configmap.yaml
filebeat-app-deployment.yaml

调整yaml

  1. 一定要根据先前学习内容调整yaml配置,如:
  2. 根据需要调整NameSpace;
  3. 根据需要调整镜像地址;
  4. 根据需要调整存储方式;
  5. 根据需要调整Pod名称;
  6. 调整Kibana可以外网访问;
  7. 调整Kibana的SERVER_BASEPATH为注释;

部署EFK服务

cd /data/efk/
kubectl create -f es-service.yaml -f es-statefulset.yaml
kubectl create -f kibana-service.yaml -f kibana-deployment.yaml
kubectl create -f filebeat-configmap.yaml -f filebeat-app-deployment.yaml

查看EFK服务

  • 查看Estaticsearch
kubectl get pod -n efk-logs | grep estaticsearch
  • 查看Kibana
kubectl get pod -n efk-logs | grep kibana
  • 查看fliebeat
kubectl get pod -n efk-logs | grep fliebeat
<think>嗯,用户的问题是关于Kubernetes调度失败的,具体错误信息显示有多个污点导致Pod无法调度。用户可能是个运维工程师或者Kubernetes管理员,正在为生产环境中的调度问题头疼。从错误信息看,涉及三种污点:dedicated:ceph、control-plane的默认污点、unreachable节点状态污点,还有节点亲和性问题。 用户提供的引用资料挺专业,说明ta已经查阅过官方文档。特别是引用[1]和[2]直接解释了污点机制,引用[5]展示了环境变量配置的细节。不过用户没有提供具体Pod配置,这会让问题排查变得困难。 这个调度错误需要分层解决:首先处理最紧急的unreachable污点(可能节点失联),然后是控制平面污点(通常不允许部署普通Pod),接着是专用节点污点(ceph存储节点),最后检查亲和性规则。其中unreachable污点最危险,可能意味着节点故障。 考虑到用户是技术人员,回复应该直接切入技术方案。需要强调操作顺序:先检查节点状态再修改污点容忍度,避免在故障节点上调度Pod。对于控制平面污点,要提醒用户仅在必要时容忍,最好通过nodeSelector选择worker节点。 亲和性匹配失败的问题比较宽泛,需要用户提供更多信息。可以建议用kubectl describe node查看节点标签,这个诊断步骤很关键但用户可能忽略。最后的安全提示不能少,毕竟修改调度规则可能影响集群稳定性。 用户可能还想知道如何预防这类问题,所以补充了最佳实践部分。提到TolerationSeconds是考虑到临时维护场景,这个细节对运维人员很有价值。最后用流程图总结很必要,因为涉及多个处理步骤。</think>这个错误表明您的 Pod 无法被调度到任何节点上,原因主要有两类:**节点污点(Taint)未被 Pod 容忍**和**节点亲和性(Node Affinity)/节点选择器(Node Selector)不匹配**。以下是详细的解决方案: **错误分析:** 1. **污点未被容忍 (Untolerated Taint):** * `{dedicated: ceph}`: 存在标签为 `dedicated=ceph` 的节点被添加了污点(例如 `kubectl taint nodes <node-name> dedicated=ceph:NoSchedule`),且您的 Pod 没有容忍这个污点。这种污点通常用于保留节点给特定的工作负载(如 Ceph 存储守护进程)。 * `{node-role.kubernetes.io/control-plane: }`: Kubernetes 1.24+ 默认会给控制平面节点(master 节点)添加 `node-role.kubernetes.io/control-plane:NoSchedule` 污点,防止普通工作负载 Pod 调度到控制平面,确保控制平面稳定[^2]。您的 Pod 没有容忍这个默认污点。 * `{node.kubernetes.io/unreachable: }`: 这个污点是由 `node-controller` 自动添加的,表示节点状态为 `NotReady`(通常超过 5 分钟未上报状态)。Kubernetes 会自动添加对应的 `node.kubernetes.io/unreachable:NoExecute` 和 `node.kubernetes.io/unreachable:NoSchedule` 污点[^2]。调度器会避免将新 Pod 调度到这种不可达节点上。 2. **亲和性/选择器不匹配 (Didn't match Pod's node affinity/selector):** * 您的 Pod 配置了 `nodeAffinity`(节点亲和性)或 `nodeSelector`(节点选择器)规则,要求 Pod 必须调度到具有特定标签的节点上。 * 当前集群中没有(或数量不足)节点满足 Pod 所要求的标签条件。 **解决方案:** **第一步:解决节点不可达问题 (Highest Priority - Stability)** 1. **检查节点状态:** `kubectl get nodes` 2. **诊断不可达节点 (`NotReady`):** * `kubectl describe node <unreachable-node-name>`: 查看节点事件和状态,找出失联原因(网络问题、kubelet 崩溃、节点宕机等)。 * **恢复节点:** 解决底层问题(重启 kubelet、修复网络、重启物理机/虚拟机)。 * **驱逐节点 (如果无法快速恢复):** `kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data`。这会安全驱逐节点上的 Pod(DaemonSet Pod 除外)并标记节点为 `SchedulingDisabled`。不可达污点通常会在节点恢复 `Ready` 状态后被自动移除。 * **重要:** 除非确定节点永久故障且要移除它,否则**不要**手动移除 `node.kubernetes.io/unreachable` 污点。解决节点本身的故障才是根本。 **第二步:处理控制平面污点 (Control-Plane Taint)** * **最佳实践:** **除非有特定需求,否则普通工作负载 Pod 不应该调度到控制平面节点上。** 控制平面节点应专注于运行 Kubernetes 系统组件(如 `kube-apiserver`, `etcd`, `kube-controller-manager`, `kube-scheduler`)。 * **方案 A (推荐):** 确保您的 Pod 的 `nodeSelector` 或 `nodeAffinity` 规则**明确指定**只匹配 `node-role.kubernetes.io/worker` 或类似标签的工作节点,避免匹配控制平面节点。这样调度器自然就不会考虑控制平面节点,无需容忍其污点。 * **方案 B (容忍污点 - 慎用):** 如果确实需要在控制平面节点上运行**特定的、非关键的系统组件或守护进程**(例如日志收集 Agent、监控 Agent),可以在该 Pod 的 `spec.tolerations` 中添加容忍: ```yaml tolerations: - key: node-role.kubernetes.io/control-plane operator: Exists effect: NoSchedule # 通常也需要容忍不可调度污点(如果该控制平面节点可能不稳定) - key: node.kubernetes.io/unreachable operator: Exists effect: NoSchedule ``` * **警告:** 过度使用此容忍可能导致控制平面资源紧张或不稳定。 **第三步:处理专用节点污点 (Dedicated: ceph Taint)** * **目标:** 让需要运行在 Ceph 节点上的 Pod 容忍该污点,或者让不应该运行在 Ceph 节点上的 Pod 避免被调度过去。 * **方案 A (容忍污点):** 如果您的 Pod **是**需要直接访问 Ceph 存储或本身就是 Ceph 守护进程(如 `osd`, `mon`, `mgr`),那么它**必须**容忍 `dedicated:ceph` 污点。在 Pod 的 `spec.tolerations` 中添加: ```yaml tolerations: - key: dedicated operator: Equal value: ceph effect: NoSchedule # 或 PreferNoSchedule, 根据实际污点效果设置 ``` * **方案 B (使用亲和性/选择器):** 如果您的 Pod **不是**需要运行在 Ceph 节点上的,但错误地尝试调度到它们(可能是因为缺少其他约束): * **明确指定目标节点标签:** 使用 `nodeSelector` 或 `nodeAffinity` 将 Pod 绑定到**非** `dedicated=ceph` 的节点上。例如: ```yaml nodeSelector: node-type: worker # 确保你的工作节点有这个标签 ``` 或更复杂的亲和性(反亲和性): ```yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: dedicated operator: NotIn values: [ceph] # 要求节点标签dedicated的值不是ceph ``` **第四步:解决亲和性/选择器不匹配问题** 1. **检查 Pod 的亲和性/选择器要求:** `kubectl describe pod <your-pod-name>`,查看 `Node-Selectors` 和 `Affinity` 部分。 2. **检查节点标签:** `kubectl get nodes --show-labels` 3. **匹配需求:** * **添加缺失标签:** 如果 Pod 要求节点有特定标签(如 `disktype=ssd`, `gpu=true`),而集群中存在满足资源要求的节点但缺少该标签,可以使用 `kubectl label nodes <node-name> <label-key>=<label-value>` 给节点打上所需标签。 * **修改 Pod 要求:** 如果 Pod 的要求过于严格或不合理(例如要求一个不存在的标签),则需要修改 Pod 的 `nodeSelector` 或 `nodeAffinity` 配置,放宽条件或要求集群中实际存在的标签。 * **检查命名空间:** 确保 `nodeSelector` 或 `Affinity` 中引用的标签确实存在于节点上,且拼写正确(包括大小写)。 **总结流程图:** ```mermaid graph TD A[调度失败错误] --> B1{节点不可达? node.kubernetes.io/unreachable} A --> B2{控制平面污点? node-role.kubernetes.io/control-plane} A --> B3{专用节点污点? dedicated:ceph} A --> B4{亲和性/选择器不匹配?} B1 -- Yes --> C1[诊断并修复节点故障<br>或安全驱逐节点] B1 -- No --> B2 B2 -- Yes --> C2A[最佳实践:使用nodeSelector/nodeAffinity<br>绑定到工作节点] B2 -- Yes --> C2B[慎选:为特定Pod添加容忍] B2 -- No --> B3 B3 -- Yes --> C3A[若Pod需在专用节点运行:添加容忍] B3 -- Yes --> C3B[若Pod不应在专用节点运行:<br>使用nodeSelector/nodeAffinity/反亲和性<br>避开该标签节点] B3 -- No --> B4 B4 -- Yes --> C4A[检查Pod要求] C4A --> C4B[检查节点标签] C4B --> C4C[给节点添加缺失标签<br>或修改Pod要求] ``` **最佳实践建议:** 1. **明确节点角色:** 使用标签(如 `node-role.kubernetes.io/worker`, `dedicated=ceph`, `gpu=true`)清晰划分节点角色和功能[^1][^2]。 2. **合理使用污点与容忍:** 污点用于“排斥”,容忍用于“接受”。为专用节点(GPU、存储、边缘设备)设置污点,确保只有明确声明容忍的特定Pod才能调度上去[^1][^2]。控制平面污点是默认的安全机制。 3. **精确使用亲和性/选择器:** 使用 `nodeSelector` 或 `nodeAffinity` 将 Pod 定向到最合适的节点类型(如需要 SSD 的 Pod 到有 `disktype=ssd` 标签的节点)。 4. **避免过度容忍:** 尤其是对 `NoExecute` 效果(如 `unreachable`)和控制平面污点的容忍,应严格限制在必要的系统级Pod上。 5. **监控节点状态:** 及时发现并处理 `NotReady` 节点,避免调度到不稳定节点。 通过以上步骤,仔细检查 Pod 的配置(污点容忍度、节点选择器、亲和性)和节点的状态(可达性)及标签,您应该能够解决 `1 node(s) had untolerated taint ... 2 node(s) didn't match Pod's node affinity/selector` 的调度失败问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值