功能描述

• 单行功能说明（可用作发行说明）：
• 主要联系人（受让人）：
• 负责的 SIG：
• 设计提案链接（社区仓库）： https :
• 审阅者 -（对于 LGTM）建议有 2 个以上的审阅者（至少一位来自代码区域 OWNERS 文件）同意进行审阅。 多家公司审稿人优先：
• 批准人（可能来自 SIG/特征所属的区域）：
• 功能目标（哪个目标等于哪个里程碑）：
  
  
  
  • Alpha 发布目标 (xy)
  
  
  • 测试版发布目标 (xy)
  
  
  • 稳定释放目标 (xy)
  
  

#########以下模板已过时

描述

IPvS 或 LVS 是一个内核特性，可以通过 3 种不同的方式代理请求，直接路由模型是首选模型。

进度追踪器

• [ ] Α
  
  
  
  • [ ] 编写和维护质量文档草案
    
    
    
    
    
    • [ ] 在开发过程中，让文档保持最新，了解该功能所需的体验以及人们如何在当前状态下试用该功能。 将其视为新功能的 README，以及在 Kubernetes 发布之前编写的文档框架。 将链接粘贴到 Google 文档： DOC-LINK
    
    
    
  
  
  • [ ] 设计批准
    
    
    
    
    
    • [x] 设计方案。 https://github.com/kubernetes/community/issues/429
    
    
    
    • [ ] 决定将签入此功能代码的存储库。 并非所有内容都需要进入核心 kubernetes 存储库。 回购名称
    
    
    
    • [ ] 初始 API 审查（如果是 API）。 也许与设计文档相同的公关。 公关号码
    
    
    
    • 任何更改 API 的代码 ( /pkg/apis/... )
    
    
    
    • 抄送@kubernetes/api
    
    
    
    • [ ] 确定牧羊人（您的 SIG 负责人和/或 [email protected] 将能够帮助您）。 我的牧羊人是： _replace。 [email protected]_ （和/或 GH 处理）
    
    
    
    • 牧羊人是一个人，他将帮助您熟悉将您的功能放入存储库的过程，识别审阅者并提供有关该功能的反馈。 他们_不是_（必然）该功能的代码审查员，或该领域的技术负责人。
    
    
    
    • 牧羊人_不_负责出席 Kubernetes-PM 会议和/或沟通该功能是否在实现发布目标的轨道上。 那仍然是你的责任。
    
    
    
    • [ ] 确定次要/备用联系人。 我的次要联络点是： _replace。 [email protected]_ （和/或 GH 处理）
    
    
    
  
  
  • [ ] 编写（代码 + 测试 + 文档）然后将它们合并。 ALL-PR-NUMBERS
    
    
    
    
    
    • [ ]默认情况下需要禁用代码。 通过代码 OWNERS 验证
    
    
    
    • [ ] 最少的测试
    
    
    
    • [] 最少的文档
    
    
    
    • 在文档 PR 上抄送@kubernetes/docs
    
    
    
    • 在此问题上抄送@kubernetes/feature-reviewers以获得批准，然后再勾选
    
    
    
    • 新的 api：文档存储库中的术语表部分项目：kubernetes/kubernetes.github.io
    
    
    
    • [ ] 更新发行说明
    
    
    
  
  
• [ ] 测试版
  
  
  
  • [ ] 测试对于 beta 来说已经足够了
  
  
  • [ ] 用户文档和教程
    
    
    
    
    
    • 在文档仓库中更新了演练/教程：kubernetes/kubernetes.github.io
    
    
    
    • 在文档 PR 上抄送@kubernetes/docs
    
    
    
    • 在此问题上抄送@kubernetes/feature-reviewers以获得批准，然后再勾选
    
    
    
  
  
  • [ ] 彻底的 API 审查
  
  
  • 抄送@kubernetes/api
  
  
• [ ] 稳定的
  
  
  
  • [ ] docs/proposals/foo.md 移至 docs/design/foo.md
    
    
    
    
    
    • 在此问题上抄送@kubernetes/feature-reviewers以获得批准，然后再勾选
    
    
    
  
  
  • [ ] 浸泡，负载测试
  
  
  • [] 详细的用户文档和示例
  
  
  • 抄送@kubernetes/docs
  
  
  • 在此问题上抄送@kubernetes/feature-reviewers以获得批准，然后再勾选
  
  

FEATURE_STATUS 用于特征跟踪并由@kubernetes/feature-reviewers 。
FEATURE_STATUS: IN_DEVELOPMENT

更多建议：

设计

• 从@kubernetes/feature-reviewers会员处获得 LGTM 后，您可以选中此复选框，审阅者将应用“设计完成”标签。

编码

• 根据需要使用尽可能多的 PR。 在相同或不同的 PR 中编写测试，这对您来说很方便。
• 当每个 PR 被合并时，在这个问题中添加一个引用 PRs 的评论。 代码位于http://github.com/kubernetes/kubernetes存储库中，
  有时http://github.com/kubernetes/contrib或其他存储库。
• 完成代码后，应用“代码完成”标签。
• 当该功能有用户文档时，请添加提及@kubernetes/feature-reviewers ，他们将
  检查代码是否与提议的功能和设计相匹配，是否一切都已完成，并且有足够的
  测试。 他们不会进行详细的代码审查：这在审查您的 PR 时已经发生了。
  完成后，您可以选中此框，审阅者将应用“代码完成”标签。

文档

• [ ] 编写用户文档并将它们合并。
• 用户文档进入http://github.com/kubernetes/kubernetes.github.io。
• 当该功能有用户文档时，请添加提及@kubernetes/docs 。
• 当您获得 LGTM 时，您可以选中此复选框，审阅者将应用“docs-complete”标签。