k8spod重启详细过程（k8s重新初始化）

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状态及问题排查方法

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

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

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

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

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，表示容器由于某种异常退出后，系统试图重启容器。

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

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

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

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

Evicted：资源不足导致，需要监控存储和内存使用。CrashLoopBackOff：容器异常退出后又立即重启。Pod的重启策略通过spec字段的restartPolicy设定，常见值有Always（默认，异常退出即重启）、OnFailure（退出码非0时重启）和Never（不重启）。

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重置了集群。

获得了对特定 Service 资源的访问权限。通过这一系列实验和实践，我们认识到在使用默认 ServiceAccount 时，可能存在与预期不符的情况。作为 K8s 初学者，这一发现不仅有助于我们更深入地理解 Kubernetes 的权限管理机制，同时也提醒我们在实际部署中应更加谨慎地配置权限，以避免潜在的安全风险。

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

K8s中的Service主要有四种类型：ClusterIP、NodePort、LoadBalancer与ExternalName。接下来，将对每种类型进行详细介绍及其适用场景。ClusterIP ClusterIP是Service的最常用类型之一，它提供了一个集群内部的虚拟IP地址，仅允许集群内部服务进行访问。适用于那些仅需在集群内部提供服务，如数据库或内部API。

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

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

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

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

4、kubeadm是Kubernetes集群部署工具，简化了K8s的部署流程。本指南将详细说明如何使用kubeadmin10版本部署Kubernetes集群。部署前，需要进行准备工作，包括检查master、nodenode2的网络环境，关闭防火墙、SELinux，禁用Swap，配置主机ip映射及主机名，并安装docker。

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

6、在其他ARM64架构的节点上重复安装kubelet， kubeadm等步骤。执行kubeadm join命令将节点加入到集群中。部署Rancher 拉取Rancher镜像：从Docker Hub或私有镜像仓库拉取适配ARM64架构的Rancher镜像。启动Rancher：使用Docker命令启动Rancher容器，并配置必要的环境变量和卷挂载。