enhancements 🚀 - 边车容器

@enisoc @dchen1107 @fejta @thockin @kow3ns @derekwaynecarr ，打开这个跟踪问题，以便我们讨论。

Joseph-Irving 于 2019-01-29

/分配

kow3ns 于 2019-01-31

@derekwaynecarr我已经对下周 sig-node 会议所需的 kubelet 更改进行了一些范围界定，我_相信_只有kuberuntime包中需要更改，特别是kuberuntime_manager.go in 和kuberuntime_container.go 。

在kuberuntime_manager.go您可以修改computePodActions以实现关闭触发（当所有非边车永久退出时杀死边车），并首先启动边车。

在kuberuntime_container.go您可以修改killContainersWithSyncResult以最后终止 sidecars 并发送 preStop 钩子（preStop 钩子有点有争议，是否应该这样做还没有解决。 @ thockin有一个很好的观点，说明为什么您可能不想鼓励这种行为，请参阅评论）。

如果你想让我进一步调查，请告诉我。

Joseph-Irving 于 2019-02-01

@kow3ns如果我们可以在 Pod 规范（sig-app）中定义容器序列的完整描述，以及如何处理 kubelet 中的序列以进行启动、重启和级联考虑（sig-node），那么讨论对我来说更有意义。让我们赶上 2 月 5 日的 sig-node 会议以提供更多输入。

抄送@约瑟夫-欧文

resouer 于 2019-02-01

该提案说 sidecars 只在 init 容器运行后运行。但是，如果用例需要边车在 init 容器运行时/之前运行，该怎么办。例如，如果您希望通过作为 sidecar 运行的代理（如在 Istio 中）路由 pod 的流量，您可能希望该代理在 init 容器运行时就位，以防 init 容器本身进行网络调用。

luksa 于 2019-02-07

👍14

@luksa我认为有可能在某个时候考虑在 init 阶段运行 sidecar，但目前该提案不会涵盖该用例。目前没有办法在 init 阶段运行并发容器，因此这可能比这里建议的更改更大/更混乱。

Joseph-Irving 于 2019-02-14

此 KEP 的更新：
我已经与来自 sig-node 的@derekwaynecarr和@dchen1107都谈过这件事，他们没有对该提案表示任何重大关切。我将向 KEP 提出 PR，添加一些关于实施细节的初步说明，并澄清讨论期间提出的几点。

我们仍然需要就 API 达成一致，似乎已经达成共识，将容器标记为 sidecars 的简单方法比更深入的排序标志更受欢迎。拥有 bool 有点限制，所以也许更多类似containerLifecycle: Sidecar会更可取，这样我们就可以选择在未来进行扩展。

Joseph-Irving 于 2019-02-14

👍3

@Joseph-Irving 实际上，布尔值和containerLifecycle: Sidecar都不适合未来的适当扩展。相反， containerLifecycle应该是一个对象，就像deployment.spec.strategy ，带有type: Sidecar 。这将允许我们引入额外的字段。对于“吊舱整个生命周期的边车”解决方案，它将按照以下方式表达：

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

与

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

请原谅我不好的命名 - 我希望这些名字传达了这个想法。

但是我们将containerLifecycle引入pod.spec.containers的方法存在一个问题。也就是说，让 sidecar 与pod.spec.containers下指定的 init 容器并行运行是错误的。因此，如果您真的希望最终能够将其扩展到 init 容器，您应该找到一种替代解决方案 - 一个允许您将容器标记为更高级别的 sidecars - 即不在pod.spec.containers或pod.spec.initContainers ，但类似于pod.spec.sidecarContainers ，我相信你已经讨论过，但被驳回了。 init 容器问题肯定需要沿着这些方向的解决方案。

luksa 于 2019-02-14

👍1

@luksa您还可以通过将 init 容器标记为 sidecar 并让它与 init 容器一起运行来解决 init 问题。据我了解，问题在于 init 容器有时需要 sidecar，这与需要在 pod 的整个生命周期内运行的容器不同。

pod.spec.sidecarContainers的问题在于它的变化要复杂得多，工具需要更新，kubelet 需要大量修改才能支持另一组容器。当前的提议要温和得多，它只是建立在已有的基础上。

Joseph-Irving 于 2019-02-14

@Joseph-Irving 我们可以解决这个问题。在 init 容器运行后关闭 sidecar 然后再次启动相同的 sidecar 并不理想，但总比没有那个选项要好。更大的问题是较旧的 Kubelets 无法正确处理 init-sidecar 容器（就像 main-sidecar 容器一样）。

我只是希望你在最终确定提案时记住 init-sidecars。从本质上讲，您将“sidecar”的概念引入 k8s（以前，我们基本上只有一组完全相同的容器）。现在您正在引入实际的 sidecar，所以恕我直言，您真的应该彻底考虑这一点，而不是忽略一个非常重要的 sidecar 用例。

我很乐意帮助实现这一点。没有它，Istio 就无法为 init 容器提供其功能（实际上，在运行 Istio 的适当安全的 Kubernetes 集群中，init 容器完全失去了与 _any_ 服务对话的能力）。

luksa 于 2019-02-14

👍4

关于https://github.com/kubernetes/enhancements/pull/841 中的实现讨论，我打开了一个 WIP PR，其中包含此提案的基本 PoC https://github.com/kubernetes/kubernetes/pull /75099。这只是初稿，显然并不完美，但基本功能有效，并让您了解所需的更改量。

抄送@enisoc

Joseph-Irving 于 2019-03-07

我整理了一个简短的视频，展示了 PoC 当前的行为https://youtu.be/4hC8t6_8bTs。看到它在行动中可能比阅读它更好。
免责声明：我不是专业的youtuber。

Joseph-Irving 于 2019-03-18

👍13 ❤5 🎉4

我打开了两个新的 PR：

https://github.com/kubernetes/enhancements/pull/918是关于毕业标准、版本偏差、升级/降级
https://github.com/kubernetes/enhancements/pull/919是决定API实现

任何想法或建议将不胜感激。

Joseph-Irving 于 2019-03-26

@Joseph-Irving 抱歉，如果我在设计过程的后期发表评论，但我有一个潜在的 sidecar 容器用例，当前的设计提案可能不支持它。我只是想提出它以供考虑。要点是我有一个场景，在 pod 终止时，1 个 sidecar 应该在主容器之前终止，而另一个 sidecar 应该在主容器之后终止。

一个具体的例子可能是一个带有 Django 应用程序容器的 pod、一个用于服务注册的 consul sidecar，以及一个用于管理数据库连接的 pgbouncer sidecar。当 pod 终止时，我希望先停止 consul sidecar（这样就不会再将流量路由到 pod），然后是应用程序容器（最好在短暂的宽限期之后），然后是 pgbouncer sidecar。当前的提议对于处理应用程序 <-> pgbouncer 容器依赖项看起来很棒，但似乎没有足够的表现力来捕捉我想在主容器 _before_ 之前拆除 sidecar 的情况。

currankaushik 于 2019-03-29

👍1

@currankaushik ，在您描述的场景中，您可能会使用 pre-stop hook 来告诉 consul 容器准备关闭并停止向您发送请求（假设它可以支持类似的东西）。在容器终止开始之前，pre stop hooks 将首先发送到 sidecars。

这样做的动机是，像 istio 这样的代理 sidecar 可以进入一种状态，即它们不会将流量路由给您，但在您的应用程序完成和关闭时仍允许流量流出。

Joseph-Irving 于 2019-03-29

听起来不错，谢谢@Joseph-Irving。所以只是在高层次上确认我的理解： pre-stop hooks 将首先发送到 sidecars，然后是 pre-stop hooks 到 non-sidecars，SIGTERM 到 non-sidecars，然后（在所有 non-sidecars 退出之后) SIGTERM 到边车？设计提案（https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md）似乎暗示了这一点，但也说：

PreStop Hooks 将同时发送到 sidecars 和容器。

currankaushik 于 2019-03-29

@currankaushik是的，你所描述的是预期的行为。

你引用的那句话需要改写。当我写那篇文章时，我对 prestop 钩子如何发送到容器有一些误解。谢谢你指出。

Joseph-Irving 于 2019-03-29

👍1

@Joseph-Irving 此功能是否针对 1.15 的 alpha 包含？

kacole2 于 2019-04-12

👍5

@kacole2是的，这就是计划，假设我们可以在增强冻结（4 月 30 日）之前及时实施 KEP。一旦 api 完成https://github.com/kubernetes/enhancements/pull/919并且测试计划同意https://github.com/kubernetes/enhancements/pull/951我想我们应该都准备好了。

Joseph-Irving 于 2019-04-12

/里程碑 v1.15
/阶段阿尔法

kacole2 于 2019-04-12

👍1

@Joseph-Irving Kubernetes 1.15 增强冻结是 2019 年 4 月 30 日。要包含在 Kubernetes 1.15 里程碑中，KEP 必须处于“可实施”状态，并具有适当的测试计划和毕业标准。请提交使此 KEP 符合纳入标准所需的任何 PR。如果这会偏离 1.15 里程碑，请告诉我们，以便我们进行适当的跟踪更改。

mrbobbytables 于 2019-04-29

@mrbobbytables不幸的是，为了使其达到可实施状态而打开的 PR 并没有对它们产生太大影响，因此我认为我们需要将其推迟到 1.16。

Joseph-Irving 于 2019-04-29

😕5 👎4

不用担心。感谢您如此迅速地回复并告知我们！
/里程碑清除

mrbobbytables 于 2019-04-29

👍2

请记住，这个 KEP 对 Istio 非常重要！

对于所有使用具有协调引导/关闭（akka 集群、lagom 等）的服务框架以及 istio 服务网格的项目来说，它都是一个亮点，请参见。

抄送@jroper

thomschke 于 2019-04-30

👍12

@Joseph-Irving sry 关于迟到的评论，但我在设计文档中没有看到以下内容，我想知道这些的预期行为是什么：

如果我们看到 sidecar 失败，如果主容器没有完成，我们是否总是重新启动它们（忽略 pod 中的 restartPolicy）？这将非常有用，因为 sidecar 过去用作代理、负载平衡、内务管理角色，只要主容器可以继续工作，它是否失败几次都没有关系

另外，在计算 pod 阶段时，如果所有主容器都成功，而 sidecar 失败（这很常见，好像 sidecar 没有捕获 SIGTERM 返回码会像 143 之类的），那么 pod 阶段是否仍然“成功”？

zhan849 于 2019-04-30

@zhan849目前 sidecar 容器遵守 pod 重启策略，并在计算 pod 阶段（例如Succeeded时被计算在内。

我们在这个过程的早期确实对此进行了辩论，但总体感觉是我们应该尽可能少地偏离普通容器，只有在启用所描述的用例时才这样做。

关于 pod 阶段：我认为所有在 kubernetes 中运行的应用程序都应该处理 SIGTERMs（尤其是 sidecars），但有时你会想知道你的 sidecars 是否以错误的方式退出，这应该反映在 pod 阶段，隐藏该信息可能会导致混淆。

对于重启策略，如果重启策略从不存在并且您的 sidecar 容易崩溃，那么这似乎只是一个问题。我不确定将它们与 pod 重启策略分开的复杂性是否值得，特别是因为有些人可能希望他们的 sidecar 遵守 pod 重启策略。

这两件事都符合普通容器的作用和当前发生的情况。
实现 Kep 中列出的目标似乎不需要更改它们。

如果您有一些广泛的用例来说明为什么需要更改它们来实现这些目标，那将会很有用。因为它可以更容易地证明对代码库进行更复杂的更改。

Joseph-Irving 于 2019-04-30

@Joseph-Irving 我们有一些更简单的 side car impls，它们已经在内部运行以满足一些紧迫的需求（我们没有做出贡献，因为这已经在社区中进行了），这是我们学到的东西。

关于 pod 阶段：

容器存在状态已经反映在pod.status.containerStatuses所以我们不会丢失信息。此外，由于 sidecar 的一个重要用例是在 Job（或任何运行到完成的 pod，例如 Kubeflow 中的那些），有意义的工作负载将仅应用于主容器，并且如果由于 sidecar 故障而将 pod 阶段标记为 Failed ，会导致不必要的重试，并导致其他误导性的后果，例如Job fail等。
尽管 sidecars 处理 SIGTERMs 是理想的，但在生产中，可能有很多 sidecars 只是建立在开源软件的基础上，它们不能很好地处理 SIGTERMs，包括kube-proxy ， postfix ， rsyslogd和许多其他（即使处理了 SIGTERM，对于不可捕获的 SIGKILL，它肯定不会是 0）

关于重启策略（这可能有争议，但让 sidecar 严格遵守 restartPolicy 在生产中是不现实的）：

通过设置“OnFailure”在主容器仍在运行时强制 sidecar 重新启动不是一个选项，因为这将重新启动失败的主容器并且与作业级别重试限制一起混淆。
通常在处理 sidecar 时，主容器通常有大量的 sidecar 不可用的重试逻辑，这些都是在社区有 sidecar 支持和明确的容器启动顺序之前完成的。考虑到它的范围，这种历史错误处理不是很容易改变。不重启 sidecar 会导致主容器挂起重试
将故障传播到上层控制器将触发协调链和大量 api 调用，因此不必要的错误升级会使 kubernetes 的可扩展性降低。
一个更具体的例子：如果作业的主容器仍在运行并且 sidecar 失败，则重新启动 sidecar 将只有 1 个 PATCH pod 状态操作和最多 1 个与事件相关的 api 调用。但是如果 pod 完全失败将导致 Job 的和解，以及更多的雇佣级别控制器，例如 CronJob 和其他 CRD，并且可能会有更多次 API 调用。

还想看看其他人是否也遇到过类似的问题（/cc

zhan849 于 2019-04-30

此更改是否包含https://github.com/kubernetes/community/pull/2342 中所需的行为，以便有一种方法可以配置整个 pod（或仅非 sidecar 容器）以在出现以下情况时重新启动边车失败？

JacobHenner 于 2019-05-01

@JacobHenner目前没有计划在这个 KEP 中实施这种机制，我们确实讨论过合并它，但它对这个 KEP 并没有太多依赖，可以独立于这个开发。所以它似乎更适合拥有自己的 KEP。

Joseph-Irving 于 2019-05-07

@Joseph-Irving 只是为了分享我们解决上述陷阱的 impl 以供您参考（https://github.com/zhan849/kubernetes/commits/kubelet-sidecar），因为我们的目标是等待官方支持，我们尝试在此提交中尽可能保持本地更改。

所以对于作业重启策略 == 从不，有 1 个主容器，1 个经常崩溃的坏边车，1 个继续运行的好边车，在主容器退出后，pod 状态将如下所示。

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

zhan849 于 2019-05-07

👍3

我大体上同意 sidecar KEP 需要考虑 pod 阶段和重启策略，然后才能进入可实现的状态。我不在乎是不是这个 KEP，但我总体上同意@zhan849的论点，需要在这里处理。

smarterclayton 于 2019-05-24

👍2

谢谢@smarterclayton ！
@Joseph-Irving 让我们知道您是否希望我们在实践中与 sidecar 分享任何其他内容。

zhan849 于 2019-05-24

@smarterclayton @zhan849 ，我并不是特别不同意你提出的观点，只是想给出一些反驳点。不改变 Pod Phases/Restart Policy 是一个有意识的选择，因为这会进一步扩大这个提案的范围，而且没有人对此有强烈的感受。

我会将这个反馈反馈给 sig-apps/sig-node，看看他们的想法。如果@derekwaynecarr或@dchen1107想插话，sig-node 特别热衷于让 sidecar 尽可能靠近普通容器，我们将不胜感激。

Joseph-Irving 于 2019-05-24

测试计划https://github.com/kubernetes/enhancements/pull/951和 API 设计https://github.com/kubernetes/enhancements/pull/919 PR 现已合并。

我已经打开了https://github.com/kubernetes/enhancements/pull/1109以将 KEP 标记为可实施，一旦每个人都满意我们应该能够在 1.16 中以 alpha 的形式开始开发🤞

Joseph-Irving 于 2019-06-19

👍7 🎉5

此 Kep 已被标记为可实施，因此我将在下周开始提高 PR 以使其进入 1.16！

Joseph-Irving 于 2019-06-28

👍6

我已经提出了https://github.com/kubernetes/kubernetes/pull/79649来实现 API，我将为 Kubelet 更改提供单独的 PR。

Joseph-Irving 于 2019-07-02

嗨@Joseph-Irving，我是 1.16 增强负责人。这个功能会在 1.16 中从 alpha/beta/stable 阶段毕业吗？请告诉我，以便将其添加到1.16 跟踪电子表格中。如果不是即将毕业，我会将其从里程碑中删除并更改跟踪标签。

一旦编码开始或已经开始，请在本期列出所有相关的 k/k PR，以便正确跟踪它们。

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

谢谢你。

kacole2 于 2019-07-09

@Joseph-Irving 如果你想要/需要一些额外的人来实现这一点，我对这次登陆很感兴趣，所以我很乐意伸出援手。

mhuxtable 于 2019-07-09

嗨@kacole2这是针对 1.16 的 Alpha，KEP 已被标记为可实施。
目前唯一的 PR 是 API 的 kubernetes/kubernetes#79649

@mhuxtable我将很快为 kubelet 更改提高 PR，只需完成一些事情，我将不胜感激，如果您能帮我看看，我将不胜感激。当它被提出时，我会在这里链接它。

Joseph-Irving 于 2019-07-09

我打开了实现 kubelet 更改的https://github.com/kubernetes/kubernetes/pull/80744 。

请注意 kubernetes/kubernetes#79649 (api) 仍然是开放的，所以这个 PR 包含来自它的提交，使它看起来很大。我已将其分解为提交，每个提交实现不同的功能，因此以这种方式查看它应该很容易。

我还没有完成所有的测试用例，但是工作实现的初稿已经完成，所以我希望人们看一看。

抄送@kacole2

Joseph-Irving 于 2019-07-30

👍5

@约瑟夫-欧文

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

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

daminisatya 于 2019-08-06

嗨@daminisatya ，是的，这需要更新文档，我已经提出https://github.com/kubernetes/website/pull/15693作为占位符 PR。
我很想知道是否有人对 Docs 应该去哪里有任何意见，我现在已经把一些东西放在content/en/docs/concepts/workloads/pods/pod-lifecycle.md中。

Joseph-Irving 于 2019-08-06

👍1

距离代码冻结还有不到一周的时间，这看起来不太可能让它进入 1.16。
我们仍然有两个相对较大的开放 PR kubernetes/kubernetes#80744 和 kubernetes/kubernetes#79649，它们一直在努力获得任何评论。
希望下一个发布周期会有更多的审阅者带宽来查看这些。

Joseph-Irving 于 2019-08-23

😕8 👍2

/分配

khenidak 于 2019-08-24

这是否允许编写一个可以按需启动实际服务（并销毁它）的边车？

就像缩放到零一样，但只有在空闲时运行的东西是边车。当请求出现时，它会启动实际服务，并在最后一次响应（例如 30 秒）后将其关闭。这可以允许一种简单的方法来将缩放比例接近于零（只剩下边车运行）。

Ciantic 于 2019-09-22

@Ciantic使用Operator Framework，您可以做到这一点以及更多。看一看

janosroden 于 2019-09-23

@janosroden我看过了，但似乎很难理解我如何将正在运行的服务提升到零可扩展性。

问题不在于没有可用的选项，例如Osiris 、 Keda或knative 。我尝试了最后一个，但它占用了 8Gb 的内存，当时很难说它是“无服务器”的。

问题是这些实现中的大多数都需要新的资源等。更容易想到这一点，这样人们就可以注入一个可以控制整个生命周期（包括按需启动和重新启动）的边车，这样它就可以控制服务，而不仅仅是坐在那里。

为什么这会有好处？它在低利用率和低内存情况下非常有用，例如带有 Raspberry Pi 的 k3s，或用于业余项目的 Digital Ocean Droplet。我们中的许多人都有很多不需要一直运行的 Web 服务，只要有一个可以按需唤醒它们的 sidecar 就足够了。

Ciantic 于 2019-09-23

👍1

不确定这是否真的适用于您的用例。我完全看到了在这种资源受限的系统上做你想做的事情的愿望。但要真正稳定，您需要使用资源请求来帮助安排工作负载。这些需要预先指定，因此无论工作负载是否正在运行，它都应该保留资源。

要解决这个问题，您几乎需要一个自己的 pod 来进行初始连接接收并向 k8s 发出新的 pod 请求，等待它启动，然后将流量发送给它。我认为在这种情况下不需要 Sidecar 容器增强。我认为您需要更像 k8s 的 xinetd。

kfox1111 于 2019-09-23

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

目前的发布时间表是：

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

如果你这样做了，一旦开始编码，请在这个问题中列出所有相关的 k/k PR，以便可以正确跟踪它们。 👍

谢谢！

mrbobbytables 于 2019-09-24

嗨@mrbobbytables ，假设我们可以及时审查所有内容，计划是在 1.17 中升级到 alpha。

目前公开的 PR 是：
https://github.com/kubernetes/kubernetes/pull/79649 - API 变更
https://github.com/kubernetes/kubernetes/pull/80744 - Kubelet 变化

需要帮助请叫我！

Joseph-Irving 于 2019-09-24

🎉3

伟大的！谢谢@Joseph-Irving 我会将信息添加到跟踪表中👍

mrbobbytables 于 2019-09-24

👍1

@约瑟夫-欧文

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

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

谢谢！

VineethReddy02 于 2019-10-21

嗨@VineethReddy02是的，这需要文档，占位符 PR 在这里https://github.com/kubernetes/website/pull/17190

Joseph-Irving 于 2019-10-25

🚀1

我提出了一个 PR 来更新 KEP https://github.com/kubernetes/enhancements/pull/1344它基于我们在实施 PR https://github.com/kubernetes/kubernetes/pull中的一些讨论

我很感激任何评论

Joseph-Irving 于 2019-10-30

嘿@Joseph-Irving 1.17 增强阴影在这里！ 👋 我正在与您联系以了解此增强功能的进展情况。

增强团队目前正在跟踪表中跟踪 kubernetes/kubernetes#79649 和 kubernetes/kubernetes#80744。是否还有其他需要跟踪的 k/k PR？

此外，另一个友好的提醒是我们很快就会接近代码冻结（11 月 14 日）。

annajung 于 2019-11-06

嗨@annajung ，是的，这些是唯一需要跟踪的 PR。

Joseph-Irving 于 2019-11-07

👍1

嗨@Joseph-Irving，明天是 1.17 发布周期的代码冻结。看起来 k/k PR 尚未合并。我们在 1.17 跟踪表中将此增强功能标记为At Risk 。

您认为所有必要的 PR 会在 14 日（星期四）的 EoD 中合并吗？在那之后，里程碑中将只允许发布阻止问题和 PR，但有例外。

annajung 于 2019-11-13

嗨@annajung ，不幸的是，它们看起来不太可能在代码冻结之前合并。我们在这个发布周期取得了很大进展，所以希望我们能尽早将它们合并到 1.18 中。

Joseph-Irving 于 2019-11-13

嘿@Joseph-Irving 谢谢你的更新。我将相应地更新里程碑并将此增强功能标记为推迟到 1.18。谢谢！

/里程碑 v1.18

annajung 于 2019-11-14

嘿@Joseph-Irving。 1.18 增强功能在这里 👋 。

1.18 版本昨天开始了，所以我想看看你是否打算在 1.18 版本中登陆它？我认为这因为代码冻结而错过了 1.17。 1.18 的情况如何？我看到 PR 仍然开放。

谢谢！

jeremyrickard 于 2020-01-07

🚀2

嗨@jeremyrickard ，

是的，计划是在 1.18 版本中得到这个。

API PR (https://github.com/kubernetes/kubernetes/pull/79649) 得到了 thockin 的评论，前几天，他有几点意见，但一旦这些问题得到解决，我们将关闭该 PR 并将提交合并到(https://github.com/kubernetes/kubernetes/pull/80744) 这样我们就可以将 API 和实现合并在一起。

至于 Kubelet PR（https://github.com/kubernetes/kubernetes/pull/80744），它只是需要审查，我希望我们能得到一些 sig-node 带宽来审查它这个周期。

Joseph-Irving 于 2020-01-07

🎉6

感谢更新@Joseph-Irving

将其添加到跟踪表中！

jeremyrickard 于 2020-01-07

很抱歉在聚会上迟到了。这是对常见情况的重大改进。但似乎没有涵盖更高级的情况。

考虑一个 sidecar 的情况，它导出也依赖于 Istio sidecar 的日志。如果 Istio sidecar 先关闭，一些敏感日志可能无法导出。

更通用的方法是定义跨容器的显式依赖项。不管它们是否是边车。

你如何看待这样的 api 定义：

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

rubenhak 于 2020-02-04

👍10 🚀2

@rubenhak很快就会变得混乱。需要满足什么才能使依赖关系清晰才能继续？开始和准备之间通常存在差距，我认为dependsOn会真正关心该api未解决的问题。

kfox1111 于 2020-02-07

👍1

@kfox1111提议的设计如何确定 sidecar 已启动并准备好启动主容器？我提出的唯一区别是，不是将容器标记为“sidecar”，而是使用更通用的定义依赖项的方式。

我不认为dependsOn应该指定标准。它可以在依赖容器中指定。 readinessProbe和/或livenessProbe还不够吗？如果没有，则可能有一个startupProbe - 成功表明可以启动依赖容器。

rubenhak 于 2020-02-07

👍4

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

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

irvifa 于 2020-02-09

嗨@irvifa我在这里提出了一个占位符 PR https://github.com/kubernetes/website/pull/19046

Joseph-Irving 于 2020-02-10

嗨@Joseph-Irving 感谢您的迅速回复！

irvifa 于 2020-02-10

@rubenhak - 我同意@kfox1111 的观点，即拥有完整的依赖关系图会很快变得非常混乱。如何按照 pod 规范中的顺序启动容器，然后以相反的顺序（如堆栈）拆除它们？这将更容易实现，并且涵盖了我能想到的大多数常见排序用例。

rgulewich 于 2020-02-11

👍3

@rgulewich ，你能详细说明一下，到底什么会变得混乱？从图中获取顺序是一项微不足道的任务，特别是考虑到没有一个理智的操作员会运行超过 15 个 sidecar（已经是一个延伸）这一事实。

顺序的想法是可以的，但是由于大多数 sidecar 是使用准入控制器注入的，因此很难保证顺序的正确性。有间接的需要。

rubenhak 于 2020-02-11

@rubenhak容器的依赖顺序可能存在循环，k8s/kubelet 如何决定打破循环并决定启动/停止容器的顺序？大声思考也许这可能是 API 端验证。

bjhaid 于 2020-02-11

嘿@Joseph-Irving，

友情提醒，1.18 的代码冻结时间是2020 年 3 月 5 日。

在我们追踪代码冻结的过程中，请列出/链接到您正在努力完成此增强功能的任何 PR！

jeremyrickard 于 2020-02-11

嘿@jeremyrickard ，

是跟踪https://github.com/kubernetes/kubernetes/pull/80744的公关
此 PR 包含 API 更改，但一旦审查完成，提交将合并到上述 PR 中https://github.com/kubernetes/kubernetes/pull/79649

Joseph-Irving 于 2020-02-11

@rubenhak容器的依赖顺序可能存在循环，k8s/kubelet 如何决定打破循环并决定启动/停止容器的顺序？大声思考也许这可能是 API 端验证。

@bjhaid ，API 端可以进行验证。循环检测是一种简单的算法，具有线性时间复杂度（就像 DFS 遍历一样）。

可能还需要在 sidecar 注入后重新运行验证。

rubenhak 于 2020-02-11

我一直在考虑这个问题……我认为大多数依赖问题都归结为服务网格。（也许有人可以想到另一个例子）

服务网格代理是一个边车，需要在其他任何事情之前启动并准备就绪，并且需要在其他任何事情之后退出。它们运行时间很长，因此更像是一个 sidecar，而不是一个 init 容器。

但理想情况下，initContainers 也应该都能够使用服务网格。

但是 initContainers 可能需要初始化其他 sidecar 容器。

虽然我们可以设计某种复杂的依赖系统，包括 init 容器、sidecar 容器和常规容器，但也许我们应该只有两类 sidecar？常规边车和网络边车？

网络边车必须在一开始就准备就绪。服务网格代理在这里。
init 容器依次运行。
边车都开始并准备就绪。这可以包括身份验证代理、记录器等内容。
常规容器启动并准备就绪。

拆卸是相反的。

这会消除依赖问题，同时仍然解决服务网格似乎与容器排序有关的所有问题吗？我是这么想的？

kfox1111 于 2020-02-19

@kfox1111 ，Vault 现在使用 sidecar 进行秘密注入。它应该适合哪个班级？此外，根据具体情况，Vault 可能依赖于服务网格，或者反过来。

我想说的是，这样的设计最终会爆炸成 10 个边车类。这种方法意味着对事情应该如何运行有更强烈的看法。人们会开始使用类进行黑客攻击，只是为了实现启动应用程序所需的命令。

如果这些类的唯一目的是定义顺序，为什么不明确地这样做呢？

回答你的问题，虽然这样的设计会涵盖一些用例，但它对其他情况没有帮助，比如保险库边车、日志边车等。这已经是重新设计原始功能的提议。由于这是第二次尝试，因此这次将其做对是值得的。

我不知道依赖关系是多么复杂。你能详细说明一下吗？依赖使得 YAML 定义更加明显，没有隐藏的逻辑。使用硬编码类的方法需要隐藏的逻辑和更多的文档来解释为什么网络边车应该在其他边车之后运行，等等。

rubenhak 于 2020-02-19

👍4

如果我们在 Container 中引入一个字段会怎样？

    // +optional
    Priority int

此字段在相同类型（sidecar、normal）的容器中有效。
对于 sidecar 容器，优先级较高的 sidecar 容器将首先被实例化/最后被拆除。

tedyu 于 2020-02-19

@tedyu ，与“优先级”相比，依赖项具有更多元数据和价值。给定依赖项https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/需要 30 行 C++ 代码来生成优先级顺序。反过来是不可能的。

另一个好处是给定的依赖图可以同时启动某些容器。
在下面的例子中：如果 C 被初始化，“A -> B，B -> C，D -> C”容器 B 和 D 可以同时启动。我并不是说实现必须支持这一点，但至少如果 API 允许这样的定义，它会非常有价值。

rubenhak 于 2020-02-19

整数优先级不会很好地工作——人们会使用各种不同的、非标准化的数字，就像他们使用 CSS z-index 属性一样（如-9999 ）。

AndiDog 于 2020-02-19

@rubenhak您此时所建议的功能与本 KEP 中描述的功能基本上完全不同，这不是一个小调整，而是完全重写。这需要让之前同意此功能的每个人（花了一年时间才获得各方批准）重新评估此功能。
如果您对这样的功能充满热情，我建议您创建自己的 KEP 并将其带到各种 SIG 以获取他们的反馈。

当该提案于 2018 年开始时，对依赖图的想法进行了详细讨论，结论是一致的，尽管它可以启用更多用例，但它们的用例不够强大，并且增加的复杂性不值得。

我认为您有点低估了实现您所描述的内容所需的更改程度。但是，如果它像您想象的一样简单，您可以创建自己的概念证明，证明在 Kubernetes 中工作并将其提交给 SIG 以帮助加强您的案例。

此 KEP 还不是 GA 功能，如果您的 KEP 获得批准并实施，那么我们可以删除此功能。它们还不是相互排斥的。

Joseph-Irving 于 2020-02-19

👍16

这种变化可能不是每个用例的完美解决方案，但它极大地改善了大多数人的体验，我认为我们最好将其合并，然后再讨论一年的实施。

howardjohn 于 2020-02-19

👍15

如果您的 KEP 获得批准并实施，那么我们可以删除这个。它们还不是相互排斥的。

它们会_永远_相互排斥吗？

我在问自己这个功能是否有价值_即使_更明确的容器启动/关闭排序（我认为这会很棒）在未来通过另一个增强功能启用......我想是的。

任何启动/关闭顺序，即容器分类为 init、sidecar 或“常规”搁置所暗示的，这些分类也表达了_other_有用的，并且可以说是容器所需行为的无关方面，不是吗？

例如，它在带有restartPolicy != Always的 pod（可能是一个实现作业的 pod）中很有用，指定为 sidecar 的容器与进入完成状态的 pod 无关。

krancour 于 2020-02-19

👍2

@kfox1111 ，Vault 现在使用 sidecar 进行秘密注入。它应该适合哪个班级？此外，根据具体情况，Vault 可能依赖于服务网格，或者反过来。

我们通过 csi 临时驱动程序工作，以便像 vault 这样的东西不需要 sidecars/init 容器。我相信有一个保险库驱动程序正在开发中。

尽管带有 emptyDir 的常规边车似乎适合需要使用网络边车的边车？

kfox1111 于 2020-02-19

@Joseph-Irving，我绝不是想阻止这个 KEP 进入。我意识到你差不多 2 年前就开始了它，并且有很多人在等待它的发布。

您是否有与依赖图相关的先前讨论的链接？

rubenhak 于 2020-02-19

👍1

嘿@Joseph-Irving，

友情提醒，我们很快就会结束2020 年 3 月 5 日的代码冻结。看起来您的 PR 还没有合并，您是否仍然觉得您正在为此增强功能进行代码冻结？

jeremyrickard 于 2020-02-24

嘿@jeremyrickard ，API 审查（https://github.com/kubernetes/kubernetes/pull/79649）基本完成。我们将关闭该 PR 并完全进入实现 PR，以便它可以将所有（API 和实现）合并到一个 PR 中。

实施 PR (https://github.com/kubernetes/kubernetes/pull/80744) 已经过彻底审查，所以我正在尝试让一个 sig-node 批准者来看看最终批准。

这是否及时发生代码冻结我有点难说，这很大程度上取决于我是否设法及时引起了一些批准者的注意。

Joseph-Irving 于 2020-02-24

👍1

很想看到这个通过代码冻结进入。这将使 Istio 对https://github.com/istio/istio/issues/7136的解决方案既简单又更好。

duderino 于 2020-02-24

👍7 ❤1

关于这个进入 1.18 的任何动作？对于快速运行的作业，istio sidecars 似乎有必要按预期工作。

nfickas 于 2020-02-28

我尝试通过各种方式联系 sig-node 批准者，但我没有得到任何回应。所以我对这将成为 1.18 不是很乐观。

Joseph-Irving 于 2020-02-28

😕14 👀2

@Joseph-Irving 针对这些情况创建了#pr-reviews 松弛频道。你试过吗？这是提升公关评论的一种方式。（我在里面没看到）

rjbez17 于 2020-02-28

嘿@约瑟夫-欧文，

我们现在距离代码冻结只有几天的时间。您想根据审阅者的带宽将此推迟到 1.19 吗？或者尝试推动？

jeremyrickard 于 2020-03-03

❤1

嘿@jeremyrickard ，

没有人回应我关于在 1.18 中合并这些 PR 的问题，所以我非常怀疑这会发生。

我们可以推迟到 1.19，但我开始怀疑这样做是否有任何意义。
这个 KEP 已经运行了将近两年（最初的 alpha 目标是 1.15），有问题的 PR 已经开放了将近一年，他们从来没有任何“审阅者带宽”。
我礼貌地发电子邮件，放松，参加 sig-meetings，甚至亲自找到人来获得评论，但我们取得的进展很小。
我设法获得的任何评论都只提出了微小的更改，并不是要求进行大规模的重写，PR 都与一年前基本相同，只是稍微改进了一点。
我不知道我是否应该每天都积极地 ping 人，直到他们回应我，但这真的不是我喜欢做的事情。

我认为问题更多的是没有人真正关心这个功能，我是唯一一个推动这个功能前进的人，SIG 中似乎没有人有兴趣看透这个。如果进入 alpha 阶段需要两年时间，那么进入 beta/GA 需要多长时间？（就像大多数人实际上可以使用它一样）

令人沮丧的是，更广泛的社区和最终用户似乎确实对获取此功能感兴趣，我首先这样做的原因是我看到这是一个问题，询问 SIG 是否要修复它，然后他们说“我们没有能力，但我们很乐意让你这样做”。
所以我做了他们要求的一切，我写了 KEP，我得到了各方的批准，我写了所有的代码，所有的测试，在每个版本通过时不断更新，但我们已经到了。

每次我们拖延，我都觉得我让很多人失望了，这都是我的错吗？代码这么糟糕，没人会评论吗？我只是在试图引起注意方面不够积极吗？
只是觉得自己一个人做不完，打死马有点累了。

我很抱歉长篇大论（不是针对你个人杰里米或任何个人），但这已经慢慢侵蚀我的灵魂很长时间了。

Joseph-Irving 于 2020-03-04

👍63 ❤27 😕20

令人沮丧的是，更广泛的社区和最终用户似乎确实对获取此功能感兴趣，我首先这样做的原因是我看到这是一个问题，询问 SIG 是否要修复它，然后他们说“我们没有能力，但我们很乐意让你这样做”。

@Joseph-Irving 关于这个。作为一个活跃的用户，看这个帖子是因为我很感兴趣（我的两个同事也很感兴趣）。问题上的活动、拉取请求、slack 频道或 sig 可能不是对此功能感兴趣的最佳指标。

@dims也许你可以

itskingori 于 2020-03-04

@thockin大约一年前，我听到您在 Kubernetes Podcast 中接受采访，您谈到了为 Kubernetes 做出贡献。也许是你或其他播客节目中的其他人对这个边车 KEP 没有达到 1.16 感到非常难过。好，我们又到这里了。

这个问题似乎是一个很好的例子，说明如果您不是例如的员工，贡献可能会有多困难。 Google、RedHat 或其他大玩家。

pre 于 2020-03-04

👍4

我也在 Slack 中寻求帮助以对其进行审查，但只是被告知@thockin明确持有，所以我也不确定前进的道路。

jaygorrell 于 2020-03-04

我花了很多时间在临时 csi 驱动程序功能上。通过它同样令人沮丧，有时我不确定经过这么多次延迟和重新设计后它会成功。所以，我感受到了你的痛苦。如果我们能找到一种方法来减轻它的痛苦，那就太好了。话虽如此，我们也确实在错过了几个主要版本后最终获得了它。所以请不要放弃/失去希望！这艘船可能很难转弯，但最终还是会转弯。

kfox1111 于 2020-03-04

❤8

任何运行依赖于网络边车的任何拓扑的人很可能会遇到此 KEP 可能解决的容器启动/关闭排序问题。这张票上的“Istio”的Ctrl-F，你会看到一堆与容器订购相关的烦恼。

这里有 Istio 维护者吗？很多是 Google 员工，并且可能在内部对 K8s 人员有更多影响。

作为一家 Istio / K8s 商店，我们绝对支持您登陆，@Joseph-Irving！ ✊❤️

nicktrav 于 2020-03-04

❤12

感谢@Joseph-Irving 制作了这么远的边车。

即使对于 sidecar 生命周期管理，任何批处理作业都需要此功能，否则 Kubernetes 对他们不起作用，这就是为什么我们还花了很多时间帮助代码审查和提供反馈！

因此，我们已经分叉 k8s 一段时间了，我们真的很期待看到官方支持如此重要的功能。

zhan849 于 2020-03-04

👍1

作为一个 Istio + Kubernetes 的店铺，我们也一直在焦急地等待这个功能。并且越来越沮丧它从一个版本滑到另一个版本。我们不高兴不得不求助于黑客来杀死工作负载中的边车。对于我们的需求，这是我们在 Kubernetes 中需要的最重要的单一功能，已经超过一年了。

@thockin上面有报道说你已经明确地控制了这一点。你能解释一下原因吗。

pluttrell 于 2020-03-04

👍4

有很多 Linkerd 用户也在热切地等待这个。坚持住@Joseph-Irving，我们支持你。

wmorgan 于 2020-03-04

👍10 ❤3

不确定这里的其他人是否看到了，但在做了一些挖掘和观看 kubecon 视频后，我发现 Lyft 做了类似的事情。这是他们 kubernetes 分支中提到的提交： https :

nfickas 于 2020-03-04

作为一个 Istio + Kubernetes 的店铺，我们也一直在焦急地等待这个功能。并且越来越沮丧它从一个版本滑到另一个版本。

我是一个潜在的 istio 用户，但由于等待这样的功能而有点保持观望。尽管如此，在上面的讨论中，我不断看到一些事情让我认为，这里讨论的 sidecar 功能本身并不能解决 istio sidecar 在工作流程中的所有问题。不过可能会有所帮助。我认为这是停滞不前的部分原因。

使用 istio cni 驱动程序在 sidecar 中运行 istio 是如何工作的？我相信尝试访问网络的 init 容器仍然无法按照 istio 文档中的说明正常运行。

因此我上面的问题是网络边车是否是它自己的东西。

kfox1111 于 2020-03-04

👍2

这个问题似乎是一个很好的例子，说明如果您不是例如的员工，贡献可能会有多困难。 Google、RedHat 或其他大玩家。

哈！你不知道的是，这些人有时也会被卡住！

说真的，我很抱歉。我有借口，但这很糟糕，所以我不会打扰。

thockin 于 2020-03-04

❤6 😄2

为了澄清：
我并不是暗示我们不应该将其合并为 alpha 来获得有关该方法的一些反馈。总的来说，我认为它是合理的。我认为在用例中存在一些漏洞，例如它没有完全涵盖的服务网格。但这并不是阻止尽快获得此功能的理由，因此我们可以找到它未涵盖的所有其他用例，以便我们可以使该功能的 Beta 版本对每个人都适用。这正是 IMO 的 alpha。

我只是提到我所做的，特别是那些希望这将成为解决现有服务网格问题的灵丹妙药的人。我认为提议的 alpha 不会完全解决该特定问题。所以现在不要抱太大希望。但是请不要仅仅因为它不支持所有人而阻止此功能。

kfox1111 于 2020-03-04

我已经请求了一个例外，让我们看看我们是否可以尝试将其输入：
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

dims 于 2020-03-04

🎉29

也许是你或另一个 [Kubernetes Podcast] 剧集中的其他人对这个 Sidecar KEP 没有达到 1.16 感到非常难过

请参阅第72集83 集，与 Guinevere Saenger 。我什至在本周大声疾呼，需要进行公关审查才能解决这一问题。我们能做到！

这里有 Istio 维护者吗？很多是 Google 员工，并且可能在内部对 K8s 人员有更多影响。

@duderino和@howardjohn都已经对这个帖子发表了评论。

craigbox 于 2020-03-05

👍2

为了清楚起见，我们需要合并：
kubernetes/kubernetes#79649
kubernetes/kubernetes#80744

还有其他我们应该跟踪的 PR 吗？

谢谢！

增强团队

kikisdeliveryservice 于 2020-03-06

非常感谢所有发布支持信息（公开或私下）的人，非常感谢❤️

社区成员做出了勇敢的努力，试图将其纳入 1.18，包括接受延期请求的发布团队，但遗憾的是，已决定将其推迟到 1.19。你可以从这个评论开始看到相关的对话： https :

尽管它没有进入 1.18，但在过去几天中它受到的关注比很长一段时间内都要多，所以我希望这种势头能够延续到 1.19。

抄送@jeremyrickard ， @kikisdeliveryservice

Joseph-Irving 于 2020-03-06

👍49 ❤21 🚀12 🎉12

很棒的东西@Joseph-Irving，听起来您的一些挫折是值得的并且值得倾听。谢谢你的坚持。

andrew-waters 于 2020-03-06

/里程碑 v1.19

dims 于 2020-03-06

👎10 😕5

大家好。我们一群人在上周一直在讨论这个话题。

首先，我们为这里发生的事情道歉。我们对此并不满意。

该 PR 和相关的 KEP 揭示了该项目可以做得更好的许多事情。我们希望将社会、程序和技术问题分开。

在社交方面，这个功能成为我们取悦对方的愿望的牺牲品。尽管 SIG 内部表达了保留意见，但 Derek 还是批准了 KEP，因为 Clayton 和 Tim 正在推动它。我们都相互信任，但显然我们并不总是觉得我们能够说“不”。我们知道这一点，因为我们都做过完全相同的事情。我们谁都不想成为下一个伟大创意的阻碍。

相互信任必须包括相信我们可以说“不”，并相信当有人说“不”时，他们这样做是有充分理由的。这个技术领域跨越 SIG，我们不应该向 sig-node 施压，他们最终将成为解决问题的人，让他们接受他们尚不习惯支持的新功能。这不是特别针对 Tim、Derek 或 Clayton，但所有高级审批者和 SIG 负责人和“高级”贡献者。

此功能也成为围绕 KEP 的程序不确定性的牺牲品。作为 KEP 审核员，我是否有义务成为代码审核员？委托给代码审查者？还是只是为了阅读 KEP？由于 KEP 跨越多个版本，我们如何确保牧羊人可用于特定版本跨度中预算的一组更改。如果 KEP 跨越 SIG，我们如何在 SIG 之间预算和分配时间？我们需要澄清这一点。我们将制定一些 KEP 变更提案 (KEP KEP)，以加强 KEP 流程中角色的定义。

从技术上讲，此功能成为时间和注意力的牺牲品。审稿人没有花足够的时间来审阅它，或者只是对他们来说优先级不够高。来回讨论需要时间。环境和我们对问题空间的理解会随着时间而改变。

随着越来越多的用户采用 Kubernetes，我们看到越来越多的奇怪的边缘情况或薄片被报告给 sig-node。由于 Pod 生命周期是 Kubernetes 的核心，因此对该子系统所做的任何更改都必须谨慎进行。我们合并新功能的能力必须与我们提高可靠性的愿望相平衡。我们今天对 Pod 生命周期的看法与我们在启动此功能时的看法略有不同。这不会以任何方式减少导致此问题的用例，但它确实表明需要随着时间的推移定期重新审查长期运行的 KEP。

我们认为我们需要围绕 Pod 生命周期做一些第一性原则的思考。我们真正想要的是什么？我们试图不降低太多的复杂性，但我们担心我们只是将这种复杂性分解为多个阶段，最终结果可能比直接解决它更复杂。

这对这个 PR 和相关的 KEP 意味着什么？我们不是 100% 确定。不过，这可能意味着我们不应该推动它。

德里克对关机顺序提出了一些担忧。 KEP 暂时将它们称为超出范围，但有些犹豫。我们已经不尊重节点关闭时的优雅终止，这让许多用户感到惊讶。这不是这个 KEP 的错，但我们称之为“情有可原”。如果有人使用 sidecars 来“清理”他们的 pod（例如将缓存的日志排放到日志服务中），他们会期望（合理地）一些关于关闭的清晰和有用的语义，这个 KEP 不能保证。

Tim 担心 init-sidecars 需要成为一种东西，这感觉不对。过去他放弃了这种担心，但它仍然困扰着他。

我们需要 SIG 节点来帮助定义 Pod 生命周期的中期目标，以及他们对实现这一目标的兴趣。如果我们同意这是朝着目标迈出的渐进一步，我们就可以解锁它，但除非我们知道目标，否则我们可能会过度开大灯。

让我们都第一个说这很臭。我们有真正的问题陈述、热情的贡献者和一组善意的维护者，我们最终……在这里。蒂姆将自愿抽出时间帮助头脑风暴和设计。 Derek 将推动当前 Pod 生命周期的节点关闭工作，以确保我们有一个稳定的基础来进一步发展它。我们需要非常仔细地指定面对计划外的机器故障我们可以和不能做出的保证。

谢谢，
克莱顿、大卫、黎明、德里克、约翰、蒂姆

thockin 于 2020-03-11

👍39 ❤21 😕14

尝试推动一些前进的运动：Derek 或 Dawn - 有没有人可以抽出时间对更全面的 Pod 和容器生命周期进行一些头脑风暴？

thockin 于 2020-03-12

@thockin会将其添加到 sig-node 议程中。

derekwaynecarr 于 2020-03-19

@thockin @derekwaynecarr tl;dr 为什么这不能进入？

单行增强描述：容器现在可以被标记为边车，以便它们在正常容器之前启动并在所有其他容器终止后关闭。

在这个服务网格边车的新时代，听起来像是可以让生活更轻松的东西。

此外，对于今天在主应用程序容器终止后让边车在主应用程序容器之前启动并关闭的任何建议吗？

naseemkullah 于 2020-03-31

... tl;dr 为什么不能进入？

@naseemkullah来自https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 ...👇

这对这个 PR 和相关的 KEP 意味着什么？我们不是 100% 确定。不过，这可能意味着我们不应该推动它。
德里克对关机顺序提出了一些担忧。 KEP 暂时将它们称为超出范围，但有些犹豫。我们已经不尊重节点关闭时的优雅终止，这让许多用户感到惊讶。这不是这个 KEP 的错，但我们称之为“情有可原”。如果有人使用 sidecars 来“清理”他们的 pod（例如将缓存的日志排放到日志服务中），他们会期望（合理地）一些关于关闭的清晰和有用的语义，这个 KEP 不能保证。
[...]
我们需要 SIG 节点来帮助定义 Pod 生命周期的中期目标，以及他们对实现这一目标的兴趣。如果我们同意这_是朝着目标迈出的一步，我们就可以解锁它，但除非我们知道目标，否则我们可能会过度开大灯。

itskingori 于 2020-03-31

恕我直言，我很好奇是否有任何潜在客户计划优先解决这个问题。 @Joseph-Irving 在这方面投入了大量的工作，并且对他的解决方案感到满意的人数量惊人，他们急切地想从那些拒绝这个的人那里听到一些更好的解决方案。

krancour 于 2020-04-10

👍18

至少，即使它的一些方面存在疑虑，我认为作为 Alpha 进入以找出在实践中会出现的问题仍然是合理的。我们可以合并吗？这些问题可能会阻止它进入 Beta，所以我认为在制作初始 Alpha 之前变得完美并不重要。

kfox1111 于 2020-04-10

👍12

将此添加到 sig-node 议程。

@thockin @derekwaynecarr目前的状态有任何更新吗？我查看了 sig-node 会议记录，但没有看到任何关于此的信息。

该线程上有大量开发人员，他们非常乐意为实现这一点贡献时间，因为这对许多用例至关重要（KEP 本身的数量是任何其他 KEP 的 2.5 倍：+1：）。我们能做些什么来实现这一点？拥有该领域稳定性的先决条件列表，即使它可能跨越许多版本来完成，我们可以开始积极工作，这将是我们今天的巨大进步。

howardjohn 于 2020-04-17

👍30

嗨@Joseph-Irving @thockin @khenidak @kow3ns -- 1.19 增强功能在这里领导，我想检查一下，如果您认为此增强功能会在 1.19 中毕业？

为了有这部分的发布：

KEP PR 必须合并为可实施状态
KEP 必须有测试计划
KEP 必须有毕业标准。

目前的发布时间表是：

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

palnabarun 于 2020-04-29

@palnabarun ，根据此评论https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056，此 KEP 已被无限期搁置，因此不会在 1.19 毕业。

Joseph-Irving 于 2020-04-29

😕28

感谢@Joseph-Irving 澄清情况。：+1：

欣赏你的努力！

palnabarun 于 2020-04-29

👍2

对于所有渴望参与其中的人，再次感谢@Joseph-Irving - 我个人对这种情况感到非常抱歉。我也想要这个（或类似的东西），但事实是 sig-node 有比人们现在要做的更多的工作，他们还没有准备好考虑这个。

糟透了。我得到它。我真的很喜欢。

人们可以提供帮助的最佳方式是跳入 sig-node 并通过进行代码审查和问题分类、修复错误和测试以及向 sig-node 专家具有更多能力和有信心做出这样的改变。

thockin 于 2020-05-08

👍24 😕11 ❤1

sig-node 现在要做的工作比人们做的多

明白了。我们一直在重点宣传 sig-node 的内部容量需求。我们正在招募和指导 sig-node OSS 志愿者，其中一些经历了一些新的经历，所有人都希望在这个领域工作（目前有四个）。我会引用你的评论@thockin ，谢谢！

mikebrow 于 2020-05-08

/里程碑清除

palnabarun 于 2020-05-18

😕18

人们可以提供帮助的最佳方式是跳入 sig-node 并通过进行代码审查和问题分类、修复错误和测试以及向 sig-node 专家具有更多能力和有信心做出这样的改变。

@thockin您能否提供存储库、邮件列表、指南等链接？这将帮助人们了解如何有效地与 sig-node 互动。这个特殊的功能请求已经超过 2 年了，看不到解决方案。

tariq1890 于 2020-07-08

👍4

@tariq1890编写此 KEP 的人所做的一切都是正确的。他们不遗余力。这里的问题正是@thockin所说的，在我们考虑这个问题之前，我们需要先解决技术债务，并且需要人手来解决这个问题。所以要求人们帮助解决需要做的事情。

请在此处查看最新更新： https :

dims 于 2020-07-08

@dims我想我被误解了。我的意思是我们需要一份可操作的目标和目标清单。如果有技术债务需要处理，那么我们可以维护一个 GitHub 里程碑或在 OP 评论中提供待处理行动项目的项目符号列表，以便访问此问题的人可以立即知道需要解决的问题。

我绝对愿意为推进这个 KEP 的 sig/node 提供帮助，但只是不知道如何

tariq1890 于 2020-07-09

👍2

@tariq1890具体问题在这里：“（尚未提交的 KEP）kubelet 节点正常关闭的先决条件” https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR9

我们需要开始。必须有人抓住重点并让它继续下去。

-- 昏暗

dims 于 2020-07-09

所以总结https://github.com/kubernetes/enhancements/pull/1874对于这个问题的那些人：Sig-node（和其他人）认为引入像这个 KEP 这样的新功能是不明智的，它增加了更复杂的行为Pod 终止，而在节点关闭时仍然存在更通用的 Pod 终止问题。
因此，已决定在实施节点终止解决方案之前，此功能不会进展。
目前这里有一个谷歌文档： https :
其中包含很多围绕该问题的讨论，但尚未提交有关此问题的 KEP。
仍然存在悬而未决的问题，因此对此发表评论可能会有所帮助，我相信@bobbypage和@mrunalp正在领导这项工作，因此也许他们可以分享人们可以帮助推动这一

Joseph-Irving 于 2020-07-10

@Joseph-Irving 非常感谢您的总结。我希望此增强功能的所有 +ve 能量转化为每个人定期更多地参与 sig-node，而不仅仅是功能的一次性参与。有很多工作要做，而手却很少。

dims 于 2020-07-10

你好！不过，关于此 KEP 的另一条评论是：我在过去的 SIG 节点会议（6 月 23 日，如果您想观看录音）中提出了一些有关此 KEP 的边缘案例，我们决定继续讨论的正确方法是打开有关这些 KEP 的 PR问题，以便我们可以决定如何最好地进行。

我目前正在做一个 PR 来陈述这些问题和我能想到的一些替代方案。

此外，KEP 状态现在是临时的（而不是可实施的），因此可以对其进行审查，并且只有在所有人都同意继续推进 KEP 时才将其设置为可再次实施。

我认为这是本期唯一缺少的信息。谢谢！

rata 于 2020-07-16

@rata您是否以正确的方式打开问题/ PR 来处理问题？

mattfarina 于 2020-08-18

@mattfarina这是公关https://github.com/kubernetes/enhancements/pull/1913
它包含许多针对 KEP 中当前问题/边缘情况的建议解决方案
还包含许多讨论过和决定反对的替代方案的详细信息，以便我们更好地记录做出某些决定的原因。

Joseph-Irving 于 2020-08-18

👍1

我非常希望看到 sidecar 功能也涵盖缩放：
今天，HPA 扩展基于一个指标（例如 cpu）。如果 pod 包含多个容器，则使用所有容器的平均值（据我所知）。对于带有 sidecar（app+nginx 等）的 pod，这使得很难正确地实现缩放功能。我希望 Kubernetes 中的 sidecar 实现包括将 pod 中的一个容器标记为“权威”，就用于 HPA 扩展的指标而言。