Matthias Endler最近发表了一篇关于《 你是否真的需要Kubernetes？》的博文，在这里我将尝试解释为何我认为Kubernetes值得一探究竟，即使你只是单单想运行一些容器。
免责声明：这并不奇怪，我对此存在偏见。我们在Zalando运行了100多个Kubernetes集群[1]，并且我在Kubernetes这个项目上投入了大量资金（你可以在我的GitHub Repo[2]上看到）。你们不必要都听取我的意见，接下来将进入正文。
Matthias Endler写道：Kubernetes是一个十分强大的容器编排系统。它在全球范围内已广受使用，支持了一些很大型的部署，但同时它也伴随着一些代价。
特别是对于规模较小的团队而言，会因为维护它并且因它的学习曲线陡峭导致大量耗时。我认为Kubernetes的内聚和可扩展性API很重要，学习它也是非常值得的，即便你仅仅只想运行一堆容器。
Apache Mesos，http://mesos.apache.org/
AWS ECS，https://aws.amazon.com/ecs/
AWS Elastic Beanstalk（在这个讨论结果[3]中我感觉可以忽略掉），https://aws.amazon.com/elasticbeanstalk/
AWS Fargate（无服务器类型容器），https://aws.amazon.com/fargate/
docker run（一个简单可行的选择）
HashiCorp Nomad，https://www.nomadproject.io/
Kubernetes（托管或自托管），https://kubernetes.io/
更多你可能喜欢的选择
以上只列出了我个人调研过的选项，所有的这些基本能满足需求，但是它们提供的用户接口差别很大：Mesos提供了容器编排，但不提供一致性的API（比较Marathon和Chronos），而且在近期我没见过任何有使用它的公司。AWS ECS，Beanstalk和Fargate是运行容器化工作负载的选择，但与所有专有AWS产品一样，要求你对AWS的工作模式有一定的信奉。这意味着你会拥有一个具有速率限制的AWS API，并紧紧依赖着AWS Lambda。AWS ECS被许多组织所使用，并且已被证实是一个可靠的选择，但它仅提供一组有限的功能和不可扩展的API。Blox试图解决它的一些痛点，但从最近的提交记录来看它似乎已经停滞了（最后一次提交还是在1年前）。Nomad似乎是一个非常棒的项目，专注于简单性并且很好地与HashiCorp公司蓝图集成，但是它提供了一个更窄的、不可扩展的HTTP API。
提供了足够的抽象来涵盖大多数应用程序用例：滚动部署，服务端点，入口路由，有状态工作负载，定时批处理任务
提供了一致性（通用型结构，OpenAPI规范模式，版本，元数据标签/注释，规格和状态字段）
可通过自定义注释扩展，即Custom Resource Definitions（CRDs），以及APIserver聚合
提供一定的兼容性保证（通过版本控制）
被广泛采用（所有主流云提供商都提供托管解决方案）并在其之上打造了庞大的生态系统
跨环境和实现工作：作为Kubernetes API的原生用户，我实际上并不关心节点是如何实现的，甚至它们是否是虚拟的
我可以创建例如kube-ops-view[4]， kube-downscaler[5]和kube-janitor[6]这样的开源工具，确保它们能工作于任何标准的Kuberntes API上，无论是托管的还是自托管的。我个人没有动力将我的时间投入到AWS ECS这种我不精通而且市场份额有限的专有技术上，我认为这种网络效应将会盛行，我们将会看到越来越多的Kubernetes高级工具（apps、operators和其他等等）。
为何关心Kubernetes API是否是可扩展的？因为你迟早会遇到基础架构API不能100%覆盖到的用例，或者是你需要与现有的组织蓝图进行集成。Kubenetes允许你使用自定义资源（即CRDs）来扩展它的API，例如Zalando使用它来集成其现有的OAuth基础架构以进行服务到服务身份验证。自定义资源同时允许你在核心概念之上构建更高层级的抽象，例如Kubernetes StackSet Controller向API添加来一个新的StackSet资源，用于管理应用程序生命周期和流量切换。更多关于自定义资源的通用用例存在于Operators这个项目，这些Operators为许多工作负载定义了CRD，例如PostgreSQL、etcd、Prometheus和Elasticsearch（Zalando计划发布一个支持自动扩展的定制的Elasticsearch operator[7]）。
也许我不是第一个写这个的人，但我经常将Kubernetes API与Linux内核做比较：这个领域整体向Linux内核API靠拢（当我们谈论容器时，99％以上指的是Linux内核功能，如cgroups/namespaces），现在我们看到了Kubernetes API类似的趋势。或许它可能不是内核而是systemd？
运行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从未如此简单，但像kind和 k3s这样的新项目仍需要持续不断改进。
Matthias Endler在 他的博文中写道：研究结果就是：不要仅仅因为其他人都使用Kubernetes你就要去用它，仔细评估你的需求并检查哪些工具能更符合场景。我当然同意这一说法，但以我的经验来看，人们从容器编排开始时经常会忽视“标准”Kubernetes API的价值（它不是他们的要求清单的一部分）。当我告诉他们这个事实标准，我对Kubernetes的主要论点是可扩展的API时感到非常惊讶。我知道很多公司正是因为这个原因而从AWS ECS切换到EKS：他们必须专门针对ECS去解决问题，但对于Kubernetes他们可以使用现有的为Kubernetes API创建的开源工具。虽然你不应该只是“因为每个人都这样做”就跳进Kubernetes这个“坑”，它的用户（组织）名单固然是一个优势，特别是对学习生产操作来说。我开始收集一些Kubernetes的失败案例[8]，除了利用庞大的社区和改善基础设施运营之外没有其他原因（对托管和自托管而言都是如此）。我还没有看到其他容器编排系统有着同样广泛的列表，并且，没找到失败案例并不意味着不存在失败;-)
不要低估Kubernetes的复杂性，但同时也不应该忽视Kubernetes API及其生态系统的价值。
并且不要忘记，五年内将不会再有人关心Kubernetes，因为它将变得无处不在;-)
这就是互联网，到处都存在不同的见解。做出决定，并知道权衡取舍。
相关链接：
https://www.youtube.com/watch?v=4QyecOoPsGU
https://github.com/hjacobs
https://twitter.com/QuinnyPig/status/1070848346992963584
https://github.com/hjacobs/kube-ops-view
https://github.com/hjacobs/kube-downscaler
https://github.com/hjacobs/kube-janitor
https://twitter.com/otrosien/status/1110587374805966849
https://srcco.de/posts/kubernetes-failure-stories.html
原文链接：https://srcco.de/posts/why-kubernetes.html
8425
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
