Kubernetes是一个开源的容器编排平台，允许你自动运行和编排容器工作负载。它是一个强大的工具，提供了一个巨大的工具生态系统--包管理器、服务网格、源插件、监控工具等等--作为一个抽象层，用于在越来越多的平台上部署标准化的全栈应用。Kubernetes通常被称为 "K8s"。
另外，Kubernetes很困难。
*Kubernetes让简单的事情变得困难，让困难的事情变得可能，*Paul Dix在他2018年的文章《Kubernetes会在其复杂性的压力下崩溃吗？"任何曾经与K8s合作的人现在可能都在大力点头表示同意。虽然容器和微服务的动态组合提供了巨大的可扩展性和速度，但它们也带来了难以掌握的规模复杂性--更不用说部署和管理了。因此，许多工程师和开发人员对K8s爱恨交加。但它是越来越多的平台上容器协调的事实标准，包括云和企业内部的平台，并被广泛认为是无缝混合和多云工作负载的网关。
Kubernetes不会消失，至少不会很快消失。而且，越来越多的开发者被要求与它互动。因此，让我们来了解一下开发人员需要知道的关于Kubernetes的内容。
- Kubernetes是做什么的
- 为什么开发人员越来越多地被要求具备K8s知识？
- 等等，我真的需要K8s吗？
- 如何与Kubernetes一起工作
什么是Kubernetes？
随着管理者越来越多地要求开发人员承担跨职能的DevOps责任，了解一下Kubernetes的工作原理以及它最适合哪些情况是有帮助的。
即使你不使用它进行开发，如果你的应用程序最终被部署到Kubernetes，你仍然应该在K8s上进行本地测试，以避免在生产中出现不愉快的意外。究竟什么是容器编排，Kubernetes如何帮助交付和支持现代的容器化应用程序？
容器是轻量级的、独立的可执行软件包，包括运行一个应用程序所需的一切：代码、运行时、系统工具、库和设置。它们是一种软件的 "标准单元"，将代码与其所有的依赖关系打包，因此可以在任何地方、任何计算环境中运行。容器平台，如Docker，使开发者能够将他们的应用程序和依赖关系打包成一个可部署的、完全独立的容器。这个容器与底层基础设施是分开的、独立的。以同样的方式，我们可以创建和运行虚拟机，而不必管理裸机服务器，我们也可以部署容器而不必管理单个服务器。容器可以根据工作负荷的需要而启动，然后在不再需要时被杀死--这意味着你可以根据你的业务需求动态地扩大和缩小。
当然，我们需要一些东西来帮助我们管理和部署所有这些容器--毕竟，一个企业级的应用程序将跨越多个容器。这些必须部署在多个服务器主机上，形成一个全面的容器基础设施，包括网络、存储、安全和其他服务。协调引擎为所需的工作负载部署必要的容器，在集群中对它们进行调度，管理它们之间的通信，同时也对它们进行扩展和维护--所有这一切都与容器基础设施相整合。换句话说，协调引擎可以做很多事情。
Kubernetes是最流行的容器编排引擎，诞生于一个名为Borg的谷歌项目。Borg为数十万的服务和工作负载管理集群。(集群是一组用于运行容器化应用程序的节点机器）。如果你正在运行Kubernetes或任何其他协调器，你就在运行一个集群）。Borg最终转变为开源的Kubernetes项目，它发展到支持多个云供应商和容器类型。(以及工程简历上的高需求技能集)。
你真的需要Kubernetes吗？
我们为什么要关心Kubernetes？
开发人员不再只是编写应用程序代码。随着应用程序越来越多地采用微服务架构，我们也被授权做出更多的基础设施决策。然而，这意味着公司也希望我们能够帮助建立和维护这些基础设施。
Kubernetes本质上已经成为指定基础设施的行业标准手段。一个系统所需要的一切--包括进程、负载均衡器和GPU--开发者现在可以用YAML来阐述，并通过Kubernetes来安排。
这么多的配置听起来是不是很吓人？幸运的是，K8s的设置和管理（有如此多的服务依赖）正变得越来越自动化，并通过用户友好型（给我们好的UI）产品和服务（如Tilt、Kublr和KontenaLens）进行抽象化。这些工具将Kubernetes协调引擎渲染成一个更容易接近的框架来管理服务依赖关系。
当你添加一个协调服务时，它消除了对部署和测试到单个虚拟服务器的担忧。同时，它还管理了整理应用组件时对服务器扩展限制的担忧。
然而，构建和管理一个Kubernetes集群可能比管理更传统的应用环境要复杂得多，也更耗时。它带来了操作上的开销，需要专门的知识。另外，不是每个应用程序都需要Kubernetes提供的力量和规模。如何判断？
要问自己的问题是，我在使用微服务吗？
如果你有一个复杂的应用程序，由许多不同的服务组成，托管在他们自己的容器中，需要快速扩展以支持其用户，那么Kubernetes可以是一个理想的选择。你的应用程序可能有数百个这样的容器化组件，必须在大量的节点上进行扩展。也可能有多个开发人员、运营人员和DevOps团队同时参与。好消息是，Kubernetes可以轻松地协调这种工作负载。坏消息呢？对于这种规模的应用程序，你现在也需要有足够的开发人员来支持集群管理。
更多的好消息是：你甚至可能不需要它
是的，Kubernetes是现在超级热门的技术。作为一名开发人员或DevOps经理，你可能会觉得你的应用开发管道如果不包括Kubernetes，就会无可救药地过时。然而，许多应用程序根本不需要这种水平的复杂性，因为它们的可扩展性足以在几个容器或传统服务器内运行。常见的例子包括已经在容器内运行的较小的应用程序，但与其他容器没有太多互动，或者有适度的扩展要求来管理负载。有时，在云中运行这些容器，多分配一些资源来管理峰值负载，比部署复杂的Kubernetes集群更有效率--特别是考虑到云基础设施的低成本和广泛可用性。
另一个例子是单体或传统托管的应用程序，在需要Kubernetes之前，它们早就可以利用部署的服务器进行扩展。扩展通常更多的是关于一个应用程序的内部结构，而不是高层架构和工具。例如，你可以通过部署多个支持亲和标记的负载均衡器的实例来扩展一个单体。你还可以使用Chef和Ansible等工具来自动配置新的服务器，以确保它们可以运行你的应用程序，而不是手动配置它们。 有了这些资源，一个用.NET或Java编写的更传统的网络应用程序仍然可以扩展到轻松处理大量的请求--就像Stack Overflow使用11个IIS网络服务器来处理每天6600万的页面加载。
Kubernetes提供的功能远远超过大多数开发者的需求。有可能，你根本不关心你的应用程序有多少个服务副本在运行，或者每个副本有什么角色，以及它们是否通过StatefulSets运行。你的主要工作只是建立一个HTTP端点来交付产品。
要取得正确的平衡是很棘手的。你不希望有一个黑匣子，但你也不希望有完全的访问权--这太容易把事情搞砸了。对集群的小改动可能会产生破坏性的、意料之外的蝴蝶效应，比如超出可用资源或使你的修补工作成倍增加。
虽然Kubernetes是一个伟大的工具，但管理分布式服务可能很复杂。如果简化的架构适合你的应用，你可以把Kubernetes留给真正需要它的项目，为自己节省一些（很多）痛苦。
不幸的是，这个决定并不总是掌握在负责实际交付应用程序的开发人员手中。因此，让我们来看看，当你别无选择，只能与K8s交朋友时，该怎么做。
如何与Kubernetes一起工作（不破坏你的大脑）
当你的工作不是真正与Kubernetes合作时，你如何与Kubernetes合作？这里有你的选择。使用组件架构，但跳过微服务，使用重量较轻的简化版K8s工作。或者尝试与你的运营团队达成协议，他们的工作实际上是与K8s一起工作。
简化的Kubernetes解决方案
在最好的情况下，K8s开发人员需要一个简化的、可操作的界面，不限制他们在需要时挖掘API。轻量级容器编排工具，如Microk8s，或用于物联网（IoT）和边缘工作负载的K3s，通过简化Kubernetes集群来减少管理要求。这两种工具都可以让你在Kubernetes上运行时保持你的应用程序的架构，尽管在可用功能上有一些限制。如果你的模块化应用开始需要扩展，这可以作为一个完整的微服务架构的良好替代。
在你的CI/CD管道内实施全规模的Kubernetes
对于那些仍然主要在DevOps连续体中的开发者来说，另一个选择是与你的运营部门合作，将Kubernetes纳入持续集成和持续部署（CI/CD）管道内。这样一来，开发人员就不会沉溺于Kubernetes的细节，也不会有破坏集群的风险。这种方法可以让你简单地推送代码到GitHub。完全精通Kubernetes的人负责剩下的工作，同时允许测试保持对开发的可用性。
如果修改你的CI/CD管线不是一个选项，可以与运营部门合作，创建一个中间层，通常是一个独立的API--幸好是一个开发者的舒适区--通过指定开发者可以和不能修改的内容来保持对集群的整体控制。这需要更多关于K8s的知识和实践工作，但可以保护开发者不面对全部的复杂性，并保护系统不出错。
总结
Kubernetes是一个部署、管理和扩展大型分布式应用程序的伟大工具。如果你的应用很简单--比如说一个单一的服务--把它放在一个地方是很明智的，单片机架构并不自动是一件可怕的事情，不管云原生的传道者怎么说。 如果你的应用程序不大，而且多个团队没有在不同的组件上工作，你可能不需要把它分成微服务。这意味着你不需要Kubernetes来协调你没有的微服务！这意味着你不需要。
但现实中，许多开发人员可能在 "我们应该使用K8s吗？"的讨论中没有发言权。好消息是：你不需要成为一个深度的Kubernetes专家。然而，在前往容器、微服务和分布式应用部署的云原生王国时，你确实需要能够说一些K8s。简单的事实是，Kubernetes现在处理大多数生产工作负载。当你基本掌握了K8s中发生的事情以及一切如何配合时，编写有效的应用程序代码和调试问题就容易多了。
未来已定：现在还没有完全在云上的一切，很快就会有。云是一个分布式系统，所以软件架构也越来越需要分布式，以充分发挥其潜力。软件越来越复杂，无法将开发者与基础设施完全隔离。
为了处理这种复杂性，我们开发人员需要拥抱K8s。或者至少要成为最好的敌人。
