@lavalamp我创建这个是为了尝试有一个地方，我们至少可以在那里整合我们的想法并跟踪第三方资源的进度。 我试图创建一个列表，列出在升级到稳定版之前要解决的已知缺陷。

我心中没有所有者，但认识到问题似乎是第 1 步。

@deads2k我最近在学习第三方资源，也想帮帮忙。

@deads2k我最近在学习第三方资源，也想帮帮忙。

我根据我认为的战术优先级重新排列了列表。 人们现在正在尝试使用它，这些问题会严重影响它们。

如果您愿意接受“多种资源”项目，那将是一个很好的开始。 你可以创建一个单独的问题，我们可以在那里讨论实施。

@deads2k我花了一些时间试图重现第一个问题：

Multiple Resources, single version, different add times - Adding resource A, waiting for it to appear, then adding resource B fails. Resource B is never added.

但运气不好。 以下是我的重现步骤：

1. 创建自定义第三方资源并等待它出现

[root<strong i="12">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/lbclaim.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancerclaim.k8s.io
description: "Allow user to claim a loadbalancer instance"
versions:
- name: v1
[root<strong i="13">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/lbclaim.yaml
thirdpartyresource "loadbalancerclaim.k8s.io" created
[root<strong i="14">@localhost</strong> kubernetes]# curl  http://localhost:8080/apis/extensions/v1beta1/thirdpartyresources/
{
  "kind": "ThirdPartyResourceList",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/",
    "resourceVersion": "170"
  },
  "items": [
    {
      "metadata": {
        "name": "loadbalancerclaim.k8s.io",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/loadbalancerclaim.k8s.io",
        "uid": "dcb88b3a-9857-11e6-a19b-08002767e1f5",
        "resourceVersion": "146",
        "creationTimestamp": "2016-10-22T13:03:01Z"
      },
      "description": "Allow user to claim a loadbalancer instance",
      "versions": [
        {
          "name": "v1"
        }
      ]
    }
  ]
}

1. 片刻（10 多秒）后，创建另一个自定义第三方资源

[root<strong i="19">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/loadbalancer.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancer.k8s.io
description: "Allow user to curd a loadbalancer instance"
versions:
- name: v1
[root<strong i="20">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/loadbalancer.yaml
thirdpartyresource "loadbalancer.k8s.io" created

1. 验证两个资源都存在

[root<strong i="25">@localhost</strong> kubernetes]# curl http://localhost:8080/apis/k8s.io/v1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "k8s.io/v1",
  "resources": [
    {
      "name": "loadbalancerclaims",
      "namespaced": true,
      "kind": "Loadbalancerclaim"
    },
    {
      "name": "loadbalancers",
      "namespaced": true,
      "kind": "Loadbalancer"
    }
  ]
}
[root<strong i="26">@localhost</strong> kubernetes]# kc get loadbalancers
No resources found.
[root<strong i="27">@localhost</strong> kubernetes]# kc get loadbalancerclaims
No resources found.

似乎我们已经支持多种资源，单一版本。

我深入研究了 TPR 相关代码。 thirdparty_controller会定期同步（每 10 秒），它会安装每个新的 TPR，还会做一些删除工作。 ThirdPartyResourceServer包含所有已安装的 TPR 映射。 从SyncOneResource和InstallThirdPartyResource可以看出，即使这个组存在，它仍然会使用新的 API 更新该组。

我还发现即使系统中有 TPR 实例，我也可以删除 TPR 架构定义。 我认为这不应该被允许。

@deads2k我花了一些时间试图重现第一个问题：

尝试启用此测试： https :

@deads2k嗨，大卫，请看一下我在 Slack 上发送的消息。 此外，我为失败的集成测试添加了一个修复程序，当 TPR 被删除时，第三方资源控制器将删除相应的路由处理程序，这将有助于集成测试，但我不确定这是否会带来任何其他问题.

对于问题 #1，这里已修复：

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

@brendandburns实际上不是，您可以运行注释掉集成测试，它会失败。

@brendandburns更准确地说，我们确实支持多个资源、单个版本，但是删除逻辑存在一些问题。

@AdoHe你提出问题了吗？ 我可以看看

@brendandburns你可以在这里看到：

https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 

启用此测试，您将看到它会失败。 我试图在我的本地解决这个问题，我将在今天晚些时候打开一个 PR。

@brendandburns恐怕我没有提出问题。

另请参考https://github.com/kubernetes/kubernetes/issues/32306 （删除命名空间时应删除 TPR）

@deads2k你能更新清单吗？

@deads2k你能更新清单吗？

所有问题仍然悬而未决。 这实际上是一个功能，用于跟踪 1.3 中（已经）测试版thirdparyresources实现中的问题。 我们需要一个地方来跟踪我们的问题，但不得不将精力投入到 1.5 中的其他工作中。

@deads2k我已经在处理Multiple Resources, single version和Multiple versions ，我认为很多代码需要更新。

@deads2k仍然以 1.5 为目标？

@idvoretskyi恐怕不会:(

@deads2k ：应将

@deads2k ：当前字段选择器在查询

@deads2k @rmohr kubectl 在对抗 TPR 方面仍然有很多出色的能力，应该更新上面的列表以跟踪这些。

@deads2k ：当前字段选择器在查询

这是一个更普遍的问题，即所有 API 类型的字段选择器支持不一致。

我也开始关注这个。 ThirdPartyResources 对于支持像spark这样的“外部”控制器非常重要，在我们添加子资源之类的东西之前，我们应该解决这个问题。

字段选择器仅适用于常规 API 对象中的手工策划字段。 我不希望它们适用于 TPR 中的任何字段——apiserver 不是为执行任意查询而构建的。 如果您需要这种行为，TPR 对您不起作用。

下一步是将 TPR 移动到插件 API 服务器中吗？
似乎有一些优秀的 PR 可以解决这里列表中的一些问题，这些问题可能会在此项目上被阻止。

/cc @liggitt @deads2k @AdoHe

为了降低 apiserver 代码中 TPR 的复杂性并使 TPR 逻辑更加明确，我肯定会投票支持独立的tpr-apiserver 。 但是 IMO 这并没有真正阻止任何修复。

在处理多个不可转换的种类时，我添加了一些关于处理 API 语义（获取、列表、监视、更新、补丁）的项目。 我认为这可能需要一个设计文档，因为语义不太可能匹配正常的 API 语义。

我将（又一次）尝试解决其中的一些问题......

https://github.com/kubernetes/kubernetes/pull/40260和https://github.com/kubernetes/kubernetes/pull/40096将使我们在 kubectl 方面处于良好状态

目前最严重的服务器端问题是垃圾收集器对指向 TPR 的 ownerRefs 失去了理智。

一旦我们解决了这个问题，我们应该决定围绕给定 TPR 的多个版本的 API 语义应该是什么，并确保 TPR 类型具有我们需要的数据。 这可能会影响服务器端存储实现，所以我宁愿在我们做太多服务器端工作之前确定设计。

@liggitt我会看看这些。 谢谢

有没有人指出如何在 RBAC 规则中引用 TPR？ 我有一个名为 foo-bar.something.example.com 的 TPR。 作为集群管理员，我可以使用kubectl get foobars获取给定命名空间中的 foobar 列表。

当普通用户尝试同样的事情时，他们会得到Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) 。

到目前为止，我已经尝试了 RBAC 规则中我能想到的 foobar、foo-bar 等的所有变体。

在规则中，您正在寻找 resource=foobars apigroup=something.example.com verb=get,list,watch

@deads2k做到了。 谢谢！

@利吉特

The most severe server-side issue at the moment is the garbage collector losing its mind over ownerRefs that point to TPRs.

有什么与 TPR 清理问题有关的吗？

不，这是垃圾收集器的一个问题，它不知道如何查找除编译类型以外的任何内容的 ownerRefs。 也存在相反的问题，垃圾收集器不会关注除编译类型之外的任何其他东西的终结器。

这两个垃圾收集器问题都不同于在删除 ThirdPartyResource 对象时需要可靠地清理 ThirdPartyResourceData 对象。

@liggitt谢谢耐心解释，那么1.6的TPR计划是什么？

GC 现在每秒只记录 1k 次而不是每秒 50k 次，
所以它不再用原木旋转器赢得比赛。 但真正的修复将是
快来，希望。

2017 年 2 月 4 日星期六晚上 11:54，TonyAdo [email protected]写道：

@liggitt https://github.com/liggitt感谢耐心的解释，所以
1.6中TPR的计划是什么？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/features/issues/95#issuecomment-277503470 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAnglmGf00K6W7SsJ1aSqWOI_M-A7Hf2ks5rZYBPgaJpZM4KLBmK
.

一些与 TPR 相关的未决问题。 不详尽。

组/版本问题： https : //github.com/kubernetes/kubernetes/pull/36977
观看： https :
自链接： https :
命名空间删除： https :
GC： https :
终结器： https :
TPR数据的清理： https :
更强大的元数据验证： https :
缺乏单元测试： https :
清理： https :

用户认为是错误的功能，因为它们适用于其他资源：
异步行为： https :
整数： https :
YAML： https :
体面的 kubectl 输出： https :
简化资源命名： https :
申请： https : //github.com/kubernetes/kubernetes/issues/39906
编辑： https :

/cc

订阅，因为我们正在尝试处理仪表板中的 TPR。

跟踪问题是https://github.com/kubernetes/dashboard/issues/1671和https://github.com/kubernetes/dashboard/issues/1504。

@kubernetes/dashboard-maintainers

非命名空间 TPR 的状态/计划是什么？ 我没有找到关于它的讨论，也许错过了什么？

@sttts首先，我对 Kubernetes 的开发很感兴趣。 我想为此做出贡献，但 Go 对我来说是一门新语言。 你们推荐我做什么才能为 GSoC 2017 获得这个项目？

补充一点，我非常擅长 C++ 和 Java，并且拥有计算机科学学士学位。 我也开始阅读文档并参加了涉及 Kubernetes 的 Udacity 课程。

@grpndrs我们有一个标签问题列表，这是进入代码的一个很好的起点： https : q=is%3Aopen+is%3Aissue+label%3Afor-new - 贡献者。 请随时与我联系，我们可以通过其中的一些。

@enisoc

Multiple Resources, single version, different add times仍然是一个问题吗？ 我可以毫无问题地创建和删除多个 TPR。

另外，我们可以给Outstanding Capabilities的复选框@deads2k我认为你可以这样做：

1. - [ ] ...
2. - [ ] ...

有谁知道这个验证组件是怎么来的？ 我经常使用 TPR，这个功能是无价的，可以节省很多自定义代码。 我很乐意为此功能做出贡献，但想知道订阅此问题的人是否知道它的状态

有谁知道这个验证组件是怎么来的？

我不希望它发生在 1.7。 目前，我们正在讨论一些结构性成长的痛点https://github.com/kubernetes/community/pull/524，以提供更稳定的成长基础。

我不希望它发生在 1.7。 目前，我们正在 kubernetes/community#524 讨论一些结构性成长的痛点，以提供更稳定的成长基础。

我们计划在 1.7 时间框架内推进https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md 。 随着我们的进展，我将在此处和 sig-apimachinery 调用中进行更新。

@deads2k我没有看到任何关于 tpr 验证的内容。 你不认为这是测试版所需要的东西吗？

@frankgreco该提案是关于建立 TPR 的良好基础。 诸如验证之类的功能可以稍后添加，但不在此处的范围内。

我已经编辑了该线程的父注释以使用新模板，并按照我的理解阐明为 1.7 计划的工作范围。 请查看它并修复/评论。

@deads2k @enisoc我们最近开始使用 TPR，TPR 验证对我们即将开展的一些项目非常重要。 如果我们有资源来处理它，你会考虑接受社区贡献者来实现它吗？

@deads2k @enisoc我们最近开始使用 TPR，TPR 验证对我们即将开展的一些项目非常重要。 如果我们有资源来处理它，你会考虑接受社区贡献者来实现它吗？

绝对地。 对于这样的事情，在我们开始查看拉取请求之前，我们需要一个设计提案。 此外，鉴于有多少种不同的方法是可能的，我建议您列出前三个左右的想法，并简要说明为什么您选择的方法是最好的。 由于是服务器端，性能和安全方面的考虑非常重要。

此外，由于这是一个影响深远的功能，重要的是它不会成为驱动性贡献。 过渡到https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md 的积极贡献（评论、测试、代码、迁移）会有所帮助。 如果您有兴趣并想谈谈，我很抱歉。

谢谢@deads2k！ 这是完全合理的。 我们将为 TPR 验证提出一些设计建议，分享它的最佳方式是什么？ 我也会松懈

@xiao-zhou 我们很高兴有一个围​​绕这个主题的被接受的 Google Summer of Code 项目（昨天刚刚宣布）。 让我们在 Slack 上聊聊如何在这方面进行协作。 很酷，你也对此感兴趣，所以我们有很大的力量来推动它！

@xiao-zhou @sttts @deads2k一旦你有一个关于 TPR 验证（最好是默认）的提议，就在提议审查中标记我？ 谢谢

@sdminonne它将发布在 sig-apimachinery 中。 如果您订阅了那个 google 群组，您应该会收到通知。

@sttts谢谢

@deads2k你打算为 TPR 添加 ObservedGeneration 吗？

https://github.com/kubernetes/kubernetes/issues/7328#issuecomment -287683598

@deads2k你打算为 TPR 添加 ObservedGeneration 吗？

我不打算这样做。 一个关心的客户不能简单地比较规范和状态名称吗？

比较规范和状态名称？

不确定你在这里的意思。 纠正我 如果我错了，但我认为 ObservedGeneration 有两部分：1）API 服务器需要在每次 TPR 规范中有更新时更新metadata.generation和 2）负责TPR 基于metadata.Generation更新status.observedGeneration metadata.Generation 。 我想 1) 是我要问你的问题，2) 是 TPR 作者需要注意的问题吗？

不确定你在这里的意思。 纠正我 如果我错了，但我认为 ObservedGeneration 有两部分：1）API 服务器需要在每次 TPR 规范中有更新时更新 metadata.generation 和 2）负责 TPR 更新状态的控制器.observedGeneration 基于 metadata.Generation。 我想 1) 是我要问你的问题，2) 是 TPR 作者需要注意的问题吗？

哦，我误解了你在问什么。 您需要为 CustomResource 而非 CustomResourceDefinition 进行观察生成。 我认为，observedGeneration 只是因为对需要采取行动的规范的更改而受到影响。 这意味着对元数据的更新不会触发它，并且对某些规范字段的更新也可以避免碰撞它。

在我上面链接的评论中，我要求生成对 TPR 实例的支持，而不是 TPR 本身（尽管这也很好。有什么理由不将它添加到所有对象？）。

例如，如果我有Kind: TPR; name: foo.example.com和该 TPR Kind: Foo; name: foo123实例，我对foo123 Generation/ObservedGeneration 感兴趣，以便 Foo 控制器可以让 Foo 消费者知道它是否已处理foo123实例的更新。 是否有意义？ 如果没有 k8s 服务器端的适当支持，我看不出这是如何实现的。

是的， generation/observedGeneration 对 TPR 的用户模式有意义，而不是对实际的 TPR 资源随着它的发展而有意义。

@kargakis规则是只在规范更新时增加对象生成，而不是状态，对吗？ 如果是这样，则意味着我们首先需要在 TPR 实例上正式支持 Spec/Status 拆分。 我打算写一份关于 TPR 状态的提案，目标是 1.8。 我可以确保在提案中包含递增对象生成。

规则是只在规范更新时增加对象生成，而不是状态，对吗？

正确的。

如果是这样，则意味着我们首先需要在 TPR 实例上正式支持 Spec/Status 拆分。

是的，我希望发现这种分裂是现有问题的一部分，但在我们到达那里之前，似乎还有更多的工作要做。

@kargakis我已经编辑了顶级评论以提及这些项目，尽管它们超出了 1.7 的范围。

/cc

@deads2k我们应该为 CustomResourceDefinition 添加一个短名称吗？

为 CustomResourceDefinition 添加了短名称 CRD 。

用于验证 CustomResources 的设计方案： https :

@deads2k @enisoc @lavalamp
想知道用户是否可以为 CRD 对象配置 k8s 控制器 AND(OR) CURD 方法

在我的特定用例中，我创建了一个networks.stable.example.com CRD 并使用它来创建网络对象 net1：

如果已经存在具有重叠子网范围的网络 CRD 对象，我需要确保不允许创建新的网络 CRD 对象

如果这种机制不存在，我很乐意将一些想法放在设计文档中。

正如 1.7 发行说明和文档中所述，TPR 现在已被弃用，我们计划在 1.8 中将其删除。 用户应在 1.7 时间范围内切换到 CRD。

如果您有任何问题或疑虑，请评论要删除的

1.8 的更新/计划：

• 支持基于 JSON Schema 的 CustomResources 验证和默认设置（提案）
• 为 CR 添加子资源（如状态和规模）（~提案即将发布~提案）

谢谢@nikhita。 我已经编辑了最高评论以反映 1.8 计划。

发现返回正确的 CR 信息，但 REST 映射器不使用它 - https://github.com/kubernetes/kubernetes/issues/49948

CustomResources 的子资源提案： https :

请原谅我的错误帖子，但我是从其他一些 kubernetes 页面来到此页面的，认为 kubernetes 包含一个微服务框架，而不仅仅是用于管理第三方容器资源。

Redhat 将 OpenShift kubernetes 作为一个微服务平台进行营销，但是，我似乎找不到这个功能。 我正在寻找类似应用程序服务器的东西，以托管我自己的一套非常轻量级的独立应用程序微服务。

是否存在这样的事情，或者我们是否被降级为在 springboot 中创建胖 java 战争应用程序并将它们部署在位于 kuberenetes 托管容器内的 tomcat 服务器上，这很难管理且难以部署。 我需要一个微服务平台，一个管理员可以管理和操作上百个微服务。

这个问题有意义吗？

@hectoralicea这个 repo 用于规划 Kubernetes 开发人员处理的功能。

对于此类一般问题，请发布到 Kubernetes 用户组。 他们通常对这种高层讨论更有帮助:)

请参阅https://groups.google.com/forum/#!forum/kubernetes -users、 http : //slack.k8s.io/ 或 Stack Overflow。

@colemickens @deads2k @nikhita @enisoc我为 1.9 添加了一个部分。

@sttts在

@luxas错误修正当然。 但我认为我们不必在这里列出。

@sttts我在考虑 CRD 验证……这是否包含在此功能问题中，并且会在 v1.9 中升级到测试版还是？

@luxas来自最初的帖子

Scope of work planned for v1.9

    CRD validation to beta kubernetes/kubernetes#22768 kubernetes/kubernetes#53829
    CRD sub-resources as alpha kubernetes/community#913

哦，谢谢@kargakis ，没看那里 :facepalm: :smile:

@ deads2k，@enisoc在1.9 “稳定”没有计划，对不对？

@idvoretskyi对。

@deads2k :wave：请打开文档 PR并添加指向跟踪电子表格的链接。 提前致谢！

@deads2k请打开文档 PR 并添加指向跟踪电子表格的链接。 提前致谢！

@zacharysarah我似乎放错了电子表格链接。 CRD 验证文档https://github.com/kubernetes/website/pull/6066

作为记录，此处存在 CRD 版本控制问题： https :

CRD 迁移到 GA 的任务列表： https :

@nikhita这是否意味着整个 CRD 功能都在迁移到 GA？

这是否意味着整个 CRD 功能都将迁移到 GA？

API 将迁移到 GA，即 v1，但可能会带有一些 beta/alpha 子功能。 但它不会终止，但何时会发生，即 1.10 是否可行。

@sttts @nikhita你能更准确地定义功能路线图吗？

你能更准确地定义功能路线图吗？

对于 1.10：

• https://github.com/kubernetes/kubernetes/issues/58682 中列出的自定义资源和错误修复的子资源（至少没有划掉的）

没有 _exact_ 为下一个版本计划的可交付成果集，但计划是在年底前正式发布 (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc)。

https://github.com/kubernetes/kubernetes/issues/58682 中所有未划掉的问题完成后，我们将进入 GA。

当 CRD api 成为 GA 时，其中可能包含一些功能（例如： CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg/features/kube_features.go#L35) 可能是 alpha/beta。

@sttts @nikhita @deads2k
在 1.11 中有任何计划吗？

如果是这样，请确保该功能是最新的，并具有以下适当的功能：

• 描述
• 里程碑
• 受让人
• 标签：
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

抄送@idvoretskyi

在 1.11 中有任何计划吗？

我没有编辑 PR 正文的权限（如果有人可以这样做，那就太好了！）。 但计划是：

• 实施 CRD 版本控制。 这还有另一个功能问题： https : https :
• 为自定义资源添加修剪和默认设置。
• 支持 CRD 验证模式中的映射。 https://github.com/kubernetes/kubernetes/issues/59485
• 为自定义资源实现配额支持（这也可以视为错误修复） https://github.com/kubernetes/kubernetes/issues/53777

如果是这样，请确保该功能是最新的，并具有以下适当的功能：
描述

应更新单行描述以包括“为 CRD 添加验证、默认、子资源和版本控制”。

描述中提到的设计方案需要包括：

• https://github.com/kubernetes/community/pull/2026
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-subresources.md

有人也可以将这些添加到 PR 正文中吗？

标签：

/种类特征

/ cc @mbohlool

有人也可以将这些添加到 PR 正文中吗？

完毕

@nikhita @sttts @mbohlool - 只是为了澄清，我们是否针对 1.11 周期的测试版？

@nikhita @sttts @mbohlool - 再次在这个问题上ping ...
我们的目标是 1.11 的 Beta 版吗？ 只是想确保功能冻结是今天。

@justaugustus CRD 已经是测试版。 GA 未计划用于 1.11。

所有列出的功能/扩展（修剪、默认、版本控制）可能会以 alpha 开始。

@sttts嗯，在这种情况下，我们是否应该有单独的问题来独立跟踪这些功能/扩展及其阶段？

记录 - @nikhita为子功能https://github.com/kubernetes/features/issues/571创建了一个问题

@sttts @justaugustus

默认和修剪子功能问题： https :

@justaugustus @idvoretskyi用于 1.12 跟踪目的：将会添加一些内容并可能修复错误，但这将保留在 1.12 的测试版中（因此从功能的角度来看没有变化）。

有一个新的子功能计划为 alpha，但它是作为一个单独的问题创建的： https :

你好
之前已经跟踪过此增强功能，因此我们想检查一下，看看是否有任何计划可以在 Kubernetes 1.13 中进行毕业阶段。 此版本的目标是更加“稳定”，并将有一个积极的时间表。 请仅在高度确信它将满足以下截止日期的情况下才包含此增强功能：

• 文档（打开占位符 PR）：11/8
• 代码泥浆：11/9
• 代码冻结开始：11/15
• 文档完成和审核：11/27

如果需要将其包含在1.13 增强跟踪表中，请花点时间更新原始帖子中的里程碑以供将来跟踪和 ping @kacole2

谢谢！

之前已经跟踪过此增强功能，因此我们想检查一下，看看是否有任何计划可以在 Kubernetes 1.13 中进行毕业阶段。

不，没有计划在 1.13 中毕业。 CRD API 仍处于测试阶段。

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

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

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

/删除生命周期陈旧

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

@claurence CRD API 也将保持在 1.14 的测试版中。

你好@nikhita @deads2k ，我是 1.15 的增强负责人。 这个功能会在 1.15 中从 alpha/beta/stable 阶段毕业吗？ 请让我知道，以便可以正确跟踪并添加到电子表格中。 KEP 也需要合并以包含 1.15。 谢谢！

编码开始后，请列出此问题中所有相关的 k/k PR，以便正确跟踪它们。

这将保持在测试阶段。 验证、转换和 OpenAPI 发布的工作正在 1.15 中进行

更新了 1.15 版相关 KEP 链接的说明

嘿， @ liggitt @deads2k @jpbetz @sttts我是 v1.15 文档发布影子。

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

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

@deads2k @jpbetz @sttts @liggitt

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

1.15 的文档 PR： https :

@deads2k你能更新问题描述吗？

/里程碑 v1.16
/stage稳定

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

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

友情提示，我们正在寻找 8 月 23 日星期五到期的针对 k/website（分支 dev-1.16）的 PR。 如果您有任何问题，请告诉我！

@simonswine占位符 PR https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts星期四是代码冻结。 是否有任何优秀的 k/k PR 会阻止它升级到稳定？ 计划 1.15* 工作的原始帖子中的所有内容看起来都已合并。

我相信出色的 PR 只是功能门版本的提升（https://github.com/kubernetes/kubernetes/pull/81965）和本周应该进行的两个出色的错误修复： https : https://github.com/kubernetes/kubernetes/issues/78707

文档准备在https://github.com/kubernetes/website/pull/15982 中审查

在 v1.16.0 中稳定发布

在https://github.com/orgs/kubernetes/projects/28 中跟踪的 GA 后工作

/关闭

@liggitt ：关闭此问题。