引入Kubernetes不要操之过急，因为它不一定适合你。本文探讨了在使用Kubernetes之前应考虑的一些因素。在过去几年中，Docker已成为构建、交付和运行应用程序的一种非常流行的方式。使用Docker，一次构建您的应用程序并在任何地方运行它。虽然这是软件开发方式的巨大飞跃，但也带来了一些新的挑战。对于初学者来说，在Docker容器和主机之间建立网络连接并不是一件容易的事。这与我们过去使用的传统网络方法有很大不同，它需要一定的技能才能做好。另一个挑战是存储。默认情况下，Docker卷绑定到它们的主机。这意味着如果我们想要运行服务的多个实例并让它们共享一个卷，我们必须设置复制或将其配置为使用云存储服务。虽然Docker被视为一项了不起的技术，但缺少一个组件可以将它们联系在一起。而Kubernetes正是那个组件。尤其是在Azure、AWS等云平台提供的全托管形式下，Kubernetes解决了所有这些问题，并通过一系列概念从终端用户那里抽象出来。Kubernetes，也称为k8s，由Google开发，旨在解决在全球范围内运行数千个应用程序时所面临的问题。在过去的一两年里，k8s的采用率在快速增长，越来越多的公司正在寻找精通k8s的工程师。虽然Kubernetes在Spotify、ING和许多其他公司的实施取得了令人难以置信的成功，但它并不是所有公司的最终解决方案。https://kubernetes.io/case-studies/spotify/https://kubernetes.io/case-studies/ing/实际上，在生产环境中运行Kubernetes也会带来一些严重的问题。在本文中，我们将探讨您在决定使用Kubernetes之前应该考虑的一些因素。1.学习曲线Kubernetes有自己的运行机制。它是围绕几个概念设计的，其中大部分是熟悉在生产中运行Kubernetes所必需的。因此，这引入了一个相当陡峭的学习曲线。不仅适用于系统管理员，也适用于开发人员。https://kubernetes.io/docs/concepts/下图显示了Kubernetes架构的高级概述Kubernetes架构（Kubernetes组件，CC-BY4.0）https://kubernetes.io/docs/concepts/overview/components/all这些管理器、调度器和服务器负责运行你的应用程序，k8s中的工作负载，24/7。他们各自扮演一个角色并实现一个或多个Kubernetes概念。在使用Docker或进行更传统的系统管理工作时，您不一定会使用这些概念。每次在集群中部署一个新的应用程序时，Kubernetes都会为您的应用程序创建最少数量的以下对象：代表应用程序的部署对象；ReplicaSet用于扩展与deployment关联的Pod；可选地，一个或多个服务处理部署的网络需求；代表实际容器的一个或多个Pod。这是Kubernetes架构中最小的组件。如您所见，这对于Kubernetes新手来说可能是一个很大的负担。更重要的是，这些对象中的每一个都可以通过无数种方式进行配置，从而彻底改变它们的行为。事实上，启动并运行Kubernetes并正确配置其所有组件需要花费大量时间。托管Kubernetes提供商承担了大量低级配置和集成工作，但是，一些工作将不可避免地转移给开发人员，他们至少需要基本熟练掌握Kubernetes才能正确完成工作。您不一定需要Kubernetes来运行您的应用程序，它只是运行生产软件的众多选项之一。您应该仔细权衡迁移成本（增加的学习曲线和配置开销）与迁移收益。2.申请是否需要延期？Kubernetes的一个关键特性是能够扩展应用程序的各个部分。流量在Pod之间自动路由和分配，如果配置，Kubernetes甚至可以为您自动扩展Pod。如果应用程序具有一个或多个需要处理意外事件的热组件，则此功能很有价值。例如，当发布新的扩展或功能时，在线游戏的身份验证服务可能会突然增加登录请求。或者是那些上线后非常火爆，需要快速扩充基础设施，不用担心网络、存储等问题的游戏。《精灵宝可梦 Go》就是这样一款刚上线不久就吸引了大量玩家的游戏。因此，他们广泛使用Kubernetes为全球大量玩家提供服务。https://scotch.io/@pavan-belagatti/pokemon-go-a-successful-kubernetes-story然而，对于大多数其他应用程序，单个服务成为整个环境的瓶颈，通过优化而不是更好地扩展来解决。当然，这种情况下，可以多用几个pod，祈祷问题消失——也就是说，只要没有达到存储层的极限，就可以简单地扩容pod来解决问题。向上。不要误会我的意思-能够动态扩展您的部署是一个巨大的优势。然而，在我见过的绝大多数情况下，通过扩大部署来解决瓶颈只是治标不治本。此外，除了能够使用Kubernetes扩展应用程序之外，还有许多其他方法。Heroku、Azure和AWS都提供了动态运行和扩展应用程序的方法。例如，AzureWebApp有一个横向扩展选项，这与在前面有负载均衡器的Kubernetes中运行多个pod是一样的。如果扩展能力是吸引您使用Kubernetes的原因，请首先考虑其他维护较少的选项。3.运行微服务Kubernetes主要用于运行许多共同构成应用程序的小型工作负载。如前一节所述，其关键特性之一是能够独立扩展基础架构的各个部分，而无需扩展整个应用程序。这些架构（通常称为微服务架构）在Kubernetes上蓬勃发展。其架构支持简单的服务发现和整个拓扑中组件之间的轻松交互。所以这里考虑的不是在Kubernetes上运行微服务是否是个好主意，而是微服务是否是适合特定应用程序的架构原则。虽然微服务架构通常比传统的单体架构更受欢迎，但它们也给开发人员带来了巨大的负担。比如优步支付体验平台放弃微服务，改用宏服务，就引起了网友的热议。让每个单独的服务都有自己明确定义的职责是一个合理的架构选择。下一步，将这些职责分离到不同的服务中似乎合乎逻辑，但并非必须如此。为了让开发人员分析和修复微服务环境中的错误，他们需要能够访问构成该环境的大部分（如果不是全部的话）服务。这使得整个应用程序更难有效地工作。由于开发人员不能只在他们的开发机器上运行应用程序，您需要引入一整套工具来分析和解决问题。考虑每个环境的分布式日志记录、消息队列和性能监控。对开发人员生产力的影响不太明显。同样，这可能是值得的，特别是对于拥有许多开发团队的大型组织，每个开发团队都在自己的微服务上工作，这是大局的一部分。然而，对于较小的公司和团队来说，微服务架构的成本要高得多。Kubernetes并不一定能让这些问题更容易处理。事实上，它甚至可能使情况变得更糟。如果启用微服务架构是吸引您使用Kubernetes的原因，请仔细考虑职责分离是否是一个可以通过代码解决的问题，而不是通过将Kubernetes等大型组件引入基础架构来解决。4.总结我们讨论了在考虑Kubernetes是否适合您的项目或组织时需要考虑的一些因素。Kubernetes最初是谷歌为了解决谷歌面临的问题而设计的。这些问题涉及在生产中运行大量工作负载，其扩展要求对于普通人来说是难以想象的。谷歌只有一个。当然，除了你可能会遇到谷歌在设计Kubernetes时遇到的同样问题，而且你成功的机会很小。在决定使用Kubernetes作为您的业务基础之前，考虑它在较长时间内对您的组织、开发团队和平台稳定性的影响非常重要。该技术还比较新，精通Kubernetes的工程师相对较少。这并不是说Kubernetes是解决问题的错误方法。以前，我从事的项目依赖Kubernetes以其他类似技术难以匹敌的规模向最终用户交付价值。最重要的是，虽然围绕Kubernetes的大部分宣传都是真实的，但不能仓促介绍Kubernetes。它有时适合-但并非总是如此。
