k8s强制重启pod，k8s重启apiserver

calico-node的Pod实例一直报错重启的问题

一直被集群pod不同node节点之间不能互ping困扰（nacos服务发现，sentinel接口发现默认使用POD ip。如果不能互ping，会导致nacos，sentinel不可用） 经排查是DaemonSet ：kube-system / calico-node 没有正常启动。

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

为calico/node创建密钥，确保与Typha之间的TLS安全连接。配置Typha：生成证书和密钥，为Typha创建serviceAccount，设置角色权限，并启动Typha实例。测试网络：创建多个实例，并验证Pod之间的网络连接，包括不同IP池的IPAM分配是否正确。

通过修改IP池配置，将ipipMode改为crossSubnet，并重建caliconode的POD。重启后检查网络，跨子网主机将通过tunl0网卡使用ipip模式。配置Route Reflector：在集群内的一台worker节点安装calicoctl，配置其连接Kubernetes集群，并通过calicoctl对Calico进行控制。

- 为calico/node创建密钥，确保与Typha之间的TLS安全连接。 配置Typha：- 生成证书和密钥，创建Typha使用的ServiceAccount，设置角色权限并启动Typha实例。1 测试网络：- 创建多实例并验证Pod之间的网络连接，包括不同IP池的IPAM分配。

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

---本来怀疑是 systemctl daemon-reload 命令造成的，但是，今天这台服务器又重启了，我又试了一遍，不执行 systemctl daemon-reload 命令是无法重启k8s的。

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

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

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

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

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

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

2、POD的生命周期与重启策略是K8s中的关键概念，理解它们对于确保应用程序稳定运行至关重要。

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

k8s解决一个apiservice的相关报错

总结而言，解决K8s中apiservice相关报错问题的关键步骤主要包括：定位错误配置、删除问题apiservice、重启pod。通过这些步骤，能够有效地解决由apiservice错误配置引发的集群问题，恢复系统的稳定运行。重要的是在配置和部署过程中保持警惕，及时发现并修正错误，以维护K8s集群的高效运行。

报错信息如下：其根本原因在于 Kubernetes 的 ApiServer 无法访问到 metrics-server，要验证这种问题，我们可以执行如下命令：返回值如下：可以看到访问 https：//2411：4443/apis/metrics.k8s.io/v1beta1 这个 API 异常，其访问的IP是一个典型的 clusterIP。

尝试修复数据文件或备份后重启Docker对应镜像或kubectl，然后检查Node状态以及集群中所有Pod。网络相关的Pod已消失，k8s DNS组件也未运行，需要重新配置网络。正常情况下，如果网络组件未启动，所有节点应为未就绪状态。时间紧迫，为了实验需要，通过kubeadm重置了集群。

基于ServiceAccount的配置中，首先生成所有必要的密钥文件，例如将k8s-master替换为master主机名。修改配置文件参数时，尝试通过命令行启动API Server，避免通过systemctl，因为该方法可能导致失败。在etcd启动过程中遇到问题时，首先检查报错日志，删除相关文件如0.tmp，可以尝试重新启动etcd。

怎么重启kubeadm部署的k8s集群?

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

2、一般来说 kubeadm reset 就行了。但经常unmount 不掉，就docker那块儿的问题，又不方便重启，就需要手动删除。

3、加入nodenode2节点（node节点操作）应确保node节点能下载flannel镜像，若节点仍为notready状态，通过手动上传flannel镜像至node节点仓库解决。

4、解决方案参考文档： Kubernetes master无法加入etcd 集群解决方法 解决方法：在kubeadm-config删除的状态不存在的etcd节点：把上边的删掉：我尝试了方案一，然后重新执行下面的命令，问题就成功解决了。

5、解决方法是首先验证网络配置，确保无HTTP_PROXY设置，然后在配置文件中添加crictl的配置。若/etc/containerd/config.toml中存在disabled_plugins = [cri]这一行，需要注释掉此行，然后重启containerd服务。

6、安装 k8s 组件：按照主节点的步骤，在子节点上安装 kubeadm、kubelet、kubectl 组件。导入镜像：将主节点导出的镜像文件导入到子节点。加入集群：使用 kubeadm join 命令将子节点加入集群。复制 admin.conf 文件：将 admin.conf 文件复制到子节点，以便在子节点上使用 kubectl 命令管理集群。

K8S问题排查-UDP频繁发包导致Pod重启后无法接收数据

1、首先，构建K8S集群，部署UDP服务并用nc命令模拟客户端频繁发送UDP请求。网络分析显示请求正常到达目标Pod和节点，但Pod重启后接收中断。通过删除Pod构造重启，发现在Pod重启后，流量未按预期到达Pod，而是节点IP。使用iptables跟踪请求路径，发现流量未经过预期路径，而是进入INPUT链，指向DNAT问题。

2、当 Pod 状态为 CrashLoopBackOff 时，表示容器在启动后立即崩溃或退出。这可能是容器配置错误、应用程序错误、内存不足或权限问题导致。排查此类问题时，需详细检查容器配置、应用程序日志、内存使用情况及权限设置。Pod 状态为 Failed 通常意味着容器已终止，并且至少一个容器以失败方式退出。

3、在。Pod 只要挂载持久化数据卷，Pod 重启之后数据还是会存在的。Pod 是 Kubernetes 中的最小调度单元，k8s 是通过定义一个 Pod 的资源，然后在 Pod 里面运行容器，容器需要指定一个镜像，这样就可以用来运行具体的服务。

4、当pod出现crash状态，容器频繁重启，使用kubelet logs 方法可能无法获取到所需日志时，可以采用kubectl previous参数进行解决。该参数的使用原理基于kubelet在pod失败后会保留前几个容器的失败记录。这为后续查看提供了前提条件。