一 為pod分配cpu，記憶體以及其他的資源
1.1 建立一個pod，同時為這個pod分配記憶體以及cpu的資源請求量
apiVersion: v1 kind: Pod metadata: name: requests-pod spec: containers: - image: busybox command: ["dd", "if=/dev/zero", "of=/dev/null"] name: main resources: requests: cpu: 200m memory: 10Mi
- 如下配置的容器裡面新增了requests欄位，包括cpu以及記憶體的請求量
- cpu:200m的含義是容器最少可使用宿主機的200毫核(即一個cpu核心時間的1/5)
- memory:10Mi的含義是該容器使用10M的記憶體
1.2 來驗證一下這個pod內的容器使用的cpu核數
Mem: 2904756K used, 977004K free, 179080K shrd, 0K buff, 2061448K cached CPU: 4.4% usr 21.6% sys 0.0% nic 73.5% idle 0.0% io 0.0% irq 0.0% sirq Load average: 1.04 1.07 1.05 2/424 15 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 1 0 root R 1300 0.0 2 25.0 dd if /dev/zero of /dev/null 6 0 root S 1308 0.0 1 0.0 top 11 0 root R 1308 0.0 3 0.0 top [root@node01 Chapter14]# cat /proc/cpuinfo| grep "processor"| wc -l 4
- 由於這個機器是一個四核的虛擬機器，，所有這個程式只能佔據全部核數的1/4
- 可以看到通過這個引數，讓容器最少可以使用20%，卻不是隻能使用20%
1.3 瞭解排程器如何判斷一個pod是否適合排程某個節點
首先排程器在排程的適合並不關注各類資源在當前時刻的實際使用量，而只關心節點上pod的資源的申請量之和，原因是如果是看叢集所有資源的實際使用總和的話，那麼之前那些資源分配的額度就有可能達不到了
用一張圖來看下所描述的現象
- 如下圖所示，節點上CPU的申請量是80%，但是實際使用量只有70%，我們的podD的申請量是25%
- 若按照實際使用量來看，pod還是可以被排程上去的，但是實際上已經無法進行排程了，因為它是根據資源的申請量來計算的
1.4 排程器如何通過pod requests為其選擇最佳節點
之前瞭解過排程器的排程原理的時候，首先會排除那些不滿足需求的節點，之後會有一個LeastRequestPriority和MostRequestPriority，前者優先順序將pod排程到請求量少的節點，而後者則是優先將pod排程到請求資源較多的節點，一般自家建設的kubernetes叢集都傾向於使用前面的策略，這樣的話負載均衡會好點，但是如果是執行雲基礎設施上面的話，使用後者的話，會省去一筆很大的開支
1.5 檢視節點資源總量
Name: node01
...... InternalIP: 172.16.70.4 Hostname: node01 Capacity: cpu: 4 ephemeral-storage: 8178Mi hugepages-2Mi: 0 memory: 3881760Ki pods: 110 Allocatable: cpu: 4 ephemeral-storage: 7717729063 hugepages-2Mi: 0 memory: 3779360Ki pods: 110
......
- 紅色字型顯示的節點的資源總量
- 綠色的字型顯示的可分配給pod的資源量
- 之所以系統總量和可分配給pod的總量，是因為要預留一些資源給系統的pod
1.6 建立一個cpu請求量較大的pod,觀察能否建立成功，如果失敗又是如何
[root@node01 Chapter14]# k run request-pod-3 --image=busybox --restart Never --requests='cpu=4,memory=20Mi' -- dd if=/dev/zero of=/dev/null pod/request-pod-3 created [root@node01 Chapter14]# k get po NAME READY STATUS RESTARTS AGE request-pod-2 1/1 Running 0 3m4s request-pod-3 0/1 Pending 0 3s requests-pod 1/1 Running 0 4h52m
[root@node01 Chapter14]# k describe po request-pod-3 Name: request-pod-3 Namespace: default Priority: 0 Node: <none> Labels: run=request-pod-3 Annotations: <none> Status: Pending IP: IPs: <none> Containers: request-pod-3: Image: busybox Port: <none> Host Port: <none> Args: dd if=/dev/zero of=/dev/null Requests: cpu: 4 memory: 20Mi Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-tzwwt (ro) Conditions: Type Status PodScheduled False Volumes: default-token-tzwwt: Type: Secret (a volume populated by a Secret) SecretName: default-token-tzwwt Optional: false QoS Class: Burstable Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 13s (x2 over 13s) default-scheduler 0/3 nodes are available: 3 Insufficient cpu.
- 建立一個超級大cpu請求量之後，叢集的任何節點都無法滿足這個pod
- 如紅色字型顯示，無法排程到任何的節點，因為任何節點都沒有足夠的cpu可以分配
- 如果節點中的資源小於pod中需要分配的資源這種行為叫做超賣
1.7 cpu requests如何影響CPU時間分配
cpu request不僅僅起排程作用，它還決定著剩餘的CPU時間如何使用，如果叢集中有2個pod，一個使用了200毫核，另一個使用了1000毫核，那麼當2個pod拼命的使用資源的時候，第一個將使用16.7%，第二個將使用83.3的cpu使用時間
