Kubernetes構成Podとコンテナ(五)応用資源割当と制限
10803 ワード
プレゼンテーションでは、Namespace、ResourceQuota、LimitRangeのリソースを使用しています.
開始前
Kubernetesクラスタが必要で、kubectlコマンドラインツールはクラスタとコミュニケーションすることができます.まだクラスタがない場合は、Minikubeを使用してクラスタを作成できます.
シーン
クラスタ管理者はマルチユーザチームのクラスタを操作し、クラスタ管理者は特定のクラスタでリソースを消費できる総量を制御し、クラスタの共有と制御コストを向上させることを望んでいる. podの実行を制限する計算リソース量 永続ボリューム宣言数を制限して、ストレージへのアクセスを制御する .負荷等化数を制限コスト を制御する.は、希少なリソースを保存するためにノードポートを使用することを制限する である.は、より良いスケジューリングポリシーを達成するためにデフォルトのコンピューティングリソース要求を提供する .
新しい名前空間
この例では、関連する概念を示すためにカスタムネーミングスペースで動作します.
quota-exampleという名前のネーミングスペースを新規作成しましょう.
オブジェクトカウント割当をネーミングスペースに適用する
クラスタ管理者は、次のリソースを制御します.永続ボリューム宣言 負荷等化 ノードポート ネーミングスペース内のオブジェクトのカウントを制御する簡単な割り当てを新規作成します.
割当システムは、割当が作成されたことを観察し、ネーミングスペース内のリソースの消費量を計算します.すぐに見えます.
割り当てを観察し、現在のネーミングスペースで消費されているものを見てみましょう.
ユーザーがアプリケーションを作成するために必要なリソースが各リソースで指定された数以上ある場合、割当システムは作成できません.
計算リソース割当のネーミングスペースへの適用
ネーミングスペースで消費できる計算リソースの量を制限し、割当追跡計算リソースを作成します.
割り当てを観察し、現在のネーミングスペースで消費されているものを見てみましょう.
割り当てシステムでは、ネーミングスペースに4つ以上の非端末podが許可されていません.さらにpodの各コンテナにcpuとメモリのrequestとlimitを定義するように強制します.
デフォルトのリソースリクエストと制限の適用
Podの開始者は、podにリソースリクエストと制限を指定することはめったにありません.
プロジェクトに割り当てを行ったので、エンドユーザーがcpuとメモリ制限のないpodを作成したときに何が起こったのかを見てみましょう.このpodにはnginxコンテナが含まれています.
このプレゼンテーションでは、nginxを実行するdeploymentを作成します.
作成したpodを見てみましょう.
podが作成されていないことがわかります!deploymentで何が起こったか見てみましょう.
deploymentは対応するコピーを作成し、podを作成しようとします.
replica setを見て、多くの詳細を取得します.
Kubernetes APIサービスはreplica set要求を拒否しました.私たちのpodはrequestsまたはlimitsのcpuとメモリを指定していないためです.
podが消費できるcpuとメモリリソースのデフォルト値を指定できます.
Kubernetes APIサービスがネーミングスペースでpodを作成する要求を観察し、podのコンテナに計算リソース要求が設定されていない場合、デフォルトのリソースrequestおよびlimitが制御の一部として適用されます.
この例では、作成された各podには、次のような計算リソースが含まれます.
ネーミングスペースにデフォルトのコンピューティングリソースを適用し、replica setでpodを作成できます.
ネーミングスペースのクォータを印刷して使用する場合:
作成したpodはコンピューティングリソースを消費しており、Kubernetesは使用状況を明確に追跡することができます.
プレミアム割当範囲
ネーミングスペースでデフォルトの消費リソースを指定したくないと仮定します.逆に、ユーザーに特定の数のBestEffort podをネーミングスペースで実行させ、分散したコンピューティングリソースを利用して、より高いサービス品質が必要なpodに対して明確なリソース要求を行うように要求したいと考えています.
ネーミングスペースを作成し、この動作を実証するために2つの割当を提供します.
このシナリオでは、podは、計算リソース要求が「best-effort」割当によって追跡されるように設定されていない.
2つのdeploymentsを作成して説明します.
デフォルトの制限が指定されていない場合でも、best-effort-nginxは8つのpodをすべて作成します.これは、best-effort構成を追跡し、not-best-effort構成は無視するためです.not-best-effort構成は、Burstableサービス品質を持つpodを作成したため、not-best-effort-nginx deploymentを追跡します.
ネーミングスペースのpodリストを見てみましょう.
10個のpodが作成されていることがわかります.
現在のネーミングスペース割当の使用状況を見てみましょう.
best-effort割当追跡はbest-effort-nginx deploymentの8つのpodの使用を作成し、not-best-effort構成は私たちが割当に作成したnot-best-effort-nginxの使用状況を追跡することがわかります.
scopeは、管理者のリソース消費の導入と追跡の柔軟性を向上させるために、割当説明を追跡するメカニズムを提供します.
BestEffortとNotBestEffortの範囲を除いて、長時間運転と時間制限のpodを制限する範囲があります.Terminatingの範囲はspec.activeDeadlineSecondsがnilでないpodと一致します.NotTerminatingの範囲はspec.activeDeadlineSecondsがnilの任意のpodに一致します.これらの範囲を使用すると、クラスタ内のノード上の予想される実行サイクルに基づいてpodを制限できます.
まとめ
ノードcpuとメモリリソースを消費するアクションは、ネーミングスペース定義の割当によって制限される場合があります.
これらのリソースを消費するアクションを調整したり、デフォルトのネーミングスペースレベルのデフォルト値を選択して最終的なニーズを満たすことができます.
割り当ては、サービス品質とクラスタノードで予想される持続性に基づいて割り当てることができる.
開始前
Kubernetesクラスタが必要で、kubectlコマンドラインツールはクラスタとコミュニケーションすることができます.まだクラスタがない場合は、Minikubeを使用してクラスタを作成できます.
シーン
クラスタ管理者はマルチユーザチームのクラスタを操作し、クラスタ管理者は特定のクラスタでリソースを消費できる総量を制御し、クラスタの共有と制御コストを向上させることを望んでいる.
新しい名前空間
この例では、関連する概念を示すためにカスタムネーミングスペースで動作します.
quota-exampleという名前のネーミングスペースを新規作成しましょう.
$ kubectl create namespace quota-example
namespace "quota-example" created
$ kubectl get namespaces
NAME STATUS AGE
default Active 2m
kube-system Active 2m
quota-example Active 39s
オブジェクトカウント割当をネーミングスペースに適用する
クラスタ管理者は、次のリソースを制御します.
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-object-counts.yaml --namespace=quota-example
resourcequota "object-counts" created
割当システムは、割当が作成されたことを観察し、ネーミングスペース内のリソースの消費量を計算します.すぐに見えます.
割り当てを観察し、現在のネーミングスペースで消費されているものを見てみましょう.
$ kubectl describe quota object-counts --namespace=quota-example
Name: object-counts
Namespace: quota-example
Resource Used Hard
-------- ---- ----
persistentvolumeclaims 0 2
services.loadbalancers 0 2
services.nodeports 0 0
ユーザーがアプリケーションを作成するために必要なリソースが各リソースで指定された数以上ある場合、割当システムは作成できません.
計算リソース割当のネーミングスペースへの適用
ネーミングスペースで消費できる計算リソースの量を制限し、割当追跡計算リソースを作成します.
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-compute-resources.yaml --namespace=quota-example
resourcequota "compute-resources" created
割り当てを観察し、現在のネーミングスペースで消費されているものを見てみましょう.
$ kubectl describe quota compute-resources --namespace=quota-example
Name: compute-resources
Namespace: quota-example
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
割り当てシステムでは、ネーミングスペースに4つ以上の非端末podが許可されていません.さらにpodの各コンテナにcpuとメモリのrequestとlimitを定義するように強制します.
デフォルトのリソースリクエストと制限の適用
Podの開始者は、podにリソースリクエストと制限を指定することはめったにありません.
プロジェクトに割り当てを行ったので、エンドユーザーがcpuとメモリ制限のないpodを作成したときに何が起こったのかを見てみましょう.このpodにはnginxコンテナが含まれています.
このプレゼンテーションでは、nginxを実行するdeploymentを作成します.
$ kubectl run nginx --image=nginx --replicas=1 --namespace=quota-example
deployment "nginx" created
作成したpodを見てみましょう.
$ kubectl get pods --namespace=quota-example
podが作成されていないことがわかります!deploymentで何が起こったか見てみましょう.
$ kubectl describe deployment nginx --namespace=quota-example
Name: nginx
Namespace: quota-example
CreationTimestamp: Mon, 06 Jun 2016 16:11:37 -0400
Labels: run=nginx
Selector: run=nginx
Replicas: 0 updated | 1 total | 0 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets:
NewReplicaSet: nginx-3137573019 (0/1 replicas created)
...
deploymentは対応するコピーを作成し、podを作成しようとします.
replica setを見て、多くの詳細を取得します.
$ kubectl describe rs nginx-3137573019 --namespace=quota-example
Name: nginx-3137573019
Namespace: quota-example
Image(s): nginx
Selector: pod-template-hash=3137573019,run=nginx
Labels: pod-template-hash=3137573019
run=nginx
Replicas: 0 current / 1 desired
Pods Status: 0 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
4m 7s 11 {replicaset-controller } Warning FailedCreate Error creating: pods "nginx-3137573019-" is forbidden: Failed quota: compute-resources: must specify limits.cpu,limits.memory,requests.cpu,requests.memory
Kubernetes APIサービスはreplica set要求を拒否しました.私たちのpodはrequestsまたはlimitsのcpuとメモリを指定していないためです.
podが消費できるcpuとメモリリソースのデフォルト値を指定できます.
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-limits.yaml --namespace=quota-example
limitrange "limits" created
$ kubectl describe limits limits --namespace=quota-example
Name: limits
Namespace: quota-example
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container memory - - 256Mi 512Mi -
Container cpu - - 100m 200m -
Kubernetes APIサービスがネーミングスペースでpodを作成する要求を観察し、podのコンテナに計算リソース要求が設定されていない場合、デフォルトのリソースrequestおよびlimitが制御の一部として適用されます.
この例では、作成された各podには、次のような計算リソースが含まれます.
$ kubectl run nginx \
--image=nginx \
--replicas=1 \
--requests=cpu=100m,memory=256Mi \
--limits=cpu=200m,memory=512Mi \
--namespace=quota-example
ネーミングスペースにデフォルトのコンピューティングリソースを適用し、replica setでpodを作成できます.
$ kubectl get pods --namespace=quota-example
NAME READY STATUS RESTARTS AGE
nginx-3137573019-fvrig 1/1 Running 0 6m
ネーミングスペースのクォータを印刷して使用する場合:
$ kubectl describe quota --namespace=quota-example
Name: compute-resources
Namespace: quota-example
Resource Used Hard
-------- ---- ----
limits.cpu 200m 2
limits.memory 512Mi 2Gi
pods 1 4
requests.cpu 100m 1
requests.memory 256Mi 1Gi
Name: object-counts
Namespace: quota-example
Resource Used Hard
-------- ---- ----
persistentvolumeclaims 0 2
services.loadbalancers 0 2
services.nodeports 0 0
作成したpodはコンピューティングリソースを消費しており、Kubernetesは使用状況を明確に追跡することができます.
プレミアム割当範囲
ネーミングスペースでデフォルトの消費リソースを指定したくないと仮定します.逆に、ユーザーに特定の数のBestEffort podをネーミングスペースで実行させ、分散したコンピューティングリソースを利用して、より高いサービス品質が必要なpodに対して明確なリソース要求を行うように要求したいと考えています.
ネーミングスペースを作成し、この動作を実証するために2つの割当を提供します.
$ kubectl create namespace quota-scopes
namespace "quota-scopes" created
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-best-effort.yaml --namespace=quota-scopes
resourcequota "best-effort" created
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-not-best-effort.yaml --namespace=quota-scopes
resourcequota "not-best-effort" created
$ kubectl describe quota --namespace=quota-scopes
Name: best-effort
Namespace: quota-scopes
Scopes: BestEffort
* Matches all pods that have best effort quality of service.
Resource Used Hard
-------- ---- ----
pods 0 10
Name: not-best-effort
Namespace: quota-scopes
Scopes: NotBestEffort
* Matches all pods that do not have best effort quality of service.
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
このシナリオでは、podは、計算リソース要求が「best-effort」割当によって追跡されるように設定されていない.
2つのdeploymentsを作成して説明します.
$ kubectl run best-effort-nginx --image=nginx --replicas=8 --namespace=quota-scopes
deployment "best-effort-nginx" created
$ kubectl run not-best-effort-nginx \
--image=nginx \
--replicas=2 \
--requests=cpu=100m,memory=256Mi \
--limits=cpu=200m,memory=512Mi \
--namespace=quota-scopes
deployment "not-best-effort-nginx" created
デフォルトの制限が指定されていない場合でも、best-effort-nginxは8つのpodをすべて作成します.これは、best-effort構成を追跡し、not-best-effort構成は無視するためです.not-best-effort構成は、Burstableサービス品質を持つpodを作成したため、not-best-effort-nginx deploymentを追跡します.
ネーミングスペースのpodリストを見てみましょう.
$ kubectl get pods --namespace=quota-scopes
NAME READY STATUS RESTARTS AGE
best-effort-nginx-3488455095-2qb41 1/1 Running 0 51s
best-effort-nginx-3488455095-3go7n 1/1 Running 0 51s
best-effort-nginx-3488455095-9o2xg 1/1 Running 0 51s
best-effort-nginx-3488455095-eyg40 1/1 Running 0 51s
best-effort-nginx-3488455095-gcs3v 1/1 Running 0 51s
best-effort-nginx-3488455095-rq8p1 1/1 Running 0 51s
best-effort-nginx-3488455095-udhhd 1/1 Running 0 51s
best-effort-nginx-3488455095-zmk12 1/1 Running 0 51s
not-best-effort-nginx-2204666826-7sl61 1/1 Running 0 23s
not-best-effort-nginx-2204666826-ke746 1/1 Running 0 23s
10個のpodが作成されていることがわかります.
現在のネーミングスペース割当の使用状況を見てみましょう.
$ kubectl describe quota --namespace=quota-scopes
Name: best-effort
Namespace: quota-scopes
Scopes: BestEffort
* Matches all pods that have best effort quality of service.
Resource Used Hard
-------- ---- ----
pods 8 10
Name: not-best-effort
Namespace: quota-scopes
Scopes: NotBestEffort
* Matches all pods that do not have best effort quality of service.
Resource Used Hard
-------- ---- ----
limits.cpu 400m 2
limits.memory 1Gi 2Gi
pods 2 4
requests.cpu 200m 1
requests.memory 512Mi 1Gi
best-effort割当追跡はbest-effort-nginx deploymentの8つのpodの使用を作成し、not-best-effort構成は私たちが割当に作成したnot-best-effort-nginxの使用状況を追跡することがわかります.
scopeは、管理者のリソース消費の導入と追跡の柔軟性を向上させるために、割当説明を追跡するメカニズムを提供します.
BestEffortとNotBestEffortの範囲を除いて、長時間運転と時間制限のpodを制限する範囲があります.Terminatingの範囲はspec.activeDeadlineSecondsがnilでないpodと一致します.NotTerminatingの範囲はspec.activeDeadlineSecondsがnilの任意のpodに一致します.これらの範囲を使用すると、クラスタ内のノード上の予想される実行サイクルに基づいてpodを制限できます.
まとめ
ノードcpuとメモリリソースを消費するアクションは、ネーミングスペース定義の割当によって制限される場合があります.
これらのリソースを消費するアクションを調整したり、デフォルトのネーミングスペースレベルのデフォルト値を選択して最終的なニーズを満たすことができます.
割り当ては、サービス品質とクラスタノードで予想される持続性に基づいて割り当てることができる.