k8s重启后查询不到pod？ k8s pod restartpolicy？

通过vagrant+virtualbox安装k8s找不到Pod问题

1、通过vagrant+virtualbox安装k8s集群的小伙伴都会碰到找不到pod的问题，但是通过api服务查看，这些POD却是活的好好的。 原因是 ，在virtualbox组网的过程中，采用了双网卡方案，网卡1使用NAT地址转换用来访问互联网，网卡2使用Host-only来实现虚拟机互相访问。

2、Jenkins版本不匹配问题使用了过低版本的Jenkins镜像导致插件安装失败。更换为“jenkinsci/jenkins：latest”镜像，但实际版本并未提升，只是linux系统不同。最终发现应使用“jenkins/jenkins”镜像，版本为“151-slim”。选择正确的镜像后，插件安装问题得到解决。

3、新建/etc/systemd/system/docker.service.d/http-proxy.conf，添加配置内容。安装virtualbox 安装k8s集群使用vagrant 参考jimmysong的vagrant教程 Kubernetes-vagrant-centos-cluster，节点数量应根据个人机器配置调整（参考kubernetes-vagrant-centos-cluster）。

重启虚机后,k8s的kube-apiServer无法正常启动的问题

1、在重启设备后，执行 systemctl status kube-apiserver 命令时，未发现该服务，表明配置文件可能存在错误，因此决定对K8S集群进行重构。在master端检查pod时，发现flannel和coredns未启动，容器启动失败。

2、为确保API聚合功能在未运行kube-proxy服务的Master节点上正常工作，还需确保kube-apiserver能够访问服务的ClusterIP。这意味着可能需要调整kube-apiserver的启动参数以适应特定的环境需求。在配置完成并重启kube-apiserver后，API聚合功能便得以启用。

3、kube-apiserver报错，错误如下：这个错误指明了是与apiserver通信时认证失败造成的，接着就去找哪个组件报错说无法获取apiserver的资源，但是查了kube-controller-manager、kube-scheduler、kube-proxy和kubelet都没有找到相关的错误。

4、原因： conntrack表项问题：在K8S环境中，通过nodePort暴露的UDP服务在接收到频繁请求时，由于UDP conntrack表项默认老化时间为30秒，频繁请求可能导致老化失效。当Pod重启后，conntrack表中记录的可能是节点IP而非Pod IP，导致后续请求被错误地转发到节点IP而非新的Pod IP。

K8S故障检查-Pod处于CONTAINERCreating状态

常见导致pod长时间处于“ContainerCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackoff”事件，表明镜像拉取存在问题。

面对k8s应用卡在ContainerCreating状态的困扰，我通过kubectl describe po命令获取到了关键的日志信息。

ContainerCreating：这种情况表示容器正在创建中，常见于配置问题导致的容器创建失败。例如，当使用docker服务时，可能会遇到节点上的kube-proxy、kubelet或docker服务重启后容器仍无法创建的情况。解决这类问题，通常需要检查服务的运行状态，确认资源是否充足，或者是否存在网络、存储配置问题。

一个pod的完整创建，通常会伴随着各种事件的产生，k8s种事件的种类总共只有4种：PodStatus 有一组PodConditions。PodCondition中的ConditionStatus，它代表了当前pod是否处于某一个阶段（PodScheduled，Ready，Initialized，Unschedulable），“true” 表示处于，“false”表示不处于。

在集群部署过程中，可能会遇到问题。例如，如果创建pod时状态为containercreating，检查是否需要升级runc版本并配置源，然后重新安装。初始化集群时出现错误，可能需要编辑crio.conf来解决。另外，遇到fs.may_detach_mounts相关错误，可能是sysctl配置问题，需要调整相关设置后重启CRIO服务。

安装kube-ovn时，需要修改install.sh脚本，执行安装，然后可能需要卸载和重新安装以解决特定问题。

k8s-踩坑篇2-服务器重启后重启集群

---本来怀疑是 systemctl daemon-reload 命令造成的，但是，今天这台服务器又重启了，我又试了一遍，不执行 systemctl daemon-reload 命令是无法重启k8s的。---但是今天重启k8s，完成之后，昨天新建的2个pod仍然是存在的，那很有可能是我昨天不熟悉流程参杂了误操作，但是现在也想不起来了，就暂时告一段落了，后面遇到问题再说吧。

要重启使用 kubeadm 部署的 k8s 集群的 API 服务器，首先需要确认 API 服务器的容器是否正常运行。这通常涉及到检查 kubeconfig 文件中的 server 地址设置是否正确。API 服务器作为集群的核心组件，以容器形式存在，且作为静态 pod 管理。这意味着它能够被 kubelet 容器运行时系统拉起。

首先打开电脑，然后登录到k8s集群，如下图所示。然后创建ServiceAccountkubectl -n infra create serviceaccount jenkins-robot，如下图所示。接着创建ClusterRoleBinding，如下图所示。然后查看ServiceAccount的Secret，将secret中的token：后面的值复制出来。

在Kubernetes环境中，coreDNS作为一个关键的服务发现配置中心，负责生成集群内部的DNS记录。它通常通过daemonSet方式部署，确保集群的每个节点上都有一个副本运行。本文将深入探讨在不同场景下处理coredns状态异常的问题。

在重启设备后，执行 systemctl status kube-apiserver 命令时，未发现该服务，表明配置文件可能存在错误，因此决定对K8S集群进行重构。在master端检查pod时，发现flannel和coredns未启动，容器启动失败。查看日志后，发现错误信息显示在Kubernetes集群中使用的Flannel网络插件遇到了问题，无法获取到所需的子网租约。

k8s中Pod状态及问题排查方法

含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 CPU 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。

Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。

要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。

首先，要从容器输出和状态详情入手。通过运行`docker logs $container_id`，您可以直接查看容器内的应用程序输出，以获取实时运行信息。接着，`docker inspect $container_id`可提供容器的详细状态信息，其中特别要注意“OOMKilled”信息，该信息表示容器因内存不足而被Docker自动终止。

查看节点机docker中的容器ID，前后不一样，确定是POD被杀掉后重启。通过容器的IP地址、端口号及路径调用HTTP get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康 。