基本的な紹介日常業務では、すべての空港に航空機の着陸場所や駐機場所を管理するためのディスパッチルームがあります。 Kubernetes にも同様のスケジューラがあり、その主な機能は Pod を適切なノードにスケジュールすることです。 Kubernetes のスケジューラは kube-scheduler であり、ワークフローは次のとおりです。 クラスター内のすべてのノードの中で、スケジューリング アルゴリズムに従って Pod を実行できるすべてのノードを選択します。 前のステップに基づいて、選択されたノードはスケジューリング アルゴリズムに従ってスコア付けされ、最も高いスコアを持つノードがスケジューリング用に選択されます。 ポッドの spec.nodeName に、スケジュール結果のノード名を入力します。 概略図は以下のとおりです。 上の図からわかるように、Kubernetes のスケジューラの中核は 2 つの独立した制御ループです。 1. インフォーマー パス: 主な機能は、Etcd 内の Pod、Node、Service などのスケジューラ関連の API オブジェクトの変更を監視するためにインフォーマーを起動することです。 Pod が作成されると、Informer Handler を通じてスケジュール キューに配置されます。デフォルトでは、Kubernetes のスケジューリング戦略は優先キューであり、クラスター情報が変更されると、スケジューラはスケジューリング キューの内容に対していくつかの特別な操作も実行します。さらに、Kubernetes のデフォルトのスケジューラは、スケジューリング アルゴリズムの実行効率を向上させるために、スケジューラ キャッシュを更新する役割も担っています。 2. Scheduler Parh の主なロジックは、キューから Pod を継続的に選択し、フィルタリングのために Predicate を呼び出して、ノードのセット (つまり、スケジューラ キャッシュから取得される、Pod を実行できるすべてのノード情報) を取得することです。次に、Priorities を呼び出してフィルタリングされたノードにスコアを付け、スコアが最も高いノードがこのスケジュールに選択されます。スケジューリングが完了したら、スケジューラは Pod の spec.nodeName の値をスケジュールされたノードの名前に変更する必要があります。このステップはバインドと呼ばれます。 ただし、バインド フェーズでは、Kubernetes のデフォルトのスケジューラはスケジューラ キャッシュ内の情報のみを更新します。楽観的な仮定に基づくこの API オブジェクト更新メソッドは、Assume と呼ばれます。 Assume 後、スケジューラは API サーバーにリクエストを送信して Pod を更新し、バインド操作を実際に完了させます。今回バインドが失敗した場合は、スケジューラ キャッシュが更新された後、正常に戻ります。 Assume により、Pod がスケジュールを完了し、ノード上で実行する必要がある場合、kubelet は Admit 操作を実行して、Pod がノード上で実行できるかどうかを確認します。これは、kubelet の二次検証として機能します。 一般的な予算編成戦略には次のようなものがあります。
ホスト名、PodFitsHostPort、MatchNodeSelector、PodFitsResources
優先権と先取権のメカニズム通常、Pod のスケジュールに失敗した場合、Pod が更新されるかクラスターのステータスが変化するまで Pod は保留され、スケジューラによって Pod が再スケジュールされます。ただし、スケジュールが失敗したときに、優先度の高い Pod を棚上げにしたくない場合があります。代わりに、特定のノード上のいくつかの低優先度のポッドを削除して、高優先度のポッドが正常にスケジュールされるようにします。 Kubernetes の優先度は、ProrityClass によって次のように定義されます。 apiバージョン:スケジューリング.k8s .io / v1 値は優先度の値です。値が大きいほど優先度が高くなります。優先度は 32 ビットの整数で、最大値は 10 億以下です。 10 億を超える値は、システム Pod がプリエンプトされないようにするために、Kubernetes によってシステム Pod が使用するために予約されています。また、globalDefault の値が true に設定されている場合、この PriorityClass の値がシステムのデフォルト値になることを意味します。 false の場合、この PriorityClass を宣言する Pod のみがこの優先度を持ち、宣言されていない他の Pod の優先度は 0 になります。 次のようにポッドを定義し、優先順位を定義します。 APIバージョン: v1 上記の PriorityClassName は PriorityClass を定義します。この Pod が Kubernetes に送信されると、Kubernetes の PriorityAdmissionController は、この Pod の spec.priority フィールドを定義した値に自動的に設定します。このポッドにこの優先度が設定されている場合、優先度の高いポッドは優先度の低いポッドよりも先にキューから削除され、スケジュールができるだけ早く完了します。 優先度の高いポッドのスケジュールに失敗した場合、そのプリエンプション メカニズムがトリガーされます。このとき、スケジューラは現在のクラスター内でノードを見つけて、このノード上の 1 つ以上の低優先度 Pod を削除し、高優先度 Pod をこのノードにスケジュールできるようにします。プリエンプションが発生した場合、優先度の高いポッドはプリエンプトされるノードにすぐにはスケジュールされません。スケジューラは、Pod の spec.nominatedNodeName の値を、プリエンプトされたノードのノード名に設定するだけです。その後、ポッドは次のスケジューリング サイクルに再び入り、このサイクル内でポッドがどのノードにスケジュールされるかを決定します。この再スケジュール期間中に、より優先度の高い Pod もこのノードをプリエンプトしたい場合、スケジューラは元の Pod の nominatedNodeName の値をクリアし、より優先度の高い Pod がこの値をプリエンプトします。 実装原則: Kubernetes は、プリエンプション アルゴリズムを実装するために、ActiveQ と unschedulableQ の 2 つのキューを使用します。
Pod のスケジュールに失敗した場合、スケジューラはそれを unschedulableQ に設定します。次に、スケジューラはスケジューリング失敗の原因をチェックし、プリエンプションを使用してスケジューリングの問題を解決できるかどうかを分析して確認します。プリエンプションが可能であると判断された場合、スケジューラはキャッシュされているすべての情報を再コピーし、このコピーを使用してプリエンプション プロセスをシミュレートします。シミュレーションが成功すると、スケジューラは実際に操作のプリエンプトを開始します。
次に、スケジューラは通常のスケジューリング プロセスを実行し、プリエンプターを正常にスケジュールします。このプロセス中、スケジューラはこのノードで述語アルゴリズムを 2 回実行します。
上記の両方が合格した場合にのみ、ノードとポッドがバインドされます。 高度なスケジュール上記は Kubernetes のデフォルトのスケジューリング戦略です。特定のノードにポッドをスケジュールしたり、特定のノードがポッドをスケジュールできないようにするなど、デフォルトのスケジューリング戦略ではニーズを満たせない場合があります。現時点では、主に次のような、より高度なスケジューリング戦略が必要です。
ノードセレクタNodeSelector はノード セレクターとも呼ばれます。その原理は、ノード上でラベル タグを定義し、ポッド内でこれらのラベルを指定して選択し、ポッドを指定されたノードにスケジュールできるようにすることです。 たとえば、kk-node01 の env=uat ラベルを指定するには、コマンドは次のようになります。 $ kubectl ラベルノード kk - node01 env = uat 次に、Pod の YAML マニフェストで nodeSelector を次のように構成します。 APIバージョン: v1 このようにして、Pod は kk-node01 ノードにスケジュールされます。 Pod が env=prod として指定されている場合、kk-node01 ノードにはスケジュールされません。 ノード名nodeName もノード セレクターです。 nodeSelector との違いは、nodeName がノード名を直接指定し、強調することです。定義は次のとおりです。 APIバージョン: v1 ノードアフィニティnodeAffinity はノード アフィニティ スケジューリングと呼ばれ、nodeSelector や nodeName よりも強力です。 現在、nodeAffinity は次の 2 つのスケジューリング戦略をサポートしています。
preferredDuringSchedulingIgnoredDuringExecution は、一致するノードがある場合、最初にそのノードにスケジュールされることを意味します。そうでない場合は、構成に応じて他のノードにスケジュールできます。 requiredDuringSchedulingIgnoredDuringExecution は、条件を満たすノードをスケジュールできることを意味します。 preferredDuringSchedulingIgnoredDuringExecution を定義する例は次のとおりです。 APIバージョン: v1 requiredDuringSchedulingIgnoredDuringExecution の例は次のとおりです。 APIバージョン: v1 このうち、演算子は In、NotIn、Exists、DoesNotExist をサポートします。 Gt、およびLt。 ポッドアフィニティ上記の nodeSelector、nodeName、および nodeAffinity はすべてノード用ですが、下記の podAffinity および podAntiAffinity は Pod 用です。 podAffinity は Pod アフィニティ スケジューリングを示します。これは、次のように、Pod をそれに近い Pod にスケジュールすることを意味します。 APIバージョン: v1 これは、バックエンド ポッドとフロントエンド ポッドを一緒にスケジュールすることを意味します。 podAffinity には、ハード アフィニティとソフト アフィニティである preferredDuringSchedulingIgnoredDuringExecution と requiredDuringSchedulingIgnoredDuringExecution もあります。使用方法は nodeAffinity と同じです。 ポッドアンチアフィニティポッドの親和性については上記で紹介しました。ここで紹介する podAntiAffinity はポッドのアンチアフィニティであり、このようなポッドは一緒にスケジュールされないことを意味します。日常業務では、このような親和性は頻繁に使用されます。マイクロサービスには単一の Pod が存在することはほとんどなく、基本的に複数の Pod が存在します。アプリケーションの高可用性を向上させるために、同じアプリケーションの複数の Pod が同じマシンにスケジュールされることはありません。このとき、podAntiAffinity は次のように使用されます。 apiバージョン:アプリ/ v1 汚染スケジュールKubernetes では、マスター ノードなどの一部のノードに組み込みの taint があります。このようなノードでは、ポッドがテイントを許容するように構成されていない場合、これらのポッドはそのようなノードにスケジュールされません。 実際には、汚染スケジュールも非常に役立ちます。シナリオによっては、特定のノードが特定のプロジェクト グループのポッドのみを許可します。たとえば、ビッグデータ プロジェクトは、他の通常のプロジェクトと混在させたくない高 IO プロジェクトです。しかし、ラベルセレクターを使用して他のプロジェクトを設定およびデプロイするのは面倒です。この場合、汚染セレクターを使用できます。 テイントに関連する構成情報は、kubectl explain node.spec.taints を通じて表示できます。 $ kubectl ノード.spec .taintsを説明します 効果はポッドに対する除外効果を定義します。
ノードに汚染を追加する場合は、次のようにします。 $ kubectl taint ノード kk - node01 ノードタイプ= dev : NoSchedule キー名が node-type、キー値が dev、効果が NoSchedule であるノード kk-node01 にテイントを追加します。つまり、この汚染に一致する許容値を持つ Pod のみがノード kk-node01 に割り当てられます。 汚染を削除する場合は、次のコマンドを使用します。 $ kubectl taint ノード kk - node01 ノード-タイプ= dev : NoSchedule - 許容汚染を設定する場合は、次のようにします。 apiバージョン:アプリ/ v1 演算子は Equal と Exists をサポートし、デフォルトは Equal です。 等しい場合は、汚染のキー値が一貫している必要があることを意味します。 Exists が使用されている場合、キーの汚染が存在する限り、次のようになります。 許容範囲: この構成は、許容値が一致し、key1 のキーが存在する限り、スケジューリングを実行できることを意味します。 許容値のキーが空で、演算子が Exists である場合、この許容値は任意のキー、値、および効果と一致することを意味します。つまり、この許容値は任意の汚れを許容できます。効果が空の場合、キー名が key1 のすべての効果が一致します。 ノードに複数のテイントを追加したり、ポッドに複数の許容設定を追加したりできます。 Kubernetes は、複数の taint と toleration をフィルターのように処理します。つまり、ノード上のすべての taint から開始し、Pod 内で一致する toleration を持つ taint を除外します。残りのフィルタリングされていないテイントの効果値によって、特に次の状況で、ポッドがノードに割り当てられるかどうかが決まります。
例えば、ノードに次の汚染を追加するとします。 $ kubectl taint ノード node1 key1 = value1 : NoSchedule 2 つの許容値を持つ Pod があると仮定します。 許容範囲: この場合、3 番目の汚染に一致する許容範囲がないため、ポッドはノード上でスケジュールされません。ただし、上記のテイントがノードに追加される前に Pod がすでにノード上で実行されている場合、3 番目のテイントは、この Pod が許容できない 3 つのテイントのうちの 1 つだけであるため、ノード上で引き続き実行できます。 通常、効果値が NoExecute の汚染がノードに追加されると、この汚染を許容できない Pod は直ちに排除され、この汚染を許容できる Pod は排除されません。ただし、Pod の効果値が NoExecute で、オプション属性 toleranceSeconds の値を指定する許容値がある場合、上記の汚染がノードに追加された後、Pod がノード上で実行を継続できる期間を示します。例えば: 許容範囲: つまり、このポッドが実行中で、それが存在するノードに一致するテイントが追加された場合、ポッドは削除されるまで 3600 秒間ノード上で実行され続けます。それまでに上記の汚染が除去された場合、ポッドは排除されません。 スケジュール変更Kubernetes では、kube-scheduler が適切なノードにポッドをスケジュールする役割を担います。ただし、Kubernetes は非常に動的で弾力性の高い環境であるため、1 つ以上のノードで Pod が不均等に分散されることがあります。例えば:
上記の理由により、複数のポッドが理想的とは言えないノードで実行される可能性があり、K8S クラスター全体が一定期間、不均衡な状態になります。この時点で、クラスターを再バランスする必要があります。 Descheduler はそのようなプロジェクトです。 Descheduler は、いくつかのルール構成に従ってクラスターのステータスを再調整できます。現在サポートされている戦略は次のとおりです。
これらのポリシーは有効または無効にすることができ、デフォルトではすべてのポリシーが有効になっています。 さらに、次のような一般的な構成がいくつかあります。
クラスターのバージョンは 1.24.2 なので、descheduler v0.24 をインストールしました。 (1)対応するHelmチャートをダウンロードします。バージョン0.24を選択しました。 $ wget https://github.com/kubernetes-sigs/descheduler/releases/download/descheduler-helm-chart-0.24.0/descheduler-0.24.0.tgz (2)科学的にインターネットにアクセスできる場合は、以下のコマンドを直接使用して展開することができます。 descheduler をインストールします。 科学的にインターネットにアクセスできない場合は、イメージを置き換え、value.yaml のイメージ情報を次のように変更します。 画像: 次にインストールコマンドを実行します。 インストールが完了すると、デフォルトのスケジュール戦略は次のように構成されます。 APIバージョン: v1 構成:
定期的にスケジュールのバランスをとるための CronJob も作成されます。 apiバージョン:バッチ/ v1 ジョブは 2 分ごとにバランスの取れたスケジュールを実行します。 要約するKubernetes のスケジューリング戦略は非常に複雑で、多くの複雑なアルゴリズムが含まれています。ここでは、日常的な使用には十分な、一般的に使用されるスケジュール戦略のみを紹介します。さらに詳しく勉強したい場合は、公式ドキュメントやソースコードを読んでみてください。 |
<<: Kubernetesをマルチクラウドやハイブリッドクラウド環境に適用する場合は、次の点に注意してください。
私は greengeeks をお勧めします。これは、古いアメリカのブランドで、無制限のスペース、無制...
ウェブページの最適化のためのキーワードを選択する際に、Baidu Index、Google ウェブマ...
以前、著者のXiaodanの近くでインターネットマーケティングサミットがありました。そのサミットで、...
長い間、外部リンクの構築について体系的に説明してきませんでしたが、今日は時間を有効に活用して、外部リ...
Hostxnowは2009年に運営を開始したホスティング会社です(登録番号:GB 210 1553 ...
ウェブサイトの最適化に関するヒントといえば、多くのウェブマスターが「ロングテール キーワード」という...
2006 年に設立されたパキスタンのサーバー販売業者である nexus.pk は、ドメイン名登録、仮...
11月25日、Sangfor傘下のクラウドコンピューティングブランドであるSangfor Cloud...
ライブストリーミングeコマースは急速に後半に突入しています。今年6月18日、トップキャスターがひっそ...
外部リンクは Baidu によって絶えず攻撃されているため、今日のウェブマスターは外部リンクの構築に...
双方に利益のある協力。この言葉があらゆる分野に当てはまるのは当然のことですが、SEO 業界でも同じこ...
inceptionhosting は評判が良く、VPS の品質が保証されているサービス プロバイダー...
Hostcramは、米国中部のダラスデータセンターでVPS事業を専門に展開しています。現在、i9-1...
Hostus の最新の公式イベント: すべての KVM 仮想 VPS が 20% オフ。Hostus...
オペレーターが完全なアクティビティ プランを計画する場合、アクティビティ設計、リソース統合、通信パス...