k8s 容器反复重启

一、容器资源限制问题

原因：
- 容器申请的资源（如 CPU、内存）超过了节点的可用资源，导致容器因资源不足而被驱逐或 OOMKilled（内存溢出被杀死），进而反复重启。
- 资源限制设置不合理，如设置的 CPU 或内存请求量过低，实际使用量可能会超过请求量而触发限制，影响容器的正常运行。
解决方法：
- 查看容器的资源使用情况：
```
kubectl top pod <pod-name> -n <namespace>
```
- 检查容器的资源请求和限制配置，可通过以下命令查看：
```
kubectl describe pod <pod-name> -n <namespace>
```
- 调整容器的资源请求和限制，可在 Pod 的 YAML 文件中修改 resources 部分，例如：
```
spec:containers:- name: <container-name>image: <image-name>resources:requests:memory: "1Gi"cpu: "500m"limits:memory: "2Gi"cpu: "1"
```
  - requests 表示容器请求的资源量，是保证容器正常运行所需的最小资源量。
  - limits 表示容器能够使用的最大资源量。

二、容器健康检查失败

原因：
- k8s 会根据容器的健康检查（liveness 和 readiness 探针）来判断容器是否健康。如果健康检查失败，k8s 会自动重启容器。
- 健康检查的配置可能不适合容器的实际运行情况，如检查间隔过短、超时时间过短等。
解决方法：
- 查看容器的健康检查配置，在 Pod 的 YAML 文件中检查 livenessProbe 和 readinessProbe 部分，例如：
```
spec:containers:- name: <container-name>image: <image-name>livenessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 10periodSeconds: 30timeoutSeconds: 10
```
- 调整健康检查的参数，例如增加 initialDelaySeconds （容器启动后开始检查的延迟时间）、periodSeconds （检查间隔）或 timeoutSeconds （检查超时时间），以适应容器的启动和响应时间。

三、容器镜像问题

四、应用程序自身问题

五、K8s 集群故障

原因：
- k8s 集群的组件（如 kubelet、kube-apiserver 等）可能出现故障，影响容器的正常运行。
- 网络问题可能导致容器无法正常通信，影响容器的服务发现和通信，进而导致容器异常重启。
解决方法：
- 检查 k8s 集群组件的状态：
```
kubectl get componentstatuses
```
- 检查网络插件的状态，例如 Calico 或 Flannel，确保网络正常。
- 查看 kubelet 的日志，通常位于 /var/log/kubelet.log ，查找可能的错误信息。

六、存储问题

原因：
- 容器使用的存储卷可能出现问题，如存储卷不可用、权限不足等。
- 存储卷的配置错误，如挂载点错误或存储卷类型不匹配。
解决方法：
- 检查存储卷的配置，在 Pod 的 YAML 文件中查看 volumes 和 volumeMounts 部分。
- 确保存储卷服务正常，如使用的是 NFS 存储，检查 NFS 服务器的状态。

七、环境变量和配置错误