EDITORIAL
前の記事チュートリアル（e）の中心的な概念の深い理解のkubernetesシリーズは、ポッド当初導入に続いて、重要な概念ポッドYAML学習kubernetesを導入チュートリアルのkubernetesシリーズリソースリソース品質ポッドの管理とサービスのサービス品質のポッド。
1.ポッドリソース管理
1.1リソース定義
cggroupを操作する方法、必要なリソースを割り当てるプロセス・コンテナー操作の必要性は、それをリンクさ？リクエストと制限、要求スケジューリングポッドは、必要性を表明リソースの要求、初期kubernetesのための主要な根拠を示しています。答えはアロケーションユニット資源配分を達成することである、リソース定義により、リソースは、2つのCPUとメモリ、リソースの種類の定義があります満たすリソースを割り当てることは、サイズ制限定義された制限を超えることができない、すなわち、ポッド、制限リソースの制約を表し、限定よりcggroup介して、リソースは、以下の4つのフィールドによって定義されたポッドを定義することができます。
- 。Spec.container [] resources.requests.cpu CPUリソースは、0.1 CPUと100メートル分布1/10 CPUを表すように、大きさを求め、
- 。Spec.container []はresources.requests.memory要求されたメモリのサイズは、使用可能な単位M、MI、G、Giが表します。
- 。Spec.container [] resources.limits.cpu CPUサイズの上限が閾値、限界値cggroupを超えることができません。
- 。Spec.container []はresources.limits.memory制限されたメモリサイズ、閾値を超えることができない、それはOOM以上発生します。
1つのスタート、一例としてnginxの、デモを定義するために、コンテナリソース要求CPUの250メートルをポッドリソース・リソースを定義する方法を学ぶためには、メモリリソース256Miを制限するために、メモリリソース128Mi要求、500メートルに制限され、もちろん、複数の容器を画定しますリソースは、コンテナの合計の複数は、次のように資源が、資源であるポッド：
[root@node-1 demo]#cat nginx-resource.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
labels:
name: nginx-demo
spec:
containers:
- name: nginx-demo
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port-80
protocol: TCP
containerPort: 80
resources:
requests:
cpu: 0.25
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi図2に示すように、構成定義アプリケーションポッド（以前に存在するようにポッドは、それがポッド<ポッド-name>を削除kubectl削除）、または別の名前は、名前付きPOD
[root@node-1 demo]# kubectl apply -f nginx-resource.yaml
pod/nginx-demo created3、資源配分は、ビューポッドの詳細を
[root@node-1 demo]# kubectl get pods
NAME READY STATUS RESTARTS AGE
demo-7b86696648-8bq7h 1/1 Running 0 12d
demo-7b86696648-8qp46 1/1 Running 0 12d
demo-7b86696648-d6hfw 1/1 Running 0 12d
nginx-demo 1/1 Running 0 94s
[root@node-1 demo]# kubectl describe pods nginx-demo
Name: nginx-demo
Namespace: default
Priority: 0
Node: node-3/10.254.100.103
Start Time: Sat, 28 Sep 2019 12:10:49 +0800
Labels: name=nginx-demo
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"name":"nginx-demo"},"name":"nginx-demo","namespace":"default"},"sp...
Status: Running
IP: 10.244.2.13
Containers:
nginx-demo:
Container ID: docker://55d28fdc992331c5c58a51154cd072cd6ae37e03e05ae829a97129f85eb5ed79
Image: nginx:1.7.9
Image ID: docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sat, 28 Sep 2019 12:10:51 +0800
Ready: True
Restart Count: 0
Limits: #限制资源
cpu: 500m
memory: 256Mi
Requests: #请求资源
cpu: 250m
memory: 128Mi
Environment: <none>
...省略...4、どのようにポッドリソースの割り当て、それ？そこノードから割り当てられている疑いがある、と私たちは、設定された要求、kubernetesスケジューラKUBE-スケジューラが実行する2つのスケジューリングプロセスあれば時間のポッドを作成するとき：重量を計量フィルターとフィルター、KUBE-スケジューラは、要求に基づいて行われますリソースフィルタは、資格のあるノードをフィルタリングするために、その後、ソート、フィルタは最も外のノードの運用ポッドを満たすために、その後、特定のノード上のポッドを実行します。スケジューリングアルゴリズムおよび詳細は、参照することができkubernetesは、スケジューリングアルゴリズムを説明しました。以下は、ディストリビューションノード3ノードのリソースの詳細、次のとおりです。
[root@node-1 ~]# kubectl describe node node-3
...省略...
Capacity: #节点上资源的总资源情况，1个cpu，2g内存，110个pod
cpu: 1
ephemeral-storage: 51473888Ki
hugepages-2Mi: 0
memory: 1882352Ki
pods: 110
Allocatable: #节点容许分配的资源情况，部分预留的资源会排出在Allocatable范畴
cpu: 1
ephemeral-storage: 47438335103
hugepages-2Mi: 0
memory: 1779952Ki
pods: 110
System Info:
Machine ID: 0ea734564f9a4e2881b866b82d679dfc
System UUID: FFCD2939-1BF2-4200-B4FD-8822EBFFF904
Boot ID: 293f49fd-8a7c-49e2-8945-7a4addbd88ca
Kernel Version: 3.10.0-957.21.3.el7.x86_64
OS Image: CentOS Linux 7 (Core)
Operating System: linux
Architecture: amd64
Container Runtime Version: docker://18.6.3
Kubelet Version: v1.15.3
Kube-Proxy Version: v1.15.3
PodCIDR: 10.244.2.0/24
Non-terminated Pods: (3 in total) #节点上运行pod的资源的情况，除了nginx-demo之外还有多个pod
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE
--------- ---- ------------ ---------- --------------- ------------- ---
default nginx-demo 250m (25%) 500m (50%) 128Mi (7%) 256Mi (14%) 63m
kube-system kube-flannel-ds-amd64-jp594 100m (10%) 100m (10%) 50Mi (2%) 50Mi (2%) 14d
kube-system kube-proxy-mh2gq 0 (0%) 0 (0%) 0 (0%) 0 (0%) 12d
Allocated resources: #已经分配的cpu和memory的资源情况
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 350m (35%) 600m (60%)
memory 178Mi (10%) 306Mi (17%)
ephemeral-storage 0 (0%) 0 (0%)
Events: <none>1.2資源配分の原則
ポッドアクション要求およびスケジューラkubernetes KUBE-shedulerで定義されたリソース制限は、実際に隔離コンテナによるCPUとメモリのコンテナで定義されたリソース、リソースのcggroupを適用し、私たちは、次のリソースをご紹介します配分の原則。
- spec.containers []。resources.requests.cpu役割CpuSharesは、重量担当CPU配分比を表すときスクランブル
- spec.containers []。resources.requests.memory主に使用KUBE-スケジューラスケジューラ、コンテナが設けられていないという意味
- :. CpuQuota / CpuPeriodとして計算spec.containers [] resources.limits.cpuロールCpuQuotaとCpuPeriod、マイクロ秒は、例えば500メートルの使用を可能にするように、使用することができる最大のCPUの最大パーセンテージを示し、50％のCPUを表しますリソース
- spec.containers []メモリ内resources.limits.memory役割は、容器の最大利用可能なメモリサイズを表し、それがOOMを超えます
上記で定義したnginxの、デモに、例えば、要求および制限力にドッカーで研究中の定義されたアプリケーションパラメータをポッド。
図1に示すように、ノードのノードビューポッドは、ノード3にnginxの-デモスケジューリングノード、配置されています
[root@node-1 ~]# kubectl get pods -o wide nginx-demo
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-demo 1/1 Running 0 96m 10.244.2.13 node-3 <none> <none>図2に示すように、取得されたコンテナのID番号はContainerIDのことで取得することができるポッドは、容器のIDに、デモをnginxの説明kubectl、ノードnode-3を得へIDまたはログインがコンテナ名に通して濾過し、デフォルトは、二つのポッドであろう：aで別のアプリケーションのイメージで作成された一時停止画像作成、
[root@node-3 ~]# docker container list |grep nginx
55d28fdc9923 84581e99d807 "nginx -g 'daemon of…" 2 hours ago Up 2 hours k8s_nginx-demonginx-demo_default_66958ef7-507a-41cd-a688-7a4976c6a71e_0
2fe0498ea9b5 k8s.gcr.io/pause:3.1 "/pause" 2 hours ago Up 2 hours k8s_POD_nginx-demo_default_66958ef7-507a-41cd-a688-7a4976c6a71e_03、[表示]ドッキングウィンドウコンテナは、情報の詳細を
[root@node-3 ~]# docker container inspect 55d28fdc9923
[
...部分输出省略...
{
"Image": "sha256:84581e99d807a703c9c03bd1a31cd9621815155ac72a7365fd02311264512656",
"ResolvConfPath": "/var/lib/docker/containers/2fe0498ea9b5dfe1eb63eba09b1598a8dfd60ef046562525da4dcf7903a25250/resolv.conf",
"HostConfig": {
"Binds": [
"/var/lib/kubelet/pods/66958ef7-507a-41cd-a688-7a4976c6a71e/volumes/kubernetes.io~secret/default-token-5qwmc:/var/run/secrets/kubernetes.io/serviceaccount:ro",
"/var/lib/kubelet/pods/66958ef7-507a-41cd-a688-7a4976c6a71e/etc-hosts:/etc/hosts",
"/var/lib/kubelet/pods/66958ef7-507a-41cd-a688-7a4976c6a71e/containers/nginx-demo/1cc072ca:/dev/termination-log"
],
"ContainerIDFile": "",
"LogConfig": {
"Type": "json-file",
"Config": {
"max-size": "100m"
}
},
"UTSMode": "",
"UsernsMode": "",
"ShmSize": 67108864,
"Runtime": "runc",
"ConsoleSize": [
0,
0
],
"Isolation": "",
"CpuShares": 256, CPU分配的权重，作用在requests.cpu上
"Memory": 268435456, 内存分配的大小，作用在limits.memory上
"NanoCpus": 0,
"CgroupParent": "kubepods-burstable-pod66958ef7_507a_41cd_a688_7a4976c6a71e.slice",
"BlkioWeight": 0,
"BlkioWeightDevice": null,
"BlkioDeviceReadBps": null,
"BlkioDeviceWriteBps": null,
"BlkioDeviceReadIOps": null,
"BlkioDeviceWriteIOps": null,
"CpuPeriod": 100000, CPU分配的使用比例，和CpuQuota一起作用在limits.cpu上
"CpuQuota": 50000,
"CpuRealtimePeriod": 0,
"CpuRealtimeRuntime": 0,
"CpusetCpus": "",
"CpusetMems": "",
"Devices": [],
"DeviceCgroupRules": null,
"DiskQuota": 0,
"KernelMemory": 0,
"MemoryReservation": 0,
"MemorySwap": 268435456,
"MemorySwappiness": null,
"OomKillDisable": false,
"PidsLimit": 0,
"Ulimits": null,
"CpuCount": 0,
"CpuPercent": 0,
"IOMaximumIOps": 0,
"IOMaximumBandwidth": 0,
},
}
]1.3。CPUリソースのテスト
ポッドCPU制限は、主requests.cpuとlimits.cpuによって、制限は、CPUのサイズを超えてはならない、我々はストレスをミラーリングすることによって確認定義され、応力は、圧力引数を指定されたパラメータを定義することによって、圧縮側CPUとメモリ手段でありますCPUのサイズ側。ポッドCPUとメモリが現在インストールされていない、そのようなメトリックサーバまたはプロメテウスを監視するように、構成要素に応じて、kubectl上部の方法によって見ることができる監視、我々は、ドッカー統計を通じて方法を参照します。
図1に示すように、ミラーは、応力POD、比率0.5で使用される上限及びコアを割り当て0.25コアで定義されています
[root@node-1 demo]# cat cpu-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
namespace: default
annotations:
kubernetes.io/description: "demo for cpu requests and"
spec:
containers:
- name: stress-cpu
image: vish/stress
resources:
requests:
cpu: 250m
limits:
cpu: 500m
args:
- -cpus
- "1"2、アプリケーションファイルが生成されたポッドYAML
[root@node-1 demo]# kubectl apply -f cpu-demo.yaml
pod/cpu-demo created3、ビューリソース割り当ての詳細ポッド
[root@node-1 demo]# kubectl describe pods cpu-demo
Name: cpu-demo
Namespace: default
Priority: 0
Node: node-2/10.254.100.102
Start Time: Sat, 28 Sep 2019 14:33:12 +0800
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubernetes.io/description":"demo for cpu requests and"},"name":"cpu-demo","nam...
kubernetes.io/description: demo for cpu requests and
Status: Running
IP: 10.244.1.14
Containers:
stress-cpu:
Container ID: docker://14f93767ad37b92beb91e3792678f60c9987bbad3290ae8c29c35a2a80101836
Image: progrium/stress
Image ID: docker-pullable://progrium/stress@sha256:e34d56d60f5caae79333cee395aae93b74791d50e3841986420d23c2ee4697bf
Port: <none>
Host Port: <none>
Args:
-cpus
1
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: Sat, 28 Sep 2019 14:34:28 +0800
Finished: Sat, 28 Sep 2019 14:34:28 +0800
Ready: False
Restart Count: 3
Limits: #cpu限制使用的比例
cpu: 500m
Requests: #cpu请求的大小
cpu: 250m図4は、ノードに特定のノードを着陸、ドッカー容器統計リソースの使用状況の詳細によってコンテナを表示します
トップビューが所有するノードポッドに、CPU使用限度率は50％です。
500メートル、テスト検証ポッドリソースが厳しく制限されている容器またはホスト内部に既にそれが上記の検証から結論付けることができる、我々が使用することができるlimits.cpu CPUのサイズを定義することにより、コア容器が使用される応力を、定義されています50％（一つだけのマシンのノードのCPUに、2種類のCPUがある場合、25％を共有するであろう）。
1.4メモリ・テスト・リソース
図1に示すように、画像効果やストレステストを取り、検証requests.memory limits.memory、容器の大きさは、メモリセットのサイズを超えた場合に、以下に定義されるようにOOM容器は、試験容器を発生する、メモリ資源を用いることができる定義limits.memory応力ミラー--vmバイトメモリサイズが定義され、圧縮側256Miを使用して、最大メモリ512Mを超えることはできません
[root@node-1 demo]# cat memory-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-stress-demo
annotations:
kubernetes.io/description: "stress demo for memory limits"
spec:
containers:
- name: memory-stress-limits
image: polinux/stress
resources:
requests:
memory: 128Mi
limits:
memory: 512Mi
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "256M", "--vm-hang", "1"]2、アプリケーションファイルが生成されたポッドYAML
[root@node-1 demo]# kubectl apply -f memory-demo.yaml
pod/memory-stress-demo created
[root@node-1 demo]# kubectl get pods memory-stress-demo -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
memory-stress-demo 1/1 Running 0 41s 10.244.1.19 node-2 <none> <none>3、リソースの割り当てを参照してください
[root@node-1 demo]# kubectl describe pods memory-stress-demo
Name: memory-stress-demo
Namespace: default
Priority: 0
Node: node-2/10.254.100.102
Start Time: Sat, 28 Sep 2019 15:13:06 +0800
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubernetes.io/description":"stress demo for memory limits"},"name":"memory-str...
kubernetes.io/description: stress demo for memory limits
Status: Running
IP: 10.244.1.16
Containers:
memory-stress-limits:
Container ID: docker://c7408329cffab2f10dd860e50df87bd8671e65a0f8abb4dae96d059c0cb6bb2d
Image: polinux/stress
Image ID: docker-pullable://polinux/stress@sha256:6d1825288ddb6b3cec8d3ac8a488c8ec2449334512ecb938483fc2b25cbbdb9a
Port: <none>
Host Port: <none>
Command:
stress
Args:
--vm
1
--vm-bytes
256Mi
--vm-hang
1
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: Error
Exit Code: 1
Started: Sat, 28 Sep 2019 15:14:08 +0800
Finished: Sat, 28 Sep 2019 15:14:08 +0800
Ready: False
Restart Count: 3
Limits: #内存限制大小
memory: 512Mi
Requests: #内存请求大小
memory: 128Mi
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-5qwmc (ro)4、ビュー使用容器メモリリソースは、メモリ256M、512Miの最大使用、50％の利用率を割り当て、この場合は、制限のサイズ制限、容器の正常な動作を超えません
内部コンテナがメモリのサイズ何が起こるか、我々は--vmバイトをします513Mにを超えた場合5、コンテナが再起動し、より多くのメモリよりはOOMになります後、KUBE-コントローラマネージャは、コンテナを再起動しようとしていきます、実行しようとします数が増加していきます。
[root@node-1 demo]# cat memory-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-stress-demo
annotations:
kubernetes.io/description: "stress demo for memory limits"
spec:
containers:
- name: memory-stress-limits
image: polinux/stress
resources:
requests:
memory: 128Mi
limits:
memory: 512Mi
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "520M", "--vm-hang", "1"] . #容器中使用内存为520M
查看容器的状态为OOMKilled，RESTARTS的次数不断的增加，不停的尝试重启
[root@node-1 demo]# kubectl get pods memory-stress-demo
NAME READY STATUS RESTARTS AGE
memory-stress-demo 0/1 OOMKilled 3 60s2.サービスの品質ポッド
サービス品質QoS（サービス品質）は、主参照ポッドスケジューリングと追放、異なる優先順位に対応するサービスQOSの異なる品質は、QoSを三種類に分けられる重要な要因のために使用されます。
- リソースを割り当てるために最善を尽くしBESTEFFORT、デフォルトのリソース割り当てのQoS、最も低い優先度を指定していません。
- バースト可能な缶が変動資源は資源、共通QOSの要求に少なくとも割り当てられる必要があります。
- 完全なリソースをサポートする保証、同じ要求および制限は、最優先のリソースを定義しました。
2.1にBestEffort最善の努力
1、PODが定義されていないリソースは、デフォルトのQoS戦略にBestEffort、追い出すのeviceに必要とされるリソースの進歩に比べ最も低い優先度は、優先度の排出にBestEffortポッドを定義して、定義されるようにBestEffortのポッドは、以下
[root@node-1 demo]# cat nginx-qos-besteffort.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-qos-besteffort
labels:
name: nginx-qos-besteffort
spec:
containers:
- name: nginx-qos-besteffort
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port-80
protocol: TCP
containerPort: 80
resources: {}2、ポッドを作成しにBestEffortにQoS戦略、qosClassを見ます
[root@node-1 demo]# kubectl apply -f nginx-qos-besteffort.yaml
pod/nginx-qos-besteffort created
查看Qos策略
[root@node-1 demo]# kubectl get pods nginx-qos-besteffort -o yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"name":"nginx-qos-besteffort"},"name":"nginx-qos-besteffort","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.7.9","imagePullPolicy":"IfNotPresent","name":"nginx-qos-besteffort","ports":[{"containerPort":80,"name":"nginx-port-80","protocol":"TCP"}],"resources":{}}]}}
creationTimestamp: "2019-09-28T11:12:03Z"
labels:
name: nginx-qos-besteffort
name: nginx-qos-besteffort
namespace: default
resourceVersion: "1802411"
selfLink: /api/v1/namespaces/default/pods/nginx-qos-besteffort
uid: 56e4a2d5-8645-485d-9362-fe76aad76e74
spec:
containers:
- image: nginx:1.7.9
imagePullPolicy: IfNotPresent
name: nginx-qos-besteffort
ports:
- containerPort: 80
name: nginx-port-80
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
...省略...
status:
hostIP: 10.254.100.102
phase: Running
podIP: 10.244.1.21
qosClass: BestEffort #Qos策略
startTime: "2019-09-28T11:12:03Z"3、テストポッドを削除
[root@node-1 demo]# kubectl delete pods nginx-qos-besteffort
pod "nginx-qos-besteffort" deleted2.2バースタブルが変動してもよいです
1、保証されたサービスの品質、少なくとも一つのコンテナ定義リクエスト、及び制限定義されたリソースを要求するリソースよりも小さい後バースタブルポッドのためのサービスの品質、
[root@node-1 demo]# cat nginx-qos-burstable.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-qos-burstable
labels:
name: nginx-qos-burstable
spec:
containers:
- name: nginx-qos-burstable
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port-80
protocol: TCP
containerPort: 80
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 200m
memory: 256Mi図2に示すように、アプリケーションは、ポッドYAMLファイルとビューQoS種別を生成します
[root@node-1 demo]# kubectl apply -f nginx-qos-burstable.yaml
pod/nginx-qos-burstable created
查看Qos类型
[root@node-1 demo]# kubectl describe pods nginx-qos-burstable
Name: nginx-qos-burstable
Namespace: default
Priority: 0
Node: node-2/10.254.100.102
Start Time: Sat, 28 Sep 2019 19:27:37 +0800
Labels: name=nginx-qos-burstable
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"name":"nginx-qos-burstable"},"name":"nginx-qos-burstable","namespa...
Status: Running
IP: 10.244.1.22
Containers:
nginx-qos-burstable:
Container ID: docker://d1324b3953ba6e572bfc63244d4040fee047ed70138b5a4bad033899e818562f
Image: nginx:1.7.9
Image ID: docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sat, 28 Sep 2019 19:27:39 +0800
Ready: True
Restart Count: 0
Limits:
cpu: 200m
memory: 256Mi
Requests:
cpu: 100m
memory: 128Mi
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-5qwmc (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-5qwmc:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-5qwmc
Optional: false
QoS Class: Burstable #服务质量是可波动的Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 95s default-scheduler Successfully assigned default/nginx-qos-burstable to node-2
Normal Pulled 94s kubelet, node-2 Container image "nginx:1.7.9" already present on machine
Normal Created 94s kubelet, node-2 Created container nginx-qos-burstable
Normal Started 93s kubelet, node-2 Started container nginx-qos-burstable2.3保証完全な保護
図1に示すように、リソースのCPUとメモリの制限に定義され、要求が含まれている必要があり、およびQoSの排出型の保護にスケジューリングおよび優先度がある場合、カット値の制限は、最高の優先順位であり、同じでなければならない要求し、それはnginxの-qos-を以下のように定義保証の容器、および同じrequests.cpuのlimits.cpu、と共感requests.memory limits.memory。
[root@node-1 demo]# cat nginx-qos-guaranteed.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-qos-guaranteed
labels:
name: nginx-qos-guaranteed
spec:
containers:
- name: nginx-qos-guaranteed
image: nginx:1.7.9
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port-80
protocol: TCP
containerPort: 80
resources:
requests:
cpu: 200m
memory: 256Mi
limits:
cpu: 200m
memory: 256Mi2、アプリケーションは、ポッドYAMLファイルを生成し、完全に保証保証されるQoSタイプのポッドを見ます
[root@node-1 demo]# kubectl apply -f nginx-qos-guaranteed.yaml
pod/nginx-qos-guaranteed created
[root@node-1 demo]# kubectl describe pods nginx-qos-guaranteed
Name: nginx-qos-guaranteed
Namespace: default
Priority: 0
Node: node-2/10.254.100.102
Start Time: Sat, 28 Sep 2019 19:37:15 +0800
Labels: name=nginx-qos-guaranteed
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"labels":{"name":"nginx-qos-guaranteed"},"name":"nginx-qos-guaranteed","names...
Status: Running
IP: 10.244.1.23
Containers:
nginx-qos-guaranteed:
Container ID: docker://cf533e0e331f49db4e9effb0fbb9249834721f8dba369d281c8047542b9f032c
Image: nginx:1.7.9
Image ID: docker-pullable://nginx@sha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Sat, 28 Sep 2019 19:37:16 +0800
Ready: True
Restart Count: 0
Limits:
cpu: 200m
memory: 256Mi
Requests:
cpu: 200m
memory: 256Mi
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-5qwmc (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-5qwmc:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-5qwmc
Optional: false
QoS Class: Guaranteed #服务质量为可完全保障Guaranteed
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25s default-scheduler Successfully assigned default/nginx-qos-guaranteed to node-2
Normal Pulled 24s kubelet, node-2 Container image "nginx:1.7.9" already present on machine
Normal Created 24s kubelet, node-2 Created container nginx-qos-guaranteed
Normal Started 24s kubelet, node-2 Started container nginx-qos-guaranteed最後に書かれました
この章さkubernetesチュートリアル第六の記事、QoSは、リソースの使用による資源配分とサービスの品質上のノードは、リソースの提案をご紹介があります。
- 要求とリソース定義は、これ以上1以下の制限をお勧めします：2、あまりにも多くのリソースやリソースの競合が発生する割り当てを回避するために、OOMが発生しました。
- ポッドデフォルトはリソースを定義されていない、ポッドは、リソースに割り当てることができることを確認し、名前空間limitrangeを定義することをお勧めします。
- 過剰なマシンリソースがライブまたはOOMハングが発生し、お薦めのノードを提供するリソースの保持及び排出を防止する、そのようなリソースが--system予約予約され= CPU = 200メートル、メモリ= 1G、排出条件は、ノード上のハード= memory.available --eviction < 500Mi。
付録
コンテナは、リソース管理を計算します：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
ポッドメモリリソースの管理：https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/
ポッドCPUリソース管理：https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/
サービス品質QoS：https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
CPUの制限にドッカー：https://www.cnblogs.com/sparkdev/p/8052522.html
あなたの才能があなたの野望をサポートする余裕がないときは、学習を停止する必要があります