与 kubernetes / kubernetes 的交叉引用：问题 # 62822

感谢更新！

/分配@leblancd
/种类特征
/sig 网络
/里程碑 1.11

@leblancd任何可用的设计文档？

/cc @thockin @dcbw @luxas @kubernetes/sig-network-feature-requests

@idvoretskyi - 还没有设计文档，但我们很快就会开始合作。

这是否意味着 Kubernetes Ingress 将支持双栈？
这是否意味着 CNI（Calico）需要运行双栈（例如 BIRD 和 BIRD6 守护进程）？

@sb1975 - 关于双栈入口支持，这是我们需要解决的问题，但这是我的初步想法：

• 双栈入口支持主要取决于您使用的入口控制器（是否支持以及如何实现）。 现有的入口控制器可能需要进行一些更改以支持双栈。
• 我希望典型入口控制器的入口配置不会改变（例如，配置可能仍将 L7 地址映射到服务名称/服务端口，而没有提及 V4/V6 系列）
• 在服务具有双栈端点 pod 的情况下，入口控制器可能需要更改以根据数据包的族映射入口数据包，即将 IPv4 入口数据包映射到 IPv4 端点，并映射 IPv6 入口数据包到 IPv6 端点。 出于负载平衡加权的目的，双堆栈端点应计为单个端点目标。

- 我们可能会考虑 FUTURE 支持跨 V4/V6 系列的入口控制器映射（将入口 IPv4 数据包映射到 IPv6 后端，反之亦然），但我们最初的开发将是严格的双栈（即分离的、独立的）堆栈）。

关于 Calico 和其他 CNI 插件：

• 该CNI插件将不必在双栈模式运行，如果集群场景不需要双协议栈，他们应该仍然能够运行仅支持IPv4或IPv6只（如果该插件支持的话）。
• 双栈支持可能需要更改各种 CNI 插件，但这项工作被认为超出了这个 Kubernetes 问题的范围（我们专注于使 Kubernetes 为任意双栈插件工作，可能使用桥接插件作为参考），CNI 工作将根据具体情况单独完成。
• 特别是对于 Calico，我不是专家，但我相信单个 BIRD 守护程序可以配置为处理 IPv4 和 IPv6 路由（在此处搜索“模板 bgp”：http://bird.network.cz/?get_doc&v= 20&f=bird-3.html#ss3.1)。 也就是说，尽管 Calico 已经在 pod 上支持双栈地址，但可能需要进行一些更改才能使 BGP 路由为两个系列工作。

@leblancd ：所以这里是场景：

1. 假设我们将使用 NGINX 入口控制器
2. 我正在通过 Ingress 公开我的服务。
3. 我正在运行在双栈上配置的 Pod
4. 我正在尝试使用 A 和 AAAA dns-records 远程访问该服务。
   希望所有这些
5. 总结：我想使用 IPv4 或 IPv6 地址连接到 pod 接口，正如我自己对 pod 服务名称的 A 和/或 AAAA 记录的查询所解决的那样。
   我可以参与这项计划以测试、文档、架构：但需要一些指导。
   请问我怎么知道这件事情的进展。

@ sb1975 - 好问题。 具有双栈的 NGINX 入口控制器。 我不是 NGINX 入口控制器的专家（也许更熟悉的人可以加入），但这是我如何看待工作流程：

• 当您尝试从外部访问 Kube 服务时，您的 DNS 控制器应使用入口控制器的 A 和 AAAA DNS 记录解析服务。 使用 A 与 AAAA 记录来到达入口控制器是您的客户端/应用程序的选择。 因此，对入口控制器的外部访问将是双栈的。
• 在 NGINX 入口控制器，NGINX 然后会查看 L7 URL（无论请求是在 IPv4 还是 IPv6 数据包中）并将其负载均衡到上游端点。 如果入口控制器负载均衡器配置为 ipv6=on（这是默认值，请参阅 https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns)，并且服务端点是双栈的，那么上游配置应该有每个双栈端点的 IPv4 和 IPv6 条目。 按照设计，NGINX 负载均衡器将端点的 IPv4 条目和 IPv6 条目视为单独的服务器。 （请参阅上述文档中的“如果一个域名解析为多个 IP 地址，这些地址将保存到上游配置中并进行负载平衡。”）这可以被认为是好消息或坏消息。 好消息是负载平衡将在 IPv4 和 IPv6 端点之间完成（为您提供一些冗余），例如传入的 IPv4 请求可以映射到 IPv4 或 IPv6 端点。 但潜在的坏消息是负载平衡粒度：到 IPv4 端点的连接和到相应 IPv6 端点的连接将被视为（出于负载平衡考虑）对单独端点的 2 个负载，而不是对同一端点的 2 个单独负载. 如果这个负载平衡粒度是一个问题，那么有人可以禁用到 IPv6（或到 IPv4，如果有一个配置旋钮？）的负载平衡，这样负载平衡将是到 IPv4-only 端点。 或者，也许可以修改 NGINX 负载均衡器以将到 IPv4 地址的连接和到其相应 IPv6 地址的连接视为到同一端点的 2 个负载。

至于帮助和参与，这将不胜感激！ 我们即将开始认真研究双栈（由于让 CI 仅适用于 IPv6 的工作有点延迟）。 我希望很快就可以为规范（Google Doc 或 KEPs WIP 文档）提供一个大纲，并且会寻求帮助进行审查，并且可能会写一些部分。 我们还绝对需要官方文档（超出设计规范）以及定义和实施双栈 E2E 测试的帮助。 我对设计仍然有点粗略的一些领域包括：

• 双栈如何影响或处理健康/活跃度/就绪性探测器
• 是否会影响网络策略？
• 负载均衡器问题？
• 云提供商插件问题？
• L3/L4 入口问题？
  如果您考虑过其中任何一个，也许您可​​以对这些部分提供帮助？

我们也在考虑一种中间的“边缘双栈”（集群内部仅使用 IPv6）方法，其中从集群外部到 K8s 服务的访问将是双栈的，但这将被映射（例如通过 NGINX入口控制器）到集群内的仅 IPv6 端点（或使用无状态 NAT46）。 集群中的 Pod 和服务需要全是 IPv6，但最大的优势是从上市时间的角度来看，双栈外部访问将更快地可用。

/里程碑 1.12

@leblancd / @caseydavenport - 我注意到这里有很多讨论和里程碑式的变化。
这应该从 1.11 里程碑中拉出来吗？

@justaugustus - 是的，这应该移到 1.12。 我是否需要删除发布电子表格中的一行，或者我需要做些什么来改变它？

@leblancd我已经解决了。 感谢关注！ :)

@leblancd @kubernetes/sig-network-feature-requests --

此功能已从之前的里程碑中删除，因此我们想查看 Kubernetes 1.12 中是否有任何计划。

如果是这样，请确保此问题与以下所有信息保持同步：

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

设置以下内容：

• 描述
• 受让人
• 标签：
  
  
  
  • 阶段/{alpha,beta,stable}
  
  
  • 签名/*
  
  
  • 种类/特征
  
  

请注意，功能冻结是 7 月 31 日，之后任何未完成的功能问题都需要一个例外请求才能被接受到里程碑中。

此外，请注意以下相关截止日期：

• 文档截止日期（开放占位符 PR）：8/21
• 测试用例冻结：8/28

请确保所有功能的 PR 也包含相关的发行说明。

祝您发货愉快！

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

@leblancd--
功能冻结是今天。 您是否打算将其升级为 Kubernetes 1.12 中的 Beta？
如果是这样，您能否确保所有内容都是最新的，以便我可以将其包含在 1.12 功能跟踪电子表格中？

嗨@justaugustus - Beta 状态需要进入 Kubernetes 1.13。 我们正在（尽管缓慢）设计 KEP (https://github.com/kubernetes/community/pull/2254) 上取得进展，并且我们即将重新参与 CI 测试 PR，但 Kubernetes 1.12目标有点太乐观了。

我将使用您之前请求的信息更新上面的描述/摘要。 感谢您的耐心等待。

/删除阶段阿尔法
/stage 测试版

不用担心，@leblancd。 感谢更新！

嗨， @ justaugustus @leblancd

我刚刚阅读了有关双堆栈的测试版已移至 1.13 的更新。 1.13 的预期发布日期是什么时候？ 我们实际上正在寻找双栈支持。 对于我们的产品转移到容器中，这是一个不折不扣的决定。

@navjotsingh83 - 我认为 Kubernetes 1.13 的发布日期尚未确定。 我没有看到Kubernetes 发布文档中列出了 1.13。

@navjotsingh83 @leblancd 1.13 发布时间表已发布。 它的发布周期很短，代码在 11 月 15 日冻结。 您认为时间足以将此功能升级为 Beta 版。 您能否以您的信心更新这个问题，在代码、测试和文档完成方面有什么待处理？

根据 SIG 网络会议上的讨论，尽管在 1.13 中将针对此功能进行大量工作，但预计不会在 1.13 中进入 Beta。 相应地删除里程碑。

/里程碑清除

@kacole2将其从 1.13 增强电子表格中删除

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
过时的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

/remove-lifecycle 陈旧

@leblancd你好 - 我是 1.14 增强功能的负责人，我正在检查这个问题以查看 1.14 版本计划进行哪些工作（如果有）。 增强功能冻结是 1 月 29 日，我想提醒所有增强功能都必须有一个 KEP

@leblancd想要跟进您之前关于在集群边缘为 IPv4/IPv6 创建描述的评论：

“我们也在考虑一种中间的“边缘双栈”（集群内仅使用 IPv6）方法，其中从集群外部到 K8s 服务的访问将是双栈的，但这将被映射（例如通过NGINX 入口控制器）到集群内的纯 IPv6 端点（或使用无状态 NAT46）。 集群中的 Pod 和服务需要全是 IPv6，但最大的优势是从上市时间的角度来看，双栈外部访问将更快地可用。”

这个用例对于当前的项目来说是一个很好的用例，所以想看看你对时间框架的想法，看看我自己或我们团队中的某个人是否可以为加快上市时间做出贡献。

@KevinAtDesignworx如果边缘双栈但仅限内部 ipv6 的方法仍然可以从容器内部（即curl -v 93.184.216.34 -H "Host: example.com" ）访问外部 ipv4 请求，我真的认为这是最好的方法。 如果您的基础设施可以使用 ipv6，那么出于兼容性原因，为什么还要在边缘使用 ipv4。 但是，如果这种方法意味着我无法从集群内部仅使用 ipv4 访问旧网站，那么我就不太确定了。

好吧，有 464XLAT，因此仅在容器内使用 ipv6 才可行。

@KevinAtDesignworx - 如果在您的场景中使用入口控制器，则可以从外部配置 NGINX 入口控制器以进行双栈操作（代理到集群内的单族）： https :

入口控制器需要在每个节点的主机网络上运行，因此控制器需要设置为守护进程（每个节点上一个入口控制器）。 这假设：

• 您的节点是双栈的（而不是 pod 和服务是单系列的）
• 每个节点上的 /etc/hosts 都有 IPv6 条目，并且该节点的主机名只有 IPv6 条目（没有 IPv4 地址）。

这将是 NAT64/DNS64 的补充，用于从集群内的 V6 客户端连接到外部仅支持 IPv4 的服务器。

无状态 NAT46 也是一种选择，但我还没有尝试过，所以我没有任何配置指南。

@leblancd这里有计划为 1.15 做的工作吗？ 目前看来 KEP 还没有被接受。 谢谢！

@leblancd想要跟进您之前关于在集群边缘为 IPv4/IPv6 创建描述的评论：

“我们也在考虑一种中间的“边缘双栈”（集群内仅使用 IPv6）方法，其中从集群外部到 K8s 服务的访问将是双栈的，但这将被映射（例如通过NGINX 入口控制器）到集群内的纯 IPv6 端点（或使用无状态 NAT46）。 集群中的 Pod 和服务需要全是 IPv6，但最大的优势是从上市时间的角度来看，双栈外部访问将更快地可用。”

这个用例对于当前的项目来说是一个很好的用例，所以想看看你对时间框架的想法，看看我自己或我们团队中的某个人是否可以为加快上市时间做出贡献。

从容器内部（只有 ipv6）向集群外部发送 curl 请求（即 curl -v 93.184.216.34 -H "Host: example.com"）。 我认为它会给出未知目的地或目的地不可达的错误，除非在容器所在的主机上存在 ipv4 路由。

@GeorgeGuo2018如果 k8s 实现 DNS64/NAT64，它会起作用。 这在很大程度上取决于 k8s 将进入 464xlat/plat 解决方案的程度以及需要在边缘路由器等处处理的内容......

实际上，我认为通过在 kube-system 命名空间内使用使用主机网络和 Tayga 的 DaemonSet/Deployment 是可能的，这样内部 DNS64 将使用 tayga 进入网络外部。

对我来说听起来像是一个解决方案。

我们在内部运行一个纯 IPv6 网络，NAT64/DNS64 对我们来说效果很好。 对于一些根本不支持 IPv6 的遗留内容，我们最终在需要的地方直接使用了 clatd。 （在我们的例子中直接在 VM 上。）

@kacole2 - 我想在 1.15 上跟踪这个。 我正在努力合并以下 PR - https://github.com/kubernetes/enhancements/pull/808

特别是对于 1.15，我们将添加对以下内容的支持：

• API 类型修改
  
  
  
  • Kubernetes 类型
  
  
  • CRI 类型
  
  
• 双栈 Pod 网络（多 IP Pod）
• kubenet 多家庭支持

cc @caseydavenport用于里程碑跟踪 ^

@kacole2 KEP 现在已合并。 让我知道是否还有其他需要在 1.15 中进行跟踪

嘿@leblancd @lachie83 友情提示，我们正在寻找一个 PR 对 k/website (branch dev-1.15) 截止日期为 5 月 30 日星期四。如果它是完整文档的开始，那就太好了，但即使是占位符PR是可以接受的。 如果您有任何问题，请告诉我！

@kacole2 KEP 现在已合并。 让我知道是否还有其他需要在 1.15 中进行跟踪

@lachie83嗨，Lachie，你是说这个 KEP 的 IPv4/IPv6 双栈支持已经完成了吗？

@kacole2 KEP 现在已合并。 让我知道是否还有其他需要在 1.15 中进行跟踪

实际上，我想弄清楚k8s 1.15中是否肯定会添加双栈支持。

@leblancd针对 k8s.io dev-1.15 的占位符 PR 将于 5 月 30 日星期四到期。

@leblancd针对 k8s.io dev-1.15 的占位符 PR 将于 5 月 30 日星期四到期。

我可以考虑在 1.15 版中提供双栈支持吗？

@GeorgeGuo2018它仍然在 1.15 的增强表上，但只有增强负责人@kacole2可以为您提供更好的细节。

嗨@lachie83 @leblancd。 代码冻结时间为 2019 年 5 月 30 日星期四@ EOD PST 。 发布的所有增强功能都必须是代码完整的，包括测试，并打开文档 PR。

请列出所有当前的 k/k PR，以便可以跟踪它们进入冻结状态。 如果 PR 未通过冻结合并，则此功能将在 1.15 发布周期中滑动。 里程碑中只允许发布阻止问题和 PR。

我看到原帖中的 kubernetes/kubernetes#62822 仍然是开放的。 我们还希望合并其他 PR 吗？

如果您知道这会滑倒，请回复并告诉我们。 谢谢！

@simplytunde - 抬起头来。 本周我正在努力将文档 PR 放在一起。

@GeorgeGuo2018 - 这将是一个多版本的 KEP。 我们计划在 1.15 中登陆第一阶段。 更多细节请查看 KEP 中的实施计划 - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -计划。

@simplytunde - 我在这里创建了初始占位符文档 PR，其中包含 WIP https://github.com/kubernetes/website/pull/14600。 我计划在接下来的几天内完成并准备好进行审查。

@kacole2感谢您的 ping。 我已经使用我们正在跟踪的 k/k PR (https://github.com/kubernetes/kubernetes/pull/73977) 以及文档 PR (https://github.com/ kubernetes/website/pull/14600）。 我们目前仍在按计划在代码冻结之前合并此 PR。 LMK 如果我还缺少其他任何东西

@kacole2在与@claurence和发布团队讨论后，我们决定将其从 1.15 里程碑中删除。 请继续删除它并根据需要更新电子表格。 感谢您到目前为止的所有帮助。

/里程碑清除

@simplytunde我也对文档 PR 发表了评论。 你能确保它也从 1.15 里程碑中删除吗？

嗨@lachie83 @leblancd ，我是1.16 增强阴影。 这个功能会在 1.16 中从 alpha/beta/stable 阶段毕业吗？ 请告诉我，以便将其添加到1.16 跟踪电子表格中。

里程碑日期是 Enhancement Freeze 7/30 和 Code Freeze 8/29。

谢谢你。

https://github.com/kubernetes/dns/issues/315涵盖将 IPv6/AAAA 添加到DNS 服务发现规范。

@lachie83 @leblancd知道这是否会在 1.16 毕业以跟踪它吗？

@evillgenius75 @kacole2这需要在 1.16 中进行跟踪。 此功能将处于 alpha 状态。 我们将实施 KEP 中定义的第 1 阶段和第 2 阶段是 1.16

跟踪 KEP

• https://github.com/kubernetes/enhancements/pull/808

合并的 k/k PRs（目前在 master 将在 1.16）

• [已合并] 第一阶段 - https://github.com/kubernetes/kubernetes/pull/73977
• [已合并] 第一阶段 e2e 测试 - https://github.com/kubernetes/kubernetes/pull/78801
• [已合并] 第一阶段 e2e 测试清理 - https://github.com/kubernetes/kubernetes/pull/80001
• 第 2 阶段服务/端点 - https://github.com/kubernetes/kubernetes/pull/79386
• 阶段 2 kube-proxy - https://github.com/kubernetes/kubernetes/pull/79576

相关 PR

• 支持 IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• 第 1 阶段文档——将在我们完成工具示例后重新开放 - https://github.com/kubernetes/website/pull/14600
• [已合并] 清理 - 节点 dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• 支持集群 cidrs 的多个掩码大小 - https://github.com/kubernetes/kubernetes/pull/79993
• 双栈的 E2e Prow 工作https://github.com/kubernetes/test-infra/pull/12966

嘿， @leblancd我是 v1.16 文档发布负责人。

此增强功能（或为 v1.16 计划的工作）是否需要任何新文档（或修改）？

友情提示，我们正在寻找 8 月 23 日星期五到期的针对 k/website（分支 dev-1.16）的 PR。 如果它是完整文档的开始，那就太好了，但即使是占位符 PR 也是可以接受的。 如果您有任何问题，请告诉我！

@simplytunde这里是文档公关 - https://github.com/kubernetes/website/pull/16010

@ lachie83 1.16 的友好提醒代码冻结时间为 8/29 星期四。 （好像你不知道一样）。 看起来这些 PR 还是很突出的：
阶段 2 服务/端点 - kubernetes/kubernetes#79386
阶段 2 kube-proxy - kubernetes/kubernetes#79576

联系：
支持集群 cidrs 的多个掩码大小 - kubernetes/kubernetes#79993
双栈 kubernetes/test-infra#12966 的 E2e Prow 作业

嗨@lachie83 @leblancd它看起来好像https://github.com/kubernetes/kubernetes/pull/79576和https://github.com/kubernetes/kubernetes/pull/79993在代码冻结之前没有合并，它不是在潮汐合并池中。 此功能将从 v1.16 开始。 如果您仍希望将其作为 1.16 版本的一部分，请提交例外

@kacole2对响应延迟https://github.com/kubernetes/kubernetes/pull/79386。 至于 kubernetes/kubernetes#79576，我们决定将其推迟到 1.17，而是专注于https://github.com/kubernetes/kubernetes/pull/82091 （与 sig-network 一致），它实现了相同的第二阶段目标已在 KEP 中列出。 此版本中跟踪的另一个相关 PR 是https://github.com/kubernetes/kubernetes/pull/80485 ，它也被合并。 kubernetes/kubernetes#79993 也被推迟到 1.17

嘿@lachie83 @leblancd -- 1.17 增强功能在这里。 我想检查一下，看看您是否认为此增强功能会在 1.17 中升级为 alpha/beta/stable？

目前的发布时间表是：

• 9 月 23 日，星期一 - 发布周期开始
• 10 月 15 日，星期二，EOD PST - 增强功能冻结
• 太平洋标准时间 11 月 14 日星期四，EOD - 代码冻结
• 11 月 19 日，星期二 - 必须完成和审查文档
• 12 月 9 日星期一 - Kubernetes 1.17.0 发布

如果您这样做，请列出本期所有相关的 k/k PR，以便正确跟踪它们。 👍

谢谢！

/里程碑清除

嗨鲍勃。 感谢您伸出援手。 我仍在计划此增强功能的第 3 阶段，这将完成增强功能。 此增强功能在此版本结束时仍处于 alpha 阶段，但将有第 3 阶段相关工作将作为 1.17 的一部分登陆 k/k。

以下是双栈 1.17 的高级可交付成果列表。 我将在整个发布过程中更新此列表。

• IPtables 双栈代理 - https://github.com/kubernetes/kubernetes/pull/79576
• Pod.Status.PodIPs 的向下 api 支持 - https://github.com/kubernetes/kubernetes/pull/83123
• e2e 测试一个 CNI 插件
• 主机文件更改（需要添加主机名的 IPv6 地址 /etc/hosts） - https://github.com/kubernetes/kubernetes/pull/83123
• Kind 双栈 - https://github.com/kubernetes-sigs/kind/pull/692
• 更新 e2e 套件 - https://github.com/kubernetes/kubernetes/pull/80725
• 端点切片支持
• Kubeadm 的双栈支持 - https://github.com/kubernetes/kubeadm/issues/1612

非常感谢，谢谢@lachie83 ❤️ 我会继续将其添加到跟踪表中。

/里程碑 v1.17

@mrbobbytables在通过 sig-network 传达计划后，我还添加了一个PR来详细说明上面列出的工作，作为 KEP 第 3 阶段的一部分。 KEP 本身仍处于implementable状态，这些更改只是专门将计划工作记录为 1.17 的一部分。

在某些时候，我想确保https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/涵盖 IPv6 DNS。 https://github.com/kubernetes/website/issues/15434跟踪变化； 在这里提到它是为了注意交叉引用。

更新了 KEP 以添加第 2 阶段 e2e 测试 - https://github.com/kubernetes/enhancements/pull/1311

你好@ lachie83我是 v1.17 文档影子之一。
此增强（或 v1.17 计划的工作）是否需要任何新文档（或对现有文档的修改）？ 如果没有，您能否更新 1.17 增强跟踪表（或让我知道，我会这样做）

如果是这样，只是一个友好的提醒，我们正在寻找在 11 月 8 日星期五之前针对 k/website（分支 dev-1.17）的 PR，它此时可以只是一个占位符 PR。 如果您有任何问题，请告诉我！

@ lachie83

由于我们即将在 11 月 8 日临近 Docs 占位符 PR 截止日期。 请尝试在 k/website dev-1.17 分支中获取一个。

嘿@ lachie83 ，我知道你一直在关注标签，但我还是需要进来提一下 🙈
代码冻结即将到来（11 月 14 日）。 情况如何？ 在此之前一切都在按计划合并吗？

谢谢！

嘿@mrbobbytables！ 谢谢你的ping。 我们正在跟踪以下 PR 以在 1.17 中登陆。 可能还会有一个或两个与此更改相关的 PR。 这些更改将需要文档。 我将提出一个占位符文档 PR

• 双栈支持 kube-proxy iptables 模式 pr/82462
• Dualstack 向下 api pr/82462
• 添加 ipvs metaproxier endpointslice 支持 pr/84089
• 在 kube-controller-manager pr/79993 中允许多个节点 cidr 掩码

@irvifa - 这是占位符文档 PR。 https://github.com/kubernetes/website/pull/17457

很酷，谢谢 🎉 @lachie83

@ lachie83明天是 1.17 发布周期的代码冻结。 看起来 k/k PR 尚未合并。 😬 我们在 1.17 增强跟踪表中将此标记为存在风险。
你认为他们会被14日（星期四）的EoD合并吗？ 在那之后，里程碑中将只允许发布阻止问题和 PR，但有例外。

谢谢 Bob - 今天我将与 sig-network 讨论这个问题，并将提供更新。

嘿@mrbobbytables。 这是我们今天正在努力由 EoD 合并并已获得 sig-network 批准的 PR 列表。

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

剩下的 PR 很可能会被推到 1.18 - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables只是确认上面所有声明的 PR 都已合并，并且我们确实要将 kubernetes/kubernetes#82462 推到 1.18。 由于这些 PR 为 1.17 中的双栈行为添加了意义更改，因此仍然可以跟踪此增强功能。 现在我只需要准备好文档 PR！ 我们希望在 1.18 中登陆 kubernetes/kubernetes#82462 并将这项工作推进到测试版

太好了，谢谢@lachie83！

它是活的！ https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

我们计划在 1.18 中将此增强功能移至测试版。 增强毕业标准和测试计划可以在KEP 中与此 PR 一起找到 - https://github.com/kubernetes/enhancements/pull/1429

/里程碑 1.18

@ lachie83 ：提供的里程碑对于此存储库无效。 此存储库中的里程碑： [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

使用/milestone clear清除里程碑。

/里程碑 v1.18

我们计划在 1.18 中将此增强功能移至测试版。 可以在KEP 中找到增强毕业标准和测试计划以及此 PR - #1429

感谢@lachie83的更新，我已在 1.18 电子表格中将此标记为已跟踪！

请跟踪以下 PR 作为在 1.18 中登陆的工作的一部分。 https://github.com/kubernetes/kubernetes/pull/82462

添加其他相关 PR 进行跟踪：
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

谢谢@lachie83！

嗨@ lachie83 ，除了上面提到的，你还有其他我们应该跟踪的 PR 吗？

你好， @lachie83 @leblancd - 我是 1.18 发布团队的 Docs 影子。

为 1.18 计划的这项增强工作是否需要任何新文档或对现有文档的修改？

如果没有，您能否更新 1.18 增强跟踪表（或让我知道，我会这样做）

如果需要更新文档，请提醒针对 k/website（分支 dev-1.18）的占位符 PR 应在 2 月 28 日星期五之前到期。

如果您有任何问题，请告诉我！

如果有人需要帮助记录 v1.18 的 IPV6 或双栈内容，请轻推我一下。 我也许能帮上忙。

嘿@lachie83 ，

看起来 kubernetes-sigs/kind#692 尚未合并。 这对您的 Beta 版毕业很重要吗？

嘿@jeremyrickard @sethmccombs ，鉴于此 PR https://github.com/kubernetes/kubernetes/pull/86895，我们将不得不将其从毕业到测试版

/里程碑清除

@ lachie83感谢您的更新。 我已从里程碑中删除了此增强功能。 期待1.19的这个。 :)

我想确认双栈增强的状态在 1.18 中保持在alpha 。 我目前正在与社区合作评估计划在 1.19 中完成的工作。 此增强功能可能仍会在 1.19 中保持 alpha 状态，但我想确认一下。 我还将采取措施更新文档以反映 1.18 文档中的增强状态。

如果网站上有页面将双栈 Kubernetes 显示为 beta，请将这些页面作为优先/重要的 bug 提交到

嗨@ lachie83 -- 1.19 增强功能 领导这里，我想检查一下您是否认为此增强功能会在 1.19 中毕业？

目前的发布时间表是：

• 4 月 13 日，星期一：第 1 周 - 发布周期开始
• 5 月 19 日，星期二：第 6 周 - 增强功能冻结
• 6 月 25 日星期四：第 11 周 - 代码冻结
• 7 月 9 日，星期四：第 14 周 - 必须完成并审核文档
• 8 月 4 日，星期二：第 17 周 - Kubernetes v1.19.0 发布

如果网站上有页面将双栈 Kubernetes 显示为 beta，请将这些页面作为优先/重要的 bug 提交到

@sftim我提出了两个 PR 来解决 1.17 和 1.18 中的发布标签

@palnabarun我们正在努力在 1.19 发布时间范围内更新双栈 KEP，但是我们目前认为我们不会在 1.19 版本中进行代码更改。 我们已经完成的工作有一个阻塞问题（由于它处于alpha状态）。 阻塞问题是https://github.com/kubernetes/kubernetes/pull/86895。 我们计划通过以下 KEP 更新https://github.com/kubernetes/enhancements/pull/1679来解决这个问题，但就提议的更改达成共识需要时间。 在这个阶段，双栈增强将保持在alpha状态，直到我们用当前的实现解决这个阻塞问题。 我会随着事情的进展提供更新。

谢谢你，Lachie 的更新。 我感谢所有的努力！ :slightly_smiling_face:

问题在 90 天不活动后变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
过时的问题在额外 30 天不活动后腐烂并最终关闭。

如果现在可以安全关闭此问题，请使用/close关闭。

向 sig-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

/remove-lifecycle 陈旧

我们希望在 1.20 中跟踪此增强功能。 它将根据更新的 kep - https://github.com/kubernetes/enhancements/pull/1679在 alpha 状态下重新实现https://github.com/kubernetes/kubernetes/pull/91824。 我们计划在 1.20 发布周期的早期完成审查并合并 PR。

在 9 月 17 日的 SIG 网络会议上讨论了最新的双栈升级到 Beta 状态，对于那些在家玩的人：

• 必须解决kubelet双栈健康检查歧义； 通过https://github.com/kubernetes/enhancements/pull/1975
• 必须完成并合并现有的双栈服务 PR（正在积极审查中）； 通过https://github.com/kubernetes/kubernetes/pull/91824
• 必须最终确定双栈节点 IP 的行为； 通过https://github.com/kubernetes/enhancements/pull/1665
• 应确定服务的 Spec.LoadBalancerIPs 字段需要哪些（如果有）更改

所有这些项目都在积极进行中，1.20 仍然是双栈 API Beta 毕业的目标。 然而，尽管我们尽了最大的努力，总会有一些事情无法及时解决，如果是这样，SIG Network 将在我们的公开会议上决定是否继续升级到 Beta。 欢迎大家加入。

@dcbw非常感谢您的更新（对不起，我无法拨打电话）。 在 1.20 中将其增强为 beta 或只是保持在 alpha 中是否有意义？ 如果我们想进入测试版，那么 KEP 中的毕业标准是否仍然有意义，因为这是一个重新实现https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#graduation -criteria

@dcbw非常感谢您的更新（对不起，我无法拨打电话）。 在 1.20 中将其增强为 beta 或只是保持在 alpha 中是否有意义？ 如果我们想进入测试版，那么 KEP 中的毕业标准是否仍然有意义，因为这是一个重新实现https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#graduation -criteria

不过，这并不是真正的重新实现。 之前的所有工作仍然有效，1.20 中的工作正在建立在它之上，以完成已确定的最后所需更改。 我对 sig-network 讨论的解释是， @dcbw发布的列表是毕业时需要解决的剩余已知问题集。

大家好，

1.20 增强功能在这里，我要将其设置为已跟踪，如果有任何更改，请更新我:)

提醒一下，增强功能冻结是 10 月 6 日。

请注意，KEP 使用的是旧格式，我们已更新为： https :

最好的事物，
克尔斯滕

/里程碑 v1.20

嗨， @russellb -

不过，这并不是真正的重新实现。 之前的所有工作仍然有效，1.20 中的工作正在建立在它之上，以完成已确定的最后所需更改。

鉴于 https://github.com/kubernetes/kubernetes/pull/91824 中的 API 更改，将双栈标记为 1.20 的 alpha 将为任何进一步的重新实现留出空间，这已经足够不同了。 我知道我们都渴望测试版，但让我们先用+9,319 −3,261登陆 PR 并让一切尘埃落定。 :)

鉴于kubernetes/kubernetes#91824 中的 API 变化，将留出空间，这已经足够了。 我知道我们都渴望测试版，但让我们先用+9,319 −3,261登陆 PR 并让一切尘埃落定。 :)

@bridgetkromhout是的，我们需要先登陆https://github.com/kubernetes/kubernetes/pull/91824，然后才能对 API 准备情况做出任何决定。 我真的希望我们能尽快做到这一点。

大家好，

1.20 增强阴影在这里👋

由于此增强功能计划在 1.20 中发布，因此请记住以下重要的即将到来的日期：
11 月 6 日，星期五：第 8 周 - Docs Placeholder PR 截止日期
11 月 12 日星期四：第 9 周 -代码冻结

提醒一下，请将您所有的 k/k PR 以及 docs PR 链接到此问题，以便我们可以跟踪它们。

谢谢！

嗨@kinarashah @kikisdeliveryservice - 我已经在 sig-network 电话中确认我们需要将其重新分类为 1.20 的 alpha。 这是一个完整的重新实现，需要时间浸泡并在 alpha 阶段进行测试。

你好@ lachie83 ，1.20 Docs 影子在这里。

为 1.20 计划的这项增强工作是否需要任何新文档或对现有文档的修改？

如果是这样，请按照此处的步骤针对k/website库中的dev-1.20分支打开 PR。 这个 PR 目前可以只是一个占位符，必须在11 月 6 日之前创建。

另请查看发布的文档，以熟悉

谢谢！

谢谢@reylejano-rxm - 我们已经打开了 kubernetes/website#24725

嗨@ lachie83

感谢您创建文档 PR！

请记住即将到来的重要日期：

• 11 月 6 日，星期五：第 8 周 - Docs Placeholder PR 截止日期完成！
• 11 月 12 日星期四：第 9 周 -代码冻结
• 11 月 23 日，星期一：第 11 周 - Docs PR 准备审核

提醒一下，请将您所有的 k/k PR 以及文档 PR 链接到此问题，以便发布团队进行跟踪。

嗨@kinarashah @kikisdeliveryservice - 我已经在 sig-network 电话中确认我们需要将其重新分类为 1.20 的 alpha。 这是一个完整的重新实现，需要时间浸泡并在 alpha 阶段进行测试。

嘿@ lachie83

鉴于上述情况，我认为这仍然适用于 alpha 版本？ 我没有看到任何需要合并/工作已经合并的未完成 PR。

_只是提醒一下， Code Freeze将于 11 月 12日例外。_

谢谢！
克尔斯滕

嗨， @kikisdeliveryservice - 是的，IPv4/IPv6 双栈支持（重新实现）将在 1.20 成为 alpha 版本。

以下是我们在此增强功能方面的进展：

1) 代码从 https://github.com/kubernetes/kubernetes/pull/91824 合并 - 将是 1.20 的 alpha
2) 涵盖该代码更改的文档更新位于https://github.com/kubernetes/website/pull/24725/ - 审查并合并到 dev-1.20 分支

1.20 中是否还有其他我们尚未完成的增强功能？

@bridgetkromhout感谢您的清晰更新，你们都很好！

看起来ServiceSpec LoadBalancerIP还不是双栈实现的一部分。 是否有任何计划支持它或我错过了它？

嗨@chenwng -https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#load -balancer-operation。

您可以通过提供您的用例和建议的更改来帮助理解和决定我们是否需要对 KEP 进行任何修改。

@chenwng在LoadBalancerIPs的 KEP 正在开发中 - https://github.com/kubernetes/enhancements/pull/1992

感谢您的信息，@aramase，@ lachie83。