我们Node上的资源是一定的，CPU和内存都是固定的，例如8CPU 32G
我们的scheduler在schedule pod的时候就会考察Node上是否有足够的CPU 和内存来支撑Pod,如果没有，那么我们会看到Pod 一直是pendding的状态
默认情况下，kubernete 认为一个pod运行至少需要0.5个cpu 和256M内存，当然实际情况是我们的pod要比这个多，我们可以通过如下方式在创建pod的时候修改request的值
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
apiVersion: v1 kind: Pod metadata: name: simple-webapp-color labels: name: simple-webapp-color spec: containers: - name: simple-webapp-color image: simple-webapp-color ports: - containerPort: 8080 resources: requests: memory: "1Gi" cpu: "1" |
上边例子中request的内存和CPU分别是1G 和1 vCPU
注意一点，Request 类似告诉Kuberentes说这个pod 要正常运行，至少需要1G内存，和1 vcpu,所以，这个pod 要去的Node 上的剩余资源肯定要大于1G内存， 大于1个cpu,但是注意，并不代表说我们的pod 实际就会用这么多，实际情况是我们的Pod实际上可能只用了512M内存，也可能会用到4G内存
为了防止pod 用太多资源，虽然Request 的很少，但是如果不加控制，就可能使用太多资源，所以，我们可以通过另外一个字段来控制
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
apiVersion: v1 kind: Pod metadata: name: simple-webapp-color labels: name: simple-webapp-color spec: containers: - name: simple-webapp-color image: simple-webapp-color ports: - containerPort: 8080 resources: requests: memory: "1Gi" cpu: "1" limits: memory: "2Gi" cpu: "2" |
上边这个例子，就是限制了最多用2G内存，最多用1个vcpu
其实，最好的实践是我们把Request 和Limits的值设置成一样的值（具体原因后续会提到）
如果我们的pod 使用超过limits 会发生什么？
CPU 如果超过了，什么都不会发生
内存如果超过了，pod就会被干掉(其实是使用超过limit的进程被干掉)
前边说的默认的0.5 cpu 和256Mi 内存需要我们提前设置好，这部分叫LimitRange
内存
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: v1 kind: LimitRange metadata: name: mem-limit-range spec: limits: - default: memory: 512Mi defaultRequest: memory: 256Mi type: Container |
CPU：
|
1 2 3 4 5 6 7 8 9 10 11 |
apiVersion: v1 kind: LimitRange metadata: name: cpu-limit-range spec: limits: - default: cpu: 1 defaultRequest: cpu: 0.5 type: Container |
也就是你在哪个namespace下创建了这两个玩意，哪个namespace下的Pod旧有默认的资源限制了
Latest posts by Zhiming Zhang (see all)
- aws eks node 自动化扩展工具 Karpenter - 8月 10, 2022
- ReplicationController and ReplicaSet in Kubernetes - 12月 20, 2021
- public key fingerprint - 5月 27, 2021