Kubernetes – Google分布式容器技术初体验

Kubernetes是Google开源的容器集群管理系统。前几天写的 分布式服务框架的4项特性 中提到一个良好的分布式服务框架需要实现 服务的配置管理。包括服务发现、负载均衡及服务依赖管理。 服务之间的调度及生命周期管理。 由于Kubernetes包含了上述部分特性,加上最近Google新推出的Container Engine也是基于Kubernetes基础上实现,因此最近对Kubernetes进行了一些尝试与体验。 运行环境 Kubernetes目前处于一个快速迭代的阶段,同时它的相关生态圈(比如docker,etcd)也在快速发展,这也意味没有适合新手使用非常顺畅的版本,网上的各种文档(也包括官方文档)和当前最新的发布版会有不同程度滞后或不适用的情况,因此在使用时可能会碰到各种细节的障碍,而且这些新版本碰到的问题,很有可能在网上也搜索不到解决方案。 Kubernetes设计上并未绑定Google Cloud平台,但由于以上原因,为了减少不必要的障碍,初次尝试建议使用GCE作为运行环境(尽管GCE是一个需要收费的环境)。默认的cluster启动脚本会创建5个GCE instance,测试完需要自己及时主动删除。为了避免浪费,可以将minions减少,同时instance类型选择f1-micro。费用方面一个f1-micro instance运行1个月大约50元人民币,因此用GCE来测试Kubernetes,如果仅是测试时候开启的话,并不会产生太多费用。 Pods及Replication Controller Kubernetes的基本单元是pods,用来定义一组相关的container。Kubernetes的优点是可以通过定义一个replicationController来将同一个模块部署到任意多个容器中,并且由Kubernetes自动管理。比如定义了一个apache pod,通过replicationController设置启动100个replicas,系统就会在pod创建后自动在所有可用的minions中启动100个apache container。并且轻松的是,当container或者是所在的服务器不可用时,Kubernetes会自动通过启动新的container来保持100个总数不变,这样管理一个大型系统变得轻松和简单。 Service 微服务 在解决部署问题之后,分布式服务中存在的一大难题是服务发现(或者叫寻址),用户访问的前端模块需要访问系统内部的后端资源或者其他各种内部的服务,当一个内部服务通过replicationController动态部署到不同的节点后,而且还存在前文提到的动态切换的功能,前端应用如何来发现并访问这些服务?Kubernetes的另外一个亮点功能就是service,service是一个pod服务池的代理抽象,目前的实现方法是通过一个固定的虚拟IP及端口来定义,并且通过分布在所有节点上的proxy来实现内部服务对service的访问。 Kubernetes自身的配置是保存在一个etcd(类似ZooKeeper)的分布式配置服务中。服务发现为什么不通过etcd来实现?Tim的判断更多的是为了Kubernetes上的系统和具体的配置服务解耦。由于服务发现属于各个系统内部的业务逻辑,因此如果使用etcd将会出现业务代码的逻辑中耦合了etcd,这样可能会让很多架构师望而却步。 尽管没有耦合etcd,部署在Kubernetes中的服务需要通过container中的环境变量来获得service的地址。环境变量虽然简单,但它也存在很多弊端,如存在不方便动态更改等问题。另外service目前的实现是将虚拟IP通过iptables重定向到最终的pod上,作者也提到iptables定向的局限性,不适合作为大型服务(比如上千个内部service一起运作时)的实现。 由于service定位是系统内部服务,因此默认情况下虚拟IP无法对外提供服务,但Kubernetes当前版本并没直接提供暴露公网IP及端口的能力,需要借助云服务(比如GCE)的load balancer来实现。 小结 总的看来Kubernetes提供的能力非常令人激动,pod、replicationController以及service的设计非常简单实用。但如果立即将服务迁移到Kubernetes,还需要面对易变的环境。另外尽管Kubernetes提供health check的机制,但service生产环境所需的苛刻的可用性还未得到充分的验证。Service发现尽管不跟Kubernetes的内部实现解耦,但利用环境变量来实现复杂系统的服务发现也存在一些不足。 安装说明 Kubernetes…

分布式机器学习的故事:Docker改变世界

Docker最近很火。Docker实现了“集装箱”——一种介于“软件包”和“虚拟机”之间的概念——并被寄予厚望,以期革新Internet服务以及其他大数据处理系统的开发、测试、和部署流程。 为了使用Docker,需要了解不少工具及其设计思路;而这些工具的文档分布在不同的网站。为了方便大家学习,本文以开发一个极简的搜索引擎为例,展示Docker带来的革新。 说是革新,其实是Google已经用了十年的方式,只是最近才因为Docker开源项目而广为人知。Eric Brewer(Google VP of Infrastructure)在Dockercon14活动上的演讲回顾了这段历程。目前,Google每周会执行20亿个集装箱。可以说,最近十年是各互联网公司和高校都在奋力模仿Google的计算技术的十年。了解这一模仿的过程,可以帮助我们深入理解分布式系统(包括现在常说的“大数据系统”)中若干重要问题。为此,本文以技术教程为主线,穿插了一些关于Hadoop和Mesos等“模仿”项目的介绍,简要追溯它们勇敢而艰难的“邯郸学步”的历程。最后,本文会介绍Google最近公布的“正确答案”——Kubernetes——Google核心技术Borg的开源版本。 Docker Docker是一个软件系统,实现了一种称为“集装箱”的概念。集装箱类似Google机群管理系统Borg中的包(package)。 通常我们说的“包”是软件包——比如Ubuntu/Debian Linux里常见的.deb文件——安装的时候,安装程序会把被依赖的包也装上。可是执行的时候呢?得根据具体情况配置,然后依次启动互相依赖的多个程序。比如,启动一个Web服务之前,要启动Apache和MySQL;而且他们仨都得有合理的配置,确保它们能一起工作,来实现这个Web服务。 但是Docker集装箱以及Borg中的包更像虚拟机。虚拟机里包括程序和配置,所以可以被执行——也就是执行其中的程序。因为程序是配置好的,所以虚拟机可以被扔到各种环境上去执行——包括开发机、做演示用的笔记本电脑、用VirtualBox虚拟的机群、测试机群、预发布环境和产品环境。近几年随着“云计算”概念的普及,虚拟机被广泛使用,作为分布式计算的基础调度单元。 Docker作为一个软件系统,可以用来创建“集装箱镜像”(container image)和执行这些镜像。就像VirtualBox是一个软件系统,可以用来创建和执行虚拟机。但是集装箱比虚拟机“轻”——一个虚拟机包括一组虚拟硬件、操作系统,用来执行用户程序;而集装箱里没有虚拟的硬件,也没有操作系统,它用主机(host)的硬件和操作系统来执行程序。 那么在集装箱里跑程序和直接在主机上跑有什么区别呢?一个区别是,集装箱有一套网络端口空间(port space)。一个集装箱里的进程可以各自开端口,也可以连接对方的端口进行通信。但是这些端口是集装箱之外的进程看不到的。我们也可以让集装箱把某些内部端口号展示给外部,比如把集装箱内的端口5000映射到外部的8080。这样,当我们用主机上的程序(比如浏览器)访问本机(主机)的8080端口时,实际上访问的是集装箱里的5000端口。这项对外公开集装箱内部端口的技术,称为端口转发(port forwarding),和虚拟机的端口转发概念一样。另一个区别在于,集装箱里有虚拟的文件系统。这样我们可以把要执行的程序拷贝进集装箱。也可以把主机上的某些目录映射成集装箱虚拟文件系统的某些目录。 集装箱这个想法已经在深刻地改变传统分布式系统的开发、测试和部署的流程了。传统的做法是,开发者写一个Makefile(或者其他描述,比如CMakeList、POM等)来说明如何把源码编译成二进制文件。随后,开发人员会在开发机上配置并且执行二进制文件,来作测试。测试人员会在测试机群上配置和执行,来作验证。而运维人员会在数据中心里的预发布环境和产品环境上配置和执行,这就是部署。因为开发机、测试机群、和产品环境里机器的数量和质量都不同,所以配置往往很不同。加上每个新版本的软件系统,配置方式难免有所差异,所以经常造成意外错误。以至于绝大部分团队都选择趁夜深人静、用户不活跃的时候,上线新版本,苦不堪言。 而利用集装箱概念的开发流程里,开发者除了写Makefile,还要写一个Dockerfile,来描述如何把二进制文件安装进一个集装箱镜像(container image),并且做好配置。而一个镜像就像一台配置好的虚拟机,可以在机群上启动多个实例(instance),而每个实例通常称为一个集装箱(container)。在自测的时候,开发者在开发机上执行一个或者多个集装箱;在验证时,测试人员在测试机群上执行集装箱;在部署时,运维人员在产品环境执行集装箱。因为执行的都是同样地集装箱,所以不容易出错。 这种流程更合理的划分了开发者和其他角色的工作边界,也大大简化了测试和部署工作。 boot2docker 上节提到,Docker虚拟了网络地址空间和文件系统。实际上,它还虚拟了进程ID空间(pid space)等系统数据结构。这些功能是一个叫dockerd的daemon程序借助Linux内核中的control groups(又叫cgroups)功能实现的。 dockerd负责执行集装箱;就像VirtualBox负责执行虚拟机一样。而cgroup是Google的两个工程师Paul Menage和Rohit Seth贡献给Linux社区的。cgroups的使用始于2006年。但是从他们的工作记录看,主要工作持续到2008和2009年。据说,Google开发它就是为了方便在自己的机群上部署各种Internet应用和离线处理系统。具体一点儿的故事,请看这篇Information Week上的帖子。。 因为cgroups功能只有Linux内核有,所以Docker目前只能运行在Linux上。可是,现在很多开发者都在用Mac。为了能让这些开发者方便的测试自己创作的集装箱镜像,Docker的开发者写了boot2docker——利用VirtualBox虚拟一个Linux主机,并且在上面安装dockerd。而命令行控制程序docker执行在Mac主机上,被配置成和虚拟Linux主机上的dockerd协作。…

64位CentOS7中静态IP,DNS的配置

我是在虚拟机中安装的CentOS7,采用的是桥接模式。起初CentOS内的地址是动态获取的,想把它固定下来。 按照网上查到的资料,通过修改/etc/sysconfig/network-scripts/下的配置文件,重启后网络服务,暂时能把IP地址修改了,但是配置中的DNS始终没有生效,这样就无法访问外部网络(实际上也不是不能访问,只是不能通过域名访问,比如你要ping一个外部公网上的ip地址是通的,但你要访问一个网址需要域名解析就不行了) 还有的问题是,这个虚拟机重启后,发现修改的配置文件中的设置还是没有生效,还是需要重启网络服务,折腾好久,一直不明白为什么。后来终于知道,是因为NetManager在捣鬼。 下面是转载的:https://Linux.cn/article-3977-1.html,有较大的参考价值,前面的第一种方法我试过了,对我的机器不管用,重启后依然设置无效。第二种方法是可以的。 如果你想要为CentOS 7中的某个网络接口设置静态IP地址,有几种不同的方法,这取决于你是否想要使用网络管理器。 网络管理器(Network Manager)是一个动态网络的控制器与配置系统,它用于当网络设备可用时保持设备和连接开启并激活。默认情况下,CentOS/RHEL 7安装有网络管理器,并处于启用状态。 使用下面的命令来验证网络管理器服务的状态: $ systemctl status NetworkManager.service 运行以下命令来检查受网络管理器管理的网络接口: $ nmcli dev status 如果某个接口的nmcli的输出结果是“已连接”(如本例中的enp0s3),这就是说该接口受网络管理器管理。你可以轻易地为某个特定接口禁用网络管理器,以便你可以自己为它配置一个静态IP地址。 下面将介绍在CentOS 7上为网络接口配置静态IP地址的两种方式,在例子中我们将对名为enp0s3的网络接口进行配置。 不使用网络管理配置静态IP地址 进入/etc/sysconfig/network-scripts目录,找到该接口的配置文件(ifcfg-enp0s3)。如果没有,请创建一个。 打开配置文件并编辑以下变量: 在上图中,“NM_CONTROLLED=no”表示该接口将通过该配置文件进行设置,而不是通过网络管理器进行管理。“ONBOOT=yes”告诉我们,系统将在启动时开启该接口。 保存修改并使用以下命令来重启网络服务: # systemctl restart…

Linux有问必答:如何为CentOS 7配置静态IP地址

问题:在CentOS 7上,我想要将我其中一个网络接口从DHCP改为静态IP地址配置,如何才能永久为CentOS或RHEL 7上的网络接口分配静态IP地址? 如果你想要为CentOS 7中的某个网络接口设置静态IP地址,有几种不同的方法,这取决于你是否想要使用网络管理器。 网络管理器(Network Manager)是一个动态网络的控制器与配置系统,它用于当网络设备可用时保持设备和连接开启并激活。默认情况下,CentOS/RHEL 7安装有网络管理器,并处于启用状态。 使用下面的命令来验证网络管理器服务的状态: $ systemctl status NetworkManager.service 运行以下命令来检查受网络管理器管理的网络接口: $ nmcli dev status 如果某个接口的nmcli的输出结果是“已连接”(如本例中的enp0s3),这就是说该接口受网络管理器管理。你可以轻易地为某个特定接口禁用网络管理器,以便你可以自己为它配置一个静态IP地址。 下面将介绍在CentOS 7上为网络接口配置静态IP地址的两种方式,在例子中我们将对名为enp0s3的网络接口进行配置。 不使用网络管理配置静态IP地址 进入/etc/sysconfig/network-scripts目录,找到该接口的配置文件(ifcfg-enp0s3)。如果没有,请创建一个。 打开配置文件并编辑以下变量: 在上图中,“NM_CONTROLLED=no”表示该接口将通过该配置文件进行设置,而不是通过网络管理器进行管理。“ONBOOT=yes”告诉我们,系统将在启动时开启该接口。 保存修改并使用以下命令来重启网络服务: # systemctl restart network.service…