什么是Kubernetes？科普文
在过去几年，整个行业逐渐转向开发更小更专业的程序。
微型服务有以下几个优点：
- 快速部署：因为你可以快速的创建并且发布一个小型服务
- 更容易迭代：因为可以独立的为每个服务添加新功能
- 更加灵活：就算单个服务（组件）不能使用，其他的服务仍能正常运行。
那么这种文化转变是怎样影响基础设施的呢？
管理大规模的基础设施
当你只需要管理几个应用程序时，一切都很简单，你甚至可以用手指算出它们的个数，并且你有足够的时间专注与应用的发布和运维。 在大公司中，管理数百个应用虽然要求很高，但仍是可以做到的。将会有几个团队专门用于开发，打包，以及发布应用。
另一方面，开发微服务将会带来新的挑战。
对于每个应用，你可能会在重构的时候，将一个应用拆分成四个组件（服务），那么你至少需要四倍的时间去开发，打包，发布这些微服务。
我们常常看到，一个小型服务由多种组件构成，例如前端应用，后台API，一个授权服务器，一个管理应用程序等等。实际上，当你开发了多个微服务，并且这些服务相互交互，你将会看到你的基础架构上部署了大量的组件（服务）。
事情变的越来越复杂。
你可能需要在计算资源上浪费很多钱
大部分服务被部署到虚拟机上，如Amazon EC2，Digital Ocean Droplets或Azure Virtual Machines。每个虚拟机都带有一个操作系统，这个系统会占用部分内存以及cpu资源。
当你在Digital Ocean上创建1GB内存和1个vCPU Droplet时，除去操作系统的开销后，最终可以使用700MB内存和0.8 vCPU。
换句话说，每五个虚拟机的操作系统的开销加起来就是一个完整的虚拟机。
你付了五个的钱，但只能使用四个。
即便是在物理机上，你也无法绕开它。你仍然需要用操作系统运行服务。
然而，操作系统上的浪费只是冰山一角。
你也浪费了大量的钱在资源利用上
您可能已经意识到，当您将服务分解为更小的组件时，每个组件都会有不同的资源需求。 某些组件（如数据处理和数据挖掘应用程序）是CPU密集型的。其他的（例如一些实时应用程序的服务器）相比于CPU，可能会使用更多的内存。
Amazon Web Services以及其他的云服务提供商的确有一长串适用于各种场景的计算资源：通用的，CPU优化的，内存优化的，存储优化的以及GPU计算的。
你需要为你的服务认真挑选合适的虚拟机。理想情况下，这个虚拟机可以满足你的服务的内存消耗以及CPU使用。
您是否正在使用Java编写的关键Web组件？也许您应该使用针对计算密集型工作负载优化的c5.4xlarge。越能满足要求，你就能更好的利用资源。但实际上，这并不常见。
你应该使用c5.2xlarge还是c5.4xlarge？
下一级别（8个vCPU和16GB内存）是否更合适？
在80％的情况下选择几个足够好的计算配置并将其用于所有组件要容易得多。
事实上，对于所有工作负载使用相同配置的虚拟机又有什么问题么？
完全没问题，只要你愿意将每个组件包装成2GB内存和vCPU计算容量。即便你的应用只需要1GB内存。
是的，你可以将来再优化。
但是老实说， 这就像在开车时更换轮胎一样——非常危险。
你花了很多精力来调整系统最后意识到应用程序再次改变而你又得从头开始。
最终，你会做一个明智的选择：选择小型，中型和大型配置文件的虚拟机，并将其用于所有工作负载。
你知道你必须忍受浪费数百兆字节的RAM和大量的CPU周期。
其实很多公司都在做同样的事情，忍受着类似的低效。
有些甚至只利用到分配资源的10％。
您在亚马逊上的EC2实例中支付1000美元，您实际上只使用了100美元。
这听起来不像是花费预算的最佳方式。
你应该把你花在不用的资源的钱拿回来。
但是为什么每个服务的需求如此不同呢？！
有时候选择合适的工具甚至会弊大于利
当开发人员可以自由地使用正确的工具时，他们通常会疯狂。前端选择Node.js，后台API选用Spring Boot，使用Flask和Celery来处理后台作业，使用React.js来创建客户端，你懂的。整个基础设施就像一个主题公园，数百个程序在不同的运行时运行。为一项工作选用合适的技术的确带来了更快的迭代速度，但是管理更多的编程语言也带来了额外的负担。
虽然你可以控制工具和编程语言的数量，但是实际上，这往往很困难。
两个应用程序的共享相同的JVM运行时，但是它们可能依赖于两组不同的依赖项和库。
也许一个依靠ImageMagick来调整图像大小。
另一个依赖于诸如PhantomJS或ZeroMQ之类的二进制文件在其路径中可用。
你需要把这些依赖与应用一起打包。
最终你可能需要处理数十种看上去相似的配置，但其实上各有不同。
你不能把基础设施当做以后才处理的事情。
在开发应用程序时，你应该从一开始就考虑好依赖项并将它们打包。
理想情况下，您应该将运行组件所需的所有依赖归档为单个包。
不要在发布前还在寻找缺失的依赖。
是的，说总是比做容易。
或许不。
从流行业借鉴集装箱的概念
信息技术行业并不是唯一遇到这个问题的行业。将货物运往全球并且保证它们独立运输也十分困难。
想象你需要存储上千个不同形状大小的盒子。并且你需要额外注意如何打包这些货物，避免它们在运送中丢失。
货运公司想出一个很好的解决方案：集装箱
货运公司不运送单个货物，而是运送集装箱。
你想要安全的运送你的货物么？
只需要将它们放置于集装箱中即可。
当集装箱到目的地时，你保证能收到你所有的货物。
你也可以将这一准则运用到你的应用上去。
你想安全的部署你的应用及其所有的依赖么？
只需要将它们打包在Linux的容器之中即可。
一个Linux容器就像是一个货物的集装箱，只是它包含的是所有的文件，二进制文件，以及所有需要运行你的程序所需的库。
这听上去是不是很像虚拟机？
精简版的虚拟机
事实上，虚拟机很像容器。他们封装了应用以及应用的所有依赖，就像容器一样。
但是，虚拟机启动很慢，而且体积大浪费资源。
事实上，你需要事先分配一些固定的CPU和内存来运行你的程序。
虚拟机必须仿真硬件，并附带操作系统这个累赘。
而另一方面，Linux容器，仅仅只是在你主机上运行的进程。
实际上，在同一个操作系统和服务器上，您可以在运行数十个容器。
尽管他们运行在同一个机器上，容器里的进程彼此并不可见。
在容器里面运行的应用是完全隔离的，它无法区分虚拟机与容器的区别。
真是个好消息！
Linux容器就像是虚拟机，但是更加高效。
那么这些容器是由什么组成的呢？
Linux容器是一个独立进程
它的神奇之处来自Linux内核中的两个功能：控制组和命名空间。控制组是限制特定进程可以使用的CPU或内存的便捷方式。
例如，您可以说您的组件应该只使用2GB内存和四个CPU内核中的一个。
另一方面，命名空间负责隔离进程并限制它可以看到的内容。
组件只能看到与其直接相关的网络数据包。
它将无法看到流经网络适配器的所有网络数据包。
控制组和命名空间是底层基元。
随着时间的推移，开发人员创建了越来越多的抽象层，以便更容易地控制这些内核功能。
最初的抽象之一是LXC，但最佳示例是2013年发布的Docker。
Docker不仅抽象了上述内核功能，而且使用起来也很容易。
运行Docker容器非常简单：
docker run <my-container>由于所有容器都实现了标准接口，因此您可以使用相同的命令运行其他任何容器：
docker run mysql就可以运行MySQL数据库。
应用程序的可移植性以及创建和运行进程的标准接口，使变得容器越来越受欢迎。
容器超棒！
- 你节省了运行几十个操作系统的钱
- 你将应用程序打包为便携式单元
- 你有大量的容器
你需要一种管理容器的方式。
管理大规模容器
当您有数百个（而不是数千个）容器时，您应该找到一种在同一服务器上运行多个容器的方法。而且你应该提前想好容器如何在多个服务器上扩展。
因此，您可以跨多个节点分配负载，并防止单个故障可能导致整个服务崩溃。
跟踪基础架构中每个容器的部署位置听起来很浪费时间。
也许有一种自动化方法？
如果您可以使用算法来决定放置这些容器的位置，该怎么办？
也许聪明有效地打包容器可以以最大化服务器密度？
甚至可以保留已部署容器及其主机的列表？
事实证明，有人正好有同样的想法，并提出了一个解决方案。
Kubernetes：强大的容器编排工具
Kubernetes最初由Google创建。谷歌当时正在使用一种类似于容器的技术，并且必须找到一种有效的方式来安排工作负载。
他们不想保留并手动更新一长串容器和服务器列表。
因此，他们决定编写一个可以自动分析资源利用率，安排和部署容器的平台。
但这个平台一开始是闭源的。
几个Google员工决定将该平台重写为开源工具。
接下来就是我们所知的历史。
那么什么是Kubernetes？
您可以将Kubernetes视为调度程序。
Kubernetes检查您的基础设施（物理机或云，公共或私有）并检测每台机器的CPU和内存。
当您请求部署一个容器时，Kubernetes会识别容器的内存要求，并找到满足您请求的最佳服务器。
您无法决定部署应用程序的具体位置。
数据中心已经把这个步骤抽象出来。
换句话说，Kubernetes将使用您的基础设施像玩俄罗斯方块一样玩转容器。
Docker容器就是方块；服务器是板，Kubernetes就是玩家。
使用Kubernetes打包你的基础设施，意味着花同样的钱你能得到更多的计算资源。
于是你的总花费会因此而减少。
记得之前提到过说很多公司仅仅使用了被分配资源的10%么？
Kubernetes将会拯救你。
别急，还有更多惊喜。
Kubernetes有一个通常被遗忘或被忽略的杀手级功能。
Kubernetes作为数据中心的API层
你在Kubernetes所做的一切都是你的一个API调用。你需要部署一个容器吗？ 有一个REST端点。
也许你想配置负载均衡器？ 不是问题。只需调用此API即可。
你想配置存储吗？ 请发送POST请求到此URL。
你在Kubernetes所做的一切都是调用API。
你肯定会因此而感到兴奋：
- 你可以创建以编程方式与API交互的脚本和守护程序 API已版本化；
- 升级群集时，您可以继续使用旧API并逐步迁移；
- 你可以在任何云提供商或数据中心安装Kubernetes，您可以使用相同的API。
由于这层是通用的，可以安装在任何地方，你可以随意迁移。
亚马逊网络服务太贵了？
没问题。
您可以在Google Cloud Platform上安装Kubernetes并把您的工作负载迁移过去。
或者也许你可以保留两者，因为高可用性策略总是会派上用场。
但也许你不相信我。因为这件事听上去太美好了以致于不真实。
让我演示给你看。
使用Kubernetes节省您的云账单
Netlify是一个用于构建，部署和管理静态网站的平台。它有自己的CI管道，因此你对代码库中的代码进行更改时，您的网站都会重新构建。
Netlify成功迁移到Kubernetes，用户数量增加了一倍，但成本仍维持不变。
这真是个好消息！
想象一下，节省50％的Google Cloud Platform花销！
但Netlify不是唯一的一个受益者。
Qbox——一家专注于托管弹性搜索的公司——设法每月在AWS账单上再次节省50％！
在此过程中，他们还 开源了他们在多云运维方面的实践 。
如果你仍然没有印象，你应该看看关于OpenAI的新闻。
OpenAI是一家非营利性研究公司，专注于人工智能和机器学习。
他们写了一个算法来让机器玩一个多人在线游戏Dota，就像任何人类玩家一样。
但他们做了一些额外的操作，他们训练了一组机器一起玩。
他们使用Kubernetes在云中扩展他们的机器学习模型。
想知道他们的集群的细节？
128000个vCPU
那是大约16000台MacBook Pro。
256 Nvidia Tesla P100
这是2100 Teraflops 16位浮点性能。
就像你运行525 PlayStation 4s一样。
你能猜出每小时的费用吗？
猜不到？
128000 vCPU仅为1280美元/小时，256个Nvidia P100仅为400美元。
考虑到赢得Dota锦标赛可以为您赢得数百万美元的奖金，这并不是很多。
你还在等什么？
准备好采用Kubernetes并节省您的云账单！
最后的笔记
Kubernetes和容器将继续流行。在谷歌，微软，红帽，Pivotal，甲骨文，IBM等公司的支持下，你很难相信它不会流行起来。
许多公司正在开始使用Kubernetes并加入这场革命。
不只是创业公司和中小企业，而是像银行，金融机构和保险公司这样的大公司都在押注容器，而Kubernetes则是未来。
甚至公司也将这项技术应用于物联网和嵌入式系统。
现在还处于早期阶段，社区仍需时间成熟，但你应该密切关注这个领域的创新。
本文转自DockOne-什么是Kubernetes？科普文
