什么是kubernetes_为什么您不必担心Kubernetes

什么是kubernetes

在1990年代末和2000年代初，在大型网络媒体资源上工作很有趣。 我的经历使我回到了American Greetings Interactive，在情人节那天，我们拥有Internet上排名前10位的网站之一（以网络流量衡量）。 我们为AmericanGreetings.com ， BlueMountain.com等提供了电子贺卡，并为MSN和AOL等合作伙伴提供了电子贺卡。 该组织的资深人士深切地记得与Hallmark等其他电子贺卡网站进行伟大战斗的史诗故事。 顺便说一句，我还经营Holly Hobbie，Care Bears和Strawberry Shortcake的大型网络媒体资源。

我记得好像昨天是我们第一次遇到真正的问题。 通常，我们的前门（路由器，防火墙和负载均衡器）有大约200Mbps的流量进入。 但是，突然之间，多路由器流量图示器（MRTG）图突然间在几分钟内飙升至2Gbps。 我到处乱跑，疯狂地乱跑。 我了解了我们的整个技术堆栈，从路由器，交换机，防火墙和负载平衡器，到Linux / Apache Web服务器，到我们的Python堆栈（FastCGI的元版本），以及网络文件系统（NFS）服务器。 我知道所有配置文件都在哪里，可以访问所有管理界面，并且我是一位经验丰富，经验丰富的系统管理员，具有多年解决复杂问题的经验。

但是，我不知道发生了什么...

当您在一千个Linux服务器上疯狂地键入命令时，五分钟的感觉就像是永恒。 我知道该站点将每秒宕机，因为将其分割并划分成多个较小的集群很容易使一千个节点的集群不堪重负。

我Swift跑到老板的办公桌前，解释了情况。 他几乎没有从电子邮件中抬头，这使我感到沮丧。 他抬头看了看，笑了笑，说道：“是的，市场营销可能会开展广告活动。有时会发生这种情况。” 他告诉我在应用程序中设置一个特殊标志，以减轻Akamai的访问量。 我跑回办公桌，在一千台Web服务器上设置了标志，几分钟后，该站点恢复正常。 避免了灾难。

关键是，我们遇到了业务问题。 当技术问题使您无法开展业务时，它们就会变成业务问题。 换句话说，如果无法访问您的网站，则无法处理客户交易。

那么，所有这些与Kubernetes有什么关系？ 一切。 世界已经改变。 早在1990年代末和2000年代初，只有大型的网络媒体资源才出现大型的网络规模的问题。 现在，借助微服务和数字化转型，每个企业都面临着一个大型的网络规模的问题，可能是多个大型的网络规模的问题。

您的企业需要能够通过许多不同的人构建的许多不同的，通常是复杂的服务来管理复杂的Web规模的资产。 您的网络媒体资源需要动态处理流量，并且它们必须安全。 从基础结构到应用程序层，这些属性都需要由API驱动。

输入Kubernetes

Kubernetes并不复杂。 您的业​​务问题是。 当您要在生产环境中运行应用程序时，要满足性能（缩放，抖动等）和安全性要求，就需要最低程度的复杂性。 诸如高可用性（HA），容量要求（N + 1，N + 2，N + 100）以及最终一致的数据技术等需求成为必需。 这些是每家进行数字化转型的公司的生产要求，而不仅仅是Google，Facebook和Twitter等大型网络公司。

在旧世界，我住在美国问候语中，每次我们加入一项新服务时，它看起来都是这样。 所有这些工作都是由Web运营团队处理的，没有一个使用票务系统等转移给其他团队的。这是在DevOps出现之前的DevOps：

1. 配置DNS（通常是内部服务层和面向外部的公共）
2. 配置负载均衡器（通常是内部服务和面向公众的）
3. 配置对文件的共享访问（大型NFS服务器，群集文件系统等）
4. 配置集群软件（数据库，服务层等）
5. 配置Web服务器集群（可以是10或50个服务器）

其中大多数是通过配置管理自动化的，但是配置仍然很复杂，因为这些系统和服务中的每一个都具有格式完全不同的不同配置文件。 我们研究了诸如Augeas之类的工具来简化此过程，但确定尝试使用翻译器标准化一堆不同的配置文件是一种反模式。

如今，借助Kubernetes，加入一项新服务的本质如下：

1. 配置Kubernetes YAML / JSON
2. 将其提交到Kubernetes API（ kubectl create -f service.yaml ）。

Kubernetes极大地简化了服务的启动和管理。 服务所有者（无论是系统管理员，开发人员还是架构师）都可以创建Kubernetes格式的YAML / JSON文件。 使用Kubernetes，每个系统和每个用户都说相同的语言。 所有用户都可以在同一Git存储库中提交这些文件，从而启用GitOps。

而且，可以弃用和删除服务。 从历史上看，删除DNS条目，负载平衡器条目，Web服务器配置等非常可怕，因为您几乎肯定会破坏某些东西。 使用Kubernetes，所有内容都被命名为名称空间，因此可以通过单个命令删除整个服务。 尽管您仍然需要确保其他应用程序不使用它（尽管微服务和功能即服务[FaaS]的不利之处），但您可以更有信心地说，删除服务不会破坏基础架构环境。

构建，管理和使用Kubernetes

太多的人专注于构建和管理Kubernetes而不是使用它（请参阅Kubernetes是 自卸车 ）。

在单个节点上构建一个简单的Kubernetes环境并不比安装LAMP堆栈复杂得多，但是我们无休止地争论着构建与购买的问题。 不是Kubernetes很难。 它以高可用性大规模运行应用程序。 建立一个复杂的，高可用性的Kubernetes集群很困难，因为要建立如此规模的任何集群都是很困难的。 它需要计划和大量软件。 建造一辆简单的自卸车并不复杂，但是建造一辆可以承载10吨泥土并能以200 mph的速度很好处理的卡车就很复杂。

管理Kubernetes可能很复杂，因为管理大型Web规模的集群可能很复杂。 有时，管理此基础架构很有意义； 有时不是。 由于Kubernetes是一个社区驱动的开源项目，它使行业能够以多种不同方式对其进行管理。 供应商可以出售托管版本，而用户可以根据需要自行决定对其进行管理。 （但是您应该质疑是否确实需要。）

使用Kubernetes是运行曾经发明的大规模网络资源的最简单方法。 Kubernetes正在使运行一组大型，复杂的Web服务的能力民主化，就像Linux在Web 1.0中所做的那样。

由于时间和金钱是零和游戏，因此我建议重点使用Kubernetes。 将您的时间和金钱花费在掌握Kubernetes原语或处理活动性和就绪性探针的最佳方法上（这是另一个例子，表明大型，复杂的服务很难）。 不要专注于构建和管理Kubernetes。 许多供应商可以为您提供帮助。

结论

我记得我曾对无数问题进行故障排除，如我在本文开头所描述的那样-当时的Linux内核中的NFS，我们自己开发的CFEngine，仅在某些Web服务器上出现的重定向问题，等等。开发人员无法提供帮助我解决任何这些问题。 实际上，除非开发人员具备高级系统管理员的技能，否则他们甚至无法进入系统并提供第二眼帮助。 没有带有图形或“可观察性”的控制台，可观察性在我和其他系统管理员的大脑中。 如今，有了Kubernetes，Prometheus，Grafana等，一切都变了。

重点是：

1. 世界是不同的。 现在，所有Web应用程序都是大型的分布式系统。 就像AmericanGreetings.com过去一样复杂，现在每个网站都需要该网站的扩展和HA要求。
2. 运行大型分布式系统非常困难。 期。 这是业务需求，而不是Kubernetes。 使用更简单的协调器并不是解决方案。

Kubernetes绝对是满足复杂Web应用程序需求的最简单，最简单的方法。 这是我们生活的世界，Kubernetes擅长于此。 您可以辩论是否应该自己构建或管理Kubernetes。 有很多供应商可以帮助您构建和管理它，但是很难否认这是大规模运行复杂Web应用程序的最简单方法。

翻译自: https://opensource.com/article/19/10/kubernetes-complex-business-problem

什么是kubernetes