微服务部署 Docker 和 Kubernetes <十七> 译

Docker

    几年前,Docker 以优雅的解决方案来实现不变交付(immutable delivery)。Docker 容许咱们将应用程序与它须要的全部依赖包(os、jvm、其余应用程序依赖项等)打包,以轻量级、分层、镜像格式进行打包。使用这些镜像运行实例,这些实例运行在 linux 容器内的应用程序,这些容器具备独立 cpu、内存、网络和磁盘使用。从某种意义上讲,这些容器是应用程序虚拟化或过程虚拟化的形式。他们容许一个进程执行,认为它是运行的惟一方法(例如,ps,您只看到您的应用程序在那里),而且它彻底访问cpu、内存、磁盘、网络和其余资源,但现实中它没有,它只能使用它分配的资源。例如,我能够启动一个Docker容器分配cpu,内存段,限制网络io的使用程度。从 linux 容器外部,在主机上,应用程序看起来就像另外一个过程。没有虚拟化设备驱动程序、操做系统或网络栈以及特殊的虚拟机监控程序。这只是个过程。这也意味着咱们能够得到更多的应用程序,运行在一个单一的硬件上,以提升密度,而无需额外操做系统和其余部分 vm 的开销,这将须要实现相似的隔离质量。前端

    发生的事情也不是革命性的,已构建到linux内核中(而且有一段时间)的名为cgroups、名称空间和chroot 的特性用于建立应用程序虚拟化的外观。linux容器已经运行了10年多了,并且在solaris和freebsd中,流程虚拟化甚至在此以前也存在。传统上,使用这些底层 linux 原语,甚至像 LXC 这样的高级抽象,充其量也是复杂的。Docker来了,并简化了 api 和用户体验围绕 linux 容器。Docker带来了一个单一客户端cli,它能够轻松地根据基于在的镜像格式来建立这些 linux 容器,如今已经向开放容器倡议(Oci)中的更大社区打开了这个格式。这种易用性和镜像格式正在改变咱们打包和交付软件的方式。linux

    一旦你有了一个镜像,那么就会把许多 linux容器的大量圈圈变得微不足道。这些层是创建在基础镜像(例如rhel、debian或其余linux操做系统)和应用程序文件之间的增量。分发新应用程序只会将新层分发到现有基础层之上。这使得非图像比绕着膨胀的云机器图像更容易。此外,若是在基镜像中找到了漏洞(例如shell冲击、Heartbleed等),则能够重建基镜像,而没必要尝试修补每一个vm。这样能够轻松地运行容器:而后它们能够从开发人员的桌面移动到dev、qa或生产,而没必要手动但愿全部正确的依赖项都位于正确的位置(此应用程序使用jvm 1.六、1.七、1.8?)。若是须要使用更改(新应用程序)从新部署或修复基镜像,那么就只需更改须要更改的图像中的层。git

Kubernetes

谷歌以规模运行linux容器而闻名。事实上,在google运行的“一切”都运行在linux容器中,而且由他们的 Borg 集群管理平台管理。谷歌前工程师 Joe·Beda 表示,该公司每周启动二十亿次以上的容易行为。谷歌甚至能够利用它建立底层 linux 技术,从而使容器成为可能。2006,他们开始着手研究“process containers”,最终变成了cgroups,并被合并到 linux 内核代码库中,并在2008发布。随着其规模和规模的运行容器规模,这并不奇怪,谷歌已经对围绕容器构建的平台产生了这样的影响。例如,一些流行的集装箱管理项目在 Kubernetes 以前受到了谷歌的影响。github

 

  • 最初的 CloudFoundry 建立者(德里克·科里森和瓦迪姆·斯皮瓦克)曾在谷歌工做,并花了几年时间使用谷歌的 Borg 集群管理解决方案。
  • ApacheMesos是为一篇博士论文而建立的,它的建立者(本·辛德曼)曾在谷歌实习,并与谷歌工程师就容器集群、调度和管理问题进行了屡次交谈。
  • Kubernetes是一个开源的容器集群管理平台和社区,最初是由在Google构建Borg的工程师建立的。


    早在2013年,当 Docker 撼动了科技行业时,谷歌就决定,是时候开放下一代继任者博格(Borg)的开源软件了,他们将其命名为 Kubernetes 。现在,Kubernetes是一个庞大的、开放的、快速发展的社区,Google、RedHat、CoreOS和许多其余人(包括许多独立的我的)都作出了贡献。Kubernetes为在Linux容器内大规模运行微服务集群带来了不少功能。Google已经将十多年的经验打包成Kubernetes,所以可以利用这些知识和功能来部署咱们本身的微服务是改变游戏规则的。网络规模的公司已经这样作多年了,他们中的许多公司(Netflix、亚马逊等)不得不手工制做许多库伯尼特如今已经好的原型机。    Kubernetes有几个简单的原语,在咱们深刻研究示例以前,您应该理解它们。在本章中,咱们将向您介绍这些概念;在接下来的一章中,咱们将使用它们来管理一个微服务集群。shell

Pods

    pod 是由一个或多个 Docker 容器组成的一组(就像一群鲸鱼?)。然而,一个典型的 pod 部署一般是一对一的带有一个 Docker 容器.。若是您有SideCar、ADVINE或适配器部署,这些部署必须始终与应用程序位于同一位置,那么将它们分组的方法是使用 Pod。此抽象也是保证容器关联的一种方法(即,Docker容器A将始终部署在同一主机上的Docker容器B旁边)。后端

    Kubernetes 负责组织、安排和管理 Pod。当咱们提到运行在 Kubernetes 内部的应用程序时,它是在一个 Pod 内的Docker容器内运行的。一个 Pod 有它本身的 IP 地址,而且 Pod 内的全部容器都共享这个IP(这不一样于普通的 Docker ,每一个容器都有一个IP地址)。当 volumes 被安装到 Pod 时,它们也在运行在Pod 中的单个容器之间共享。api

    关于 Pod 还有最后一件事要知道:它们是可替换的。这意味着它们能够在任什么时候候消失(要么是由于服务崩溃,要么是集群杀死了它)。他们不像一个虚拟机,你关心和培育。Pod 在任什么时候候均可以被摧毁。这符合咱们在微服务世界中的预期,即事情会失败(而且会发生),所以强烈鼓励咱们在编写微服务时考虑到这一前提。这是一个重要的区别,由于咱们将在下面几节中讨论其余一些概念。微信

Labels

    标签是简单的键/值对,咱们能够将其分配给释放=稳定或层=后端之类的 Pod。Pod(和其余资源,但咱们将重点放在 Pod )能够有多个标签,分组和分类在松散耦合的方式,这变得至关明显,尤为当你使用Kubernetes。这并不奇怪,谷歌已经肯定了这样简单的结构,咱们能够创建强大的集群规模。在咱们标记了 Pod 以后,咱们可使用标签选择器来找出哪些 Pod 属于哪一组。例如,若是咱们有一些豆荚标签层=后端和其余标签层=前端,使用标签选择器表达式的层!=前端。咱们能够选择全部没有标记为“前端”的Pod。标签选择器用于下面两个概念:复制控制器和服务。网络

Replication Controllers

    当谈到在规模上运行微服务时,咱们可能会讨论任何给定微服务的多个实例。Kubernetes有一个名为ReplyingController的概念,即给定的一组微服务的副本数进行控制。例如,假设咱们想要管理标记为tier=后端和Release=稳定的 Pod 的数量。咱们可使用适当的标签选择器建立一个复制控制器,而后可以用ReplicationController上的副本值控制集群中的那些 Pod 的数量。若是咱们将副本计数设置为10,那么 Kubernetes 将协调它的当前状态,以反映为给定的 ReplyingController 运行的10个 Pod。若是如今只有五我的在跑,Kubernetes 就会再运行五个。若是有20个运行,Kubernetes将杀死10(其中10杀死是不肯定的,就你的应用程序而言)。Kubernetes将作它所须要的任何事情来收敛到所需的10个副本的状态。您能够想象使用ReplicationController很是容易地控制集群的大小。咱们将在下一章中看到Rep许可控制器的例子。jvm

Services

    咱们应该理解的最后一个 Kubernetes 的概念是Kubernetes 服务。ReplicationController能够控制咱们所拥有的服务的表明的数量。咱们也看到 Pod 能够被杀死(或者他们本身坠毁,或被杀,多是做为一个恢复控制器的规模缩小事件的一部分)。所以,当咱们试图与一组 Pod 通讯时,咱们不该该依赖它们的直接IP地址(每一个 Pod 都有本身的IP地址),由于 Pod 能够来来去去。咱们须要的是一种方法来分组 Pod,以发现他们在哪里,如何与他们沟通,并可能对他们负载平衡。这正是 Kubernetes 服务机构的职责所在。它容许咱们使用标签选择器对咱们的 Pod 进行分组,并用单个虚拟(集群)IP对它们进行抽象,而后咱们能够用它来发现它们并与它们交互。咱们将在下一章中展现具体的例子。

    有了这些简单的概念、pods、标签、ReplicationControllers和服务,咱们就能够像 Google 已经学会的(或者不学会的)管理和扩展咱们的微服务。为复杂的问题找出简单的解决方案须要不少年和许多失败,所以咱们强烈鼓励您学习这些概念,并体验使用Kubernetes管理容器为您的微服务带来的力量。

    下章咱们看看怎么使用!

 

原文:

做者源码:https://github.com/redhat-developer/microservices-by-example-source

有什么讨论的内容,能够加我微信公众号:

相关文章
相关标签/搜索