Kubernetes 是一个软件系统，用于自动部署和管理由运行在容器中的计算机进程组成的复杂、大规模的应用系统。
对基础设施的抽象
当软件开发人员或运营商决定部署应用程序时，他们会通过 Kubernetes 来执行此操作，而不是将应用程序部署到单个计算机上。 Kubernetes 在底层硬件上为用户和应用程序提供了一个抽象层。
如下图所示，底层基础设施，即计算机、网络和其他组件，对应用程序是隐藏的，从而更容易开发和配置它们。
对应用部署的标准化
由于底层基础设施的细节不再影响应用程序的部署，因此您将应用程序部署到公司数据中心的方式与在云中的部署方式相同。描述应用程序的单个清单（mainfest）可用于本地部署和部署在任何云提供商上。底层基础设施的所有差异都由 Kubernetes 处理，因此您可以专注于应用程序及其包含的业务逻辑。
声明式地部署应用
Kubernetes 使用声明性模型来定义应用程序，如下图所示。您描述构成您的应用程序的组件，Kubernetes 将此描述转化为一个正在运行的应用程序。然后，它根据需要通过重新启动或重新创建应用程序的一部分来保持应用程序的健康。
每当您更改描述时，Kubernetes 都会采取必要的步骤来重新配置正在运行的应用程序以匹配新的描述，如下图所示。
承担应用程序的日常管理
一旦您将应用程序部署到 Kubernetes，它就会接管应用程序的日常管理。如果应用程序失败，Kubernetes 会自动重启它。如果硬件出现故障或基础架构拓扑发生变化，需要将应用程序转移到其他机器上，Kubernetes 会自行完成这一切。负责操作系统的工程师可以专注于大局，而不是在细节上浪费时间。
回到航行的类比：开发和运营工程师是船上的军官，他们舒适地坐在扶手椅上做出高层决策，而 Kubernetes 是舵手，负责引导系统通过您的应用程序和基础设施在波涛汹涌的大海中航行。
Kubernetes 为什么那么受欢迎
自动化管理微服务
过去，大多数应用程序都是大型单体应用程序。应用程序的组件是紧密耦合的，它们都在一个计算机进程中运行。该应用程序是由一个大型开发团队作为一个单元开发的，应用程序的部署非常简单。您将它安装在一台功能强大的计算机上，并提供了它所需的少量配置。横向扩展应用程序几乎是不可能的，因此当您需要增加应用程序的容量时，您必须升级硬件 - 换句话说，垂直扩展应用程序。
然后微服务模式出现了，巨石被分成几十个，有时是几百个独立的进程，如下图所示。这允许组织将他们的开发部门分成更小的团队，每个团队只开发整个系统的一部分——只是一些微服务。
现在，每个微服务都是一个独立的应用程序，具有自己的开发和发布周期。随着时间的推移，不同微服务的依赖关系不可避免地会出现分歧。一个微服务需要一个版本的库，而另一个微服务需要另一个可能不兼容的相同库版本。在同一个操作系统中运行这两个应用程序变得很困难。
幸运的是，容器单独解决了这个问题，每个微服务都需要不同的环境，但现在每个微服务都是一个单独的应用程序，必须单独管理。应用程序数量的增加使这变得更加困难。
整个应用程序的各个部分不再需要在同一台计算机上运行，这使得扩展整个系统变得更加容易，但也意味着需要将应用程序配置为相互通信。对于只有少数组件的系统，这通常可以手动完成，但现在常见的是部署有超过一百个微服务。
当系统由许多微服务组成时，自动化管理至关重要。 Kubernetes 提供了这种自动化。它提供的功能使得管理数百个微服务的任务几乎是微不足道的。
搭建开发和运维的桥梁
除了应用程序架构的这些变化，我们还看到团队开发和运行软件的方式发生了变化。过去，开发团队孤立地构建软件，然后将成品扔给运营团队，然后由运营团队进行部署和管理，这在过去是很正常的。
随着 Dev-ops 模式的出现，两个团队现在在软件产品的整个生命周期中更加紧密地合作。开发团队现在更多地参与部署软件的日常管理。但这意味着他们现在需要了解运行它的基础设施。
作为软件开发人员，您的主要关注点是实现业务逻辑。你不想处理底层服务器的细节。幸运的是，Kubernetes 隐藏了这些细节。
云上标准化
在过去的一两年里，许多组织已经将他们的软件从本地服务器转移到了云端。这样做的好处似乎超过了对被锁定在特定云提供商的恐惧，这是由于依赖提供商的专有 API 来部署和管理应用程序造成的。
任何希望能够将其应用程序从一个提供商转移到另一个提供商的公司都必须做出额外的、不必要的努力，因为需要从应用程序中抽象出底层云提供商的基础架构和 API。
Kubernetes 在这方面也有所帮助。 Kubernetes 的流行迫使所有主要的云提供商将 Kubernetes 集成到他们的产品中。客户现在可以通过 Kubernetes 提供的一组标准 API 将应用程序部署到任何云提供商。
若有收获，就点个赞吧
0 人点赞
