【云计算】Kubernetes是什么？为什么也称为K8S？

会员服务 ·

【云计算】Kubernetes是什么？为什么也称为K8S？

2018 年 10 月 20 日 产业智能官

是一篇 Kubernetes 的概览。Kubernetes 是一个自动化部署、伸缩和操作应用程序容器的开源平台。

使用 Kubernetes，你可以快速、高效地满足用户以下的需求：

快速精准地部署应用程序
即时伸缩你的应用程序
无缝展现新特征
限制硬件用量仅为所需资源

目标是培育一个工具和组件的生态系统，以减缓在公有云或私有云中运行的程序的压力。

Kubernetes的优势：

可移动: 公有云、私有云、混合云、多态云
可扩展: 模块化、插件化、可挂载、可组合
自修复: 自动部署、自动重启、自动复制、自动伸缩

Google 公司于 2014 年启动了 Kubernetes 项目。Kubernetes 是在 Google 的长达 15 年的成规模的产品级任务的经验下构建的，结合了来自社区的最佳创意和实践经验。

为什么选择容器?

想要知道你为什么要选择使用容器?

程序部署的传统方法是指通过操作系统包管理器在主机上安装程序。这样做的缺点是，容易混淆程序之间以及程序和主机系统之间的可执行文件、配置文件、库、生命周期。为了达到精准展现和精准回撤，你可以搭建一台不可变的虚拟机镜像。但是虚拟机体量往往过于庞大而且不可转移。

容器部署的新的方式是基于操作系统级别的虚拟化，而非硬件虚拟化。容器彼此是隔离的，与宿主机也是隔离的：它们有自己的文件系统，彼此之间不能看到对方的进程，分配到的计算资源都是有限制的。它们比虚拟机更容易搭建。并且由于和基础架构、宿主机文件系统是解耦的，它们可以在不同类型的云上或操作系统上转移。

正因为容器又小又快，每一个容器镜像都可以打包装载一个程序。这种一对一的“程序 – 镜像”联系带给了容器诸多便捷。有了容器，静态容器镜像可以在编译/发布时期创建，而非部署时期。因此，每个应用不必再等待和整个应用栈其它部分进行整合，也不必和产品基础架构环境之间进行妥协。在编译/发布时期生成容器镜像建立了一个持续地把开发转化为产品的环境。相似地，容器远比虚拟机更加透明，尤其在设备监控和管理上。这一点，在容器的进程生命周期被基础架构管理而非被容器内的进程监督器隐藏掉时，尤为显著。最终，随着每个容器内都装载了单一的程序，管理容器就等于管理或部署整个应用。

容器优势总结：

敏捷的应用创建与部署：相比虚拟机镜像，容器镜像的创建更简便、更高效。
持续的开发、集成，以及部署：在快速回滚下提供可靠、高频的容器镜像编译和部署（基于镜像的不可变性）。
开发与运营的关注点分离：由于容器镜像是在编译/发布期创建的，因此整个过程与基础架构解耦。
跨开发、测试、产品阶段的环境稳定性：在笔记本电脑上的运行结果和在云上完全一致。
在云平台与OS上分发的可转移性：可以在 Ubuntu、RHEL、CoreOS、预置系统、Google 容器引擎，乃至其它各类平台上运行。
以应用为核心的管理：从在虚拟硬件上运行系统，到在利用逻辑资源的系统上运行程序，从而提升了系统的抽象层级。
松散耦联、分布式、弹性、无拘束的微服务：整个应用被分散为更小、更独立的模块，并且这些模块可以被动态地部署和管理，而不再是存储在大型的单用途机器上的臃肿的单一应用栈。
资源隔离：增加程序表现的可预见性。
资源利用率：高效且密集。

为什么我需要 Kubernetes，它能做什么?

至少，Kubernetes 能在实体机或虚拟机集群上调度和运行程序容器。而且，Kubernetes 也能让开发者斩断联系着实体机或虚拟机的“锁链”，从以主机为中心的架构跃至以容器为中心的架构。该架构最终提供给开发者诸多内在的优势和便利。Kubernetes 提供给基础架构以真正的以容器为中心的开发环境。

Kubernetes 满足了一系列产品内运行程序的普通需求，诸如：

协调辅助进程，协助应用程序整合，维护一对一“程序 – 镜像”模型。
挂载存储系统
分布式机密信息
检查程序状态
复制应用实例
使用横向荚式自动缩放
命名与发现
负载均衡
滚动更新
资源监控
访问并读取日志
程序调试
提供验证与授权

以上兼具平台即服务（PaaS）的简化和基础架构即服务（IaaS）的灵活，并促进了在平台服务提供商之间的迁移。

Kubernetes 是一个什么样的平台?

虽然 Kubernetes 提供了非常多的功能，总会有更多受益于新特性的新场景出现。针对特定应用的工作流程，能被流水线化以加速开发速度。特别的编排起初是可接受的，这往往需要拥有健壮的大规模自动化机制。这也是为什么 Kubernetes 也被设计为一个构建组件和工具的生态系统的平台，使其更容易地部署、缩放、管理应用程序。

标签（label）可以让用户按照自己的喜好组织资源。注释（annotation）让用户在资源里添加客户信息，以优化工作流程，为管理工具提供一个标示调试状态的简单方法。

此外，Kubernetes 控制面板是由开发者和用户均可使用的同样的 API 构建的。用户可以编写自己的控制器，比如调度器（scheduler），使用可以被通用的命令行工具识别的他们自己的 API。

这种设计让大量的其它系统也能构建于 Kubernetes 之上。

Kubernetes 不是什么？

Kubernetes 不是传统的、全包容的平台即服务（Paas）系统。它尊重用户的选择，这很重要。

Kubernetes：

并不限制支持的程序类型。它并不检测程序的框架 (例如，Wildfly)，也不限制运行时支持的语言集合 (比如， Java、Python、Ruby)，也不仅仅迎合 12 因子应用程序，也不区分应用与服务。Kubernetes 旨在支持尽可能多种类的工作负载，包括无状态的、有状态的和处理数据的工作负载。如果某程序在容器内运行良好，它在 Kubernetes 上只可能运行地更好。
不提供中间件（例如消息总线）、数据处理框架（例如 Spark）、数据库（例如 mysql），也不把集群存储系统（例如 Ceph）作为内置服务。但是以上程序都可以在 Kubernetes 上运行。
没有“点击即部署”这类的服务市场存在。
不部署源代码，也不编译程序。持续集成 (CI) 工作流程是不同的用户和项目拥有其各自不同的需求和表现的地方。所以，Kubernetes 支持分层 CI 工作流程，却并不监听每层的工作状态。
允许用户自行选择日志、监控、预警系统。（ Kubernetes 提供一些集成工具以保证这一概念得到执行）
不提供也不管理一套完整的应用程序配置语言/系统（例如 jsonnet）。
不提供也不配合任何完整的机器配置、维护、管理、自我修复系统。

另一方面，大量的 PaaS 系统运行在 Kubernetes 上，诸如 Openshift、Deis，以及 Eldarion。你也可以开发你的自定义PaaS，整合上你自选的CI系统，或者只在 Kubernetes 上部署容器镜像。

因为 Kubernetes 运营在应用程序层面而不是在硬件层面，它提供了一些 PaaS 所通常提供的常见的适用功能，比如部署、伸缩、负载平衡、日志和监控。然而，Kubernetes 并非铁板一块，这些默认的解决方案是可供选择，可自行增加或删除的。

而且， Kubernetes 不只是一个编排系统。事实上，它满足了编排的需求。编排的技术定义是，一个定义好的工作流程的执行：先做 A，再做 B，最后做 C。相反地， Kubernetes 囊括了一系列独立、可组合的控制流程，它们持续驱动当前状态向需求的状态发展。从 A 到 C 的具体过程并不唯一。集中化控制也并不是必须的；这种方式更像是编舞。这将使系统更易用、更高效、更健壮、复用性、扩展性更强。

Kubernetes 这个单词的含义？k8s？

Kubernetes 这个单词来自于希腊语，含义是舵手或领航员。其词根是 governor 和 cybernetic。 K8s 是它的缩写，用 8 字替代了“ubernete”。

来源：Kubernetes.io

译者：Linux中国

什么原因让Kubernetes放弃Libnetwork技术？

1.0版发布以来，Kubernetes已经拥有了一种非常基本的网络插件形式，大约与Docker的Libnetwork和容器网络模型(CNM)一起推出。与Libnetwork不同，Kubernetes插件系统仍保留其“alpha”标识。

现在Docker的网络插件支持已经发布并得到支持，我们得到的一个明显问题就是为什么Kubernetes还没有采用它。毕竟，供应商几乎肯定会为Docker编写插件我们都会更好地使用相同的驱动程序，对吧？

在进一步讨论之前，重要的是要记住Kubernetes是一个支持多个容器运行时的系统，Docker只是其中一个。配置网络只是每个运行时的一个方面，所以当人们问“Kubernetes是否支持CNM？”时，他们的真正意思是“kubernetes是否支持使用Docker运行时的CNM驱动程序？”如果我们能够跨运行时实现通用网络支持，那再好不了，但这不是一个明确的目标。

的确，Kubernetes并没有在Docker运行时采用CNM/Libnetwork。事实上，我们一直在研究由CoreOS提出的替代容器网络接口(CNI)模型和App Container规范的一部分。为什么？有许多原因，无论是技术还是非技术。

首先，Docker网络驱动程序的设计中有一些基本假设会给我们带来麻烦。Docker有一个“本地”和“全局”驱动程序的概念。本地驱动程序(如“桥”)是以单节点为中心的，不会执行任何跨节点协调。全局驱动程序(例如“Overlay”)依靠Libkv(一个键值存储抽象)来跨节点进行协调。这个键值存储是另一个插件接口，并且是非常低级的(键和值，没有语义含义)。

要在Kubernetes集群中运行诸如Docker overlay驱动程序之类的东西，我们需要集群管理员运行一个完全不同的Consul实例，etcd或Zookeeper(请参阅多主机网络)，否则我们将不得不提供我们自己的被Kubernetes支持的Libkv实现。

后者听起来很有吸引力，我们试图实现它，但是libkv接口是非常低级的，并且schema是在Docker内部定义的。我们不得不直接暴露底层的键值存储，或者提供键值语义(在我们的结构化API之上，它本身是在键值系统上实现的)。由于性能，可扩展性和安全性原因，这两者都不具有吸引力。最终结果是，整个系统将显得更加复杂，但是使用Docker网络的目标应该是件简化事情。

对于愿意并能够运行必要的基础设施以满足Docker全局驱动程序并自行配置Docker的用户，Docker网络应该“只是工作”。Kubernetes不会妨碍这样的设置，无论项目的方向如何，该选项都应该可用。然而，对于默认安装，实际结论是，这对用户来说是一种不必要的负担，因此我们无法使用Docker的全局驱动程序(包括“Overlay”)，这消除了使用Docker插件的许多价值。

Docker的网络模型提出了许多对Kubernetes无效的假设。在Docker版本1.8和1.9中，它包含一个从根本上有缺陷的“发现”实现，导致容器中的/etc/hosts文件损坏(docker＃17190)，并且这不容易关闭。在版本1.10中，Docker计划捆绑一个新的DNS服务器，目前还不清楚这是否可以关闭。

容器级命名不是Kubernetes的正确抽象 -我们已经有了我们自己的服务命名，发现和绑定的规则，并且我们已经有了我们自己的DNS模式和服务器(基于完善的SkyDNS)。捆绑的解决方案不足以满足我们的需求，但也不是无法使用的。由于本地/全局的划分，Docker具有进程内和进程外(“远程”)插件。我们调查了是否可以绕过libnetwork(从而跳过上述问题)并直接驱动Docker远程插件。不幸的是，这意味着我们不能使用任何Docker进程内插件，特别“bridge”和“overlay”，这再次消除了libnetwork的很多实用性。

另一方面，CNI在哲学上与Kubernetes更加一致。它比CNM简单得多，不需要守护进程，并且至少可以跨平台(CoreOS的rkt容器运行时支持它)。跨平台意味着有机会启用网络配置，这些配置将在运行时间内保持一致(例如Docker，Rocket，Hyper)。

它遵循UNIX做好一件事的哲学。此外，包装CNI插件并生成更加定制的CNI插件也很简单 - 可以使用简单的shell脚本完成。 CNM在这方面要复杂得多。这使CNI成为快速开发和迭代的有吸引力的选择。早期的原型已经证明，可以将kubelet中几乎100％的当前硬编码网络逻辑弹出到插件中。

我们分析了为Docker写一个Bridge的CNM驱动，运行CNI驱动，事实证明这非常复杂。

首先，CNM和CNI模型非常不同，所以没有一个“方法”排队。我们仍然有上面讨论的全局与本地和键值问题。假设这个驱动程序会声明自己是本地的，我们必须从Kubernetes获得有关逻辑网络的信息。不幸的是，Docker驱动程序很难映射到像Kubernetes这样的其他控制平面。具体而言，驱动程序不会被告知容器所连接的网络的名称只是Docker在内部分配的ID。这使得驱动程序难以映射回到另一个系统中存在的任何网络概念。

这个问题和其他问题已经由网络供应商提供给Docker开发人员，并且通常以“按预期工作”(lbnetwork＃139，libnetwork＃486，libnetwork＃514，libnetwork＃865，docker＃18864)关闭，尽管它们使非Docker第三方系统更难以集成。

在整个调查过程中，Docker已经明确表示，他们对于偏离当前过程或委托控制的想法并不是很开放。这对我们来说是非常令人担忧的，因为Kubernetes补充了Docker并增加了很多功能，但存在于Docker本身之外。由于所有这些原因，我们选择投资CNI作为Kubernetes插件模型。这会有一些不幸的副作用。他们中的大多数都相对较小(例如，Docker检查不会显示IP地址)，但有些是重要的。

特别是，由Docker运行启动的容器可能无法与Kubernetes启动的容器进行通信，如果网络集成商想要与Kubernetes完全集成，则必须提供CNI驱动程序。另一方面，Kubernetes将变得更简单和更灵活，并且早期引导的许多丑陋(例如配置Docker使用我们的桥)将会消失。

随着我们沿着这条道路前进，我们一定会保持眼睛和耳朵的畅通，以便更好地整合和简化。如果您对我们如何做到这一点有想法，我们真的很想听到他们，可以通过slack.k8s.io和邮件列表找到我们。

链接：https://kubernetes.io/blog/2016/01/why-kubernetes-doesnt-use-libnetwork/

关于Kubernetes技术内容和总结，请点击阅读原文参考<Kubernetes技术和实战总结>电子书，获取更多技术内容，具体内容如下所示。

工业互联网

产业智能官 AI-CPS

加入知识星球“产业智能研究院”：先进产业OT（工艺+自动化+机器人+新能源+精益）技术和新一代信息IT技术（云计算+大数据+物联网+区块链+人工智能）深度融合，在场景中构建状态感知-实时分析-自主决策-精准执行-学习提升的机器智能认知计算系统；实现产业转型升级、DT驱动业务、价值创新创造的产业互联生态链。