我最近遇到了同样的问题，经过一些研究，我发现GKE有一个默认的LimitRange，CPU请求限制设置为100m，这可以通过运行kubectl get limitrange -o=yaml来检查。

apiVersion: v1
items:
- apiVersion: v1
  kind: LimitRange
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"v1","kind":"LimitRange","metadata":{"annotations":{},"name":"limits","namespace":"default"},"spec":{"limits":[{"defaultRequest":{"cpu":"100m"},"type":"Container"}]}}
    creationTimestamp: 2017-11-16T12:15:40Z
    name: limits
    namespace: default
    resourceVersion: "18741722"
    selfLink: /api/v1/namespaces/default/limitranges/limits
    uid: dcb25a24-cac7-11e7-a3d5-42010a8001b6
  spec:
    limits:
    - defaultRequest:
        cpu: 100m
      type: Container
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

这个限制适用于每个容器。例如，如果您有一个4核节点，并且假设您的每个POD将创建2个容器，则只允许创建约20个POD。
这里的“修复”是更改默认的LimitRange，设置您自己的限制，然后删除旧的pod，以便使用更新的值重新创建它们，或者在创建pod时直接设置它们的限制。
一些阅读材料：
https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/#specify-a-cpu-request-and-a-cpu-limit
https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/#create-a-limitrange-and-a-pod
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#how-pods-with-resource-limits-are-run
https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-resource-requests-and-limits

我在尝试部署到集群时遇到了同样的问题。在我的情况下，为我的应用程序的测试分支自动创建了不需要的pod。要诊断该问题，我需要执行以下操作：
kubectl get po
kubectl describe po-对于其中一个现有pod，用于检查它正在哪个节点上运行
kubectl get nodes
kubectl describe node-查看现有机架正在使用的节点的CPU使用情况，如下所示：

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                       Requests      Limits
  --------                       --------      ------
  cpu                            1010m (93%)   4 (210%)

然后，可以使用以下命令删除不需要的pod：
kubectl get deployments
kubectl delete deployment ....-我需要删除的单元的部署名称。
一旦我删除了足够多的未使用的pod，我就可以部署新的pod。

是的，目前不支持过量使用。它在计划中的改进http://kubernetes.io/docs/user-guide/compute-resources中。github的相关问题：https://github.com/kubernetes/kubernetes/issues/168
附言：理论上你可以定义自定义节点容量，但我不确定。

对我来说，在不同的名称空间（而不是default）中创建所有部署和服务解决了这个问题。

**TL;DR（如果使用限制和请求）：**降低CPU请求和/或限制。

内容：

在我的情况下，我管理的CPU和内存非常接近极限，下面是我一段时间后的发现。
假设我有如下的：

• 一个名为node-1的节点，CPU/A = 2000百万处理器和内存/A = 7827字节
• 一个名为app-1的应用程序，我想部署与Helm，采取所有理论上可用的。

看下面的截图，名字是轻微审查的原因，但你看到的大图片。
在我的例子中，我用一些resources.limits.cpu、resources.limits.memory、resources.requests.cpu、resources.requests.memory配置app-1，其中resources.limits.cpu最初设置为1000m。

具体发生了什么：

所以node-1不仅运行app-1，还运行其他3个额外的应用程序来做其他事情。从上到下，CPU请求的总和是100m + 0 + 250m + 1 (1000m) = 1350m（也可以在下面的资源分配中找到）。
看起来不错，但如果我想部署另一个版本的app-1，该怎么办？在这种情况下，我必须删除旧版本并重新创建它。
在某些情况下，这可能是可以接受的，但当我想部署一个更新到app-1与Helm在我的情况下（helm更新将删除旧的Pod，并开始一个新的提醒你）没有采取旧的下来第一，然后我会得到 * CPU不足的错误 *。
这是因为kube-scheduler“可能”会执行以下操作。它会获取您之前的CPU值，并将其添加到您要部署的新app-1的限制中。理论上，使CPU请求“超出请求的限制”。换句话说，在另一个Pod关闭之前，它会在很短的时间内执行1350 m + 1 (1000m) = 2350m。这就是问题所在，因为它超出了2000m的初始限制。

溶液：

这种情况下的解决方案是将CPU请求设置为一个较小的数字，可能仅为500m，这样初始值为100m + 0 + 250m + 500m = 850m，当它执行加法时，仅为100m + 0 + 250m + 500m + 500m = 1350m，仍低于2000m的硬限制。helm将删除旧的Pod，使整个请求CPU使用率恢复到850m，但有一个非常短的跨度，它总结了其余部分。