一篇文章带你了解Kubernetes

                        

【本文专栏于[头条号]、[知乎]同步发布，可关注同名账号订阅相关文章，每周固定更新】

【全文5489字，阅读时间约15分钟，建议先收藏】

Kubernetes是一个流行的开源平台，重要用于容器编排——也就是说，它用于管理由多个容器构建的应用程序。自2013年Docker容器化项目启动以来，容器已经变得越来越流行，但是与此同时，大型分布式容器化应用程序会因此变得越来越难以协调。通过使应用程序容器化，我们更容易大规模管理应用程序。而Kubernetes已经成为这场容器革命中关键的部分。

---

 

先从容器编排谈起

容器支持类似虚拟机间的彼此隔离，但是开销更小，灵活性更大。因此，容器改变了人们对开发、部署和运维的想法。在容器化体系结构中，构成应用程序的不同服务被打包到单独的容器中，并支持跨物理或虚拟机集群部署。但是这就产生了对容器编排的需求——这是一种能够支持对基于容器的应用程序进行自动部署、自动管理、自动扩展、自动组网的工具。

何谓Kubernetes？

Kubernetes最开始只是一个开源项目，目前已经成为最流行的容器编制工具之一;它允许我们大规模部署和管理多容器应用程序。实际上，Kubernetes最常与Docker一起使用，Docker是目前最流行的容器化平台，它也可以与任何符合开放容器协议(Open container Initiative, OCI)的镜像格式和运行时标准的容器系统一起运行。而且，由于Kubernetes是开源的，对如何使用它的限制相对较少，所以任何想要运行容器的人都可以自由地使用它，我们可以在任何能够运行容器的地方使用它——在本地、在公共云中，或者两者兼而有之。

谷歌和Kubernetes

Kubernetes最初是谷歌内部的一个项目。它是谷歌内部使用的早期容器管理工具Google Borg的继承者(虽然不是直接的继承者)。谷歌在2014年开源了Kubernetes，部分原因是Kubernetes提供的分布式微服务架构使得在云中运行应用程序变得很容易。谷歌将容器、微服务和Kubernetes的采用视为潜在的推动客户使用其云服务的动力(尽管Kubernetes也可以运行在Azure和AWS上)。Kubernetes目前由云原生计算基金会(Cloud Native Computing Foundation)维护，该基金会本身属于Linux基金会。

Kubernetes vs Docker&Kubernetes vs Docker Swarm

Kubernetes并没有取代Docker，而是增强了它。不过，Kubernetes确实取代了一些因Docker而生的高级技术。

Docker Swarm就是这样一种被取代的技术，它是与Docker捆绑在一起的编排工具。目前我们仍然可以使用Docker Swarm来代替Kubernetes，但是Docker公司已经同意让Kubernetes成为Docker社区和Docker企业版的一部分。但这也不代表Kubernetes是Docker Swarm的替代品。Kubernetes比Swarm复杂得多，需要更多的配置更多的内容。但是，从长远来看，这项工作的目的将会带来巨大的回报——一个更易于管理、更有弹性的应用程序基础设施。对于开发工作和更小的容器集群，Docker集群提供了一个更简单的选择。

Kubernetes与Mesos的竞争

Kubernetes还有另外一个竞争对手——Mesos。Mesos是一个Apache项目，最初由Twitter的开发人员开发;它实际上被看作是谷歌Borg项目的一个解决方案。

Mesos实际上已经提供了容器编排服务，但它的野心远不止于此。它的目标是成为一种云操作系统，能够协调容器和非容器组件。为此，许多不同的平台可以在mesos中运行——包括Kubernetes本身。

---

 

Kubernetes 架构：Kubernetes的工作原理

Kubernetes的体系结构使用了各种概念和抽象。其中一些是对现有的、熟悉的概念的变体，但另一些则是针对Kubernetes的。

Kubernetes集群

最高级别的Kubernetes抽象集群是指运行Kubernetes的机器组(本身是集群级应用程序)及其管理的容器。一个Kubernetes集群必须有一个master，其管理和控制集群中所有其他Kubernetes机器。一个高度可用的Kubernetes集群可以跨多台机器建立多个master副本。但是同一时间只有一个master运行作业调度和controller-manager。

Kubernetes节点和Pod

每个集群都包含Kubernetes节点。节点可能是物理机器或vm。同样，这个想法也是抽象的：无论应用程序运行在什么平台上，Kubernetes都负责在该平台上的部署。Kubernetes甚至可以确保某些容器只运行在vm或物理机上。

节点运行的pods，这是Kubernetes创建或管理的最基本的对象。每个pod表示Kubernetes中运行的应用程序或进程的单个实例，并由一个或多个容器组成。Kubernetes将一个pod中的所有容器视为一个组进行启动、停止和创建副本。Pods的概念让用户更近关注与应用程序上，而不是容器本身。有关Kubernetes需要如何配置的详细信息(从pod启动开始)保存在Etcd(一个分布式键值存储)中。

在节点上创建和销毁pod需要符合用户在pod定义中指定的期望状态。Kubernetes提供了一个称为控制器的抽象概念，用于处理吊舱如何向上、展开和向下旋转的后勤问题。根据所管理的应用程序的类型的不同，对应有几种不同的类型的控制器。例如，“StatefulSet”控制器用于处理需要持久状态的应用程序。另一种控制器是deployment控制器，用于将应用程序进行滚动升级或降级，将应用程序更新到新版本，或者在出现问题时将应用程序回滚到已知的好版本。

Kubernetes服务

因为pod存在生存和死亡，所以我们需要一个不同的抽象概念来管理应用程序生命周期。应用程序应该是一个持久实体，即使运行组成应用程序的容器的pod本身不是持久的。为此，Kubernetes提供了一个抽象概念称为service（服务）。

Kubernetes中的服务描述了如何通过网络访问给定的pod组(或其他Kubernetes对象)。正如Kubernetes文档所指出的，构成应用程序后端的pod可能会发生变化，但是前端不必知道或跟踪这些细节。我们只需要知道service，就可以隐藏后端的细节。

Kubernetes内部的一些片段使情况更加完整。Scheduler组件将工作负载分配给各个节点，以便在资源之间实现平衡，从而使部署满足应用程序要求。controller manager组件确保应用程序、工作负载等的系统状态匹配Etcd中设置的预期状态。

需要记住的是，容器使用的任何底层机制(如Docker本身)都不会被Kubernetes所替代。相反，Kubernetes将如何使用这些机制以保证应用程序规模化运行进行了抽象。

Kubernetes入口

Kubernetes服务被认为是在集群中运行的。但是您希望能够从外部访问这些服务。Kubernetes有几个组件可以以不同程度的简化和健壮性来实现这一需求，包括NodePort和LoadBalancer，但是最灵活的组件是Ingress。Ingress是一个API，用于管理对集群服务的外部访问，通常通过HTTP方式进行。

Ingress确实需要一些配置来正确设置。（Matthew Palmer写了一本关于Kubernetes开发的书，他在他的网站上介绍了如何配置Ingress）

Kubernetes Dashboard（仪表板）

Kubernetes的一个组件Dashboard可以帮助我们控制所有其他组件，这是一个基于web的UI，我们可以使用它部署和定位并处理应用程序故障，管理集群资源。Dashboard默认情况下没有安装，但是我们能很容易的把它部署到集群中。

---

 

Kubernetes的优势

因为Kubernetes引入了新的抽象和概念，而且Kubernetes的学习周期较长，所以通常会问使用Kubernetes的长期回报是什么。下面举了一些具体方案来告诉你在Kubernetes内部运行应用程序会变得更简单。

Kubernetes为我们管理应用程序健康状况、副本、负载平衡和硬件资源分配

Kubernetes最基本的职责之一就是保持应用程序的正常运行和响应用户的需求。那些变得“不健康”，或者不符合我们的健康定义的应用程序，Kubernetes可以帮我们自动修复。

Kubernetes提供的另一个好处是最大限度地使用硬件资源，包括内存、存储I/O和网络带宽。应用程序可以对其资源使用设置宽松的限制和硬性限制。许多使用最少资源的应用程序可以打包在同一个硬件设备上。需要扩展的应用程序可以放在有增长空间的系统上。同样，跨集群更新，或者在更新中断时回滚，都可以实现自动化。

Kubernetes使用Helm charts简化了预配置应用程序的部署

像Debian Linux的APT和Python的Pip这样的包管理器为用户省去了手动安装和配置应用程序的麻烦。当应用程序拥有多个外部依赖项时，这个功能显得尤其方便。

Helm本质上是Kubernetes的一个包管理器。许多当下流行的软件应用程序必须作为一组相互依赖的容器在Kubernetes中运行。Helm提供了一种定义方法，即“图表”，它描述了如何将应用程序或服务作为Kubernetes中的一组容器运行。

如果你正在构建一个私有的自定义应用程序，你就必须从头开始创建你自己的Helm charts。但是，如果您使用的是具有公共部署模式的流行应用程序，那么很可能已经有人为它编写了一个Helm chart，并将其发布到官方Helm charts存储库中。另一个寻找官方Helm charts的地方是Kubeapps.com目录。

Kubernetes简化了对存储、secrets和其他应用程序相关资源的管理

容器通常是不可变的，不管你往里面放什么都不应该改变。但是应用程序需要状态，这意味着它们需要一种可靠的方法来处理外部存储卷。这使得容器在应用程序的一个生命周期中生存、死亡和重生的方式都变得更加复杂。

Kubernetes提供了抽象概念，允许容器和应用程序以与其他资源相同的解耦方式进行存储。许多常见的存储类型，从Amazon EBS卷到普通的NFS共享，都可以通过Kubernetes存储驱动程序(称为卷)访问。通常，卷被绑定到一个特定的pod，但是一个称为“持久卷”的子类型可以用于存储需要独立于任何pod生存的数据。

容器通常需要与“secrets”一起工作—诸如API密钥或服务密码之类的证书。我们不希望这些证书硬编码到容器中或公开存储在磁盘卷中。虽然第三方解决方案可以做到这一点，比如Docker secrets和HashiCorp Vault，Kubernetes也有自己的机制来处理原生的secrets来保证这些secrets能被小心保存。例如，Etcd必须配置为在节点之间发送秘密时使用SSL/TLS，而不是使用纯文本。

Kubernetes应用程序可以在混合云和多重云环境中运行

云计算的一个长期梦想是能够在任何云环境中，或者在任何公有或私有云的混合云中运行任何应用程序。这不仅可以避免厂商垄断，还可以更好的利用有别单一云环境的优势。

Kubernetes提供了一组基本类型，统称为联邦，用于保持跨多个区域和云的多个集群之间的同步。例如，一个给定的应用程序部署可以在多个集群之间保持一致，不同的集群可以共享服务发现，以便可以从任何集群访问后端资源。联邦还可以用于创建高可用性或容错性高的Kubernetes部署，无论我们是否跨多个云环境。

对Kubernetes来说，联邦还相对较新。并不是所有的API资源都支持跨联邦实例。但是这些缺点将在Kubernetes的未来版本中得到解决。

---

 

获取Kubernetes

Kubernetes有很多可用的形式——从开源版本到商业支持的发行版，再到公共云服务——最好的方法是根据用例来确定从哪里获得它。

• 如果想自己完成所有工作，可以从Kubernetes的GitHub存储库下载源代码和大多数常见平台的预构建二进制文件。

• 如果您正在使用Docker社区或Docker Enterprise，Docker的最新版本附带了Kubernetes安装包。对于docker专家来说，这显然是比Kubernetes更容易上手的方法，因为你使用你已经很熟悉的产品实现的。

• 如果您正在进行内部部署或在私有云中部署，选择一个基础架构中内置Kubernetes的私有云都是有利的。标准发行版、认证版和受支持的Kubernetes发行版可以从几十个供应商获得，包括Canonical、IBM、Mesosphere、Mirantis、Oracle、Pivotal、Red Hat、Suse、VMware等等。

• 如果您在公共云中部署服务，三大公共云供应商都提供Kubernetes作为服务。谷歌云平台提供了谷歌Kubernetes引擎。微软Azure提供Azure Kubernetes服务。亚马逊已经将Kubernetes添加到其现有的弹性容器服务中。托管Kubernetes服务还可以从IBM、Nutanix、Oracle、Pivotal、Platform9、Rancher Labs、Red Hat、VMware和许多其他供应商获得。