Kubernetes Schedulerは実際にどのように機能しますか？

ご注意 perev。 ：この記事は、国際的なオンライン決済会社であるStripeのエンジニアであるJulia Evansによって書かれました。 彼女は、「フリーズ」ポッドで定期的に発生するバグによってKubernetesスケジューラの内部を理解するよう促されました。これは、約1か月前にRancher Labsの専門家（ 問題49314 ）によっても報告されました。 この問題は解決され、Kubernetesの基本メカニズムの1つの技術構造に関する詳細を共有することができました。これは、対応するプロジェクトコードからの必要な抜粋とともにこの記事で提示されています。



今週、Kubernetesスケジューラがどのように機能するかの詳細について学びました。これを実際に機能させるためのジャングルに飛び込む準備ができている人と共有したいと思います。

さらに、このケースは、誰かの助けを必要とせずに、「このシステムがどのように設計されているかわからない」状態から「OK、基本的なアーキテクチャソリューションとその原因を理解していると思う」に切り替える方法の明確な説明であったことに注意してください。

この小さな意識の流れが誰かに役立つことを願っています。 このトピックを検討している間、Kubernetesの開発者向けのすばらしい、すばらしい、すばらしいKubernetesのドキュメントの執筆コントローラー ドキュメントは 、私にとって最も役に立ちました。

スケジューラーの目的は何ですか？

Kubernetesスケジューラーは、 ポッドの割り当てを担当します。 彼の作品の本質は次のとおりです。

• 下に作成します。
• スケジューラーは、新しい炉床にノードが割り当てられていないことに気付きます。
• スケジューラーはポッドノードを割り当てます。

彼はポッドの実際の起動について責任を負いません-これはkubeletの仕事です。 彼に基本的に必要なことは、各ポッドにノードが割り当てられていることを確認することだけです。 シンプルでしょ？

Kubernetesはコントローラーのアイデアを使用しています。 コントローラーの操作は次のとおりです。

• システムの状態を見てください。
• 現在の状態が目的の状態に対応していないことに注意してください（たとえば、「この炉床にノードを割り当てる必要があります」）。
• 繰り返します。

スケジューラー-コントローラーのタイプの1つ。 一般に、多くの異なるコントローラーがあり、誰もが異なるタスクを持ち、それらは独立して実行されます。

一般に、スケジューラの作業は次のようなサイクルとして表すことができます。

while True: pods = get_all_pods() for pod in pods: if pod.node == nil: assignNode(pod) 

Kubernetesでスケジューラがどのように機能するかの詳細に興味がない場合は、おそらく記事を読むだけで十分です。 このサイクルには、完全に正しいモデルが含まれています。

だから、私はスケジューラが実際にこのように動作するように思えました、なぜならcronjobコントローラーは同じように動作するからです-コードを読んだ唯一のKubernetesコンポーネントです。 cronjobコントローラーcronjobすべてのcronジョブを処理し、それらのいずれに対しても何も実行する必要がないことを確認し、10秒待機して、このループを無限に繰り返します。 とても簡単です！

しかし、それはそのようには機能しません

しかし、今週、Kubernetesクラスターの負荷が増加し、問題が発生しました。

時々、サブが永続的にPending状態のままになります（ノードがサブに割り当てられていない場合）。 スケジューラーがリブートすると、スケジューラーはこの状態を終了しました（ ここにチケットがあります ）。

この動作は、Kubernetesスケジューラーの動作の内部モデルと一致しませんでした。ノードの割り当てが予想される場合、スケジューラーはこれを検出してノードを割り当てる必要があります。 この場合、スケジューラは再起動しないでください！

コードに目を向ける時が来ました。 そして、ここに私が見つけたものがあります-いつものように、エラーがある可能性があります すべてが非常に複雑で、勉強するのに1週間しかかかりませんでした。

スケジューラーの仕組み：コードの概要

scheduler.goから始めましょう。 （必要なすべてのファイルを結合することはここで利用可能です -内容を簡単にナビゲートするために。）

メインスケジューラサイクル（ e4551d50e5コミット時 ）は次のようになります。

 go wait.Until(sched.scheduleOne, 0, sched.config.StopEverything) 

...つまり、「 sched.scheduleOne 。」 そこで何が起こっていますか？

 func (sched *Scheduler) scheduleOne() { pod := sched.config.NextPod() // do all the scheduler stuff for `pod` } 

OK、 NextPod()は何をしていますか？ 足はどこから成長しますか？

 func (f *ConfigFactory) getNextPod() *v1.Pod { for { pod := cache.Pop(f.podQueue).(*v1.Pod) if f.ResponsibleForPod(pod) { glog.V(4).Infof("About to try and schedule pod %v", pod.Name) return pod } } } 

さて、すべてが非常に簡単です！ 囲炉裏からのキュー（ podQueue ）があり、次の囲炉裏がそこから来ています。

しかし、ポッドはこのラインにどのように組み込まれますか？ 関連するコードは次のとおりです。

 podInformer.Informer().AddEventHandler( cache.FilteringResourceEventHandler{ Handler: cache.ResourceEventHandlerFuncs{ AddFunc: func(obj interface{}) { if err := c.podQueue.Add(obj); err != nil { runtime.HandleError(fmt.Errorf("unable to queue %T: %v", obj, err)) } }, 

つまり、新しいハースが追加されると、それをキューに追加するイベントハンドラがあります。

スケジューラーの仕組み：平易な言葉で

コードを確認したので、次のことを要約できます。

1. 最初は、スケジューラを必要とするすべてのサブがキューに配置されます。
2. 新しいポッドが作成されると、それらもキューに追加されます。
3. プランナーは、常にポッドをキューから取り出し、それらの計画を実行します。
4. 以上です！

ここに興味深い詳細があります：何らかの理由でそれがプランナーに該当しない場合、プランナーは彼のために再試行しません。 潜水艦はキューから削除され、その計画は完了しません。それだけです。 唯一のチャンスは失われます！ （スケジューラーを再起動するまで、この場合、すべてのポッドがキューに再び追加されます。）

もちろん、スケジューラは実際にはよりスマートです。スケジューラにヒットしない場合、一般的な場合、次のようなエラーハンドラが呼び出されます。

 host, err := sched.config.Algorithm.Schedule(pod, sched.config.NodeLister) if err != nil { glog.V(1).Infof("Failed to schedule pod: %v/%v", pod.Namespace, pod.Name) sched.config.Error(pod, err) 

sched.config.Error関数sched.config.Error再びキューに追加されるため、それでも処理が試行されます。

ちょっと待って なぜ私たちの「スタック」の下にあるのですか？

すべてが非常に簡単です。実際にエラーが発生したときに、このError関数が常に呼び出されるとは限らないことがわかりました。 パッチを作成しました（ パッチは同じ号で発行されました - およそTransl。 ）正しく呼び出すために、その後、復元が正しく行われ始めました。 クラス！

スケジューラがなぜこのように設計されているのですか？

より堅牢なアーキテクチャは次のとおりだと思います。

 while True: pods = get_all_pods() for pod in pods: if pod.node == nil: assignNode(pod) 

では、なぜこのアプローチの代わりに、キャッシュ、リクエスト、コールバックに関するこれらの問題をすべて見るのでしょうか？ ストーリーを見ると、主な理由は生産性であるという結論に達します。 例としては、Kubernetes 1.6のスケーラビリティの更新や、Kubernetesスケジューラのパフォーマンスの改善に関するこのCoreOSの出版物があります。 後者は、 2万時間から10分未満まで、3万炉の計画時間の短縮（1千ノード-約Transl。）について述べています 。 2時間は非常に長い時間であり、パフォーマンスが重要です！

新しい囲炉裏を計画するたびにシステムの3万個すべての囲炉裏を調べるのは長すぎることが明らかになったため、本当に複雑なメカニズムを考え出す必要があります。

スケジューラが実際に使用するもの：Kubernetesのインフォーマー

すべてのKubernetesコントローラーのアーキテクチャにとって非常に重要と思われるもう1つのことを言いたいと思います。 これが「情報提供者」の考え方です。 幸いなことに、「kubernetes informer」をグーグル検索するドキュメントがあります。

この非常に便利なドキュメントは、 Writing Controllersと呼ばれ、コントローラーを作成する人（スケジューラーやcronjobコントローラーなど）の設計について説明しています。 とてもクール！

この文書が最初に見つかった場合、何が起こるかについての理解が少し速くなったと思います。

だから、情報提供者！ ドキュメントの内容は次のとおりです。

SharedInformers使用しSharedInformers 。 SharedInformersは、特定のリソースの追加、変更、削除に関する通知を受信するためのフックを提供します。 また、共有キャッシュにアクセスし、キャッシュの適用場所を決定するための便利な機能も提供します。

コントローラーが起動すると、 informerフォーinformer （ pod informerフォーpod informer ）が作成されます。

1. すべての囲炉裏の結論（まず）;
2. 通知を変更します。

cronjobコントローラーは情報提供者を使用しません（それらを操作するとすべてが複雑になりますが、この場合、パフォーマンスの問題はまだないと思います）が、他の多くの（ほとんど？）それを使用します。 特に、スケジューラがこれを行います。 彼の情報提供者の設定はこのコードで見つけることができます 。

再キューイング

同じドキュメント（Writing Controllers）にも、キュー内のアイテムの再配置を処理する方法に関する指示が含まれています。

信頼できる再キューイングを行うには、エラーを上位レベルに上げてください。 合理的なロールバックを使用した単純な実装には、 workqueue.RateLimitingInterfaceがありworkqueue.RateLimitingInterface 。

再キューイングが必要な場合、コントローラーのメイン機能はエラーを返します。 存在しない場合は、 utilruntime.HandleErrorを使用してnilを返します。 これにより、エラー処理のケースの調査が大幅に簡素化され、必要なときにコントローラーが何かを失うことがなくなります。

良いアドバイスのように見えます。すべてのエラーを正しく処理することは困難な場合があるため、コードレビューアがエラーが正しく処理されているかどうかを確認する簡単な方法が重要です。 かっこいい！

情報提供者を「同期」する必要があります（右？）

そして、私の調査中の最後の興味深い詳細。

インフォーマーでは、「同期」（ sync ）の概念が使用されます。 これはプログラムを再起動するようなものです。監視しているすべてのリソースのリストを取得するので、すべてが実際に正しいことを確認できます。 同じガイドが同期について述べていることは次のとおりです。

ウォッチとインフォーマーは「同期」されます。 定期的に、クラスター内の各適切なオブジェクトをUpdateメソッドに配信します。 オブジェクトで追加のアクションを実行する必要がある場合に適していますが、これは常に必要なわけではありません。

要素を再キューイングする必要がなく、新しい変更がないことが確実な場合は、新しいオブジェクトと古いオブジェクトのリソースバージョンを比較できます。 それらが同一である場合、再キューイングをスキップできます。 注意してください。 エラーのために要素の繰り返し配置がスキップされた場合、その要素は失われる可能性があります（キューに再入力しないでください）。

簡単に言えば、「同期を行う必要があります。 同期しないと、アイテムが失われ、キューへの新しい試行が行われない状況が発生する可能性があります。」 これがまさに私たちのケースで起こったことです！

Kubernetesスケジューラが再同期しない

だから、同期の概念に精通した後... Kubernetesスケジューラーはそれを決して実行しないと思われるという結論に達しますか？ このコードでは、すべてが次のようになります。

 informerFactory := informers.NewSharedInformerFactory(kubecli, 0) // cache only non-terminal pods podInformer := factory.NewPodInformer(kubecli, 0) 

これらの数値「0」は「 再同期期間 」（ 再同期期間 ）を意味し、「再同期が発生しない」と解釈するのが論理的です。 おもしろい！ なぜこれが行われるのですか？ この問題に自信がなく、「kubernetesスケジューラーの再同期」をグーグルで検索すると、 プルリクエスト＃16840 （スケジューラーの再同期を追加）を次の2つのコメントで見つけることができました。

@brendandburns-ここで何が修正される予定ですか？ パフォーマンスに大きな影響を与えるため、このような小さな再同期期間には本当に反対です。

私は@ wojtek-tに同意します。 再同期で問題を解決できる場合は、コードのどこかにバグを隠そうとしていることを意味します。 再同期は正しい解決策ではないと思います。

プロジェクトのメンテナーは、再同期を使用して非表示にするよりも、コード内のバグをポップアップして修正する方がよいため、再同期しないことに決めたことがわかりました。

コード読み取りのヒント

私が知る限り、内部からのKubernetesスケジューラの実際の作業は、他の多くのものと同様に、どこにも記述されていません。

必要なコードを読むのに役立ついくつかのトリックを次に示します。

1. 必要なものをすべて大きなファイルに結合します。 上記についてはすでにこれについて書かれていますが、実際には、特にすべてが完全に編成されている方法がまだわからない場合、ファイル間の切り替えに比べて関数呼び出し間の切り替えがはるかに簡単になりました。
   
   
2. いくつか具体的な質問があります。 私の場合、「エラー処理はどのように機能しますか？」 プランナーに届かないとどうなりますか？」 近くには多くのコードがあります...ポッドに割り当てられる特定のノードを選択する方法がありますが、あまり気にしませんでした（そして、それがどのように機能するかまだわかりません）。

Kubernetesでの作業はとてもクールです！

Kubernetesは本当に洗練されたソフトウェアです。 稼働中のクラスターを取得するためにも、APIサーバー、スケジューラー、コントローラーマネージャー、flannel、kube-proxy、kubeletなどのコンテナーネットワーキングの少なくとも6つの異なるコンポーネントを構成する必要があります。 したがって（私のように、実行するソフトウェアを理解したい場合）、これらすべてのコンポーネントが何をするのか、それらがどのように相互作用するのか、そして50兆個の各機能を構成して必要なものを取得する方法を理解する必要があります。

しかし、ドキュメントは十分に優れており、何かが十分にドキュメント化されていない場合、コードは非常に読みやすく、プルリクエストは本当にピアレビューされているようです。

「ドキュメントを読み、そうでない場合はコードを読む」という原則を実際に、そしてもっと日常的に実践しなければなりませんでした。 しかし、いずれにしても、これは良くなるための素晴らしいスキルです！

翻訳者からのPS 。 ブログもご覧ください。

• 「 小規模プロジェクトでのKubernetesでの経験 」 （Kubernetesの技術デバイスの紹介を含むビデオレポート）;
• 「 Kubernetesが必要な理由とPaaSよりも大きい理由 ";
• 「 MinikubeでKubernetesを使い始める 」 （翻訳）