为什么我不能在 e2 中型机器类型上为我的 pods 使用第二个 vCPU？
Why I can't use the second vCPU for my pods on a e2-medium machine type?
因为Google指的是here:
For a 2vCPUs machine type , the allocatable CPU= Capacity- Reserved =
2000mCPU- 6% of the first CPU- 1% of the second CPU= 2000mCPU-60mCPU
-10mCPU=1930 mCPU
我已经确认对于 e2-standard 2vCPU 机器类型。
但是，对于具有 2vCPU 的 e2-medium 机器，可分配的 CPU 是 940mCPU。
为什么我不能在 e2-medium 机器类型上为我的 pods 使用第二个 vCPU？
https://news.ycombinator.com/item?id=23289918
正如 google 在 2020 年 5 月 24 日所说：
今天，e2-micro、e2-small 和 e2-medium 有 1930 mCPU 的可分配资源供 Kubernetes 在每个节点上调度 Pods，随着这一变化，它将是940 米CPU。 Kubernetes 在调度期间使用节点可分配资源来决定它应该在节点上放置多少 Pods。如果您的工作负载当前请求的 CPU 资源多于升级后可用的资源，它们可能会在升级后变得未安排。
我将其作为 Community Wiki 发布，因为这个答案主要基于 Kostas Tsakos 已经发布的那个，实际上是它的扩展。
让我添加一些官方来源。此信息也可以在 release notes（2020 年 6 月 2 日）中找到，因此可以在官方 GCP 文档中找到：
As part of ensuring better representation of available resources on
the node for e2 burstable node types, GKE has decided to reduce the
allocatable CPU resources available to schedule user workloads (known
as the node allocatable
resources)
on e2-micro, e2-small, and e2-medium machine types.
What do I need to know?
Today, e2-micro, e2-small, and e2-medium have 1930 mCPU of
allocatable resources for Kubernetes to schedule Pods on per node, and
following this change it will be 940m CPU. Kubernetes uses the node
allocatable resources during scheduling to decide how many Pods it
should place on the node. If your workloads are currently
requesting more CPU resources than what will be available after
upgrading, they may become unscheduled after upgrade.
We are making this change in order to more accurately represent the
resources available in these machine types. These machine types can
temporarily burst to 2 vCPUs, but this is not sustained. The
underlying compute capabilities and resources are not changing, the
machines retain the ability to temporarily burst to 2 vCPU, this
change only affects how many resources the Kubernetes scheduler
considers when allocating Pods to nodes.
When your cluster is upgraded to 1.14.10-gke.42, 1.15.11-gke.18,
1.16.8- gke.17, or 1.17.5-gke.5 (whether you perform this manually
or you are automatically upgraded), your workloads may become
unscheduled if there are not enough allocatable resources in the
cluster.
正如 SYN, this is aplicable to shared-core machine types which leverage CPU bursting capability, that allows them to use up to 2vCPUs for short periods of time. This means the actual computing power available for most of the time is far lower than 2vCPUs. As you can read here 在评论中提到的：
When you use E2 shared-core machine types, your VM runs two vCPUs
simultaneously, shared on one physical core, for a specific fraction
of time, depending on the machine type.
e2-micro sustains 2 vCPUs, each for 12.5% of CPU time, totaling 25% vCPU time.e2-small sustains 2 vCPUs, each at 25% of CPU time, totaling 50% of vCPU time.e2-medium sustains 2 vCPUs, each at 50% of CPU time, totaling 100% vCPU time.
Each vCPU can burst up to 100% of CPU time, for short periods, before
returning to the time limitations above.
另请注意 table 中的引用：
1Fractional vCPU of 0.25, 0.5, or 1.0 with 2 vCPUs exposed to the
guest operating system.
这意味着尽管上述所有机器类型的可用 CPU 时间差异很大，但它们中的每一个都会向来宾操作系统公开 2 vCPUs（在本例中 GKE 节点).
所以真正介绍的是调整allocatable资源，供Kubernetes在node上调度Pods（从1930mCPU减少到940mCPU）以便它更准确地反映这些机器类型上可用的实际资源。
因为Google指的是here:
For a 2vCPUs machine type , the allocatable CPU= Capacity- Reserved = 2000mCPU- 6% of the first CPU- 1% of the second CPU= 2000mCPU-60mCPU -10mCPU=1930 mCPU
我已经确认对于 e2-standard 2vCPU 机器类型。
但是，对于具有 2vCPU 的 e2-medium 机器，可分配的 CPU 是 940mCPU。
为什么我不能在 e2-medium 机器类型上为我的 pods 使用第二个 vCPU？
https://news.ycombinator.com/item?id=23289918
正如 google 在 2020 年 5 月 24 日所说：
今天，e2-micro、e2-small 和 e2-medium 有 1930 mCPU 的可分配资源供 Kubernetes 在每个节点上调度 Pods，随着这一变化，它将是940 米CPU。 Kubernetes 在调度期间使用节点可分配资源来决定它应该在节点上放置多少 Pods。如果您的工作负载当前请求的 CPU 资源多于升级后可用的资源，它们可能会在升级后变得未安排。
我将其作为 Community Wiki 发布，因为这个答案主要基于 Kostas Tsakos 已经发布的那个，实际上是它的扩展。
让我添加一些官方来源。此信息也可以在 release notes（2020 年 6 月 2 日）中找到，因此可以在官方 GCP 文档中找到：
As part of ensuring better representation of available resources on the node for e2 burstable node types, GKE has decided to reduce the allocatable CPU resources available to schedule user workloads (known as the node allocatable resources) on
e2-micro,e2-small, ande2-mediummachine types.What do I need to know?
Today,
e2-micro,e2-small, ande2-mediumhave 1930 mCPU of allocatable resources for Kubernetes to schedule Pods on per node, and following this change it will be 940m CPU. Kubernetes uses the node allocatable resources during scheduling to decide how many Pods it should place on the node. If your workloads are currently requesting more CPU resources than what will be available after upgrading, they may become unscheduled after upgrade.We are making this change in order to more accurately represent the resources available in these machine types. These machine types can temporarily burst to 2 vCPUs, but this is not sustained. The underlying compute capabilities and resources are not changing, the machines retain the ability to temporarily burst to 2 vCPU, this change only affects how many resources the Kubernetes scheduler considers when allocating Pods to nodes.
When your cluster is upgraded to 1.14.10-gke.42, 1.15.11-gke.18, 1.16.8- gke.17, or 1.17.5-gke.5 (whether you perform this manually or you are automatically upgraded), your workloads may become unscheduled if there are not enough allocatable resources in the cluster.
正如 SYN, this is aplicable to shared-core machine types which leverage CPU bursting capability, that allows them to use up to 2vCPUs for short periods of time. This means the actual computing power available for most of the time is far lower than 2vCPUs. As you can read here 在评论中提到的：
When you use E2 shared-core machine types, your VM runs two vCPUs simultaneously, shared on one physical core, for a specific fraction of time, depending on the machine type.
e2-microsustains 2 vCPUs, each for 12.5% of CPU time, totaling 25% vCPU time.e2-smallsustains 2 vCPUs, each at 25% of CPU time, totaling 50% of vCPU time.e2-mediumsustains 2 vCPUs, each at 50% of CPU time, totaling 100% vCPU time.Each vCPU can burst up to 100% of CPU time, for short periods, before returning to the time limitations above.
另请注意 table 中的引用：
1Fractional vCPU of 0.25, 0.5, or 1.0 with 2 vCPUs exposed to the guest operating system.
这意味着尽管上述所有机器类型的可用 CPU 时间差异很大，但它们中的每一个都会向来宾操作系统公开 2 vCPUs（在本例中 GKE 节点).
所以真正介绍的是调整allocatable资源，供Kubernetes在node上调度Pods（从1930mCPU减少到940mCPU）以便它更准确地反映这些机器类型上可用的实际资源。