GKE Autopilot - 容器卡在特定节点的初始化阶段答案

【问题标题】：GKE Autopilot - Containers stuck in init phase on particular nodeGKE Autopilot - 容器卡在特定节点的初始化阶段
【发布时间】：2022-01-29 07:38:54
【问题描述】：

我正在使用 GKE 的 Autopilot 集群来运行一些 kubernetes 工作负载。将 Pod 安排到其中一个分配的节点大约需要 10 分钟才能停留在 init 阶段。不同节点中的同一个 pod 在几秒钟内就启动了。

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: jobs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: job
  template:
    metadata:
      labels:
        app: job
    spec:
      volumes:
        - name: shared-data
          emptyDir: {}
      initContainers:
        - name: init-volume
          image: gcr.io/dummy_image:latest
          imagePullPolicy: Always
          resources:
            limits:
              memory: "1024Mi"
              cpu: "1000m"
              ephemeral-storage: "10Gi"
          volumeMounts:
            - name: shared-data
              mountPath: /data
          command: ["/bin/sh","-c"]
          args:
          - cp -a /path /data;
      containers:
        - name: job-server
          resources:
            requests:
              ephemeral-storage: "5Gi"
            limits:
              memory: "1024Mi"
              cpu: "1000m"
              ephemeral-storage: "10Gi"
          image: gcr.io/jobprocessor:latest
          imagePullPolicy: Always
          volumeMounts:
            - name: shared-data
              mountPath: /ebdata1

仅当容器具有 init 容器时才会发生这种情况。在我的情况下，我将一些数据从虚拟容器复制到我安装在实际容器上的共享卷.. 但是，每当 pod 被安排到这个特定节点时，它就会在 init 阶段停留大约 10 分钟，然后自动得到解决。我在事件日志中看不到任何错误。

kubectl 描述节点有问题的节点

    Events:
  Type     Reason      Age   From            Message
  ----     ------      ----  ----            -------
  Warning  SystemOOM   52m   kubelet         System OOM encountered, victim process: cp, pid: 477887
  Warning  OOMKilling  52m   kernel-monitor  Memory cgroup out of memory: Killed process 477887 (cp) total-vm:2140kB, anon-rss:564kB, file-rss:768kB, shmem-rss:0kB, UID:0 pgtables:44kB oom_score_adj:-997

只有消息是上述警告。这个问题是由我这边的一些错误配置引起的吗？

【问题讨论】：

我可以帮助您了解其他信息吗？如果您认为我的回答对您有所帮助，请考虑通过单击左侧投票箭头下方的复选标记（✔️）来接受它。应将颜色更改为绿色。

标签： kubernetes google-kubernetes-engine

【解决方案1】：

最好的建议是在 Kubernetes 集群中正确管理容器计算资源。创建 Pod 时，您可以选择指定每个 Container 需要多少 CPU 和内存 (RAM) 以避免 OOM 情况。

当容器指定了资源请求时，调度程序可以更好地决定将 Pod 放置在哪些节点上。并且当容器指定了它们的限制时，可以以指定的方式处理节点上的资源争用。 CPU规格以核心为单位，内存以字节为单位。

每次调度器失败时都会产生一个事件，使用下面的命令查看事件的状态：

$ kubectl describe pod <pod-name>| grep Events

另外，请阅读有关“配置资源不足处理”的官方 Kubernetes 指南。始终确保：

为 kubelet 和 OS 内核等系统守护进程保留 10-20% 的内存容量，以识别 pod 在 90-95% 的内存利用率下可以被驱逐，以减少系统 OOM 的抖动和发生率。

为了促进这种情况，kubelet 将使用以下选项启动：

--eviction-hard=memory.available<xMi
--system-reserved=memory=yGi

拥有Heapster container monitoring 一定有助于可视化。在Kubernetes and Docker Administration 上阅读更多内容。

【讨论】：