（译）Matt Klein 的 KubeCon 作业
偶尔看到他在刷屏，说了些最近我常不小心触及的问题，就凑一篇更新了。
参加过了今年的 KubeCon，我现在已经返回圣克劳德，有些感想，不吐不快。
CNCF 技术栈已经走向成熟，但（这些产品）仍然停留在预制件的阶段。最终用户还在为如何将这些工具进行组合应用而绞尽脑汁。最终还经常会被迫接受并不需要的复杂性。
在降低复杂性方面，厂商生态并无建树——刚好相反，激烈的竞争、FUD 以及一些（商业）诋毁让最终用户更加困惑。CNCF 在这里也无能为力：官方的 Landscape 已经大到令人不解，失去了应有的作用。我们应该做得更好。
百度说：FUD就是恐惧（Fear）、不确定（Uncertainty）、怀疑（Doubt）的缩写，是行业垄断巨头对付比弱小竞争对手时使用的竞争手段之一。
从积极的态度上来看，的确存在大型的复杂的组织部署 CNCF 技术的成功案例，这的确是值得一看的事情。
较小的组织只想运行自己的业务，不希望增加不必要的复杂性，如何能让他们分享胜利果实而不受困扰呢？对厂商来说，在产品手册之外，提供更多的接地气的教育和案例研究，应该会很有帮助。
恕我直言，会议本身需要发展，来更好地满足不同与会者的多样化需求：新用户、老用户、供应商、项目维护者和合作者等。与此相比，我更希望看到一组有针对性的并置微型会议（扩展第 0 天的同场活动）。
在开源策略方面，Google 拒绝向 CNCF 捐献 Istio 和 Knative 的短视决策，造成了超出我想象的焦虑。分叉出来一个的“OpenIstio”，已经不是玩笑了，时间会证明一切。
转到 EnvoyProxy，Envoycon 和维护者会议都令人愉快。我喜欢与用户交谈，Envoy 的部署量让我感到震惊。有趣的是，我怀疑 Envoy 大规模生产的使用已经超过了 Kubernetes。
我并不急于开设 Envoy 的相关公司，这个决策已经在过去每个会议周期上得到验证，充满活力和真正成功故事的社区，已经一去不复返了。
最后会说回开源软件的问题，CNCF 技术被大量的能量、热情和金钱所包围。然而也需要直面维护者倦怠的问题。2020 年，我们需要想方设法让更多最终用户参与进来，缓解倦怠和过度劳累的问题。
我自己的沟通体验来说，许多最终用户想提供帮助，他们只是不知道如何入门、或受到雇主制约。CNCF 可以并且应该在贡献者加入和项目服务方面提供更多支持，来给维护者减负。
在圣地亚哥，我参加了很多精彩的技术对话。我们在云原生的路上已经走了很远，对于很多尚待完成的工作，我依然充满期待。
腾讯云开发者
