/ sigノード
/種類の機能
cc @ConnorDoyle @balajismaniam @nolancon

ボーグからの学習に基づいて、このデザインを知らせることができます。 だから私をレビューア/承認者として数えてください。

ボーグからの学習に基づいて、このデザインを知らせることができます。 だから私をレビューア/承認者として数えてください。

この機能がborgでどのように機能するかについての公開ドキュメントはありますか？

NUMAAFAIKについてではありません。

2019年2月11日月曜日、午前7時50分Jeremy Eder < [email protected]は次のように書いています。

ボーグからの学習に基づいて、このデザインを知らせることができます。 だから私を数えて
レビューア/承認者として。

この機能がborgでどのように機能するかについての公開ドキュメントはありますか？

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/enhancements/issues/693#issuecomment-462378195 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AGvIKPfanjb9Q5DxXAiBgv9C6Y809JX0ks5vMZFZgaJpZM4aE3uz
。

参考までに@claurence

この追跡の問題とKEP（https://github.com/kubernetes/enhancements/pull/781）は、v1.14の拡張機能のフリーズや期限の延長に間に合いませんでした。 締め切り前にこれらを開いていただきありがとうございますが、十分なレビューや承認が得られなかったようです。 これは、例外プロセスを通過する必要があります。

これが例外に値するかどうかを判断するまで、私はこの機能強化に関連するすべてのPRを保留する傾向があります。

参照： https ：

/ cc @jiayingz @ dchen1107

@lmdalyすべての説明にアルファマイルストーンとして1.14がリストされているようです-マージされた実装可能なKEPがなかったため、この問題は1.14で追跡されていません-そのリリースに含める意図がある場合は、例外リクエストを送信します。

@lmdalyすべての説明にアルファマイルストーンとして1.14がリストされているようです-マージされた実装可能なKEPがなかったため、この問題は1.14で追跡されていません-そのリリースに含める意図がある場合は、例外リクエストを送信します。

@claurence KEPがマージされました（KEPは以前にコミュニティリポジトリにマージされていました。これは、新しいガイドラインに従って新しい拡張リポジトリに移動するためだけのものでした）、この問題を追跡するには、例外リクエストを送信する必要がありますか？ 1.14の場合？

デザインとWIPPRをよく読んだ後、 https：//github.com/kubernetes/enhancements/pull/781で提案した元のトポロジデザインのように、現在の実装が一般的ではないことに懸念を抱いてい

ここでさらに議論するためにいくつかのコメントを残しました： https ：

現在の実装はジェネリックではありません

それについて同じ懸念を共有してください:)他の人、例えばデバイス間のリンク（GPUのnvlinke）はどうですか？

@resouer @ k82cn最初の提案では、CPUマネージャーとデバイスマネージャーが下した決定を調整して、コンテナーが実行されているCPUとデバイスが確実に近接するようにすることのみを扱っています。 デバイス間の親和性を満たすことは、提案の目標ではありませんでした。

ただし、現在の実装が将来のデバイス間アフィニティの追加をブロックしている場合は、その方法を理解したら、実装を変更できます。

現在の実装とデバイス間のアフィニティをサポートする機能で私が目にする主な問題は次のとおりです。

デバイス間のアフィニティをサポートするには、通常、コンテナに割り当てるソケットアフィニティを決定する前に、コンテナに割り当てるデバイスを最初に把握する必要があります。

たとえば、Nvidia GPUの場合、最適な接続を実現するには、最初に、最も接続されているNVLINKを備えたGPUのセットを見つけて割り当てる必要があります。その前に、そのセットのソケットアフィニティを決定します。

現在の提案で私が言えることから、これらの操作は逆の順序で行われる、つまり、デバイスの割り当てを行う前にソケットアフィニティが決定されるという仮定があります。

@klueskaは必ずしもそうとは限りません。 トポロジヒントがポイントツーポイントデバイストポロジをエンコードするように拡張された場合、デバイスマネージャはソケットアフィニティを報告するときにそれを考慮することができます。 つまり、クロスデバイストポロジは、デバイスマネージャの範囲外にリークする必要はありません。 それは実行可能だと思いますか？

多分私はどういうわけか流れについて混乱しています。 これが私がそれを理解する方法です：

1）初期化時に、デバイスプラグイン（ devicemanager ）がtopologymanager登録されるため、後でコールバックを発行できます。

2）ポッドが送信されると、kubeletはtopologymanagerのlifecycle.PodAdmitHandlerを呼び出します。

3） lifecycle.PodAdmitHandlerは、登録された各デバイスプラグインでGetTopologyHintsを呼び出します

4）次に、これらのヒントをマージして、ポッドに関連付けられた統合されたTopologyHintを生成します

5）ポッドを許可することを決定した場合、ポッドの統合されたTopologyHintをローカルの州のストアに格納しているlifecycle.PodAdmitHandlerから正常に戻ります。

6）将来のある時点で、 cpumanagerとdevicemanagerはtopologyマネージャーでGetAffinity(pod)を呼び出して、関連付けられたTopologyHintを取得しますポッド付き

7） cpumanagerは、このTopologyHint`を使用してCPUを割り当てます

8） devicemanagerは、このTopologyHint`を使用して一連のデバイスを割り当てます

9）ポッドの初期化は続行されます...

これが正しければ、デバイスプラグインがTopologyHintsを報告する時点と、 devicemanagerが実際の割り当てを行う時点との間に何が起こるかについて苦労していると思います。

これらのヒントが割り当てのための「設定」をエンコードすることを意図している場合、あなたが言っていることは、より次のような構造を持つことだと思います。

type TopologyHints struct {
    hints []struct {
        SocketID int
        DeviceIDs []int
    }
}

ソケットアフィニティプリファレンスのリストを渡すだけでなく、それらのソケットアフィニティプリファレンスが割り当て可能なGPUプリファレンスとどのようにペアになるかを示します。

これがあなたが考えている方向であるなら、私たちはそれを機能させることができると思いますが、 cpumanagerとdevicemanager間で何らかの形で調整して、それらが同じように「受け入れられる」ことを確認する必要があります割り当てを行う際のヒント。

私が見逃したことをすでに可能にする何かがありますか？

@klueska

フローにいくつかの_マイナー_修正を加えると、何が起こるかと思います。

1. 初期化時に、デバイスプラグインはdevicemanager登録されるため、後でコールバックを発行できます。

2. lifecycle.PodAdmitHandlerは、Kubeletの各トポロジ対応コンポーネント（現在はdevicemanagerおよびcpumanager GetTopologyHintsを呼び出します。

この場合、Kubeletでトポロジ対応として表されるのは、 cpumanagerとdevicemanagerです。 トポロジー・マネージャーは、トポロジー対応コンポーネント間の割り振りを調整することのみを目的としています。

このため：

ただし、cpumanagerとdevicemanagerの間で何らかの調整を行って、割り当てを行うときに同じヒントを「受け入れる」ようにする必要があります。

これは、 topologymanager自体が達成するために導入されたものです。 以前のドラフトの1つから、

これらのコンポーネントは、NUMA間の割り当てを回避するために調整する必要があります。 この調整に関連する問題は注意が必要です。 「割り当てられたNICと同じNUMAノード上の排他的コア」などのクロスドメインリクエストには、CNIとCPUマネージャーの両方が含まれます。 CPUマネージャーが最初に選択した場合、NICが使用できないNUMAノード上のコアを選択する可能性があります。その逆も同様です。

そうですか。

だから、 devicemanagerとcpumanager実装の両方GetTopologyHints()だけでなく、コールGetAffinity()からの方向の相互作用を避け、 topologymanagerすべての基本となるデバイスのプラグインとの。 コードを詳しく見ると、 devicemanager単にプラグインに制御を委任して、 TopologyHintsを支援していることがわかります。これは、いずれにせよ、より理にかなっています。

私が提起した元の質問/問題に戻ります。

Nvidiaの観点からは、将来的にポイントツーポイントリンク情報を報告するためにTopologyHints構造体（およびその結果としてデバイスプラグインインターフェイス）にさらに情報が追加されると仮定すると、この提案されたフローですべてを機能させることができると思います。

ただし、ソケットアフィニティをアドバタイズするための主要なデータ構造としてSocketMaskから始めると、既存のインターフェイスを壊すことなく、将来的にポイントツーポイント情報でTopologyHintsを拡張する機能が制限される可能性があると思います。 主な理由は、（少なくともNvidia GPUの場合）優先ソケットは、最終的にどのGPUが実際に割り当てられるかによって異なるためです。

たとえば、最適な接続で2つのGPUをポッドに割り当てようとする場合は、次の図を検討してください。

（2、3）と（6、7）のGPUの組み合わせには、両方とも2つのNVLINKがあり、同じPCIeバス上にあります。 したがって、2つのGPUをポッドに割り当てようとする場合、これらは同等の候補と見なされます。 ただし、選択した組み合わせに応じて、（2、3）がソケット0に接続され、（6、7）がソケット1に接続されるため、別のソケットが明らかに優先されます。

devicemanagerが最終的にこれらの必要な割り当てのいずれかを実行できるように（つまり、 topologymanagerがヒントを統合する方）、この情報をTopologyHints構造体にエンコードする必要があります。至るまで）。 同様に、優先デバイス割り当てと優先ソケットの間の依存関係は、 TopologyHintsでエンコードして、 cpumanagerが正しいソケットからCPUを割り当てることができるようにする必要があります。

この例のNvidiaGPUに固有の潜在的なソリューションは、次のようになります。

type TopologyHint struct {
    SocketID int
    DeviceIDs []int
}

type TopologyHints []TopologyHint

devicemanagerhints := &TopologyHints{
    {SocketID: 0, DeviceIDs: []int{2, 3}},
    {SocketID: 1, DeviceIDs: []int{6, 7}},
}

cpumanagerhints := &TopologyHints{
    {SocketID: 1},
}

topologymanagerがこれらのヒントを統合して、 devicemanagerとcpumanager後でGetAffinity()呼び出すときに、優先ヒントとして{SocketID: 1, DeviceIDs: []int{6, 7}}を返す場合。

これはすべてのアクセラレータに十分な汎用ソリューションを提供する場合と提供しない場合がありますが、 TopologyHints構造体のSocketMaskを次のような構造に置き換えると、個々のヒントをより多くのフィールドで拡張できます。未来：

GetTopologyHints()引き続きTopologyHintsを返しますが、 GetAffinity()は、 TopologyHintsではなく単一のTopologyHintを返すように変更されていることに注意して

type TopologyHint struct {
    SocketID int
}

type TopologyHints []TopologyHint

&TopologyHints{
    {SocketID: 0},
    {SocketID: 1},
}

type HintProvider interface {
    GetTopologyHints(pod v1.Pod, container v1.Container) TopologyHints
}

type Store interface {
    GetAffinity(podUID string, containerName string) TopologyHint
}

考え？

@klueska何かが足りないかもしれませんが、NV

@ConnorDoyleが提案したように、デバイスがポイントツーポイントデバイス接続に関する情報を送り返すことができるようにデバイスプラグインAPIが拡張された場合、デバイスマネージャーはこれに基づいてソケット情報を送り返すことができます。

あなたの例では、 devicemanagerhintsは、デバイスプラグインがデバイスマネージャーに送り返した情報である可能性があります。 次に、デバイスマネージャはソケット情報をそのままTopologyManagerに送り返し、TopologyManagerは選択されたソケットヒントを保存します。

割り当て時に、devicemanagerはGetAffinityを呼び出して、目的のソケット割り当て（この場合はソケットが1であるとしましょう）を取得します。この情報とデバイスプラグインから返される情報を使用して、ソケット1でデバイスを割り当てる必要があることを確認できます（ 6,7）NVLinkデバイスであるため。

それは理にかなっていますか、それとも私が見逃しているものがありますか？

私と一緒にこれを明確にするために時間を割いてくれてありがとう。 @ConnorDoyleの最初の提案を誤解したに違いありません。

トポロジヒントがポイントツーポイントデバイストポロジをエンコードするように拡張された場合、デバイスマネージャはソケットアフィニティを報告するときにそれを考慮することができます。

私はこれを、ポイントツーポイント情報でTopologyHints構造体を直接拡張したいと読んでいます。

devicemanagerにポイントツーポイント情報を提供するためにデバイスプラグインAPIのみを拡張する必要があることを示唆しているようです。これにより、この情報を使用してSocketMaskに通知できます。 GetTopologyHints()が呼び出されるたびに、 TopologyHints構造体に設定する

デバイスプラグインのAPI拡張機能が、上記の例で概説したものと同様の情報を提供するように設計されており、ポッドアドミッションとデバイス間でこの情報を保存するためにdevicemanagerが拡張されている限り、これは機能すると思います。割り当て時間。

現在、Nvidiaにはカスタムソリューションがあり、 kubeletにパッチを適用して、基本的にあなたが提案していることを実行します（ただし、デバイスプラグインに決定を下す必要はありません- devicemanager GPUを認識し、トポロジベースのGPU割り当ての決定を行います）。

長期的なソリューションが導入されれば、将来これらのカスタムパッチを削除できるようになります。 そして、ここでのフローがどのように機能するかをよりよく理解できたので、私たちを妨げるものは何も見当たりません。

すべてを明確にするために時間を割いていただき、ありがとうございます。

こんにちは@lmdaly 、私は1.15のエンハンスメントリードです。 この機能は1.15でアルファ/ベータ/安定ステージを卒業する予定ですか？ 適切に追跡してスプレッドシートに追加できるように、お知らせください。

コーディングを開始したら、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。

この機能は独自の機能ゲートになり、アルファ版になります。

/マイルストーン1.15

@derekwaynecarr ：提供されたマイルストーンはこのリポジトリでは無効です。 このリポジトリのマイルストーン：[ keps-beta 、 keps-ga 、 v1.14 、 v1.15 ]

/milestone clearを使用して、マイルストーンをクリアします。

/ milestone v1.15

/ assign @lmdaly

https://github.com/kubernetes/kubernetes/issues/72828

コードPR

@lmdaly
https://github.com/kubernetes/kubernetes/issues/72828
私のチームと私は、numaに敏感なアプリケーションのトポロジマネージャーをテストすることを検討しています。
それで、いくつか質問があります。
PRの上で、これらはトポロジマネージャにとって完全な意味合いですか？
そして、それは今テストされていますか、それとも安定していますか？

@ bg-chun私たちはNvidiaでも同じことをしています。 これらのWIPPRを内部スタックに取り込み、その周りのCPU / GPUにトポロジ対応の割り当て戦略を構築しました。 そうすることで、いくつかの問題を発見し、これらのPRに関する具体的なフィードバックを提供しました。

詳細については、こちらのディスカッションスレッドをご覧ください。
https://kubernetes.slack.com/archives/C0BP8PW9G/p1556371768035800

ねえ、 @ lmdaly私はv1.15ドキュメントリリースシャドウです。

1.15リリースのこの拡張機能のアルファ版をターゲットにしているようです。 これには新しいドキュメント（または変更）が必要ですか？

5月30日木曜日までにk / website（ブランチdev-1.15）に対するPRを探しています。 それが完全なドキュメントの始まりであるならばそれは素晴らしいでしょう、しかしプレースホルダーPRさえ受け入れられます。 ご不明な点がございましたらお知らせください。 😄

@lmdaly 5月30日木曜日までに、k / website（branch dev-1.15）に対するPRを探しています。 それが完全なドキュメントの始まりであるならばそれは素晴らしいでしょう、しかしプレースホルダーPRさえ受け入れられます。 ご不明な点がございましたらお知らせください。 😄

こんにちは@lmdaly 。 コードフリーズは2019年5月30日木曜日@EODPSTです。 リリースに含まれるすべての拡張機能は、テストを含めてコードが完全であり、ドキュメントのPRが開いている必要があります。

https://github.com/kubernetes/kubernetes/issues/72828を見て、すべてがマージされているかどうかを確認します。

これがスリップすることがわかっている場合は、返信してお知らせください。 ありがとう！

@daminisatya私はドキュメントPRをプッシュしました。 https://github.com/kubernetes/website/pull/14572

それが正しく行われたかどうか、そして何か追加の項目を行う必要があるかどうかを教えてください。 念押し有難う！

ありがとう@ lmdaly✨

こんにちは@lmdaly 、今日は1.15リリースサイクルのコードフリーズです。 トラッキングの問題https://github.com/kubernetes/kubernetes/issues/72828からまだマージされていないk / kPRがまだかなりあり1.15拡張追跡シートでリスクありとしてマークされています。 これらが今日EODPSTによって統合されるという高い確信はありますか？ この時点以降、マイルストーンでは、リリースブロッキングの問題とPRのみが例外として許可されます。

/マイルストーンクリア

こんにちは@ lmdaly @ derekwaynecarr 、私は1.16エンハンスメントリードです。 この機能は1.16でアルファ/ベータ/安定ステージを卒業する予定ですか？ 1.16トラッキングスプレッドシートに追加できるようにお知らせください。 卒業していない場合は、マイルストーンから削除し、追跡ラベルを変更します。

コーディングが開始されたら、またはすでにある場合は、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。

マイルストーンの日付は、Enhancement Freeze7 / 30およびCodeFreeze8 / 29です。

ありがとう。

@ kacole2リマインダーをありがとう。 この機能は、1.16でAlphaとして導入されます。

進行中のPRのリストは、 https ：

ありがとう！

これが1.16でアルファ版に到達することに同意します。以前に1.15でマージされたケップで開始され、キャプチャされた作業を終了します。

こんにちは@lmdaly 、私はv1.16ドキュメントリリースシャドウです。

この拡張機能には、新しいドキュメント（または変更）が必要ですか？

8月23日金曜日までにk / website（ブランチdev-1.16）に対するPRを探しています。 それが完全なドキュメントの始まりであるならばそれは素晴らしいでしょう、しかしプレースホルダーPRさえ受け入れられます。 ご不明な点がございましたらお知らせください。

ありがとう！

ドキュメントPR： https ：

@lmdalyトポロジマネージャーは、特定のポッドのNUMA構成をユーザーに通知するための情報またはAPIを提供しますか？

@mJace kubectlを介して表示される何かがポッドについて説明しますか？

@lmdalyええ、 kubectl describeはいいです。 または関連情報を返すためのAPI。
ポッドのCPUピニングステータスや、パススルーVFのnumaノードなど、ポッドのトポロジ関連情報を提供するサービスを開発しているためです。
また、weaveスコープなどの一部のモニターツールは、APIを呼び出して凝った作業を行うことができます。
管理者は、たとえば、VNFが適切なNUMA構成の下にあるかどうかを確認できます。

TopologyManagerがこの部分をカバーするかどうかを知りたいだけです。
または、Topology Managerがこの種の機能をサポートすることを計画している場合に実行できる作業がある場合は、

@mJaceわかりました。現在、TopologyManager用のようなAPIはありません。 CPUとデバイスマネージャーの場合、ポッドに実際に割り当てられているものが表示されないため、これに優先順位はないと思います。

ですから、これについて話し合いを始めて、ユーザーにどのような見方をすることができるかを見てみるのもいいと思います。

なるほど、CPU＆DeviceManagerがこの情報を見ることができると思いました。

たぶん、cadvisorはこの情報を提供するための良い役割です。
基本的にcadvisorはPIDなどのコンテナ情報をps ls取得するためです。
また、コンテナのトポロジ関連情報を確認するのと同じ方法です。
これをcadvisorに実装し、prを作成します。

cadvisorで関連する問題を作成しました。
https://github.com/google/cadvisor/issues/2290

/割当

@mJaceのcadvisor案に+1。

CPU ManagerおよびTopology Managerでコンテナー内のDPDK libを使用するには、コンテナーのCPUアフィニティーを解析してからdpdk libに渡します。どちらも、DPDKlibのスレッド固定に必要です。

詳細については、cpusがコンテナのcgroup cpusetサブシステムで許可されていない場合、cpusでプロセスを固定するためのsched_setaffinityの呼び出しは除外されます。
DPDK libはスレッドの固定にpthread_setaffinity_npを利用し、 pthread_setaffinity_npはsched_setaffinityスレッドレベルのラッパーです。
また、KubernetesのCPUマネージャーは、コンテナーのcgroupcpusetサブシステムに排他的なCPUを設定します。

@ bg-chun cadvisorの変更は、監視という別の目的に役立つものとして理解しました。 要件に応じて、「/ proc / self / status」から「Cpus_Allowed」または「Cpus_Allowed_List」を解析することにより、コンテナ内から割り当てられたCPUを読み取ることができます。 そのアプローチはあなたのために働きますか？

Cpus_Allowedような/ proc / * / statusの@ConnorDoyle情報は、 sched_setaffinity影響を受けます。 したがって、アプリケーションが何かを設定すると、それはCgroupのcpusetコントローラーによって実際に許可されるもののサブセットになります。

@kad 、私はコンテナ内のランチャーがcpuid値を見つけてDPDKプログラムに渡す方法を提案していました。 したがって、これはスレッドレベルのアフィニティが設定される前に発生します。

@ConnorDoyle
ご提案ありがとうございます、検討させていただきます。
私の計画は、tiny-rest-apiサーバーをデプロイして、排他的なCPU割り当て情報をdpdk-containerに通知することでした。

変更点については、まだcadvisorの変更は見ていませんが、提案のみが表示されています。
提案は言うable to tell if there is any cpu affinity set for the container.の目標とでto tell if there is any cpu affinity set for the container processes.今後の仕事では。

提案を読んだ後、私はちょうどcadvisorは、CPUピニング情報を解析することが可能であり、以下のように容器にそれを渡すkubelet場合、それは素晴らしいことだと思った環境変数のようなstatus.podIP 、 metadata.name 、およびlimits.cpu 。
それが私が+1を残した主な理由です。

@ bg-chunあなたはcadvisorで私の最初のPRをチェックすることができます
https://github.com/google/cadvisor/pull/2291

で同様の機能を終了しました。
https://github.com/mJace/numacc
しかし、cadvisorでそれを実装するための適切な方法は本当にわかりません
そのため、1つの新機能でPRを作成するだけです-> PSRを表示します。

しかし、cadvisorでそれを実装するための適切な方法は本当にわかりません

たぶん、その提案の下でこれについて議論することができますか？ あなたが教祖がこの機能が必要だと思うなら:)

1.16の@lmdalyコードフリーズは8/29木曜日です。 残りのk / k PRについては、 https：//github.com/kubernetes/kubernetes/issues/72828を追跡し

@ kacole2この機能に必要なすべてのPRがマージされるか、マージキューに入れられます。

こんにちは@ lmdaly -1.17拡張機能がここにつながります。 チェックインして、この拡張機能が1.17でアルファ/ベータ/安定に移行すると思われるかどうかを確認したいと思います。

現在のリリーススケジュールは次のとおりです。

• 9月23日月曜日-リリースサイクルが始まります
• 10月15日火曜日、EODPST-拡張機能のフリーズ
• 11月14日木曜日、EODPST-コードフリーズ
• 11月19日火曜日-ドキュメントを完成させて確認する必要があります
• 12月9日月曜日-Kubernetes1.17.0がリリースされました

その場合は、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。 👍

ありがとう！

/マイルストーンクリア

@lmdaly RDMAディスカッションでGPUダイレクトへのリンクはありますか？

@nickolaev 、このユースケースも検討しています。 私たちはこれを行う方法についていくつかの内部的な考えを始めましたが、私たちはこれについて協力したいと思っています。

@ moshe010 @nickolaev @lmdaly、我々はあまりにもRDMAと直接GPUに関連するこのユースケースを覗きます。 これについて協力したいと思います。 この周りのスレッド/ディスカッションを開始することは可能ですか？

こんにちは！ NTMとスケジューラについて質問があります。 私が理解しているように、スケジューラーはNUMAについて知らず、目的のNUMAにリソース（CPU、メモリ、デバイス）がないという点でノードを優先できます。 そのため、トポロジー・マネージャーはそのノードでのリソース割り当てを拒否します。 それは本当ですか？

@nickolaev @Deepthidharwar 、私はユースケースでグーグルドキュメントを始めます、そして私たちはそれに議論を移すことができます。 来週何か投稿します。 それでよければ。

この機能を見て本当にうれしいです。 また、単一のNUMAノードにCPU、Hugepage、SRIOV-VF、およびその他のハードウェアリソースが必要です。
しかし、hugepageはデバイスプラグインによってスカラーリソースとして認識されません。この機能はk8sのhugepage機能を変更する必要がありますか？
@iamneha

@ConnorDoyle確認のために、この機能にはCPUマネージャーとデバイスマネージャーの両方からのトポロジヒントが必要ですか？ 1.16でテストしましたが、機能しませんでした。CPUマネージャーからのヒントしか得られなかったようですが、デバイス側からのヒントは得られなかったようです。

@ConnorDoyleはここにもう少し詳細があります：
https://gist.githubusercontent.com/jianzzha/c2a66a2514c178cca76a432029ff3387/raw/264f13dfcd06f1f80c48c113aa235fab7c33d81e/hyper%2520threading%2520enabled

@jianzzha 、どのデバイスプラグインを使用していますか？ たとえば、SR-IOVデバイスプラグインを使用する場合は、NUMAノードが報告されていることを確認する必要があります。[1]を参照してください。

[1] https://github.com/intel/sriov-network-device-plugin/commit/000db15405f3ce3b7c2f9feb180c3051aa3f7aea。

@andyzheung巨大なページ統合は現在議論されており、過去2週間のsig-node会議で発表されました。 関連するリンクは次のとおりです。

https://docs.google.com/presentation/d/1H5xhCjgCZJjdTm-mGUFwqoz8XmoVd8xTCwJ1AfVR_54/edit?usp=sharing
https://github.com/kubernetes/enhancements/pull/1245
https://github.com/kubernetes/enhancements/pull/1199

@jianzzhaデバイスプラグインがヒントを与えていないことについて。 プラグインは、列挙するデバイスに関するNUMA情報を報告するように更新されていますか？ このフィールドをデバイスメッセージhttps://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/deviceplugin/v1beta1/api.proto#L100に追加する必要があり

みんなありがとう。 修正され、動作するようになりました。

@klueska
nvidia-gpu-device-pluginについて。
Topology Mangerのnvidia-gpu-device-pluginを更新するアクティブなPR（WIP）が1つだけ表示されます。
nvidia-gpu-divice-pluginは、上記のPRでトポロジヒントを提供するように更新されますか？ または私が見逃しているものはありますか？

@ bg-chunはい、そうあるべきです。 作者にpingを送信しました。 翌日かそこらで戻ってこない場合は、プラグインを自分で更新します。

@ bg-chun @ klueskaパッチを更新しました。

@klueska @carmark
更新と通知をありがとうございます。
ワークスペースのユーザーにsr-iov-pluginupdateとgpu-pluginupdateを紹介します。

次のリリースの機能強化を提案します。
これは基本的に、「ポッドが保証されたQoSにある場合にのみトポロジの調整が行われる」という制限を取り除くことです。
この制限により、現時点ではTopology Managerを使用できなくなります。これは、K8から専用のCPUを要求したくないためですが、複数のプール（GPU + SRなど）からの複数のデバイスのソケットを調整したいのです。 -IOV VFなど）
また、ワークロードがメモリに敏感でない場合、またはメモリの使用を制限したくない場合（保証されたQoSの別の基準）はどうなりますか。
将来、巨大なページも配置されることを期待すると、この制限はIMOをさらに制限するように感じます。

「調整可能な」リソースを個別に調整することに反対する議論はありますか？ 確かのように、排他的なCPUが使用されている場合のが唯一のCPUマネージャからヒントを収集してみましょう、しかし独立して、ユーザーがデバイス持つソケット情報を必要とする場合、またはメモリマネージャからユーザーがのhugepagesなどを要求したときのデバイスマネージャからヒントを収集してみましょう

これ、またはポッドの起動中に不要な追加の計算負荷が懸念される場合は、元のポッドレベルの構成フラグを戻し、アライメントが発生するかどうかを制御します（実装中に廃棄されるのを見て驚いた）

次のリリースの機能強化を提案します。
これは基本的に、「ポッドが保証されたQoSにある場合にのみトポロジの調整が行われる」という制限を取り除くことです。

これは、1.17のTODOリストのアイテム番号8です。
https://docs.google.com/document/d/1YTUvezTLGmVtEF3KyLOX3FzfSDw9w0zB-s2Tj6PNzLA/edit#heading = h.xnehh6metosd

「調整可能な」リソースを個別に調整することに反対する議論はありますか？ 確かのように、排他的なCPUが使用されている場合のが唯一のCPUマネージャからヒントを収集してみましょう、しかし独立して、ユーザーがデバイス持つソケット情報を必要とする場合、またはメモリマネージャからユーザーがのhugepagesなどを要求したときのデバイスマネージャからヒントを収集してみましょう

どのリソースを整列させ、どのリソースを整列させないかを選択的にkubeletに指示するメカニズムがあることを提案していますか（つまり、CPUとGPUの割り当てを調整したいが、巨大なページ割り当ては調整したくない）。 これに完全に反対する人はいないと思いますが、ノードレベルでフラグとして配置を指定し続けると、配置するリソースと配置しないリソースを選択的に決定するためのインターフェイスが非常に煩雑になる可能性があります。

これ、またはポッドの起動中に不要な追加の計算負荷が懸念される場合は、元のポッドレベルの構成フラグを戻し、アライメントが発生するかどうかを制御します（実装中に廃棄されるのを見て驚いた）

これでポッド仕様を更新する提案を正当化するためのポッドレベルフラグの十分なサポートがありませんでした。 一部のポッドは位置合わせが必要/必要であり、一部は必要ないため、私にはこの決定をポッドレベルにプッシュすることは理にかなっていますが、全員が同意したわけではありません。

トポロジアラインメントのQoSクラス制限を削除するための+1（リストに追加しました：smiley :)。 @Levovarがリソースごとにトポロジを有効にすることを求めているのは

私が覚えている限り、KEPにはトポロジにオプトインするためのポッドレベルのフィールドはありませんでした。 そもそも導入しない理由は、排他的コアを暗黙的に残す理由と同じでした。プロジェクトとしてのKubernetesは、ノードレベルのパフォーマンス管理の観点からポッド仕様を自由に解釈できることを望んでいます。 コミュニティの一部のメンバーにとってスタンスが不満であることは知っていますが、いつでもトピックを再び取り上げることができます。 少数のユーザーに高度な機能を有効にすることと、ほとんどのユーザーに認知的負荷を調整することの間には、自然な緊張関係があります。

設計の非常に初期の段階でのIMOには、少なくとも私の記憶がうまく機能する場合はポッドレベルのフラグがありましたが、それは約1.13：Dでした。
私は個人的には常にすべてのリソースを調整しようとしても大丈夫ですが、「昔」は通常、起動やすべてのポッドのスケジュール決定に遅延をもたらす機能に対するコミュニティの反発がありました。彼らは本当に強化が必要かどうか。

そのため、2つのオプションが頭に浮かび、これらの懸念に「事前に対処」しようとしていました。いくつかの基準に基づいてリソースグループの調整を事前にゲートします（CPUの定義は簡単、他の基準は難しい）。 または、構成フラグを導入します。

ただし、一般的な拡張機能に対するプッシュバックがない場合は、それで完全にクールです:)

@mrbobbytables 1.17でTopologyManagerをbetaに卒業する予定です。 追跡の問題はここにあります： https ：

@ bg-chun @ klueskaパッチを更新しました。

マージされたパッチ：
https://github.com/NVIDIA/k8s-device-plugin/commit/cc0aad87285b573127add4e487b13434a61ba0d6

パッチで新しいリリースを作成しました：
https://github.com/NVIDIA/k8s-device-plugin/releases/tag/1.0.0-beta2

v1.17の追跡ベータ

素晴らしい、ありがとう@derekwaynecarr 。 シートに追加します:)
/ステージベータ

@lmdaly

私はv1.17ドキュメントシャドウの1つです。
この拡張機能（またはv1.17で計画されている作業）には、新しいドキュメント（または既存のドキュメントへの変更）が必要ですか？ そうでない場合は、1.17エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

もしそうなら、11月8日金曜日までに予定されているk / website（ブランチdev-1.17）に対するPRを探しているのは、フレンドリーなリマインダーです。現時点では、プレースホルダーPRになる可能性があります。 ご不明な点がございましたらお知らせください。

ありがとう！

@ VineethReddy02はい、トラッカーシートを更新できれば、1.17のドキュメントの更新を計画しています。

その前に必ずそのPRを開きます。リマインダーをありがとう。

このためのドキュメントを追跡するための問題はここにあります： https ：

https://github.com/kubernetes/enhancements/pull/1340
皆さん、私はKEPアップデートPRを開いて、トポロジマネージャーの組み込みノードラベル（ beta.kubernetes.io/topology ）を追加しました。
ラベルはノードのポリシーを公開します。
同じクラスター内に複数のポリシーを持つノードがある場合、特定のノードにポッドをスケジュールするのに役立つと思います。
レビューをお願いしてもいいですか？

こんにちは@ lmdaly

ここにある1.17拡張チームのジェレミー👋。 追跡できるように、このために実行中のk / kPRをリストしてください。 ＃83492がマージされたようですが、追跡項目全体にぶら下がっている関連する問題がさらにいくつかあるようです。 11月14日にCodeFreezeに近づきますので、それまでにこれがどのように進行しているかを把握したいと思います。 本当にありがとう！

@jeremyrickardこれは、上記の1.17の追跡の問題です： https ：

@lmdaly @derekwaynecarr

11月8日金曜日までに、k / website（ブランチdev-1.17）に対するドキュメントのプレースホルダーPRを探しています。 この期限はあと2日です。

ドキュメントPRはここにあります： https ：

@klueska作業の一部が1.18にぶつかったのがわかります。 これを1.17でベータ版に卒業する予定ですか、それともアルファ版のままですが変更されますか？

気にしないでください。https：//github.com/kubernetes/kubernetes/issues/85093で、1.17の一部としてではなく、1.18でベータ版にジャンプすることがわかりました。 1.17マイルストーン@klueskaの一部として、アルファバージョンへの主要な変更としてこれを追跡しますか？ それとも、卒業を1.18に延期しますか？

/ milestone v1.18

ねえ@klueska

1.18拡張チームのチェックイン！ これを1.18でベータ版に卒業する予定はありますか？ KEPで更新が必要な場合、拡張フリーズは1月28日、コードフリーズは3月5日です。

ありがとう！

はい。

@klueskaアップデートしてくれてありがとう！ トラッキングシートを更新しています。

@klueskaは、このリリースのKEPを確認しているときに、テスト計画が欠落していることに気付きました。 リリースでベータ版に移行するには、テスト計画を追加する必要があります。 今のところマイルストーンから削除しますが、例外リクエストを提出してKEPにテストプランを追加すると、再度追加できます。 通知が遅れたことをお詫びします。

/マイルストーンクリア

@vpickard上記をご覧ください

@vpickard上記をご覧ください

@klueska頭を上げてくれてありがとう。 KEPへのテスト計画の追加に取り組み、例外リクエストを提出します。 私たちは積極的にテストケースを開発しており、いくつかのテストPRを実施しており、次のようないくつかのテストが進行中です。

https://github.com/kubernetes/kubernetes/pull/87645

@jeremyrickard参照用に私に指示できるテスト計画テンプレートはありますか？

@vpickardあなたは見ることができます：

https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190530-pv-health-monitor.md#test -plan
と
https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20200120-skip-permission-change.md#test -plan

単体テストとe2eテストの概要を含めます。

テストグリッドに表示されるものがある場合は、含めると便利です。

例外が承認されました。

/ milestone v1.18

@jeremyrickardテストプランが統合されました： https ：

こんにちは@ klueska @ vpickard 、コードフリーズが3月5日木曜日に発効することをお知らせします。

この拡張のために追跡する必要があるすべてのk / k PRまたはその他のPRをリンクしていただけますか？

ありがとうございます ：）

こんにちは@palnabarun

ここで1.18の問題を追跡します：
https://github.com/kubernetes/kubernetes/issues/85093

現在オープンPR：
https://github.com/kubernetes/kubernetes/pull/87758 （承認済み、フレーキングテスト）
https://github.com/kubernetes/kubernetes/pull/87759（WIP ）
https://github.com/kubernetes/kubernetes/pull/87650 （レビュー済み、承認が必要）

https://github.com/kubernetes/kubernetes/pull/87645（e2eテストPR、承認が必要）

@vpickardは、私が見逃した

ありがとう

ここでPRとアンブレラの問題をリンクしてくれた@nolanconに感謝します。 トラッキングシートにPRを追加しました。

こんにちは@ palnabarun 、 @ nolancon 、

E2Eテストに関連するいくつかの追加のオープンPR：
https://github.com/kubernetes/test-infra/pull/16062 （レビューと承認が必要）
https://github.com/kubernetes/test-infra/pull/16037 （レビューと承認が必要）

追加の更新をしてくれた@vpickardに感謝します。 :)

こんにちは@lmdaly私はv1.18ドキュメントシャドウの1つです。
この拡張機能（またはv1.18で計画されている作業）には、新しいドキュメント（または既存のドキュメントへの変更）が必要ですか？ そうでない場合は、1.18エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

もしそうなら、2月28日金曜日までに予定されているk / website（ブランチdev-1.18）に対するPRを探しているのは、フレンドリーなリマインダーです。現時点では、プレースホルダーPRになる可能性があります。 ご不明な点がございましたらお知らせください。

こんにちは@irvifa 、頭を上げてくれてありがとう。 いくつかの小さな変更を加えて、ここkubernetes / website＃19050でPRを開きました。 このPRは今のところWIPです。ベータ版に移行するための基準が満たされたら、WIPから削除します（上記のPRはまだ検討中です）。
ありがとう。

こんにちは@nolancon迅速な対応に感謝します。ステータスをプレースホルダーPRに変更します。ありがとうございます。

@palnabarun参考までに、レビュープロセスを容易にするために、この：//github.com/kubernetes/kubernetes/pull/87759を2つのPRに分割しました。 2つ目はhttps://github.com/kubernetes/kubernetes/pull/87983で、追跡する必要があります。 ありがとう。

@nolancon更新していただきありがとうございます。

一部のPRはまだマージが保留されているようです。 レビュー担当者と承認者をPRに参加させるために、リリースチームの支援が必要かどうかを確認したいと思いました。 何か必要な場合はお知らせください。

参考までに、3月5日のCodeFreezeに非常に近づいてい

@nolancon更新していただきありがとうございます。

一部のPRはまだマージが保留されているようです。 レビュー担当者と承認者をPRに参加させるために、リリースチームの支援が必要かどうかを確認したいと思いました。 何か必要な場合はお知らせください。

参考までに、3月5日のCodeFreezeに非常に近づいてい

@palnabarunもう1つの更新、 https：//github.com/kubernetes/kubernetes/pull/87983は現在閉じられており、追跡する必要はありません。 必要な変更は、レビュー中の元のPRhttps ：//github.com/kubernetes/kubernetes/pull/87759に含まれています。

@nolanconかっこいい。 上記で共有したアンブレラトラッカーの問題も追跡しています。 :)

こんにちは@nolancon 、これは3月5日のCodeFreezeからわずか2日であるということを思い出させて

コードフリーズでは、関連するすべてのPRをマージする必要があります。そうしないと、例外リクエストを提出する必要があります。

こんにちは@nolancon 、

今日、EODはコードフリーズです。

https://github.com/kubernetes/kubernetes/pull/87650が期限までにレビューされると思い

そうでない場合は、例外リクエストを提出してください。

こんにちは@nolancon 、

今日、EODはコードフリーズです。

kubernetes / kubernetes＃87650は期限までにレビューされると思いますか？

そうでない場合は、例外リクエストを提出してください。

こんにちは@palnabarun 、

明確にするために、EODとは、午後5時または午前0時のPSTを意味しますか？ ありがとう

明確にするために、EODとは、午後5時または午前0時のPSTを意味しますか？ ありがとう

太平洋標準時午後5時。

PRは承認されましたが、sig-nodeがマージするために追加する必要のあるマイルストーンがありません。 私はそれらをたるんでpingしました、うまくいけばそれは動かなくなり、あなたは例外を必要としません。 =）

このkepのすべてのPRが統合されたようです（そして期限までに承認されました）。拡張機能の追跡シートを更新しました。 ：笑顔：

/マイルストーンクリア

（マイルストーンが完了したら、v1.18マイルストーンからこの拡張機能の問題を削除します）

こんにちは@ nolancon @ lmdaly 、ここで1.19の拡張シャドウ。 1.19でこれについて何か計画はありますか？

1.19で計画されている唯一の拡張機能は次のとおりです。
https://github.com/kubernetes/enhancements/pull/1121

残りの作業は、必要に応じてコードのリファクタリング/バグ修正になります。

この問題の所有者を@lmdalyではなく私に変更する方法はありますか？

ありがとう、連絡先を更新します。

/ milestone v1.19

/ Assign @klueska
/ unassign @lmdaly

これで、Kevin https://prow.k8s.io/command-help

こんにちはケビン。 最近、KEP形式が変更され、＃1620も先週マージされ、KEPテンプレートに本番準備レビューの質問が追加されました。 可能であれば、時間をかけてKEPを再フォーマットし、テンプレートに追加する質問にも答えて

@klueska ^^

@derekwaynecarr @klueska @johnbelamaric
また、1.19relに新しいトポロジポリシーを追加する予定です。
しかし、それはまだ所有者とメンテナによるレビューを受けていません。
（1.19で作成するのが難しいと思われる場合は、お知らせください。）

• KEPアップデートPR： https ：
• kubeletのPR：WIP

こんにちは@ klueska👋1.19ドキュメントシャドウここに！ 1.19で計画されているこの拡張作業には、ドキュメントの新規または変更が必要ですか？

ドキュメントの新規/変更が必要な場合は、6月12日金曜日までにk / website（ブランチdev-1.19 ）に対するプレースホルダーPRが必要になることを覚えておいてください。

こんにちは@klueskaは、あなたがうまくやっていることを願っています。もう一度チェックインして、これにドキュメントが必要かどうかを確認してください。 確認してもらえますか？

こんにちは@annajung。 両方ともドキュメントの変更が必要になる2つの保留中の拡張機能があります。

1121

1752年

これらを1.19にするか、1.20にプッシュするかはまだ決定中です。 それらを1.19の間保持することにした場合、6月12日までにドキュメントのプレースホルダーPRを作成することになります。

素晴らしい！ 更新していただきありがとうございます。それに応じてトラッキングシートを更新します。 プレースホルダーPRが作成されたらお知らせください。 ありがとう！

@lmdaly @ConnorDoyle
ここが質問やフィードバックをするのに適切な場所であることを願っています。

k8sクラスターv1.17でTopologyManagerとCPUManagerオンにします。
そして彼らの方針はbest-effortとstatic
これが私のポッドのリソースです

      resources:
        requests:
          cpu: 2
          intel.com/sriov_pool_a: '1'
        limits:
          cpu: 2
          intel.com/sriov_pool_a: '1'

sriov_pool_aのPFはNUMAノード0にあるため、ポッドはNUMAノード0のCPUでも実行されるはずです。
しかし、ポッドのプロセスがNUMAノード1のCPUで実行されていることがわかりました。
また、 taskset -p <pid>結果に応じて設定されたCPUアフィニティマスクはありません。

何か問題がありますか？ コンテナには、numaノード0のCPUにcpuアフィニティマスクが設定されている必要があります。

TopoloyManagerが正しく機能しているかどうかを知るためにできる例やテストはありますか？

@annajung Placeholder docs PRが追加されました： https ：

こんにちは@klueska 、

月曜日にk-devに送信された電子メールのフォローアップとして、CodeFreezeが7月9日木曜日に延長されたことをお知らせします。 改訂されたスケジュールはここで確認できます： https ：
その時までにすべてのPRが統合されることを期待しています。 ご不明な点がございましたらお知らせください。 😄

一番、
キルステン

こんにちは@klueska 、次の締め切りが迫っていることを友好的に思い出させてくれます。
プレースホルダードキュメントPRにデータを入力し、7月6日月曜日までに確認できるようにしてください。

ありがとう@annajung 。 コードのフリーズが7月9日に移動したので、ドキュメントの日付も前倒しするのは理にかなっていますか？ ドキュメントを作成したが、機能が間に合わなかった場合（またはドキュメントが示唆しているものとは少し異なる形式で作成された場合）はどうなりますか？

こんにちは@klueska 、それは素晴らしいポイントです！ すべてのドキュメントの締め切りも新しいリリース日で1週間延期されましたが、有効なポイントがあると思います。 リリースのドキュメントリードに連絡して、返信させてください。 これを指摘していただきありがとうございます！

こんにちは@klueska 、これを私たちの注意を喚起してくれてありがとう。 リリースのドキュメントの日付と混同されています。 あなたが言ったように、「レビューの準備ができているPR」は、コードがフリーズした後、過去のリリースにあるはずです。

ただし、リリースチームと話し合った後、「PRのレビュー準備完了」を期限として締めることにより、この1.19リリースの日付をそのまま維持することにしました。 ドキュメントチームは柔軟性があり、ドキュメントがコードと同期していることを確認するために余分な時間が必要になる可能性のあるあなた/他の人と協力します。 「PRのレビュー準備完了」の期限は強制されませんが、「PRのレビューと読み取りによるマージ」は強制されます。

これがあなたの懸念に答えるのに役立つことを願っています！ ご不明な点がございましたら、お気軽にお問い合わせください。

また、日付のフレンドリーなリマインダー：
「ドキュメントの締め切り-レビューの準備ができているPR」は7月6日までに締め切られます
「ドキュメントが完了しました-すべてのPRが確認され、マージの準備ができています」の期限は7月16日です。

こんにちは@klueska ：wave：

リリースチームがそれらを追跡できるように、ここですべての実装PRにリンクしてください。 ：slightly_smiling_face：

ありがとう。

@palnabarun
PR追跡https://github.com/kubernetes/enhancements/pull/1121は次の場所にあります。
https://github.com/kubernetes/kubernetes/pull/92665

残念ながら、拡張機能＃1752はリリースに含まれないため、追跡するPRはありません。

こんにちは@klueska ：wave：、あなたが言及した両方のPR（https://github.com/kubernetes/enhancements/pull/1121とhttps://github.com/kubernetes/enhancements/pull/1752）がわかります同じ拡張機能を参照してください。 https://github.com/kubernetes/enhancements/pull/1752はベータ卒業要件を拡張し、リリースには含まれないため、1.19でこれ以上の変更はないと想定できますか？

ありがとう。 ：slightly_smiling_face：

コードフリーズは7月9日木曜日EODPSTに始まります

@palnabarunこれは、今日または明日着陸する＃92665の後続PRです： https ：

その後、予期しないバグが発生するまで、このリリースのPRはなくなります。

素晴らしい！ アップデートありがとうございます。 ：+1：

https://github.com/kubernetes/kubernetes/pull/92794を監視し

@annajunghttps ：//github.com/kubernetes/website/pull/21607これでレビューの準備が整いました。

おめでとうございます@klueskakubernetes / kubernetes＃92794がついに統合されました。それに応じてトラッキングシートを更新します😄

/マイルストーンクリア

（マイルストーンが完了したら、v1.19マイルストーンからこの拡張機能の問題を削除します）

こんにちは@klueska

拡張機能はここをリードします。 これを1.20で卒業する予定はありますか？

ありがとう！
キルステン

卒業する予定はありませんが、この機能強化に関連して1.20で追跡する必要のあるPRがあります。
https://github.com/kubernetes/kubernetes/pull/92967

1.20で卒業していませんが、今行ったように、関連するPRをこの問題にリンクし続けてください。

@kikisdeliveryserviceプロセスを理解するのを手伝ってください。 トポロジマネージャー機能は1.20で卒業していませんが、新しい機能が追加され、現在機能しています：https： //github.com/kubernetes/enhancements/pull/1752 k / k： https：// github。 com / kubernetes / kubernetes / pull / 92967。 これはリリースチームで追跡する必要があるものですか？ 1.20のドキュメントの更新、または追跡されている他の何かの追跡を簡素化する可能性があります。

この変更は付加的なものであるため、beta2などと呼ぶ理由はあまりありません。

追加機能が1.19で出荷されなかったという現実を反映する関連するバンプPR： https ：

Topology Manager WebドキュメントがPRを更新して、スコープ機能を追加します： https ：

1.20で追跡でき、必ずしも卒業する必要はないと思います。 @kikisdeliveryservice正しくない場合は、チャイムを

こんにちは@SergeyKanzhelev

歴史を見ると、これは実際にはそうではありません。 私はこれが上で卒業しないだろうと言われました、それは問題ありません、そしてなぜこのKEPは追跡されていません。 ただし、この拡張機能（拡張機能チームには不明）は、最近@ k-wiatrzykによって1.20のベータ版として再ターゲットされました（https://github.com/kubernetes/enhancements/pull/1950）。

リリースプロセスを活用したい場合：拡張機能の追跡、リリースマイルストーンの一部であり、ドキュメントチームにこれを追跡させる/ドキュメントを1.20リリースに含める場合は、拡張機能の例外リクエストをできるだけ早く提出する必要があります。

この機能は、（拡張期限の前に）（既存の）KEPにすでにマージされています。
https://github.com/kubernetes/enhancements/pull/1752

その実装では、PRはすでにマイルストーンの一部です。
https://github.com/kubernetes/kubernetes/pull/92967

これ以上やるべきことがあるとは知りませんでした。

誰に例外を提出する必要がありますか、そして正確には何のために？

こんにちは@klueskaあなたが参照しているprは、1.19のkepにベータを追加するために6月にマージされました： https ： -manager.md＃beta -v119

1.20の拡張期限は10月6日でしたが、ベータ版を1.20に移動し、1.19への参照を削除するという変更は、3日前にhttps://github.com/kubernetes/enhancements/pull/1950を介してマージされました

例外リクエストを送信する手順については、 https ：

申し訳ありませんが、例外を提出する内容についてはまだ混乱しています。
私はそれを喜んでやっています、私はそれに何を含めるべきかわからないだけです。

「NodeTopologyManager」機能は、1.18ですでにベータ版に移行しています。
1.20ではGAに移行していません（ベータ版のままです）。

1.20でマージされるPR（つまり、kubernetes / kubernetes＃92967）は、トポロジマネージャーの既存のコードを改善したものですが、alpha / beta / gaなどのステータスの点で「バンプ」とは関係ありません。

締め切りが今日なので（念のため）、Call of Exceptionメールを送信しました： https ：

@kikisdeliveryservice @klueska @annajung
例外の呼び出しが承認されました。確認はここで確認できます： https ：

おかげで@ K-wiatrzyk＆@klueska追跡シートを更新しました。

cc： @annajung

ねえ@ k-wiatrzyk @klueska

kubernetes / kubernetes＃92967は承認されているようですが、リベースが必要です。

コードフリーズが11月12日木曜日の2日後に登場することを思い出してください。 すべてのPRはその日付までにマージする必要があります。そうしないと、例外が必要になります。

一番、
キルステン

PRが統合され、シートが更新されました。 ：smile_cat：