機能の説明

• 1行の機能の説明（リリースノートとして使用できます）：
• 主な連絡先（譲受人）：
• 責任あるSIG：
• デザイン提案リンク（コミュニティリポジトリ）： https ：
• レビュー担当者-（LGTMの場合）2人以上のレビュー担当者（コード領域のOWNERSファイルから少なくとも1人）にレビューに同意してもらうことをお勧めします。 複数の企業のレビュー担当者が優先：
• 承認者（機能が属するSIG /エリアからの可能性が高い）：
• 機能ターゲット（どのターゲットがどのマイルストーンに等しいか）：
  
  
  
  • アルファリリースターゲット（xy）
  
  
  • ベータリリースターゲット（xy）
  
  
  • 安定したリリースターゲット（xy）
  
  

#########以下の古いテンプレート

説明

IPvSまたはLVSは、3つの異なる方法で要求をプロキシできるカーネル機能です。ダイレクトルーティングモデルが推奨されるモデルです。

プログレストラッカー

• []アルファ
  
  
  
  • []ドラフト品質のドキュメントを作成して維持する
    
    
    
    
    
    • []開発中は、機能の望ましいエクスペリエンスと、誰かが現在の状態で機能を試す方法について、ドキュメントを最新の状態に保ちます。 これは、新機能のREADMEであり、Kubernetesリリースの前に作成されるドキュメントのスケルトンと考えてください。 Googleドキュメントへのリンクを貼り付けます： DOC-LINK
    
    
    
  
  
  • []設計承認
    
    
    
    
    
    • [x]設計提案。 https://github.com/kubernetes/community/issues/429
    
    
    
    • []この機能のコードをチェックインするリポジトリを決定します。 すべてがコアkubernetesリポジトリに到達する必要はありません。 リポジトリ名
    
    
    
    • []最初のAPIレビュー（APIの場合）。 たぶんデザインドキュメントと同じPR。 プラントル数
    
    
    
    • APIを変更するコード（ /pkg/apis/... ）
    
    
    
    • cc @kubernetes/api
    
    
    
    • []羊飼いを特定します（SIGリードおよび/または[email protected]がお手伝いします）。 私の羊飼いは： _replaceです。 [email protected]_ （および/またはGHハンドル）
    
    
    
    • シェパードとは、機能をリポジトリに取り込むプロセスを理解し、レビュー担当者を特定し、機能に関するフィードバックを提供するのに役立つ個人です。 彼らは（必然的に）機能のコードレビューア、またはその分野の技術リーダーではありません。
    
    
    
    • シェパードは、Kubernetes-PMミーティングに参加したり、機能がリリース目標を達成するために順調に進んでいるかどうかを伝えたりする責任はありません。 それはまだあなたの責任です。
    
    
    
    • []セカンダリ/バックアップの連絡先を特定します。 私の二次連絡先は： _replaceです。 [email protected]_ （および/またはGHハンドル）
    
    
    
  
  
  • []書き込み（コード+テスト+ドキュメント）してから、それらをマージします。 ALL-PR-NUMBERS
    
    
    
    
    
    • []コードはデフォルトで無効にする必要があります。 コードOWNERSによって検証済み
    
    
    
    • []最小限のテスト
    
    
    
    • []最小限のドキュメント
    
    
    
    • ドキュメントPRのcc @kubernetes/docs
    
    
    
    • これをチェックする前に承認を得るために、この問題についてcc @kubernetes/feature-reviewers
    
    
    
    • 新しいAPI：ドキュメントリポジトリの用語集セクションアイテム：kubernetes / kubernetes.github.io
    
    
    
    • []リリースノートを更新
    
    
    
  
  
• []ベータ版
  
  
  
  • []ベータ版にはテストで十分です
  
  
  • []チュートリアル付きのユーザードキュメント
    
    
    
    
    
    • ドキュメントリポジトリのウォークスルー/チュートリアルを
    
    
    
    • ドキュメントPRのcc @kubernetes/docs
    
    
    
    • これをチェックする前に承認を得るために、この問題についてcc @kubernetes/feature-reviewers
    
    
    
  
  
  • []徹底的なAPIレビュー
  
  
  • cc @kubernetes/api
  
  
• [ ] 安定
  
  
  
  • [] docs / options /foo.mdがdocs / design /foo.mdに移動しました
    
    
    
    
    
    • これをチェックする前に承認を得るために、この問題についてcc @kubernetes/feature-reviewers
    
    
    
  
  
  • []ソーク、負荷テスト
  
  
  • []詳細なユーザードキュメントと例
  
  
  • cc @kubernetes/docs
  
  
  • これをチェックする前に承認を得るために、この問題についてcc @kubernetes/feature-reviewers
  
  

FEATURE_STATUSは、機能の追跡に使用され、 @kubernetes/feature-reviewersによって更新されます。
FEATURE_STATUS：IN_DEVELOPMENT

その他のアドバイス：

設計

• @kubernetes/feature-reviewersメンバーからLGTMを取得したら、このチェックボックスをオンにすると、レビュー担当者は「デザイン完了」ラベルを適用します。

コーディング

• 必要な数のPRを使用します。 都合のよいように、同じまたは異なるPRでテストを記述します。
• 各PRがマージされるときに、PRを参照するコメントをこの問題に追加します。 コードはhttp://github.com/kubernetes/kubernetesリポジトリにあります。
  また、 http ：//github.com/kubernetes/contribやその他のリポジトリもあり
• コードが完成したら、「code-complete」ラベルを適用します。
• 機能にユーザードキュメントがある場合は、 @kubernetes/feature-reviewers言及するコメントを追加してください。
  コードが提案された機能と設計に一致していること、すべてが完了していること、および適切なものがあることを確認してください
  テスト。 彼らは詳細なコードレビューを行いません：それはあなたのPRがレビューされたときにすでに起こっています。
  それが完了したら、このボックスをチェックすると、レビュー担当者は「コード完了」ラベルを適用します。

ドキュメント

• []ユーザードキュメントを作成し、それらをマージします。
• ユーザードキュメントはhttp://github.com/kubernetes/kubernetes.github.ioにアクセスし
• 機能にユーザードキュメントがある場合は、 @kubernetes/docs言及するコメントを追加してください。
• LGTMを入手したら、このチェックボックスをオンにすると、レビュー担当者は「docs-complete」ラベルを適用します。