pod内部访问svc失败分析
始终是1/2的成功率，但是完全没有新的contrack记录。 Pod访问svc 应该没走kube-Proxy。解决方式： 移除eth1的网卡上的ip，该情况完全消失。
原因：镜像问题导致容器重启失败。解决方法：更换镜像。POD创建失败：原因：镜像问题导致容器无法启动。解决方法：更换镜像。Pod的ready状态未进入：原因：Pod的执行命令失败，无法获取资源。解决方法：进入容器内部，创建yaml定义的资源。Pod创建失败：原因：yml文件内容出错，如使用了中文字符。
开始时，一个正常运行的Pod突然无法创建新的连接，业务通过Pod A访问svc B时出现此问题。查阅资料后，发现错误可能源于Linux内核的随机端口数量阈值已满，导致无法分配新的端口用于连接。内核参数`net.ipvip_local_port_range`默认为32768~60999，若业务需要大量长连接，可能需要调整这个范围。
若pod1需访问pod2，通常通过Service2的域名进行访问，直接访问pod较为罕见，因pod IP易变，而服务IP相对稳定。当pod1使用servicenamespacesvc.cluster.local发起域名解析请求时，NodeLocaldns若缓存中未找到解析结果，则将请求转发至全局CoreDNS。全局CoreDNS解析后将IP返回给pod1，完成访问过程。
可能导致健康检查失败、业务访问异常等问题。大量创建 svc 的时候减少创建监听的步骤只是提交 ipvs/iptables 规则，这样可以优化连接性能。另一个就解决某些场景下出现大量的 CLOSE_WAIT 占用 TCP 连接等问题。在 22 版本之后就去掉了 PortOpener 逻辑。
首先，创建DNS诊断工具pod用于检测DNS服务状态。接着，检查本地DNS配置文件，确保search域名设置正确。进一步，验证DNS服务pod状态是否正常，以及服务的Endpoints是否关联正确。通过描述DNS服务，确认服务与pod之间的关联性。
POD控制器(kube-controller-manager)
Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成。 它通过 APIserver 监控整个集群的状态， 并确保集群处于预期的工作状态。
kube-controller-manager，k8s的大脑，大部分控制器所在，大管家，配置包括：开启选举。利用ETCd的强一致性，可以用来组件的选主，kube-controller-manager就是利用这个特性实现的高可用。高可用条件： kube-controller-manager数量大于等于2即可。
kube-controller-manager Control Manager负责实现用户通过API Server提交的终态声明。它通过一系列操作步骤驱动API对象的当前状态逼近或同于期望状态。kubernetes提供了驱动Node、Pod、Server、Endpoint、ServiceAccount和Token等数十种类型的API对象的控制器。
Kubernetes常见故障
原因：端口映射错误，服务正常工作但不能提供服务。解决方法：删除SVC，重新映射端口。Kubernetes集群服务暴露失败：原因：容器已暴露服务，但SVC配置有误。解决方法：删除SVC，重新映射端口。外网无法访问Kubernetes集群提供的服务：原因：集群的type为ClusterIP，未将服务暴露至外网。
在Kubernetes的日常运维中，遇到的故障处理问题通常包括ContainerCreating、ErrImagePull或ImagePullBackOff、Pending、CrashLoopBackOff或ERROR、Terminating或Unknown以及UnexpectedAdmissionError等。以下是对这些问题的详细分析与解决办法。ContainerCreating：这种情况表示容器正在创建中，常见于配置问题导致的容器创建失败。
查看kubectl describe命令的输出将使您更加清楚。如果Pod保持挂起状态，则可能是一个问题，根本原因可能是节点中的资源不足。或者，如果您为不可用的容器指定主机端口，或者该端口已在Kubernetes集群的所有节点中使用，则Pod可能未就绪。结论 Kubernetes中的故障排除似乎是一项艰巨的任务。
就绪探针失败是应用程序的特定错误，因此你应检查kubectl describe中的“ 事件”部分以识别错误。 服务的故障排除 如果你的Pod正在运行并处于就绪状态，但仍无法收到应用程序的响应，则应检查服务的配置是否正确。 service旨在根据流量的标签将流量路由到Pod。 因此，你应该检查的第一件事是服务关联了多少个Pod。
Probe Failures：排查Pod生命周期阶段，查看kubectl描述，可能是资源不足或端口冲突。优化应用程序、调整探针设置或增加资源来解决问题。总结来说，通过深入理解这些错误类型，系统地分析和调整配置，你将能更有效地处理 Kubernetes 中的故障，让运维过程更加顺畅。希望这些排障技巧能助你解决遇到的问题。
在 Kubernetes 集群中，Pod 的 Pending 状态是常见的问题，尤其是在 DevOps 工程师面临的常见故障中。当 Pod 的生命周期停滞在 Pending 阶段时，意味着它被集群接受但容器尚未准备好提供服务，可能涉及调度延迟或镜像下载问题。
