kubernetes学习

在 ，我谈到了一种工具，它可以很好地解决其设计要解决的问题，一旦您学会了如何使用它。 在本系列的第2部分中，我将更深入地研究Kubernetes的学习曲线。

进入的旅程通常始于在一台主机上运行一个容器。 您很快就会发现运行新版本的软件有多容易，与他人共享该软件有多容易，以及那些用户以您期望的方式运行它有多容易。

但是那你需要

• 两个容器
• 两位主持人

使用容器在端口80上启动一个Web服务器很容易，但是当您需要在端口80上启动另一个容器时会发生什么呢？ 当您构建生产环境并且需要容器化的Web服务器故障转移到第二台主机时会发生什么？ 不管是哪种情况，最简单的答案是您必须进入容器编排。

不可避免地，当您开始处理两个容器或两个主机的问题时，您会引入复杂性，因此会出现学习曲线。 两个服务（一个更通用的容器版本）/两个主机的问题已经存在了很长时间，并且总是引入了复杂性。

从历史上看，这将涉及负载平衡器，集群软件，甚至集群文件系统。 每个服务的配置逻辑都嵌入每个系统（负载平衡器，群集软件和文件系统）中。 在负载均衡器后面运行60或70个群集的服务非常复杂。 添加另一项新服务也很复杂。 更糟糕的是，停止服务是一场噩梦。 回想过去对生产和制造MySQL和Apache服务器进行故障排除的日子，这些逻辑和嵌入在三个，四个或五个不同位置的逻辑（都以不同的格式）仍然困扰着我。

Kubernetes用一款软件优雅地解决了所有这些问题：

1. 两项服务（容器）：检查
2. 两台服务器（高可用性）：检查
3. 单一配置来源：检查
4. 标准配置格式：检查
5. 联网：检查
6. 储存：检查
7. 依赖关系（哪些服务与哪些数据库对话）：检查
8. 轻松配置：检查
9. 轻松取消布建：检查（也许是Kubernetes 最强大的功能）

等等，它开始看起来像Kubernetes一样优雅而强大。 它是。 您可以在Kubernetes中为整个微型IT领域建模。

但是，请勿将学习曲线用于构建或装备Kubernetes（为自卸车挑选合适的挡泥板可能很困难，大声笑）与使用它的学习曲线相混淆。 学习在这么多不同的层次（容器引擎，日志记录，监控，服务网格，存储，网络）上拥有如此多的不同选择来构建自己的Kubernetes，然后每六个月维护每个组件的更新选择，可能不值得投资—但是学会使用它绝对值得。

我每天都在吃饭，睡觉和呼吸Kubernetes和容器，甚至我也很难跟踪几乎每天都宣布的所有重大新项目。 但是，没有一天，我对使用单个工具来对整个IT miniverse进行建模的操作优势感到兴奋。 另外，请记住，Kubernetes已经成熟了很多，并将继续这样做。 像之前的Linux和OpenStack一样，每一层的接口和事实上的项目都将成熟并变得更容易选择。

在本系列的第三篇文章中，我将深入探讨在驾驶Kubernetes“卡车”之前您需要了解的知识。

翻译自:

kubernetes学习