[root@k8s-master01 elasticsearch]# kubectl exec -n logging elasticsearch-master-1 -- curl -s http://127.0.0.1:9200/_cluster/health?pretty Defaulted container "elasticsearch" out of: elasticsearch, configure-sysctl (init) { "cluster_name" : "elasticsearch", "status" : "green", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 1, "active_shards" : 1, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 0, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 100.0 } [root@k8s-master01 elasticsearch]# kubectl exec -n logging elasticsearch-master-0 -- curl -s http://127.0.0.1:9200/_cluster/health?pretty Defaulted container "elasticsearch" out of: elasticsearch, configure-sysctl (init) { "cluster_name" : "elasticsearch", "status" : "green", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 1, "active_shards" : 1, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 0, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 100.0 }

<think>好的，我现在需要帮助用户确认他们的三个Elasticsearch节点是否属于同一个集群。用户之前已经按照我的指导执行了一些命令，并提供了输出结果。现在我需要分析这些结果，找出问题所在。 首先，用户执行了kubectl exec命令，分别查询了elasticsearch-master-1和elasticsearch-master-0两个Pod的集群健康状态。从输出结果来看，两者的cluster_name都是“elasticsearch”，这说明它们的集群名称一致，这是一个好的迹象。不过，两个节点的number_of_nodes都显示为1，这意味着每个节点都认为自己单独在集群中，没有检测到其他节点。 接下来，我需要考虑可能的原因。用户有三个节点，但每个节点都报告只有自己一个节点，这说明它们可能没有成功组成集群。可能的问题点包括网络通信问题、节点配置错误或发现机制配置不当。 根据之前的建议，用户应该检查集群名称、节点列表、网络连通性等。这里集群名称一致，所以问题可能出在网络或发现配置上。Elasticsearch节点之间通常通过9300端口通信，用户需要确认这些端口是否开放，并且节点之间可以互相访问。另外，Kubernetes环境中可能需要检查服务发现配置，比如是否使用了正确的headless服务，或者是否有网络策略阻止了节点间的通信。 用户可能没有正确配置发现模块。在Elasticsearch的配置中，需要设置discovery.seed_hosts来指向其他节点的地址。如果每个节点都只配置了自己的地址，或者配置不正确，就会导致节点无法发现彼此。 此外，检查日志是关键步骤。用户需要查看每个节点的日志，确认是否有关于节点加入集群的成功或失败信息。例如，日志中可能会出现连接超时或无法连接到其他节点的错误，这有助于定位问题。 另外，用户提到有三个节点，但当前查询的两个节点都显示为单节点集群。可能第三个节点也存在同样的问题，或者根本没有启动。需要确认第三个节点的状态，是否正常运行，并且配置是否正确。 总结来说，用户的问题在于节点之间无法发现对方，导致每个节点独立运行。解决这个问题需要检查网络配置、发现设置，以及日志中的错误信息，逐步排查可能的原因。</think>--- ### **诊断分析** 从您提供的命令输出可以看出： 1. **集群名称一致**：两个节点均返回 `"cluster_name": "elasticsearch"`，说明配置正确。 2. **节点数量异常**：每个节点均报告 `"number_of_nodes": 1`，但您预期有 3 个节点组成集群。 **结论**：当前两个节点均处于**独立运行状态**，未形成真正集群。 --- ### **原因定位** 以下情况可能导致此问题： 1. **网络隔离**：节点间无法通过 `9300` 端口通信（默认集群通信端口）。 2. **发现配置错误**：未正确配置 `discovery.seed_hosts` 或 `cluster.initial_master_nodes`。 3. **Kubernetes服务配置问题**：Headless Service 未正确暴露节点 IP 或端口。 --- ### **解决步骤** #### **1. 检查节点间网络连通性** 在 Pod 内测试其他节点的 `9300` 端口连通性： ```bash # 进入 elasticsearch-master-0 的 Shell kubectl exec -n logging -it elasticsearch-master-0 -- /bin/bash # 测试与其他节点的通信（假设节点 IP 为 10.244.1.10, 10.244.1.11, 10.244.1.12） curl -v telnet://elasticsearch-master-1.elasticsearch-headless.logging.svc.cluster.local:9300 curl -v telnet://elasticsearch-master-2.elasticsearch-headless.logging.svc.cluster.local:9300 ``` **预期结果**：返回 `Connected to ...`。 **异常处理**： - 若连接失败，检查 Kubernetes Service 和 NetworkPolicy 配置，确保 Headless Service (`elasticsearch-headless`) 正确暴露 `9300` 端口。 --- #### **2. 验证 Elasticsearch 发现配置** 确保所有节点的 `elasticsearch.yml` 包含以下关键配置： ```yaml # 集群名称必须一致 cluster.name: elasticsearch # 节点角色配置（主节点/数据节点） node.roles: [master, data] # 使用 Kubernetes 服务发现 discovery.seed_hosts: ["elasticsearch-headless.logging.svc.cluster.local:9300"] cluster.initial_master_nodes: ["elasticsearch-master-0", "elasticsearch-master-1", "elasticsearch-master-2"] ``` **重点检查**： - `discovery.seed_hosts` 必须指向 Headless Service 的 DNS 名称。 - `cluster.initial_master_nodes` 需列出所有**候选主节点**的节点名称（与 StatefulSet 名称匹配）。 --- #### **3. 查看节点日志定位握手失败原因** 检查节点启动日志，重点关注节点加入集群的过程： ```bash kubectl logs -n logging elasticsearch-master-0 | grep "discovery" ``` **正常日志示例**： ``` [INFO][o.e.d.DiscoveryModule] Using discovery type [zen] and host providers [settings, [kubernetes]] [INFO][o.e.n.Node] Starting to ping [elasticsearch-master-1.elasticsearch-headless.logging.svc.cluster.local:9300] [INFO][o.e.c.c.ClusterBootstrapService] successfully joined cluster with elected master node [abcdef123456] ``` **常见错误日志及解决方案**： | 错误日志 | 原因 | 解决方案 | |-------------------------------------------------------------------------|-------------------------------|--------------------------------------------------------------------------| | `failed to resolve host [elasticsearch-headless...]` | DNS 解析失败 | 检查 Headless Service 名称和 Kubernetes DNS 配置 | | `Connection refused to node [...]` | 目标节点未监听 9300 端口 | 确认目标节点的 Elasticsearch 进程正常启动 | | `master not discovered yet, this node has not previously joined a bootstrapped cluster` | 初始主节点未正确引导 | 确保 `cluster.initial_master_nodes` 包含所有候选主节点名称 | --- #### **4. 强制重启 StatefulSet 触发集群重建** 如果配置已修复但问题仍存在，尝试重启所有节点： ```bash kubectl delete pod -n logging elasticsearch-master-0 elasticsearch-master-1 elasticsearch-master-2 ``` StatefulSet 会自动重建 Pod，观察新 Pod 日志中的集群形成过程。 --- ### **验证集群状态** 在所有节点重启后，执行以下命令确认集群规模： ```bash kubectl exec -n logging elasticsearch-master-0 -- curl -s http://127.0.0.1:9200/_cat/nodes?v ``` **预期输出**： ```text ip heap.percent ram.percent cpu load_1m load_5m load_15m node.role master name 10.244.1.10 25 95 8 0.01 0.03 0.05 cdfhilmrstw - elasticsearch-master-0 10.244.1.11 22 93 7 0.02 0.04 0.06 cdfhilmrstw * elasticsearch-master-1 10.244.1.12 20 92 6 0.00 0.01 0.03 cdfhilmrstw - elasticsearch-master-2 ``` - `number_of_nodes` 应显示为 3。 - 其中一个节点的 `master` 列标记为 `*`（当前主节点）。 --- ### **总结** 您的节点未形成集群的原因是**节点间通信失败**或**发现配置错误**。通过修复网络策略、检查 Headless Service 配置、完善 `discovery.seed_hosts` 参数，可解决此问题。若需进一步协助，请提供节点日志片段。