Warning Unhealthy 29s (x50 over 7m39s) kubelet Readiness probe failed: Waiting for elasticsearch cluster to become ready (request params: "wait_for_status=green&timeout=1s" ) Cluster is not yet ready (request params: "wait_for_status=green&timeout=1s" ) [root@k8s-master01 elasticsearch]# kubectl get po -n logging -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES elasticsearch-master-0 0/1 Running 0 12m 172.16.135.142 k8s-node03 <none> <none> elasticsearch-master-1 0/1 Running 0 12m 172.16.85.233 k8s-node01 <none> <none> elasticsearch-master-2 0/1 Running 0 12m 172.16.58.212 k8s-node02 <none> <none>

<think>嗯，用户现在遇到了Kubernetes集群中Elasticsearch Pod的Readiness探针失败的问题，导致Pod的状态一直是0/1，处于Running但未就绪。用户之前的问题是关于HTTPS协议是否影响Kibana的HTTP访问，现在转向了Elasticsearch的健康检查失败。这说明用户可能在部署Elasticsearch时遇到了问题，特别是在Kubernetes环境下。 首先，我需要分析用户提供的错误信息。错误显示Readiness探针失败，因为Elasticsearch集群未准备好，等待状态变为green超时。用户执行了kubectl get po，发现所有三个master节点都是0/1，虽然状态是Running，但未通过就绪检查。这表明Elasticsearch集群未能达到green状态，可能是由于集群初始化或节点通信问题。 接下来，我需要考虑可能的原因。常见的原因包括资源不足（如内存、CPU），网络策略阻止节点间通信，持久卷（PV）问题导致数据无法写入，或者Elasticsearch配置错误（如发现设置、节点名称、主机地址等）。另外，安全设置如SSL/TLS配置错误也可能导致节点无法加入集群。 用户之前配置过HTTPS，可能涉及到安全设置，需要检查Elasticsearch的配置文件是否正确，尤其是证书和密钥的路径是否正确，以及节点之间的SSL通信是否正常。此外，Kubernetes中的Service或Endpoint是否正确暴露了所需的端口（如9300用于节点间通信），以及网络策略是否允许这些通信。 接下来需要指导用户进行故障排查。首先查看Elasticsearch的日志，使用kubectl logs命令检查各个Pod的日志，寻找错误或警告信息。然后检查资源使用情况，确认是否有足够的内存和CPU，因为Elasticsearch对资源要求较高，特别是内存不足会导致启动失败。检查持久卷的配置，确保PVC绑定成功，并且存储类可用，有足够的空间。 网络方面，需要验证节点间的通信，尤其是9300端口是否开放，可以使用telnet或nc命令测试。检查Kubernetes的Service配置是否正确，确保headless service（如elasticsearch-discovery）正确配置，用于节点发现。同时，查看Elasticsearch的配置文件，特别是elasticsearch.yml中的集群名称、节点角色、网络主机设置是否正确，以及发现种子主机是否指向正确的服务名称。 安全配置方面，如果启用了X-Pack安全功能，需要确认用户名、密码和证书是否正确配置，并且各节点之间的SSL/TLS配置一致。此外，检查就绪探针的配置，确认探测命令是否正确，比如使用的端口和路径，以及超时时间是否足够长（用户当前设置为1秒，可能太短，建议增加到30秒）。 用户可能需要逐步验证每个方面，从日志入手，找到具体的错误信息，然后针对性地解决。例如，如果日志显示无法连接到其他节点，可能是网络策略问题；如果显示磁盘空间不足，则需要调整存储配置。同时，建议用户延长就绪探针的超时时间，避免因集群启动较慢而误判为失败。 最后，提供一些常见的解决步骤，如重新创建Pod，确保配置正确，检查Kubernetes事件以获取更多信息，以及如何验证集群状态是否正常。确保用户能够按照步骤逐步排查问题，最终使Elasticsearch集群达到green状态，从而解决Readiness探针失败的问题。</think>以下是针对 **Elasticsearch Pod 就绪探针失败（Readiness probe failed）** 的详细分析及解决方案： --- ### 一、问题核心 - **现象**：Elasticsearch Pod 处于 `Running` 状态但未就绪（`0/1 READY`），日志显示集群未达到 `green` 状态。 - **直接原因**：Elasticsearch 集群未完成初始化或节点间通信异常，导致就绪探针检测失败（默认超时仅 `1s`）。 - **关键风险**：若持续未修复，Kubernetes 可能重启 Pod，导致集群启动陷入死循环。 --- ### 二、故障排查步骤 #### 1. **查看 Elasticsearch 日志** ```bash kubectl logs -n logging elasticsearch-master-0 --tail=100 # 检查主节点日志 ``` - **重点关注以下错误**： - `master not discovered yet`（节点发现失败） - `failed to join existing cluster`（节点间通信异常） - `disk watermarks exceeded`（磁盘空间不足） - `SSL handshake failed`（证书或 TLS 配置错误） #### 2. **检查资源限制** ```bash kubectl describe pod -n logging elasticsearch-master-0 | grep -A 5 "Limits" # 查看资源配额 ``` - **常见问题**：内存不足（Elasticsearch 默认要求至少 2GB 堆内存）。 - **修复建议**：在 Helm Chart 或 Deployment 中调整资源请求： ```yaml resources: requests: memory: "4Gi" limits: memory: "8Gi" ``` #### 3. **验证持久卷（PV）状态** ```bash kubectl get pvc -n logging # 检查 PVC 是否绑定成功 kubectl describe pvc -n logging elasticsearch-data-elasticsearch-master-0 # 查看 PVC 详情 ``` - **常见问题**：存储类（StorageClass）未正确配置或存储配额不足。 #### 4. **检查网络通信** - **验证节点间通信**（Elasticsearch 默认使用端口 `9300`）： ```bash kubectl exec -n logging elasticsearch-master-0 -- curl -s telnet://elasticsearch-master-1.logging:9300 ``` - **修复建议**： - 确保 Kubernetes Service `elasticsearch-discovery` 存在且端口正确。 - 检查网络策略（NetworkPolicy）是否允许 Pod 间通信。 --- ### 三、关键配置修复 #### 1. **调整就绪探针参数** ```yaml # Helm Chart 或 Deployment 中的探针配置 readinessProbe: exec: command: - sh - -c - 'curl -s -k --fail http://localhost:9200/_cluster/health?wait_for_status=green&timeout=30s' # 延长超时时间 initialDelaySeconds: 60 # 适当延长初始化等待时间 periodSeconds: 10 ``` #### 2. **修复 Elasticsearch 集群配置** ```yaml # elasticsearch.yml 关键配置 cluster.name: "elasticsearch" node.name: "elasticsearch-master-0" # 需与 Pod 名称匹配 network.host: "0.0.0.0" discovery.seed_hosts: ["elasticsearch-master-headless.logging.svc.cluster.local"] # 使用 headless service cluster.initial_master_nodes: ["elasticsearch-master-0", "elasticsearch-master-1", "elasticsearch-master-2"] # 指定初始主节点 ``` #### 3. **处理 TLS/SSL 问题（若启用安全模式）** ```yaml # 确保所有节点共用同一 CA 证书 elasticsearch.keystore: "/usr/share/elasticsearch/config/certs/elastic-certificates.p12" xpack.security.transport.ssl.keystore.password: "your_password" ``` --- ### 四、操作验证流程 #### 1. **强制重启 Pod** ```bash kubectl delete pod -n logging elasticsearch-master-{0,1,2} # 触发 Pod 重建 ``` #### 2. **监控集群状态** ```bash kubectl exec -n logging elasticsearch-master-0 -- curl -s http://localhost:9200/_cluster/health?pretty ``` - **预期输出**： ```json { "cluster_name" : "elasticsearch", "status" : "green", # 关键指标 "number_of_nodes" : 3 } ``` --- ### 五、附录：典型错误场景与修复 | 错误场景 | 修复方案 | |-----------------------------------|--------------------------------------------------------------------------| | 节点发现失败 (`master_not_found`) | 检查 `discovery.seed_hosts` 是否指向正确的 headless service | | 磁盘空间不足 (`disk watermark`) | 清理数据或调整 `cluster.routing.allocation.disk.watermark` 阈值 | | 证书不匹配 (`SSL handshake`) | 确保所有节点使用同一 CA 签发的证书 | | 资源不足 (`OOMKilled`) | 增加内存限制并添加 JVM 参数 `-Xms4g -Xmx4g`（堆内存设为物理内存的 50%） | --- ### 六、协议关系示意图 ``` Elasticsearch 集群启动流程： +----------------+ 选举主节点 +----------------+ 数据同步 +----------------+ | Master-Node-0 | <-------------> | Master-Node-1 | <------------> | Master-Node-2 | | (Pending) | 9300 端口通信 | (Pending) | 9300 端口通信 | (Pending) | +----------------+ +----------------+ +----------------+ ↓ ↓ ↓ 达到法定节点数 (quorum) → 选举成功 → 集群状态变为 green → 就绪探针通过 → Pod 标记为 Ready ```