江苏龙网

  1. 首页 > 资讯 > 科技 > >

InfoQ|我们为什么不用Kubernetes？( 五 )


如果提供 Kubernetes（或任何其他容器编配平台）我们的工程师可以从中获得显著的收益时 ， 我们才会研究提供它们 。 现在 ， 提供 Kubernetes 并没有什么明显的好处 。 如果 Kubernetes 提供了许多我们现在没有的新特性 ， 偿清了技术债务 ， 或者我们的客户需要它们可以提供的新功能 ， 而我们在可预见的将来都无法提供 ， 这种情况就可能会改变 。 如果妨碍其进入我们当前平台的因素发生了显著的变化 ， 并且它有了明显的独特之处 ， 那么我们也会研究提供一个不同的平台 。
如果 / 当我们现有的平台达到了极限 ， 由于缺少客户需要的特性而负担太重或者可以预见将会负担太重 ， 而扩展我们平台的工作又过于繁重 ， 或者中断太多违反我们的 SLA ， 那么我们可能会重新审视不同的容器编排平台 。
如果 / 当我们失去了主要上游依赖方（如 AWS 或 ASG）的支持 ， 我们也会考虑其他选项 。
这是我们可能会选择研究另一个容器编排平台的几个理由 。 目前 ， 我们还没有构建、拥有、运营 Kubernetes 的计划 。
Kubernetes 不是解决了像再平衡 / 自愈、自动扩展和服务发现等多方面的问题吗？我们现在是如何解决这些问题的？
在规模较小时 ， Kubernetes 解决了这些问题中的大部分 ， 而且也不是很麻烦 。 在规模较大时 ， 就需要更多的思考和胶水代码 ， 并在几乎所有的东西上增加封装器 / 安全保护 ， 以使其能够安全可靠地工作 。 通常 ， 如前所述 ， 人们倾向于添加 Istio 这样的服务网格来支持更高级的特性 / 需求 。
目前 ， 我们是这样解决的：
借助 Odin 和 ASG 实现再平衡 / 自愈；
借助 DNS 和 Envoy 实现服务发现 。
Kubernetes 有存储编排 ， 我们目前还没有 ， 我们应该有吗？
现在 ， Coinbase 有两个主要的有状态应用程序——区块链节点和交易引擎 ， 它们可能是存储编排等特性的潜在用例 。 对于前者（区块链节点） ， 存储的使用定制化程度很高 ， 我们构建了一个自定义的部署器 ， 为它们提供所需的特性 。 对于后者（交易引擎） ， 我们依赖可靠性（SRE）团队为他们的一些特定挑战提供支持 。
虽然 Kubernetes 内置的存储编排对于区块链节点和交易引擎来说都是一个很好的起点 ， 但是我们在底层技术中遇到的很多问题仍然存在 。
9
如果 Kubernetes 不是容器编排平台的未来 ， 那么什么才是？
对于部分应用程序 ， 我们将探索并迁移到更高级的抽象服务 。 我们将探讨把 Fargate 和 ECS 作为这方面的候选者 。 目前的首要原因是利用率和成本的增加——这两者都不是很以客户为中心 。 我们可以选择再等等 ， 到我们有更多以客户为中心的理由时才实施 。
以客户为中心的潜在问题可能是部署时间、部署模式（除了金丝雀之外）、比目前更复杂的服务网格需求 ， 或者在现有的工具中构建不可能 / 不合理但可以添加到 Fargate 或 ECS 的特定改进 / 特性 。 这些是一些潜在的以客户为中心的问题 ， 这些问题可能会有 ， 但目前还不知道或没有发现 。
在理想情况下 ， 向另一种底层容器技术的转移是不可见的 ， 因为与它们交互的工具不会从根本上改变 。 迁移到不同的平台可能会揭示出关于现有系统隐藏的或未知的期望 。 如何在过渡环境和生产环境部署和调试服务仍然是抽象的 ， 但是可能提供了一些现在没有的特性 。
InfoQ|我们为什么不用Kubernetes？
本文插图
10
我 / 我们讨厌 Kubernetes 吗？它是一个失败的容器平台吗？
不 。 尽管存在挑战 ， 但它是一个了不起的工具 。 Kubernetes 已经将我们的行业推向了一个越来越积极的方向 。 随着 Kubernetes 进入 v1 版本 ， Knative、Fargate 和 Cloud Run 的开发正在不断提高抽象级别 ， 并解决管理 Kubernetes 的潜在挑战 。 未来是光明的 。 随着这些潜在的挑战得到解决 ， 许多现存的问题未来可能会得到缓解 。


推荐阅读


上一篇：cnBeta|[图]TikTok重申：计划停止对 iOS 系统剪贴板的访问

下一篇：创业者李孟|2020年升降式结构的新机明显少了，到底有怎样的优缺点？