江苏龙网

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

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


为了处理服务发现和负载平衡 ， 我们使用了 Route53（DNS）、ALB（应用程序负载均衡器）和 gRPC 客户端负载均衡（可以是原生的 ， 也可以通过 Envoy） 。 我们预计今年晚些时候还会开展进一步的工作 。
6
我们为什么不使用 Kubernetes？
运行 Kubernetes 不能解决任何客户（工程）问题 。 相反 ， 运行 Kubernetes 实际上会产生一系列新的问题 。
我们就需要组建一支全职的计算团队 。 尽管随着发展 ， 我们可能会这样做 ， 但运行 Kubernetes 的话 ， 我们立即就需要这样做 ， 这样才能集中精力构建数十个集群（可能每个团队 / 组织都是分开的） ， 开始研究 / 构建封装 / 胶水工具 ， 开始构建抽象控制平面 / 服务网格 ， 等等 。
保护 Kubernetes 安全不是一项轻松简单或易于理解的操作 。 为了使我们能够拥有 / 运营 Kubernetes ， 我们整个平台中使用的工具和控件（Odin、ASG、Step Deployer——以及它们依赖的东西）都要有 。 构建相同的原语 ， 提供与目前相同的安全级别 ， 对于（未来的）计算团队和我们的安全团队来说都是一项非常大的投资 。
托管的 Kubernetes（AWS 的 EKS、谷歌的 GKE）还处于起步阶段 ， 拥有 / 运营 Kubernetes 的大多数挑战都尚未解决（如果有什么问题的话 ， 就更困难了） 。 在 AWS ， 为了运行 EKS ， 他们正在扩充支持 / 运营团队 ， 而在谷歌 ， GKE 中断数小时的情况并不少见（参见这里 。 你只是把一些运营问题和挑战转移给了另一个运营团队（而可见性大幅降低了） 。
集群升级和管理要比我们现在所做的操作多很多 。 合理运行 Kubernetes 的唯一方法是让团队 / 组织拥有自己的集群（类似于让他们有自己的 AWS 帐户或 GCP 项目） 。 即使有了 Istio 和相关工具 ， 升级集群和修补漏洞也不是一件容易的事 。 通常 ， 你必须构建 / 运行一个辅助集群 ， 将所有的应用程序故障转移 ， 然后在升级后进行故障恢复 。 目前 ， 这个原语还没有构建到任何抽象中 。 虽然托管集群（GKE）中可能提供了 ， 但它并不总是像你预期的那样工作 ， 并且启动后回滚通常也没有得到很好的处理 。
如今 ， 我们没有这个负担 。 我们运行在一个坚固的操作系统上 ， 几乎没什么依赖 。 我们的 AMI 上线是从开发开始 ， 然后经过数周的测试再继续 。 如果需要回滚 ， 只需要简单地更改一行代码就可以实现 。 平均而言 ， 我们每个月花在与这个领域密切相关的任何事情上的时间都不到 5 小时 。
7
Kubernetes 安全保护
让我们看一下 ， 在一个保存了超过 80 亿美元加密资产的企业中 ， 运行 Kubernetes 并保证其安全的复杂性 。
https://blog.coinbase.com/our-focus-on-the-institutional-space-5c8e87332268
组件
保证 Kubernetes 集群安全的基础知识众所周知 ， 但是如果需要对其中的每一项都做深入的研究 ， 复杂性就来了 。 保护所有系统组件（etcd、kubelet）、API 服务器和任何抽象 /Overlay（Istio）的安全 ， 就有许多东西需要理解、测试和保护 。 考虑到攻击面增加 ， 必须要深入研究命名空间、seccomp、SELinux、cgroups 等 。 Kubernetes 非常大 ， 它有自己的 CIS 基准测试和 InSpec 套件（谢天谢地） 。
https://www.cisecurity.org/benchmark/kubernetes/
https://github.com/dev-sec/cis-kubernetes-benchmark
漏洞
下面是一个简短的列表 ， 可以作为漏洞研究的起点：
CVE-2019–5736（8.6 高）：使攻击者可以改写主机的二进制文件 runc（从而获得主机 root 访问权限） 。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736
CVE-2019–11246（6.5 中）：如果容器中的二进制文件 tar 存在恶意代码 ， 它就可以运行任何代码并输出意料之外的不良后果 。


推荐阅读


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

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