kubeletはsystem、kubeリソースを予約する
6439 ワード
kubeletはsystem、kubeリソースを予約する
KubernetesのノードはCapacityに従ってスケジューリングできます.デフォルトではpodはノードのすべての使用可能な容量を使用できます.これは、ノード自身が通常、OSとKubernetesを駆動するシステムデーモンプロセス(system daemons)を多く実行しているため、問題です.これらのシステム・デーモン・プロセスにリソースを残さない限り、podとリソースを争い、ノードのリソース不足の問題を引き起こします.
kubeletは、Node Allocatableという特性を開示し、システム・デーモンのコンピューティング・リソースを予約するのに役立ちます.Kubernetesは、クラスタ管理者がノード上のワークロード密度ごとにNode Allocatableを構成することを推奨します.
Node Allocatable
Kubernetesノード上のAllocatableはpodが利用可能な計算リソース量として定義される.スケジューラはAllocatableを超過申請しません.現在、CPU、memory、storageのパラメータがサポートされています.
Node AllocatableはAPIにv 1として露出する.ノードオブジェクトの一部であり、CLIにおけるkubectl describe nodeの一部でもある.
クbeletでは、2つのシステムデーモンプロセスにリソースを予約できます.
QoSとPodレベルのcgroupsを有効にする
ノード範囲でnode allocatableを適切に実装するには、--cgroups-per-qosフラグを使用して新しいcgroup階層を有効にする必要があります.このフラグはデフォルトで有効です.有効にすると、kubeletは管理するcgroup階層にすべてのターミナルユーザーのpodを作成します.
cgroupドライバの構成
kubeletは、ホスト上でcgroupドライバを使用してcgroup階層を操作することをサポートします.ドライバは--cgroup-driverフラグで構成されています.
サポートされるパラメータの値は次のとおりです. cgroupfsはデフォルトのドライバであり、ホスト上でcgroupファイルシステムを直接操作してcgroup砂箱を管理します. systemdはオプションの駆動であり、initシステムがサポートするリソースの瞬時スライスを使用してcgroup砂箱を管理する.
関連コンテナの実行時(container runtime)の構成に応じて、オペレータはシステムの正常な動作を保証するために特定のcgroupドライバを選択する必要がある場合があります.たとえば、オペレータがdocker実行時に提供されるcgroupドライバを使用する場合は、kubeletがsystemd cgroupドライバを使用するように構成する必要があります.
Kube Reserved Kubelet Flag: --kube-reserved=[cpu=100m][,][memory=100Mi][,][storage=1Gi] Kubelet Flag: --kube-reserved-cgroup=
kube-reservedは、kubelet、container runtime、node problem detectorなどのkubernetesシステムのデーモンプロセスにリソースの予約を獲得するためである.これはpod形式で実行されるシステム・デーモン・プロセスにリソースを保持するわけではありません.kube−reservedは、通常、ノード上のpod密度(pod density)機能である.この性能ダッシュボードはpod密度の複数の面からkubeletとdocker engineのcpuとmemoryの使用状況を示した.
システム・デーモン上でkube-reservedを選択的に実行するには、kubeletの--kube-reserved-cgroupフラグの値をkubeデーモンの親制御グループに設定する必要があります.
kubernetesシステム・デーモン・プロセスを、システム・マシン上のruntime.sliceなどのトップ・レベルの制御グループの下に配置することを推奨します.理想的には、各システム・デーモン・プロセスは、独自のサブ制御グループで実行される必要があります.このドキュメントを参照して、推奨制御グループの階層の詳細を参照してください.
--kube-reserved-cgroupが存在しない場合、Kubeletは作成されません.無効なcgroupを指定した場合、Kubeletは失敗します.
システム予約値(System Reserved) Kubelet Flag: --system-reserved=[cpu=100mi][,][memory=100Mi][,][storage=1Gi] Kubelet Flag: --system-reserved-cgroup=
System−reservedは、sshd、udevなどのシステムガードプロセスのためにリソース予約を獲得するために使用される.System-reservedもkernelのためにメモリを予約しなければならない.現在kernelが使用しているメモリはKubernetesのpodに記録されていないからだ.また、ユーザーログインセッションのリソース(systemdシステムのuser.slice)を予約することも推奨されます.
システム・デーモンでシステム・デーモンをオプションで実行するには、システム・デーモンの親制御グループであるシステム・デーモンの値を指定します.
OSシステム・デーモン・プロセスは、systemdマシン上のsystem.sliceなどのトップ・レベルの制御グループの下に配置することを推奨します.
--system-reserved-cgroupが存在しない場合、Kubeletは作成しません.無効なcgroupが指定されている場合、Kubeletは失敗します.
駆逐しきい値(Eviction Thresholds) Kubelet Flag: --eviction-hard=[memory.available<500Mi]
ノードレベルのメモリ圧力は、システムのメモリ不足(System OOMs)を引き起こし、ノード全体とその上で実行されるすべてのpodに影響します.ノードは、メモリが回収されるまで一時的にオフラインにすることができます.システムのメモリ不足を防止(または減少)するために、kubeletはリソース不足(Out of Resource)管理を提供します.駆逐(Eveiction)操作はmemoryとstorageのみをサポートします.--eviction-hardフラグでメモリを予約すると、ノード上の使用可能なメモリが保存値以下に下がると、kubeletはpodを駆逐しようとします.ノードにシステム・デーモン・プロセスが存在しない場合、podはcapacity-eviction-hardを超えるリソースを使用できないと仮定します.したがって,駆逐のために予約された資源はpodには利用できない.
実行ノードAllocatable Kubelet Flag: --enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]
スケジューラはAllocatableをpodの利用可能なcapacityで扱います.
kubeletはpodでAllocatableをデフォルトで実行します.いつでも、すべてのpodの総使用量がAllocatableを超えた場合、podを駆逐する措置が実行されます.駆逐戦略の詳細はここで見つけることができます.kubelet--enforce-node-allocatableフラグ値をpods制御に設定してください.
オプションとして、同じフラグにkube-reservedとsystem-reservedの値を同時に指定することにより、kubeletはkube-reservedとsystem-reservedを実行することができる.kube-reservedまたはsystem-reservedを実行するには、--kube-reserved-cgroupまたは--system-reserved-cgroupをそれぞれ指定する必要があります.
一般原則
システムデーモンプロセスはGuaranteed podのように扱われることが望ましい.システム・デーモン・プロセスは、その範囲制御グループで爆発的に増加し、この動作をkubernetesの導入の一部として管理する必要があります.たとえば、kubeletは独自の制御グループを持ち、コンテナ実行時(container runtime)とKube-reservedリソースを共有する必要があります.しかしながら、kube-reservedが実行されると、kubeletはノードの使用可能なすべてのリソースを突然爆発させ、消費することはできない.
System-reserved予約操作を実行するときは、ノード上のキーシステムサービスCPUリソースが不足したり、メモリ不足(OOM)によって終了したりする可能性があるので、注意してください. pods上でAllocatableを開始として実行します. システム・デーモン・プロセスの監視およびアラートを追跡するのに十分なメカニズムが確立されたら、kube-reservedを用量探索(usage heuristics)方式に基づいて実行してみてください. 時間が経つにつれて、絶対必要であればsystem-reservedを実行することができる.
時間の増加とますます多くの特性の加入に伴い、kubeシステムのデーモンプロセスのリソースに対する需要も増加する可能性があります.今後、kubernetesプロジェクトはノードシステムのデーモンプロセスの利用を減らすことを試みますが、現在は優先事項ではありません.そのため、将来のリリースでAllocatableの容量が低下することを期待してください.
サンプルシーン
ノードAllocatableの計算方法を説明する例です.ノードは32 Giメモリ、16コアCPU、100 Giメモリ を有する.--kube-reservedはcpu=1、memory=2 Gi、storage=1 Gi に設定されています.--system-reservedはcpu=500 m、memory=1 Gi、storage=1 Gi に設定--eviction-hardはmemoryに設定されています.available<500Mi,nodefs.available<10%
このシナリオでは、Allocatableは14.5 CPU s、28.5 Giメモリ、98 Giストレージになります.スケジューラは、このノード上のすべてのpodリクエストのメモリ総量が28.5 Giを超えず、88 Giを超えないことを保証します.podのメモリ使用量が28.5 Giを超える場合、またはディスク使用量が88 Giを超える場合、Kubeletはそれらを駆逐します.ノード上のすべてのプロセスがCPUをできるだけ多く使用する場合、podを合わせると14.5 CPUを超えるリソースは使用できません.
kube-reservedおよび/またはsystem-reservedが実行されず、システムデーモンの使用量がその予約を超えた場合、ノードメモリの使用量が31.5 Gi以上、または90 Gi以上のストレージがある場合、kubeletはpodを駆逐する.
使用可能なプロパティ
Kubernetes 1.2リリースまでは、kube-reservedとsystem-reservedの予約をオプションで指定できます.同じパブリケーションで使用可能な場合、スケジューラはCapacityの代わりにAllocatableを使用するようになります.
Kubernetes 1.6リリースまで、eviction-thresholdsはAllocatableを計算することによって考慮されています.古いバージョンの動作を使用するには、--experimental-allocatable-ignore-eviction kubeletフラグをtrueに設定します.
Kubernetes 1.6リリースまで、kubeletはコントロールグループを使用してpod上でAllocatableを実行します.古いバージョンの動作を使用するには、--enforce-node-allocatable kubeletフラグの設定を解除します.Allocatableの実装は、--kube-reservedまたは--system-reservedまたは--eviction-hardフラグにデフォルトパラメータがない限り、既存のdeploymentには影響しません.
Kubernetes 1.6リリースまで、kubeletはpod独自のcgroup砂箱で起動し、このcgroup砂箱はkubeletが管理するcgroup階層の独占部分にある.前のバージョンからkubeletをアップグレードする前に、podとその関連するコンテナがcgroup階層の適切な部分で起動することを保証するために、オペレータdrainノードが必要です.
KubernetesのノードはCapacityに従ってスケジューリングできます.デフォルトではpodはノードのすべての使用可能な容量を使用できます.これは、ノード自身が通常、OSとKubernetesを駆動するシステムデーモンプロセス(system daemons)を多く実行しているため、問題です.これらのシステム・デーモン・プロセスにリソースを残さない限り、podとリソースを争い、ノードのリソース不足の問題を引き起こします.
kubeletは、Node Allocatableという特性を開示し、システム・デーモンのコンピューティング・リソースを予約するのに役立ちます.Kubernetesは、クラスタ管理者がノード上のワークロード密度ごとにNode Allocatableを構成することを推奨します.
Node Allocatable
Node Capacity
---------------------------
| kube-reserved |
|-------------------------|
| system-reserved |
|-------------------------|
| eviction-threshold |
|-------------------------|
| |
| allocatable |
| (available for pods) |
| |
| |
---------------------------Kubernetesノード上のAllocatableはpodが利用可能な計算リソース量として定義される.スケジューラはAllocatableを超過申請しません.現在、CPU、memory、storageのパラメータがサポートされています.
Node AllocatableはAPIにv 1として露出する.ノードオブジェクトの一部であり、CLIにおけるkubectl describe nodeの一部でもある.
クbeletでは、2つのシステムデーモンプロセスにリソースを予約できます.
QoSとPodレベルのcgroupsを有効にする
ノード範囲でnode allocatableを適切に実装するには、--cgroups-per-qosフラグを使用して新しいcgroup階層を有効にする必要があります.このフラグはデフォルトで有効です.有効にすると、kubeletは管理するcgroup階層にすべてのターミナルユーザーのpodを作成します.
cgroupドライバの構成
kubeletは、ホスト上でcgroupドライバを使用してcgroup階層を操作することをサポートします.ドライバは--cgroup-driverフラグで構成されています.
サポートされるパラメータの値は次のとおりです.
関連コンテナの実行時(container runtime)の構成に応じて、オペレータはシステムの正常な動作を保証するために特定のcgroupドライバを選択する必要がある場合があります.たとえば、オペレータがdocker実行時に提供されるcgroupドライバを使用する場合は、kubeletがsystemd cgroupドライバを使用するように構成する必要があります.
Kube Reserved
kube-reservedは、kubelet、container runtime、node problem detectorなどのkubernetesシステムのデーモンプロセスにリソースの予約を獲得するためである.これはpod形式で実行されるシステム・デーモン・プロセスにリソースを保持するわけではありません.kube−reservedは、通常、ノード上のpod密度(pod density)機能である.この性能ダッシュボードはpod密度の複数の面からkubeletとdocker engineのcpuとmemoryの使用状況を示した.
システム・デーモン上でkube-reservedを選択的に実行するには、kubeletの--kube-reserved-cgroupフラグの値をkubeデーモンの親制御グループに設定する必要があります.
kubernetesシステム・デーモン・プロセスを、システム・マシン上のruntime.sliceなどのトップ・レベルの制御グループの下に配置することを推奨します.理想的には、各システム・デーモン・プロセスは、独自のサブ制御グループで実行される必要があります.このドキュメントを参照して、推奨制御グループの階層の詳細を参照してください.
--kube-reserved-cgroupが存在しない場合、Kubeletは作成されません.無効なcgroupを指定した場合、Kubeletは失敗します.
システム予約値(System Reserved)
System−reservedは、sshd、udevなどのシステムガードプロセスのためにリソース予約を獲得するために使用される.System-reservedもkernelのためにメモリを予約しなければならない.現在kernelが使用しているメモリはKubernetesのpodに記録されていないからだ.また、ユーザーログインセッションのリソース(systemdシステムのuser.slice)を予約することも推奨されます.
システム・デーモンでシステム・デーモンをオプションで実行するには、システム・デーモンの親制御グループであるシステム・デーモンの値を指定します.
OSシステム・デーモン・プロセスは、systemdマシン上のsystem.sliceなどのトップ・レベルの制御グループの下に配置することを推奨します.
--system-reserved-cgroupが存在しない場合、Kubeletは作成しません.無効なcgroupが指定されている場合、Kubeletは失敗します.
駆逐しきい値(Eviction Thresholds)
ノードレベルのメモリ圧力は、システムのメモリ不足(System OOMs)を引き起こし、ノード全体とその上で実行されるすべてのpodに影響します.ノードは、メモリが回収されるまで一時的にオフラインにすることができます.システムのメモリ不足を防止(または減少)するために、kubeletはリソース不足(Out of Resource)管理を提供します.駆逐(Eveiction)操作はmemoryとstorageのみをサポートします.--eviction-hardフラグでメモリを予約すると、ノード上の使用可能なメモリが保存値以下に下がると、kubeletはpodを駆逐しようとします.ノードにシステム・デーモン・プロセスが存在しない場合、podはcapacity-eviction-hardを超えるリソースを使用できないと仮定します.したがって,駆逐のために予約された資源はpodには利用できない.
実行ノードAllocatable
スケジューラはAllocatableをpodの利用可能なcapacityで扱います.
kubeletはpodでAllocatableをデフォルトで実行します.いつでも、すべてのpodの総使用量がAllocatableを超えた場合、podを駆逐する措置が実行されます.駆逐戦略の詳細はここで見つけることができます.kubelet--enforce-node-allocatableフラグ値をpods制御に設定してください.
オプションとして、同じフラグにkube-reservedとsystem-reservedの値を同時に指定することにより、kubeletはkube-reservedとsystem-reservedを実行することができる.kube-reservedまたはsystem-reservedを実行するには、--kube-reserved-cgroupまたは--system-reserved-cgroupをそれぞれ指定する必要があります.
一般原則
システムデーモンプロセスはGuaranteed podのように扱われることが望ましい.システム・デーモン・プロセスは、その範囲制御グループで爆発的に増加し、この動作をkubernetesの導入の一部として管理する必要があります.たとえば、kubeletは独自の制御グループを持ち、コンテナ実行時(container runtime)とKube-reservedリソースを共有する必要があります.しかしながら、kube-reservedが実行されると、kubeletはノードの使用可能なすべてのリソースを突然爆発させ、消費することはできない.
System-reserved予約操作を実行するときは、ノード上のキーシステムサービスCPUリソースが不足したり、メモリ不足(OOM)によって終了したりする可能性があるので、注意してください.
時間の増加とますます多くの特性の加入に伴い、kubeシステムのデーモンプロセスのリソースに対する需要も増加する可能性があります.今後、kubernetesプロジェクトはノードシステムのデーモンプロセスの利用を減らすことを試みますが、現在は優先事項ではありません.そのため、将来のリリースでAllocatableの容量が低下することを期待してください.
サンプルシーン
ノードAllocatableの計算方法を説明する例です.
このシナリオでは、Allocatableは14.5 CPU s、28.5 Giメモリ、98 Giストレージになります.スケジューラは、このノード上のすべてのpodリクエストのメモリ総量が28.5 Giを超えず、88 Giを超えないことを保証します.podのメモリ使用量が28.5 Giを超える場合、またはディスク使用量が88 Giを超える場合、Kubeletはそれらを駆逐します.ノード上のすべてのプロセスがCPUをできるだけ多く使用する場合、podを合わせると14.5 CPUを超えるリソースは使用できません.
kube-reservedおよび/またはsystem-reservedが実行されず、システムデーモンの使用量がその予約を超えた場合、ノードメモリの使用量が31.5 Gi以上、または90 Gi以上のストレージがある場合、kubeletはpodを駆逐する.
使用可能なプロパティ
Kubernetes 1.2リリースまでは、kube-reservedとsystem-reservedの予約をオプションで指定できます.同じパブリケーションで使用可能な場合、スケジューラはCapacityの代わりにAllocatableを使用するようになります.
Kubernetes 1.6リリースまで、eviction-thresholdsはAllocatableを計算することによって考慮されています.古いバージョンの動作を使用するには、--experimental-allocatable-ignore-eviction kubeletフラグをtrueに設定します.
Kubernetes 1.6リリースまで、kubeletはコントロールグループを使用してpod上でAllocatableを実行します.古いバージョンの動作を使用するには、--enforce-node-allocatable kubeletフラグの設定を解除します.Allocatableの実装は、--kube-reservedまたは--system-reservedまたは--eviction-hardフラグにデフォルトパラメータがない限り、既存のdeploymentには影響しません.
Kubernetes 1.6リリースまで、kubeletはpod独自のcgroup砂箱で起動し、このcgroup砂箱はkubeletが管理するcgroup階層の独占部分にある.前のバージョンからkubeletをアップグレードする前に、podとその関連するコンテナがcgroup階層の適切な部分で起動することを保証するために、オペレータdrainノードが必要です.