Kubernetes で watch.Interface、cache.NewInformer、cache.NewSharedIndexInformer を使用する必要があるのはどのような場合ですか?

Linda Hamilton
リリース: 2024-11-11 19:56:03
オリジナル
576 人が閲覧しました

When Should You Use watch.Interface, cache.NewInformer, or cache.NewSharedIndexInformer in Kubernetes?

watch.Interface vs.cache.NewInformer vs.cache.NewSharedIndexInformer

Kubernetes でリソースを監視し、変更に対応する場合、開発者はさまざまな操作を行う必要があります。彼らが利用できるオプション。これらのメソッドの違いを理解することが重要です。

watch.Interface

rest.Request.Watch() などのメソッドを通じて取得された watch.Interface は、ストリーミングする ResultChan を提供します。リソース変更のイベント (追加/変更/削除)。これは低レベルの抽象化を提供し、リソースの「後」の状態のみを提供します。

cache.NewInformer

cache.NewInformer 関数を使用すると、 OnAdd()/OnUpdate()/OnDelete() 呼び出しを処理する ResourceEventHandler。これには、リソースの「前」と「後」の両方の状態を受け取るメカニズムが含まれています。 NewInformer は内部的に、NewListWatchFromClient.

cache.NewSharedInformer と cache.NewSharedIndexInformer

を通じて watch.Interface を利用します。これらの関数は、NewInformer よりも高いレベルの抽象化を提供します。 API サーバーへの共有接続を使用し、情報提供者間でリソースを共有します。

推奨事項

ほとんどの使用例では、下位レベルの抽象化よりも SharedInformers が推奨されます。 SharedInformers はリソースを共有し、より高いレベルの抽象化を提供し、多くの下位レベルのタスクを簡素化します。大規模なデータセットを操作する場合は、インデックス作成機能があるため、SharedIndexInformers が推奨されます。

同じ SharedInformerFactory から SharedInformers をインスタンス化して、リソースを効率的に共有します。例を以下に示します。

informerFactory := informers.NewSharedInformerFactory(clientset, time.Second*30)

podInformer := informerFactory.Core().V1().Pods()
serviceInformer := informerFactory.Core().V1().Services()

podInformer.Informer().AddEventHandler(
  // Add event handling 
)
// Add event handling for serviceInformer

informerFactory.Start(wait.NeverStop)
informerFactory.WaitForCacheSync(wait.NeverStop)
ログイン後にコピー

以上がKubernetes で watch.Interface、cache.NewInformer、cache.NewSharedIndexInformer を使用する必要があるのはどのような場合ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
著者別の最新記事
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート