深度解析 Kubernetes 部署及使用案例
技术
作者:Jeremy Hess
译者:Sandy
2018-06-14 06:26

在 2008 年,容器出现之前,虚拟机是优化数据中心物理资源的最优选择。虽然虚拟机运作得不错,但仍存在一些缺陷:比如虚拟机占用了太多的资源,因为它们需要一个完整的操作系统和仿真指令才能访问物理 CPU。即使像 Intel VT-x 和 AMD-V,这些解决仿真问题的技术也使用了虚拟机。


容器的目标是让资源利用率达到最大化,从而利用虚拟机的优势达到类似物理机的性能。为了达到这个目标,需要将共享内核分配给所有可根据需要,选择任何操作资源的应用程序。所有容器都能单独访问资源(如 CPU,内存,磁盘和网络),并且每个容器都可以由管理员划分优先级。换句话说,容器可以在物理机上运行并进行资源共享,但不能访问其他容器的资源。


那容器是如何确保高可用性,灾备恢复能力和可扩展性的呢? Kubernetes 等容器编排系统提供了解决方案。系统负责处理一个或多个机器集群并检测运行在其上的每个镜像的可用性。集群的大小可以从三台机器到几千台机器和容器,如果有需要甚至可以分布在不同的云提供商之间。如果一台机器发生故障,该工具有能力将容器转移到另一个节点上,并同时保持整个集群的正常运行。


编排即多云操作系统


容器编排系统可以操作位于同一个数据中心或不同位置的,不同供应商的多台机器。实际上,使用诸如 Kubernetes 之类的编排工具的组织,不需要知道计算资源分布在哪或如何分布。 容器编排能将云供应商的功能转化为可以被轻松替代的商品,也能帮助组织将 workload 分配给不同的供应商。


拥有本地数据中心的公司也可以从容器编排器中受益。如果编排器部署在本地基础架构中,那云的无限计算资源将不能再用。但公司仍可用相同的方式管理资源,并轻松实现迁移。


另一个使用案例是,当运营商除了使用内部资源外还想使用云的无限计算功能的话,混合云可以帮助公司在不购买新硬件的情况下,利用现有的硬件资源增加计算容量。


像 Kubernetes 这样的容器编排工具可以作为多云操作系统使用。公司只需指定所需运行的资源,而无需知道他们正在处理什么,操作系统在哪里或它们是由谁提供的。


Kubernetes 的崛起


Kubernetes 于 2014 年首次发布,它是一款开源的容器编排工具,可自动扩展,分配容器并管理容器容错。 Kubernetes 最初由 Google 创建并捐赠给 CNCF,它广泛地用于以容错的方式处理 Docker 容器和其他容器工具。 作为开源产品,它可用于各种平台和系统。 Google Cloud,Microsoft Azure 和 Amazon AWS 为 Kubernetes 提供官方支持,因此不必对集群本身进行配置更改。
Kubernetes 的受欢迎程度稳步上升,其在 2017 年发布了四个以上的版本。它也是 GitHub 在 2017 年度热度最高,评论数量第 2 的项目。

部署 Kubernetes

Kubernetes 提供了使用容器部署应用程序的新方法。它创建了一个抽象层,可以用声明式而不是命令式编程来操作。这样,随着时间的推移,部署 Kubernetes 和升级服务要简单得多。下图是 replication controller [1] 的部署,该控制器控制着小型 Kubernetes 单元的创建。

该文件几乎不言自明:gcr.io/google_containers/elasticsearch:v5.5.1-1 表示 Docker Elasticsearch 的部署。该镜像包含两个副本,并使用持久性储存来存储永久性数据。


目前有很多方法来部署一个工具。比如说,Deployment [2] 可以在保持可用状态的情况下,更新从具有执行滚动更新机制的 replication controller 进行升级。此外,可以通过声明来配置 Load Balancer、 subnet 甚至是  secrets。


计算资源偶尔会闲置;主要目的是避免超额使用。减少闲置时间的一个好方法是用 Namespace 作为虚拟集群的一种形式。每个 Namespace 都是 Kubernetes 内部一个完全隔离的空间,这意味着可以根据需要创建多个环境,例如 production 环境或 staging 环境。Namespace 中的服务将收到一个 DNS 名称,例如 <service-name>.<namespace-name> .svc.cluster.local。这意味着同一 Namespace 内的服务只需要使用 service name 向另一个服务发出请求。


根据公司的规模和目标,Kubernetes 可以部署在不同的场景中:

  • 内部:公司可以将他们自己的数据中心转换为 Kubernetes 集群。在这种情况下,公司可以充分利用自己的资源。
  • :安装过程类似于内部部署,但包括云中的虚拟机。这允许公司根据需要创建无限数量的机器。
  • 混合:组织的数据中心可能在大部分时间表现良好,但有时会出现本地计算资源无法处理的峰值。在这种情况下,可以使用混合解决方案。必要时,Kubernetes 将在云上创建虚拟机,这样在内部服务器已满的情况下可以更好地分配计算资源。
  • 本地部署:某些云供应商有自己的 Kubernetes 嵌入式实施。在这种情况下,不需要部署和配置 Kubernetes 本身;公司只需管理该服务。由于部署 Kubernetes 可能会非常棘手,对于那些没有能力处理集群配置和维护的大型 IT 团队的公司来说,这是一个很好的解决方案。
  • 多云:这是混合云解决方案的升级。计算资源部署在两个或更多的云供应商之间。在这种情况下,企业需要避免被供应商锁定,并在出现问题时尽量降低风险。

Kubernetes 不是唯一可用的容器编排器。市场上其他流行的工具包括 Docker Swarm [3] 和 Apache Mesos [4]。 Swarm 是一个开源的容器编排器,旨在成为 Docker 和 Docker Compose 的“大哥”。 Swarm 与 Docker 使用相同的命令行,彼此高度包容:企业自行决定其集群上所有功能需要使用的工具。 
Apache Mesos 是另一个开源编排器,除了管理容器外它还管理其他技术。 Apache Mesos 自称为“数据中心操作系统”。这也是其商业产品 Mesosphere 的数据中心操作系统(DC / OS)的名称。 Apache Mesos 比 Kubernetes 更具包容性,可以部署除容器应用以外的各种类型的应用程序。


使用案例


我们选择了一些常见案例来演示 Kubernetes 的功能。这些案例可以用于不同的设置。


自我修复和可扩展服务

简单来说,Kubernetes 处理的单元可以描述为 Pod 和 Service。Pod 是 Kubernetes 的基本部署单位。一个 Pod 可以包含几个容器,而这些容器相互通讯,比如网络和存储。Service 是为一组容器提供可访问性的接口, 它可用于内部或公共访问,并负责多个容器实例的负载均衡。

一旦完成,Pod 就会从集群中消失。 Pod 既可以自然终止也会因为操作错误而终止。Deployment 是用于创建和维护 Pod 的最现代的 Kubernetes 模型。使用单个描述文件,开发人员可以指定部署所需的所有内容,继续运行,扩展和升级 Pod。


下图是一个简单的部署。这个 Pod 带有三个副本的 Nginx(版本 1.7.9)。换句话说,Kubernetes 将管理三个 Nginx 实例;当一个实例停止工作时,Kubernetes 将创建一个新实例。



Kubernetes 部署 Nginx


可以用以下命令将 Deployment 配置为可自动扩展:

$ kubectl autoscale deployment nginx-deployment --min = 10 --max = 15 --cpu-percent = 80


Kubernetes 的优势之一就是让用户很容易理解平台在做什么。在这种情况下,集群将部署 10 个 Nginx 实例,如果 CPU 利用率超过 80%,则最多有 15 个实例。


服务与无服务

自从 AWS 推出 Lambda 以来,无服务架构已经席卷全球。 用法很简单:只需开发代码,不用担心其他任何事情。 服务和可扩展性由云供应商来负责,代码只需要作为处理特定事件的函数来开发,比如从 HTTP 请求到消息队列。


供应商锁定是该解决方案的主要缺点。 在不重构大多数代码的情况下更改云供应商几乎是不可能的。 有一些像无服务的解决方案试图在云与云之间让功能代码标准化。 


另一种解决方案是使用 Kubernetes 集群来创建无供应商的无服务平台。 如上所述,Kubernetes 忽略了云服务之间的差异。 目前流行两种将集群虚拟化为无服务平台的框架:Kubeless 和 Fission。


使用 Namespace 优化资源使用Kubernetes 的 Namespace 也被称为虚拟集群。Namespace 在真正的集群中创建一个虚拟分离的集群。没有Namespace 的集群可能有 test,staging 和 production 集群。虚拟集群通常会浪费一些资源,因为它们不会进行持续测试,并且 staging 集群有时会被用于检测新功能。通过使用虚拟集群或 Namespace,运维团队可以根据给定的 workload 将同一组物理机用于不同的集合。

Namespace  与 DNS 密切相关,因为位于同一 Namespace  内的服务可以通过其名称进行访问。Namespace  为通过网络名称来定位服务的环境提供了一个很好的解决方案:来自不同 Namespace 的实例都能找到它们的依赖关系,而不需要考虑它们位于哪个 namespace 。


另外,Namespace 可以有资源配额:每个虚拟集群都可以接收固定的分配,以避免 Namespace 之间的资源竞争。这对于避免在少数优先环境中,生产环境共享计算资源特别有用。最后,可以使用每个 Namespace 的角色创建不同的权限,以限制可以访问生产环境的人员数量。


混合云与多云

混合云一般利用来自本地传统数据中心和云提供商的计算资源。当公司在本地数据中心中有一些服务器,并希望使用云的无限计算资源来扩展或替代公司资源时,他们通常会使用混合云。另一方面,多云是指使用多个云供应商来处理计算资源的云。 多云通常用于避免供应商锁定,并降低云供应商在执行关键任务操作时出现故障的风险。

这两个解决方案都可以由 Kubernetes Federation [5] 处理。多个集群(每个云或本地数据中心都有一个),由 Federation 创建并管理。Federation 会同步计算资源,甚至允许跨集群服务发现:几乎所有 Pod 都可以在不了解基础架构的情况下与另一集群中的 Pod 进行通信。
Federation 的设置并不简单,它有个问题:该解决方案不适用于 Google Kubernetes Engine,Azure Container Service 或 AWS EKS 等托管服务。

原文链接:https://thenewstack.io/kubernetes-deep-dive-and-use-cases/

参考文献:[1]https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/[2]https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rollover-aka-multiple-updates-in-flighttZXWWk75SX2sg/pubhtml?gid=0&single=true[3]https://docs.docker.com/engine/swarm/[4]http://mesos.apache.org/[5]https://kubernetes.io/docs/concepts/cluster-administration/federation/

402 comCount 1

sdfgh

fdghjj