「爷爷，Kubernetes是什么？」「…那是宇宙花园」

1 年 ago

逸, 科

1 minute

你好，早上好，晚上好。
我是zerobillbank股份有限公司的基础设施工程师tomato，也就是tomato。
顺便提一下，”to”是姓，”mato”是名。

我想谈一谈关于Kubernetes这个话题。我希望能尽量简单地讲解Kubernetes是什么，并将其与常见的传统系统进行比较。

Kubernetes之前的宇宙

我希望可以通过与常见的现有系统配置进行比较来讨论什么是Kubernetes。
由于Kubernetes仅仅是一个“扩展”，因此如果不了解其根本特点，就会有所欠缺。

通常的三层客户端系统

这是一个典型的三层客户端系统的图示。
它通常出现在教科书中，但其实这只是一种方便整理的概念而已。
所以请把它当作仅仅是这样的一个概念，就好像是啊，这样分开比较容易理解的那种。

如果将亚马逊的购物网站应用于上述情况的话，

データ層が、商品の価格とか在庫とかユーザ情報とかのデータの部分

嗯，可能有些粗略，但我觉得大致会变成这样。

多余的长度

在上面的图里，我认为计算机（服务器）的数量增加到了6台。或许有人会想：“咦，把它们都放在一台服务器上不就好了吗？”确实，对于这个问题，一台服务器也能正常运行。但在这种情况下，可能会出现一些问题。

マシンのリソース（CPU,メモリ,HDD容量など）が限界を迎えた際、カタストロフィーが訪れる

在实际运营中，会出现各种不便之处。当然，如果不商用，并且即使服务停止也没有问题的话，就算只有一台也可以运作。

因此，在实际的系统运行中，这个冗余性一词变得不可避免。在Kubernetes中也变得非常重要。

所以，将其分成6台的原因如下。

障害が起こった際に全体に伝播することを防ぐ

有很多不同的目的等等。
因此，我们实际上基于这3层进行更细致的分层，或者增加服务器数量来进行运营。

服务器部分可以通过自有服务器（本地服务器）是物理计算机，或者通过云计算是虚拟划分的计算机来实现。基本上，通过扩展（添加服务器）或升级（升级服务器）来提高整体的运行率，但同时成本也会增加，因此这是一个权衡。

服务器模式的问题

这是在Kubernetes之前的宇宙中。
这是一个简单而易懂的宇宙，但实际运作时也会暴露出以下问题。

1. 服务器资源计算困难且成本不被优化

例如，表示层的服务器负载很高，而应用层的服务器负载很低是很常见的情况。
比如，两台表示层服务器的平均使用率为80%，而两台应用层服务器的平均使用率只有20%。
即使在这种情况下，从可用性的角度来看，将应用层服务器减少到一台是危险的，所以需要将表示层服务器增加到三台。
另外，哪台服务器将被使用多少，当然是要事先进行预测，但实际上到底会使用多少，只有上线后才知道，事先准确预测是困难的。

如果特别是在本地运行（使用公司自己的服务器），那么服务器的采购需要花费时间和成本，因此不能轻易实现。

2. 运用变得庞大且成本相当高。

在那些全天候运营的服务中，为了随时应对故障，需要进行全年365天的监视和处理。
如果是大型项目，公司内部或外包部门会负责运营监控。
如果某个服务器的进程（应用程序）崩溃了！不管是凌晨还是晚上，警报将无情地响起，并且需要立刻赶到现场进行故障处理。
如果问题能立即得到解决就好了，但如果出现原因不明的错误之类的情况，现场将陷入混乱和末日般的混乱状态。
而且，这些服务器或进程的故障情况比预想的要多。不知道为什么…

而且，就只是在每个服务器上统一环境，像操作系统设置和应用程序版本这样的事情，也是一项艰巨的任务。大型项目还需要操作系统设置专家和特定应用程序专家。

虽然还有很多，但是我想等我想到了就用追加的方式继续写下去。

paraphrased sentence in Chinese:

有一个名为Kubernetes的宇宙

突然但是把上述的服务器模型替换成了Kubernetes。
实际上还有一些细节，但首先为了理解概念，请多多包涵不太精确的地方。

在这里重要的是服务器被替换为了节点（node）和Pod（pod）。
仅仅就是这一个变化，但它却是一种革新性的不同…
顺便提一句，三层客户端系统本身是一个概念，所以在Kubernetes中也是有效的。

爷爷节点是什么？

节点可以视为服务器（计算机），只要你这样想就可以了。
唯一稍有不同的是，在Kubernetes中，节点被视为服务器群，仅仅是资源提供者的角色。
与前面的服务器模式相比，Kubernetes将服务器视为资源组，并且没有明确的区分。
在上面的图中，将三个服务器视为一个节点池，例如，如果每台服务器配备了2 GHz的CPU，那么节点池总共就有6 GHz！就像这样的概念。
并没有明确指定使用哪个服务器的1 GHz，而是从空闲的位置选择来使用。

顺便提一下，关于节点管理问题，与其说是 Kubernetes 的基本功能，不如说更注重云环境下的托管功能。

老爷爷，什么是“POD”？

如果将node视为资源的提供者，那么pod将成为资源的接收方。
例如，表示HTML的pod将被称为“显示HTML的小伙伴”的表现层仅需要请求node上所需的资源（如CPU，内存等）。
node会根据这些请求为pod分配资源。

通过这样做，可以充分利用服务器资源。

Pod使用了Docker容器技术。关于这个问题的解释需要一本书那么多的内容，所以我会略去细节部分，但是请把它看作是在Docker中定义了操作系统设置和应用程序，并且可以在任何时间以相同的环境运行的东西。

这里真了不起，Kubernetes先生。

我想根据上述内容来总结一下Kubernetes的强大之处。

1. 自动资源分配

这里也提到了节点和Pod之间的关系，我们将节点（服务器）视为资源，并将思考转移到如何在Pod（应用程序）中使用该资源上，这是革命性的宇宙。
通过这种方式，我们可以在不意识到服务器的物理边界的情况下，简单地利用资源来使用应用程序，只要资源允许。

自动繁殖

在Kubernetes中，这不就是它最大的特点吗？
上述的节点和容器根据使用情况，自动地像变形虫一样进行增减。
例如，如果表现层的“显示HTML的pod小伙伴”负载变大，
它会自动增加pod的数量来进行横向扩展。
当pod的数量增加过多，资源不足时，节点会自动进行扩展（如云服务上的托管功能）。

所以，如果某条新闻报道上了，瞬间访问量就会上升！而且，无论是在繁忙期还是冷清期，访问量都会有所差异。
因为它可以自动调整节点和Pod的数量，所以运营非常轻松。
当然，如果节点过多，成本就会增加，但是可以设置在多长时间内增加或减少节点和Pod的数量。嗯，可谓是超神的宇宙。

3. 自我修复功能

这展现了Docker的特点，但如果应用程序出现异常，在kubernetes中，会终止该pod并重新启动一个新的pod。由此，pod将始终以应有的姿态在宇宙中闪耀。同时，还能大大减少系统运维的工作量。嗯，轻描淡写地说就是神级宇宙。

尝试将服务器问题应用于Kubernetes。

最后，让我们将前述的服务器模型的问题应用到 Kubernetes 中。

1. 服务器资源的计算复杂，成本无法优化

可以说，通过kubernetes可以解决这个问题。正如前面提到的，将节点（服务器）视为资源，并通过Pod（应用程序）使用这些资源进行设计，因此可以根据资源的需求来部署应用程序。因此，可以减少整体服务器的数量。根据情况而定，对于大约10台服务器的系统，使用kubernetes可能只需要3-4个节点就可以实现。当然，如果是使用AWS或Azure等托管的kubernetes，节点的自动增减是可能的，所以可能不太需要担心这方面的问题。

2. 运用变得庞大且成本相当高。 dé qiě

即使在这里引入Kubernetes，也无法完全避免发生问题。因为即使使用了Kubernetes，系统故障仍有可能发生，所以仍然需要进行运营监控。

虽然如此，可以大幅减少运维监控的工作量。
Pod的规模也会自动调整，而且如果是可以通过Pod重新启动来解决的故障，它还会自动修复。
尽管我们公司已经使用Kubernetes一年多了，但几乎没有出现由Kubernetes系统引起的故障。

在中国的母语中进行改述：
通过在docker文件中定义，服务器的操作系统设置和应用程序的设置都将变得不再需要。对于这些设置来说，花费的工作量可能会超出预期，因此削减工作量将产生巨大效果。

关于Kubernetes的缺点

到目前为止，我一直在写关于 Kubernetes 的好处，但是当然也有缺点。代表性的缺点可能是学习成本。由于 Kubernetes 的概念与传统的服务器模式不同，所以理解起来确实需要花费一些时间。由于 Kubernetes 本身还处于发展阶段，工程师数量也比较少。

虽然如此，我认为缺点主要是学习成本和迁移成本。
此外，如果是一个只需要1、2台服务器就可以运行的小规模系统的话，
可能并不需要专门用kubernetes组建。它更适合于大规模系统。

最后

所以这次的第一回，我主要写了关于Kubernetes的概念性内容。
下一次，我希望能够谈谈实际的部署问题。

下次再见?‍♂️

ZEROBILLBANK目前正在招募合作伙伴。
我们有很多机会使用JavaScript、区块链、Kubernetes等技术创建各种API。
目前我们团队有大约5名工程师。虽然我们是一家初创公司，但工作环境非常宜人。

日本零账单银行有限公司