为什么需要Kubernetes?

Matthias Endler最近发表了一篇关于《你是否真的需要Kubernetes?》的博文,在这里我将尝试解释为何我认为Kubernetes值得一探究竟,即使你只是单单想运行一些容器。 免责声明:这并不奇怪,我对此存在偏见。我们在Zalando运行了100多个Kubernetes集群,并且我在Kubernetes这个项目上投入了大量资金(你可以在我的GitHub Repo上看到)。你们不必要都听取我的意见,接下来将进入正文。 Matthias Endler写道:

Kubernetes是一个十分强大的容器编排系统。它在全球范围内已广受使用,支持了一些很大型的部署,但同时它也伴随着一些代价。 特别是对于规模较小的团队而言,会因为维护它并且因它的学习曲线陡峭导致大量耗时。

我认为Kubernetes的内聚和可扩展性API很重要,学习它也是非常值得的,即便你仅仅只想运行一堆容器。 # 运行容器 假设你将要运行一堆容器,你会有哪些选择?(以下按字母顺序排列) 以上只列出了我个人调研过的选项,所有的这些基本能满足需求,但是它们提供的用户接口差别很大:Mesos提供了容器编排,但不提供一致性的API(比较MarathonChronos),而且在近期我没见过任何有使用它的公司。AWS ECS,Beanstalk和Fargate是运行容器化工作负载的选择,但与所有专有AWS产品一样,要求你对AWS的工作模式有一定的信奉。这意味着你会拥有一个具有速率限制的AWS API,并紧紧依赖着AWS Lambda。AWS ECS被许多组织所使用,并且已被证实是一个可靠的选择,但它仅提供一组有限的功能和不可扩展的API。Blox试图解决它的一些痛点,但从最近的提交记录来看它似乎已经停滞了(最后一次提交还是在1年前)。Nomad似乎是一个非常棒的项目,专注于简单性并且很好地与HashiCorp公司蓝图集成,但是它提供了一个更窄的、不可扩展的HTTP API。# Kubernetes API对比上面的选项,对我来说,Kubernetes唯一的卖点是:
  • 提供了足够的抽象来涵盖大多数应用程序用例:滚动部署,服务端点,入口路由,有状态工作负载,定时批处理任务
  • 提供了一致性(通用型结构,OpenAPI规范模式,版本,元数据标签/注释,规格和状态字段)
  • 可通过自定义注释扩展,即Custom Resource Definitions(CRDs),以及APIserver聚合
  • 提供一定的兼容性保证(通过版本控制
  • 被广泛采用(所有主流云提供商都提供托管解决方案)并在其之上打造了庞大的生态系统
  • 跨环境和实现工作:作为Kubernetes API的原生用户,我实际上并不关心节点是如何实现的,甚至它们是否是虚拟的
我可以创建例如kube-ops-viewkube-downscalerkube-janitor这样的开源工具,确保它们能工作于任何标准的Kuberntes API上,无论是托管的还是自托管的。我个人没有动力将我的时间投入到AWS ECS这种我不精通而且市场份额有限的专有技术上,我认为这种网络效应将会盛行,我们将会看到越来越多的Kubernetes高级工具(apps、operators和其他等等)。为何关心Kubernetes API是否是可扩展的?因为你迟早会遇到基础架构API不能100%覆盖到的用例,或者是你需要与现有的组织蓝图进行集成。Kubenetes允许你使用自定义资源(即CRDs)来扩展它的API,例如Zalando使用它来集成其现有的OAuth基础架构以进行服务到服务身份验证。自定义资源同时允许你在核心概念之上构建更高层级的抽象,例如Kubernetes StackSet Controller向API添加来一个新的StackSet资源,用于管理应用程序生命周期和流量切换。更多关于自定义资源的通用用例存在于Operators这个项目,这些Operators为许多工作负载定义了CRD,例如PostgreSQLetcdPrometheusElasticsearchZalando计划发布一个支持自动扩展的定制的Elasticsearch operator)。也许我不是第一个写这个的人,但我经常将Kubernetes API与Linux内核做比较:这个领域整体向Linux内核API靠拢(当我们谈论容器时,99%以上指的是Linux内核功能,如cgroups/namespaces),现在我们看到了Kubernetes API类似的趋势。或许它可能不是内核而是systemd?
1.png
# 运行KubernetesKubernetes虽然很复杂,但建立Kubernetes(集群)却不一定非常复杂或是昂贵:在DigitalOcean上创建一个集群只需不到4分钟而且相当便宜(3个小节点每月仅需30美元,每个节点配备有2 GB内存和1个CPU)。所有主流的云提供商都提供有托管型的Kubernetes产品,虽然有些不足使得开始使用存在不必要的困难。使用K3s可以更轻松地在Raspberry PI上运行Kubernetes 。无论实现如何,Kubernetes API都很有价值:Virtual Kubelet允许你在不关注节点的情况下运行工作负载。Microsoft已在其Azure云中提供此功能(AKS虚拟节点)。你甚至可以尝试使用virtual-kubelet和AWS Fargate。现在有很多选择可以在本地运行Kubernetes API进行开发或测试:
  • Minikube(KVM或Virtualbox)
  • kind(Docker中的Kubernetes,尤其是CI/CD管道)
  • k3s(轻量级Kubernetes,可以在Linux桌面或Raspi上运行)
虽然在本地运行Kubernetes从未如此简单,但像kindk3s这样的新项目仍需要持续不断改进。 Matthias Endler在他的博文中写道:

“研究结果就是:不要仅仅因为其他人都使用Kubernetes你就要去用它,仔细评估你的需求并检查哪些工具能更符合场景。”

我当然同意这一说法,但以我的经验来看,人们从容器编排开始时经常会忽视“标准”Kubernetes API的价值(它不是他们的要求清单的一部分)。当我告诉他们这个事实标准,我对Kubernetes的主要论点是可扩展的API时感到非常惊讶。我知道很多公司正是因为这个原因而从AWS ECS切换到EKS:他们必须专门针对ECS去解决问题,但对于Kubernetes他们可以使用现有的为Kubernetes API创建的开源工具。虽然你不应该只是“因为每个人都这样做”就跳进Kubernetes这个“坑”,它的用户(组织)名单固然是一个优势,特别是对学习生产操作来说。我开始收集一些Kubernetes的失败案例,除了利用庞大的社区和改善基础设施运营之外没有其他原因(对托管和自托管而言都是如此)。我还没有看到其他容器编排系统有着同样广泛的列表,并且,没找到失败案例并不意味着不存在失败;-) # 结论 不论如何你都不得不以某种方式去投资你的基础架构设施,即使对于像ECS这样的托管平台,你也需要学习特定的概念,抽象以及如何避开陷阱。我相信Kubernetes可以让你在云提供商间,环境甚至雇主间更好地利用所学知识。 不要低估Kubernetes的复杂性,但同时也不应该忽视Kubernetes API及其生态系统的价值。 并且不要忘记,五年内将不会再有人关心Kubernetes,因为它将变得无处不在;-)
twitter-kubernetes-five-years.png
这就是互联网,到处都存在不同的见解。做出决定,并知道权衡取舍。 原文链接:Why-Kubernetes (翻译:冯旭松)

0 个评论

要回复文章请先登录注册