Kubernetes应用场景

     Kubernetes，简称 K8s，是用 8 代替中间 8 个字符 “ubernete” 而成的缩写，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes 提供了应用部署，规划，更新，维护的一种机制。Kubernetes 是一个分布式系统：有一台控制工作机器的主机器，工作被安排在不同的工作机器上。然后，每台机器在容器中运行工作。

Kubernetes是否适合项目？

项目应该具有多个服务或实例

从单体架构应用，部署应用只有一个或几个，部署与伸缩的确不算是麻烦，此时Kubernetes的确没有必要了。当拥有庞大的微服务架构时，或者每个租户都有专用实例，同时又有很多租户时，Kubernetes才有意义。

另外，服务应该是无状态的，并且状态应该存储在群集之外的数据库中。Kubernetes的另一个卖点是对网络的精细渐变控制。而且，也许使用Kubernetes的最普遍的论点是它提供了容易的可伸缩性。

如果不需要可扩展性，那么Kubernetes不适用！

      如果服务严重依赖磁盘，那么是否要迁移到Kubernetes都应该三思。基本上，一个磁盘只能连接到一个节点，因此所有服务都需要驻留在该节点上。因此，将失去节点自动缩放功能，这是Kubernetes的最大卖点之一。出于类似的原因，如果不在公共云中托管基础架构，则可能不应该使用K8S。在本地运行应用程序时，您需要事先购买硬件，而不能仅仅凭空想像一下机器。因此，基本上，您也将失去节点自动扩展功能，除非您愿意使用混合云并通过分解公共云中的某些计算机来消除一些多余的负载。

      如果有一个为所有客户提供服务的整体应用程序，并且需要在各处进行扩展，那么云服务提供商可以通过自动扩展组为您处理该应用程序。确实没有必要为此引入Kubernetes。

微服务

基于微服务的常规体系结构，该体系结构包含许多通过HTTP和消息传递队列进行通信的服务。每个服务都有其自己的数据库，并且大多数服务都在Minio中存储了一些文件。Minio是一个实现S3 API的对象存储系统。

当系统允许运行多服务时，很容易就会编写许多服务。其实，这并不是个好主意。

首先，分布式应用程序很难编写，服务越多，问题就会越多。
其次，分布式应用程序很难调试，可能需要新的工具和日志记录来调试。

微服务其实是一种组织层面的扩展技术，当 500 名开发人员在共同开发一个网站时，不同的开发团队需要独立工作，这时支付大规模分布式系统的成本是有意义的，如果是一个 5 人团队，微服务是没有意义的。

除非你的应用程序真的复杂到必须使用 Kubernetes，否则使用其它工具也可以很好的完成工作，例如单机 Docker Compose、类似 Heroku 的系统、用于计算管道的 Snakemake 等等。