k8spod频道重启，k8s重启后无法启动

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

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

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

安装kubeadm、kubelet、kubectl：确保所有节点安装指定版本的这些组件。配置kubelet：根据需要更改kubelet的容器路径。集群初始化 Master节点初始化：替换镜像地址：将kubeadm镜像地址替换为国内镜像。执行初始化命令：在Master节点上执行kubeadm init命令，并记录生成的join命令参数。

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

在部署不使用CRIO的k8s集群，采用kubeovn网络插件时，需要按照以下步骤进行准备工作和配置：内核模块与工具安装：确保加载必要的内核模块。安装ipvsadm工具。环境准备：更新yum源，确保软件包的最新版本。安装Go语言环境，虽然不直接使用CRIO，但Go环境可能在后续步骤中有用。

下载kubectl工具 加x权限 将二进制文件移到PATH中 查看版本 创建kube目录 编辑config文件 查看node状态 查看所有pod状态 至此，rancher部署k8s集群完成。rancher控制台的操作非常简单，只需点点点即可部署k8s集群，并提供了丰富的可视化功能管理模块，非常方便。

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

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

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

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

4、切换到cross-subnet模式，kubectleditipPool/default-ipv4-ippool，将ipipMode改为crossSubnet，在UI将calico-node的POD删了重建，重启检查calico网络，可以看见同子网的主机出口走的是bgp，不同子网主机走的是tunl0网卡走ipip模式。

重启虚机后,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。

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

6、问题表现：客户端写入数据后，在异常节点上无法读取到数据，即数据丢失。问题背景：在K8S滚动更新发布时，发现Pod未按照预期创建，通过kubeapiserver查看发现对应的Deployment版本已经是最新版，但Pod未出现。通过提高日志等级并重启kubeapiserver后，问题暂时解决，但随后又发现新创建的Pod在查询时突然消失。

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

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

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

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

在Pod层面配置共享Volume，允许所有容器访问，保留持久数据，即使容器重启。容器间共享IP与端口空间，通过localhost相互发现。多容器Pod示例展示了共处容器与资源的打包管理，以及容器间通信与协调。Pod中设置重启策略，如Always，降低应用中断时间，适用于所有容器。

容器在其生命周期内也有waiting、Running和Terminated等状态，以及针对不同状态的具体原因（Reason）描述。例如，容器状态为Terminated且原因CrashLoopBackOff，表示容器由于某种异常退出后，系统试图重启容器。