pod网络超时？ ping网络连接超时？

原标题：pod网络超时？ ping网络连接超时？

导读：

Pod健康检查介绍Pod健康检查是Kubernetes生态系统中确保容器健康运行的关键机制，主要包括存活探测和就绪探测。存活探测：目的：监控容器内部应用程序的健康状态，确...

Pod 健康 检查 介绍

POD健康检查是kubernetes 生态系统中确保容器健康运行的关键机制，主要包括存活探测和就绪探测。存活探测：目的：监控容器内部应用程序的健康状态，确保应用程序在异常情况下能被及时重启。实现方式：命令执行：通过执行容器内部的自定义命令，判断应用程序的健康状态。

在Kubernetes的生态系统中，pod健康检查机制是确保容器健康运行的关键。默认情况下，kubelet依据容器运行状态来判断健康，但这不足以监控容器内部应用程序的健康状况，比如程序假死。由此引入了健康检查机制，它通过存活探测（livenessprobe）和就绪探测（readinessProbe）来监控容器的健康状态。

通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。资源文件定义访问8080端口，但是8080端口未开放，所以访问会超时，不能建立连接，命中检测，重启Pod 用于判断容器服务是否可用（Ready状态），达到Ready状态的Pod才可以接收请求。

K8s中Pod生命 周期和重启策略

例如，deployment 通常会将Pod的重启策略设置为Always，以确保Pod在出现问题时能够自动恢复。K8s重启的时间间隔和最大延迟 KuberneTES在重启Pod时，会遵循一定的时间间隔和最大延迟规则。具体来说，重启的时间间隔通常是2的幂次方倍增（即2n），最大延迟时间通常为5分钟。

K8s中Pod生命周期包括五种状态，重启策略有三种。Pod生命周期状态： Pending：API server已创建Pod，但容器镜像尚未运行。 Running：Pod中的所有容器都在运行中或正在启动中。 Succeeded：Pod中的所有容器已成功退出，并且不会重启。 FaiLED：Pod中的所有容器都已退出，且至少有一个容器是异常退出的。

Always策略：无论正常或非正常停止，容器均会重启。例如，正常关闭 tomcat服务后，Pod状态恢复正常，而非正常关闭时，容器会重启。Never策略：正常或非正常停止，容器都不会重启。停止Tomcat后，正常情况下容器状态保持，非正常时显示Error状态。

腾讯容器集群 故障

不同现象及原因、规避方法5 秒延时：通常是内核 conntrack 冲突导致丢包。可使用 Localdns 规避，如每个容器自带或每个节点运行一个 DNS 缓存服务。解析外部域名超时：可能是上游 DNS 故障或其 ACL 或防火墙拦截了报文。所有解析都超时：通常是 Pod 与集群 DNS 之间通信有问题，可能是节点防火墙没放开集群网段或 kube - proxy 异常。

当遇到集群异常故障时，首先发现的问题是主机配置中出现了一行多余的异常配置。尝试通过ping hostname进行自我检查时，结果异常，返回的IP地址为2。同时，集群服务CM也产生了大量告警，Zookeeper服务的状态与现场告警情况相符，显示出连接问题。

多集群管理：可无缝纳管云上云下不同基础设施上的Kubernetes容器集群，实现混合云场景下的多集群统一管理能力，方便用户跨环境部署和管理应用。服务管理：兼容Kubernetes原生服务访问模式，支持集群内服务互访及被集群外其他负载访问。通过服务容器化封装和镜像仓库统一管理，提升业务的迁移和发布效率。

云原生之K8S中Pod健康检测、服务可用性检查详解

kubectl-deBUG的日常用法包括简单使用、进阶使用和自定义镜像配置。简单使用需要kubectl 10或更高版本，支持从PATH中自动发现插件。进阶使用包括排错init-container、诊断DNS解析、使用tcpdump抓包等。自定义镜像配置可以通过配置文件~/.kube/debug-config修改默认参数。

资源对象与概念Kubernetes的核心资源对象包括Master节点、node节点、Pod、Controller和Service等。这些对象构成了集群的基石，Master负责集群管理，Node作为工作节点，Pod是基础调度单元，Label用于标记和选择，Deployment用于服务编排，而Service则提供服务入口。

k8s 本身是一个容器调度平台。从宿主机操作系统来看，容器就是一个一个的进程；从容器内部来看，容器就是一个操作系统，它有着自己的网络、CPU、文件系统等资源。容器是应用运行的环境。Pod Pod 是 k8s 的基本调度单位，而不是直接调度容器。

pod不足导致接口请求超时

1、多个系统调用。由于Pod中的容器中提供的服务可能会与多个系统之间进行调用，应用程序都是以Pod的形式运行的，导致Pod与Pod之间无法正常调用，从而影响系统的使用。Plainolddatastructure，缩写为POD，是C++语言的标准中定义的一类数据结构，POD适用于需要明确的数据底层操作的系统中。

2、资源不足：检查集群内所有 Node 的资源使用情况，确保有足够的 cpu、内存等资源满足 Pod 的请求。HostPort 已被占用：如果 Pod 配置了 HostPort，确保该端口在目标 Node 上未被其他 Pod 或服务占用。调度问题：使用 kubectl describe pod pod-name 查看 Pod 的事件，检查是否有调度失败的信息。

3、资源不足也可能导致curl请求速度慢或连接超时。解决方案：使用kubectl describe node命令查看节点的CPU、内存等资源使用情况。如果发现资源使用率很高，可能需要考虑增加节点的资源或调整应用程序的资源限制。检查网络连接状况：网络连接问题也可能导致curl连接超时。

4、Pod 试图访问需要身份验证的服务，但凭证错误或权限不足。示例：访问 AWS RDS 数据库时未正确配置访问凭证。应用程序内部错误：应用程序代码中存在错误，如未经处理的异常或逻辑缺陷。示例：Java 应用程序中的 NullPointerException。资源不足或资源限制过于严格：Pod 请求的 CPU 或内存超过可用资源或限制。

5、在Kubernetes集群环境中，Harbor以Pod的形式运行时，可能会因为多个业务应用同时拉取镜像而导致网络带宽被大量占用。这可能会影响到业务应用的正常响应速度。为了解决这一问题，管理员可以考虑实施网络带宽的公平分配策略，确保镜像拉取不会抢占业务应用的带宽资源。

记:k8s内部服务调用连接超时

1、当服务之间使用 Fegin 进行访问的时候，我们使用的是 service_name . namespace：port 进行访问的，根据k8s的DNS策略，找到相关的服务并进行路由是没有问题的，但是仍然会出现的服务连接超时的问题。最开始我只是通过最简单粗暴的方式解决，那就是重启服务器，但是这并不能从根本上解决问题。