k8s启动Pod遇到CrashLoopBackOff的解决方法

Posted 2023-03-15

参考技术A 一直正常运的k8s，集群节点没问题，但启动pod出现异常
等待中: CrashLoopBackOff

3.查看此pod日志

错误原因在这里 经查elasticsearch运行要求:
vm.max_map_count内核参数必需大于262114，确认系统调过 $sysctl -w vm.max_map_count=262144
这里注意的问题是 上述属于临时性调整，主机重启后又恢复到默认状态
记久性修改 vi /etc/sysconfig 加入：

保存/etc/sysctl.conf,重新启动服务器以应用更改,或执行：sysctl -p以应用更改而不重新启动.他们将在重新启动时永久保持.
重启pod 进入控制台 查询状态 恢复

4.总结 出现故障可能很多种 但要学查看日志 排查具体原因及应用所在

Kubernetes - 滚动更新杀死旧 pod 而不启动新 pod

【中文标题】Kubernetes - 滚动更新杀死旧 pod 而不启动新 pod

【英文标题】：Kubernetes - Rolling update killing off old pod without bringing up new one

【发布时间】：2018-03-04 07:00:18

【问题描述】：

我目前正在使用 Deployments 来管理我的 K8S 集群中的 pod。

我的一些部署需要 2 个 Pod/副本，有些需要 3 个 Pod/副本，而其中一些只需要 1 个 Pod/副本。我遇到的问题是一个 pod/副本。

我的 YAML 文件是：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: user-management-backend-deployment
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2
  selector:
    matchLabels:
      name: user-management-backend
  template:
    metadata:
      labels:
        name: user-management-backend
    spec:
      containers:
      - name: user-management-backend
        image: proj_csdp/user-management_backend:3.1.8
        imagePullPolicy: IfNotPresent
        ports:
          - containerPort: 8080
        livenessProbe:
          httpGet:
            port: 8080
            path: /user_management/health
          initialDelaySeconds: 300
          timeoutSeconds: 30
        readinessProbe:
          httpGet:
            port: 8080
            path: /user_management/health
          initialDelaySeconds: 10
          timeoutSeconds: 5
        volumeMounts:
          - name: nfs
            mountPath: "/vault"
      volumes:
        - name: nfs
          nfs:
            server: kube-nfs
            path: "/kubenfs/vault"
            readOnly: true

我的旧版本运行良好。

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-mrrvl               1/1       Running        0          4d

现在我要更新图像：

# kubectl set image deployment  user-management-backend-deployment  user-management-backend=proj_csdp/user-management_backend:3.2.0

现在根据 RollingUpdate 设计，K8S 应该在保持旧 pod 正常工作的同时启动新 pod，并且只有在新 pod 准备好接受流量时，旧 pod 才会被删除。但是我看到的是旧的 pod 立即被删除并创建了新的 pod，然后开始占用流量需要时间，这意味着我必须丢弃流量。

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9               0/1       ContainerCreating   0          1s

# kubectl get po | grep  user-management-backend-deployment
user-management-backend-deployment-3264073543-l93m9               1/1       Running            0          33s

我使用过maxSurge: 2 和maxUnavailable: 1，但这似乎不起作用。

任何想法为什么这不起作用？

【参考方案1】：

好像是maxUnavailable: 1；我能够轻松地重现您设置该值的体验，并通过将其设置为 maxUnavailable: 0

轻松实现正确的体验

这是我对调度程序如何得出您所遇到的行为的“伪证明”：

因为replicas: 1，k8s 的期望状态恰好是Ready 中的一个 Pod。在滚动更新操作期间，这是您请求的策略，它将创建一个新 Pod，使总数达到 2。但是您授予 k8s 允许 一个 Pod 处于不可用状态，并且您指示它将期望的 Pod 数量保持在 1。因此，它满足了所有这些约束：1 Pod，期望的数量，处于不可用状态，由 RU 策略允许。

通过将maxUnavailable 设置为零，您可以正确地指示 k8s 永远不要让任何 Pod 不可用，即使这意味着 Pod 会在短时间内飙升至超过 replica 计数

【讨论】：

假设我们有maxUnavailable: 0 的这种部署策略，k8s 会耗尽节点吗？在此之前它会在现有节点上创建新的 pod 吗？

【参考方案2】：

将 Strategy Type 设置为 RollingUpdate 会在删除旧 pod 之前创建一个新 pod，即使只有一个副本也是如此。策略类型Recreate 在创建新 pod 之前杀死旧 pod https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment

【讨论】：

OP 正在使用策略类型 RollingUpdate 因为他想要这种行为 - 不确定这个答案有什么帮助......

【参考方案3】：

正如已经回答的那样，您可以将 maxUnavailable 设置为 0 以获得所需的结果。一些额外的说明：

当使用挂载单个特定卷的有状态服务时，您不应期望这会工作，该卷将由新 pod 使用。该卷将附加到即将更换的 pod，因此无法附加到新的 pod。

文档指出，如果您已将 .spec.strategy.rollingUpdate.maxSurge 设置为 0，则无法将其设置为 0。

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable

【讨论】：

那么你是说如果我们在 pod 上有一个永久卷，我们就不应该这样做吗？