主持人 > 博客 > 管理 > 你可能不需要 Kubernetes

你可能不需要 Kubernetes

你可能不需要 Kubernetes
骑摩托车的女孩。 插图 freepik, 游牧标志来自 HashiCorp

Kubernetes 是容器编排领域的 300 磅重的大猩猩。 它适用于世界上一些最大的容器系统，但价格昂贵。

对于较小的团队来说特别昂贵，这将需要大量的支持时间和陡峭的学习曲线。 这对我们的四人团队来说太大了。 所以我们开始寻找替代品 - 并且爱上了 游牧.

你想要什么

我们的团队支持许多常见的性能监控和分析服务：用 Go 编写的指标 API 端点、Prometheus 导出、Logstash 等日志解析器和 咕噜，以及 InfluxDB 或 Elasticsearch 等数据库。 这些服务中的每一个都在其自己的容器中运行。 我们需要一个简单的系统来保证一切正常运行。

我们从容器编排的要求列表开始：

  • 在许多机器上运行一组服务。
  • 正在运行的服务概述。
  • 服务之间的链接。
  • 如果服务出现故障，自动重新启动。
  • 由小团队维护基础设施。

此外，以下内容也不错，但不是必需的补充：

  • 根据机器的功能对其进行标记（例如，为具有用于繁重 I/O 服务的快速磁盘的机器进行标记）。
  • 能够独立于编排器运行服务（例如，在开发期间）。
  • 共享配置和秘密的公共场所。
  • 指标和日志的端点。

为什么 Kubernetes 不适合我们

当我们使用 Kubernetes 进行原型设计时，我们注意到我们正在添加我们严重依赖的越来越复杂的逻辑层。

例如，Kubernetes 通过以下方式支持内置服务配置 配置映射。 您很快就会感到困惑，尤其是在合并多个配置文件或向 pod 添加其他服务时。 Kubernetes（或 舵 在本例中）允许您动态实现外部配置来分离关注点。 但这会导致您的项目和 Kubernetes 之间产生紧密的、隐藏的耦合。 但是，Helm 和 ConfigMaps 是附加选项，因此您不必使用它们。 您只需将配置复制到 Docker 镜像中即可。 然而，沿着这条路走下去并构建不必要的抽象是很诱人的，你可能会后悔。

此外，Kubernetes 生态系统正在快速发展。 需要花费大量的时间和精力来了解最新的最佳实践和最新的工具。 Kubectl、minikube、kubeadm、helm、tiller、kops、oc——这样的例子不胜枚举。 刚开始时，并非需要所有这些工具，但您不知道需要什么，因此您需要了解所有内容。 因此，学习曲线相当陡峭。

何时使用 Kubernetes

在我们公司，很多人都使用 Kubernetes，并且对此非常满意。 这些实例由 Google 或 Amazon 管理，它们拥有支持它们的资源。

Kubernetes 附带 惊人的功能，这使得大规模容器编排更易于管理：

  • 详细的 权限管理.
  • 定制控制器 向集群添加逻辑。 这些只是与 Kubernetes API 对话的程序。
  • 自动缩放！ Kubernetes 可以使用服务指标按需扩展服务，而无需手动干预。

问题是您是否真的需要所有这些功能。 你不能仅仅依赖于抽象；还要依赖抽象。 你必须弄清楚幕后发生了什么.

我们的团队远程提供大部分服务（由于与主要基础设施的紧密连接），因此我们不想建立自己的 Kubernetes 集群。 我们只是想提供服务。

不含电池

Nomad 只占编排工作的 20%，可提供 80% 的需求。 它所做的只是管理部署。 Nomad 负责部署，在出现错误时重新启动容器......仅此而已。

Nomad 的全部意义在于它的作用 最低限度：没有精细的权限管理或 扩展网络策略，这是专门设计的。 这些组件是外部提供的或根本不提供的。

我认为 Nomad 已经找到了易用性和实用性之间的完美折衷。 它适合小型、独立的服务。 如果您需要更多控制，则必须自己提高它们或使用不同的方法。 游牧民族是 只是 协调者。

Nomad 最好的一点是它很简单 替代。 实际上与供应商没有任何联系，因为它的功能很容易集成到管理服务的任何其他系统中。 它只是像常规二进制文件一样在集群中的每台机器上运行，仅此而已！

松散耦合组件的游牧生态系统

Nomad 的真正优势在于其生态系统。 它与其他完全可选的产品集成得很好，例如 领事 （键值存储）或 拱顶 （处理秘密）。 Nomad 文件内有一些用于从这些服务中提取数据的部分：

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

这里我们读取密钥 service/geo-api/log-verbosity 来自 Consul，在工作时我们将其暴露给环境变量 LOG_LEVEL。 我们还提供了关键 secret/geo-api-key 从Vault作为 API_KEY。 简单但功能强大！

由于其简单性，Nomad 可以通过 API 轻松扩展其他服务。 例如，支持任务标签。 我们用指标标记所有服务 trv-metrics。 这样Prometheus就可以通过Consul轻松找到这些服务并定期检查端点 /metrics 以获得新数据。 例如，对于日志，可以使用同样的方法 洛基.

还有许多其他可扩展性的例子：

  • 使用钩子运行 Jenkins 作业，当服务配置发生变化时，Consul 监控 Nomad 作业的重新部署。
  • Ceph为Nomad添加了分布式文件系统。
  • 法比奥 用于负载平衡。

这一切都让 有机发展基础设施 与供应商没有任何特殊联系。

公平警告

没有一个系统是完美的。 我不建议立即将最新功能引入生产。 当然存在错误和缺失的功能，但这同样适用于 Kubernetes。

与 Kubernetes 相比，Nomad 社区并没有那么大。 Kubernetes 已经拥有约 75 次提交和 000 名贡献者，而 Nomad 拥有约 2000 次提交和 14 名贡献者。 Nomad 将很难跟上 Kubernetes 的速度，但也许不必如此！ 与 Kubernetes 相比，它是一个更专业的系统，较小的社区也意味着您的拉取请求更有可能被注意到和接受。

总结

底线：不要仅仅因为其他人都在使用 Kubernetes 就使用它。 仔细评估您的需求并检查哪种工具更有利。

如果您计划在大规模基础设施上部署大量同质服务，那么 Kubernetes 是一个不错的选择。 请注意增加的复杂性和运营成本。 通过使用托管 Kubernetes 环境可以避免一些成本，例如 Google Kubernetes引擎 или 亚马逊EKS.

如果您只是在寻找一个易于维护且可扩展的可靠编排器，为什么不尝试 Nomad 呢？ 您可能会惊讶地发现这将带您走多远。

如果将 Kubernetes 比作一辆汽车，那么 Nomad 就是一辆踏板车。 有时您需要一件事，有时您需要另一件事。 两者都有存在的权利。

来源： habr.com

添加评论