InfoQ|我们为什么不用Kubernetes？( 二 )
容器使工程师在本地开发、测试和运行应用程序的方式与在其他环境（过渡环境和生产环境）中运行的方式相同或类似 。 容器允许描述依赖绑定关系 ， 可以是显式的 ， 也可以是隐式的（操作系统总是包含服务所依赖的包 $foo） 。 容器允许更小的服务封装和资源定义（使用 X CPU 和 Y GB 内存） 。 容器让你可以考虑水平伸缩应用程序 ， 而不是垂直伸缩应用程序 ， 从而实现更健壮的架构 。
其中一些观点可能还需要进一步地讨论 。 为了推动对话 ， 这些观点都有点过于大胆和发散 ， 因为这并不是在讨论容器化或服务化（service-ification）的利弊（例如 ， 将单个应用程序拆分为许多更小的独立运行的服务） 。
3
虚拟化呢？
虚拟化的概念是指能够在一个 OS 虚拟化系统] 上运行多个容器 。 容器只能看到授权给它的设备 / 资源 。 在 AWS 这样的托管计算平台上 ， 你实际上是运行在一个管理程序之下 ， 它管理运行你的操作系统和容器的 VM 。
本文插图
简图
虚拟化使当今的容器世界成为可能 。 如果没有虚拟化能力 ， 那么现在是不可能使硬件资源在容器中运行多个应用程序的 。
4
容器编排平台（Mesos、Kubernetes、Docker Swarm）有什么问题需要解决？
容器编排平台解决以下几类问题：
【InfoQ|我们为什么不用Kubernetes？】托管 / 标准化部署工具（部署）；
根据一些定义好的启发式规则扩展应用程序（横向扩展）；
当出现故障时重新调度 / 移动容器（自愈） 。
有些平台可能声称他们有其他特性 ， 如存储编排、秘密 / 配置管理和自动装箱 。 但实际上 ， 如果要把它们应用于大规模安装 ， 就需要大量的投资 ， 要么是在分支 / 定制方面 ， 要么是在集成与分离方面 。
例如 ， 大多数运行大型容器编排平台的人都无法使用其内置的秘密或配置管理 。 这些原语通常不是为几十个团队中的几百名工程师设计或构建的 ， 而且通常不包括能够让他们稳健地管理、拥有和操作应用程序所需的控件 。 对于提供更强保证和控制（更不用说扩展）的系统 ， 人们通常会把秘密管理和配置管理分开 。
类似地 ， 对于服务发现和负载均衡 ， 将其分离出来并运行 Overlay 或抽象控制平面是很常见的 。 人们经常会部署 Istio 为 Kubernetes 处理这个问题 。 管理和运行 Istio 并不是一项简单的任务 ， 许多现代化集群宕机都是由对这个控制平面 / 服务网格的错误配置以及对其细节缺乏理解造成的 。
5
我们用什么作为容器编排平台？
我们的容器编排平台是 Odin + AWS ASG（自动伸缩组） 。 当你在 Codeflow（我们用于部署的内部 UI）上点击 Deploy 时 ， Odin 将通过 Codeflow 的 API 调用被激活 。 Odin 启动一个 Step Function 并开始部署应用程序 。 AWS 上会新启动一个 VM 并将其加载到新的 ASG 中 ， 软件都是从各种内部位置获取的 ， 负载均衡器开始对这些新实例进行健康检查 ， 最终 ， 流量以蓝 / 绿方式切换到负载均衡器后面新 ASG 中的新主机上 。
https://github.com/coinbase/odin
https://blog.coinbase.com/scaling-developer-productivity-d23ce491f869
我们的容器编排平台非常简单 。 我们启用了与 Kubernetes 相同的关键特性：Codeflow 中有一个 Deploy + Rollback 按钮 ， 基于一些定义好的启发式规则（我们支持自定义 AWS 指标或标准 CPU 指标）进行伸缩 ， 并能在 ASG 中的 VM 宕掉或变得不健康时重新调度 / 移动容器 。
为了处理秘密和配置管理 ， 我们构建了一个动态配置服务 ， 它为所有内部客户提供库 ， 第 95 百分位延迟为 6ms 。 它后台基于 DynamoDB ， 每分钟可以为成百上千个同步和异步方法请求提供服务 。
推荐阅读
- 情感|华为今天如此成功，看一下任正非的岳父是谁，你就知道为什么
- 华为手机|泪奔！等等党的心酸，为什么有些手机它偏不降价？
- 36氪|为什么说远程办公也许会毁了硅谷?
- 硅谷|为什么说远程办公也许会毁了硅谷?
- 科技造就未来|Apple为什么要使用ARM？为什么不从头开始？
- |为什么我店铺流量狂掉？淘宝竞争这么激烈还能不能做？
- 科学,探月|嫦娥五号年内升空 我们为什么要去月亮上“挖土”？
- 科学|嫦娥五号年内升空 我们为什么要去月亮上“挖土”？
- 混乱|我们处在一个重新认识和定义品牌价值的混乱时代
- 互联网|你的聊天内容可能正“被窃听”