应用开发的先锋:容器和Kubernetes的故事

本文介绍了容器和Kubernetes的底层概念,以及它们如何给应用开发提供了新的模式。

容器就是新的进程

让我们从计算机开聊。 当计算机启动时,它会运行一个叫init的程序,然后init会启动其他所需的程序:服务器、终端、窗口管理器等。 Init能做几件有趣的事情, 例如让一个程序开机启动, 隔一段时间运行一个程序, 还有确保一个程序没有失败或者crash,如果有就重启它。 正在运行的程序可以看到这台机器上的所有东西: 其它在运行的程序,所有的文件,以及网络。

多个进程同时跑在一台计算机上。所有的进程可以自由的互相之间交互,或者与常规的资源交互。

通过将进程进行划分, 程序员可以有一个更加简单的模型来方便理解, 所以创建命名空间(namespace)的工具也被开发出来了。 程序或者进程只能看到运行在同一个命名空间下的其他进程。 如果它们寻找文件,那么只能看见硬盘上分配到这个命名空间的那一部分。 从安全的角度而言,一个命名空间里面的某个进程被黑掉了影响的仅仅也只是这个命名空间而已。

类似于Docker和Rkt这样的工具被开发出来以后使得我们能系统化地使用这些特性。 这些工具提供了打包的功能,将一个命名空间打包成一个容器,使得我们可以很方便的将它搬到另一台机器上运行,不出意外的它会跟之前完全一致的方式继续运行,因为它本身的隔离特性。 事实上,通常可以很容易的将容器想象为可以完全独立的运行的小计算机. 因为这些新的工具非常易用,它们渐渐成为一种流行的构建软件方式。

容器就是新的进程。

容器中的进程。 在这里,一个进程仅仅能够与所在同一个容器里面的其他进程和资源交互。

扩展: 一个好“难题”

一台计算机的资源是有限的,而且同时仅能处理有限的数据和运行有限的进程。 当面临增长的负载时(比如更多用户,更大的数据集)一个简单的应对方式是垂直扩展,也即是增加更多的处理能力和内存给到这台计算机,但是很快这个代价就会非常昂贵,而且本身扩展的空间也相当有限。 另一种方式就是通过增加更多的计算机来水平扩展。 这些计算机一起就组成了集群。

为了能跑在集群上,应用也需要以不同的方式架构。 例如,如果我们确认同一个程序的两份拷贝可以不需要访问对方的数据就能运行,那么我们就能放心的将它的多份拷贝放到不同的计算机上运行。

水平扩展:在这里集群里,三台计算机每台运行两个容器。 一共有两个app server的实例来处理大的负载。

虽然容器本身并没有给我们任何其他的工具来构建分布式应用,但是考虑一下这个级别上的抽象能让构建集群的应用方便一些。容器模型所鼓励的假设情形是:

可以有多份拷贝同时运行(架构要考虑并发性)。

容器可以在集群中的任意一台机器上动态启动和停止(最好是无状态或者临时的),而且

计算机或者进程可能会在任意的时间点失败或者不可用但是整个系统仍然保持工作(架构要考虑失败和恢复)。

由于在集群里面有这么多的计算机要管理,我们面临一些额外挑战:

首先,我们需要管理计算机上的资源,比如处理能力和存储。这意味着我们不得不有效地分发和调度进程到不同的计算机上去执行。

我们也需要“亲和性”和方法将相关的进程放在一起跑,以便高效利用共享存储;而同时“反亲和性”的要求又需要保证对同一个资源有竞争性的进程不能运行在同一台机器上。例如,如果我们想要将应用服务器的进程跑两份来服务两倍的请求,我们可能希望他们跑在集群里两台不同的服务器上。

当许多的进程跑在不同的地方时,我们需要一种方式让他们互相发现和沟通。我们只需要某个进程运行所在的机器ip就可以与这个进程通信。

在只有一台计算机的时候,只有一个ip地址就可以了。 在有多个计算机之后,我们需要维护一个进程到ip的映射,例如像etcd这样的分布式数据库。 当一个进程在一台机器上启动时,这个信息就被加入到数据库中。 如果进程挂掉或者机器宕机,也需要将这个条目从数据库中删除。

程序员对于开发跑在一台计算机上的应用很得心应手了。 理想状态下,我们想要的是有一个工具能将集群里面所有的计算机管理起来,而展现给程序员的就像一台“巨型”的计算机。

这个方向上的一个进展是CoreOS的Fleet项目,它的基本思想就是像一台计算机上的init进程那样延伸做整个集群的init。

Google 贡献的Kubernetes项目则让我们更加接近我们想要一台”巨型”计算机的模型。

Kubernetes:pod就是新的计算机

Kubernetes做的第一件事情就是拿走你的所有计算机,然后还回给你一个”巨型”计算机--一个Kubernetes的集群。

一个Kubernetes的pod指定一组需要运行Docker或者rkt容器。

之前我们描述的是一个集群里面不同计算机上跑着不同进程,现在我们看到的是Kubernetes集群里面的不同pod里跑着不同进程。

一个Kubernetes集群围绕着pod也就是容器组构建了一个模型. 这些pod基于资源和”亲和度”的约束被动态分配到底层节点上。

之前,我们考虑的是什么进程需要在一台机器上一起运行。 现在,我们考虑将哪些进程组构造成什么pod;pod已经成为一种优美的方式来对一个应用的一个功能单元构造模型。我们甚至可以直接使用社区构造的pod,直接将他们跑起来,例如日志和监控。

一个pod里面的所有进程跑在同一台机器上,这样解决了类似挂载磁盘这样的资源共享的问题。 背后是Kubernetes将pod分配到不同的计算节点也就是kubernetes node上,我们可以给pod或者node设置发生的条件例如资源约束、亲和性等。

计算机就是资源的集合:计算能力、内存、磁盘和网络接口。与之类似,一个pod可以从底层的资源池中分配一定量的资源. 它也会有自己的网卡和pod所在的虚拟网络的ip。

所以,pod就是新的计算机。

如果我们需要某个特定功能进行扩展,我们只需要在集群中多跑几个这个pod的拷贝。 当硬件不足,我们就往集群里面增加更多的计算和存储。 通过将资源与它所承载的功能解耦,调度器可以保证所有的可用资源会被尽可能高效利用。

Kubernetes复制控制器用来保证任意时间某个pod的一定数量的拷贝在运行。 就像一个分布式的init,如果一个pod挂了: 起因可能是里面的一个进程失败了,或者pod 的依赖挂了,或者它所在的节点down了; kubernetes会探测到并在另一个可用的节点上启动一个新的拷贝。

一个Kubernetes的service会跟踪集群里某种特定type的pod的所有实例。 例如,我们有一个ap server service,它会跟踪cluster里面所有的app server的pod。service是一个非常简便的抽象;我们的应用可以非常快的找到某种类型服务的所有功能单元然后将工作分发给他们。

 一个完整的Kubernetes集群图

Pod被动态分配到节点上。 每一种pod对应的服务都有服务发现和负载均衡,同时也描绘了pod和服务的虚拟网络。

Kubernetes既是一个在集群里面管理和调度进程的框架,也是一种构建应用的新的思维模型,基于的是pod里面的进程分组和service所提供的服务发现。

整个生态以及未来发展

管理一台计算机已经是一个难题了。 管理一大群互相通讯的机器更是复杂得多. 感谢发明了像Docker、Kubernetes这样非凡工具的好心人,我们现在有了容器这样的简单模型,也有工具将集群管理起来就像一台计算机。 构建可扩展的应用也从没像现在这样如此简单。

容器和集群管理软件业也影响了人们构建应用的方式。 他们创造了新的模式和抽象,很多的可能性仍在探索中, 例如, 使用容器来构建可重用的应用组件或者库可能也会很有意思。 在Hasura,我们正为数据库、搜索、用户管理、文件管理等等创建组件,构建应用就只需将它们快速组装起来。

总的来说,在追求创造更简模型的道路上我们已经前进了一大步。 当今的所有软件本质就是运行代码,执行功能。 从这个角度,我们做的所有的事情仅仅是管理这些功能:将它们分组,运行它们的多份拷贝,找到并与它们交互,然后处理失败的情况。 由此推出一个逻辑结论, 或许某一天我们会有这样一个系统,我们只需要描述我们需要的功能,余下的交给系统按照描述完成即可。 那确实是求之不得啊!

Akshaya Acharya

Akshaya领导着Hasuar的平台工程团队。 他曾经在Intellectual Ventures的一个咨询团队与敏捷开发团队一起工作过,也曾经作为Tech mentor在MEST、Ghana工作过。

本文转自d1net(转载)

时间: 2024-10-23 10:47:06

应用开发的先锋:容器和Kubernetes的故事的相关文章

区块链Hyperledger Fabric在阿里云容器服务Kubernetes中的进阶使用技巧(一)

我们在支持用户在阿里云容器服务Kubernetes集群中使用容器服务区块链Hyperledger Fabric配置部署解决方案.或者使用自建的基于Hyperledger Fabric的区块链方案的过程中,逐渐积累了一些相关的进阶使用经验.技巧和最佳实践,涵盖了系统设计.资源规划.服务使用.错误诊断.运营维护等方面,适用于区块链Hyperledger Fabric应用和方案的开发测试.以及生产部署等用途.这些内容将以系列文章的形式陆续发布并更新,同时欢迎有兴趣.有经验的朋友不吝指正. 利用区块链解

iOS开发入门:nib、xib与故事板的关系

nib.xib与故事板 如果大家使用过苹果的官方资料,一定会发现某些资料上会提到nib文件,那么nib与xib是怎样的一种关系呢? 最初只有nib文件,后来将其更名为xib,但大家一直沿袭nib这个叫法(即称xib文件为nib文件),所以目前为止,nib等同于xib.xib文件采用xml格式. 前文已提到故事板是用来替代xib的,那么两者除后缀名外,还存在哪些差异呢? 首先,在数量上,使用故事板技术时,一个工程只有一个故事板文件.当使用xib技术时,xib在数量上与视图控制器相对应,而一个工程可

容器和Kubernetes的应用与开发

容器就是新的进程 让我们从计算机开聊. 当计算机启动时,它会运行一个叫init的程序,然后init会启动其他所需的程序:服务器.终端.窗口管理器等. Init能做几件有趣的事情, 例如让一个程序开机启动, 隔一段时间运行一个程序, 还有确保一个程序没有失败或者crash,如果有就重启它. 正在运行的程序可以看到这台机器上的所有东西: 其它在运行的程序,所有的文件,以及网络. 多个进程同时跑在一台计算机上.所有的进程可以自由的互相之间交互,或者与常规的资源交互. 通过将进程进行划分, 程序员可以有

Java微服务开发指南 -- 使用Docker和Kubernetes构建可伸缩的微服务

使用Docker和Kubernetes构建可伸缩的微服务     从现在开始,我们将从更高的维度讨论微服务,涵盖了组织敏捷性.设计和依赖的思考.领域驱动设计以及Promise理论.当我们深入使用之前介绍的三个流行的微服务框架:Spring Boot.Dropwizard和WildFly Swarm,我们能够使用它们开箱即用的能力去构建一个暴露或者消费REST服务的应用,能够使用外部环境对应用进行配置,可以打包成一个可执行的jar,同时提供Metrics信息,但这些都是围绕着一个微服务实例.当我们

iOS开发那些事--nib、xib与故事板的关系

nib.xib与故事板 如果大家使用过苹果的官方资料,一定会发现某些资料上会提到nib文件,那么nib与xib是怎样的一种关系呢? 最初只有nib文件,后来将其更名为xib,但大家一直沿袭nib这个叫法(即称xib文件为nib文件),所以目前为止,nib等同于xib.xib文件采用xml格式. 前文已提到故事板是用来替代xib的,那么两者除后缀名外,还存在哪些差异呢? 首先,在数量上,使用故事板技术时,一个工程只有一个故事板文件.当使用xib技术时,xib在数量上与视图控制器相对应,而一个工程可

编排管理成容器云关键,Kubernetes和Swarm该选谁

  不论是公有云还是私有云环境,Docker 在新一代技术架构中的重要地位已经毋庸多言,甚至已经有企业在探索完全 Docker 化.在此背景下,如何选择容器技术栈就成为了企业实践的关键.回答这个问题,首先需要厘清技术体系更新的逻辑,再看可选技术是否符合需求.本文认为,容器的管理和编排将是容器云的关键,而 Kubernetes 是最为成熟的编排技术. 容器管理和编排将成云计算主战场 从云化的诱因说起.中国云计算实践八年多,市场认知逐渐提升,锐意创新企业对云的期待已经不是资源弹性.成本优势那么简单,

阿里云容器宣布开放支持Kubernetes托管服务

在刚刚结束的云栖大会上,阿里云宣布了飞天专有云敏捷版2.0,它带来了对Kubernetes框架的支持,10月31日,阿里云公共云容器服务宣布开放支持Kubernetes 1.8.1版本的托管服务,结合并发挥如云主机.负载均衡.分布式存储.异构计算等阿里云强大的IaaS能力,通过一键部署.控制台集成等,为用户提供了一个安全.稳定.易用的Kubernetes托管服务. 阿里云提供的Cloud Provider Controller实现了原生Kubernetes和阿里云能力的无缝整合,可以轻松使用阿里

容器编排初探:探索Docker swarm mode、Kubernetes和Mesosphere

本文讲的是容器编排初探:探索Docker swarm mode.Kubernetes和Mesosphere[编者的话]本文首先介绍了容器技术的基础知识,说明了容器技术的前景和市场份额.容器技术的重点之一是容器的管理编排.作者介绍了三种编排工具的共同特点和各自的特性.表明企业应该根据自身需求来选择使用那一款工具或者混合使用. [上海站|3天烧脑式微服务架构训练营]培训内容包括:DevOps.微服务.Spring Cloud.Eureka.Ribbon.Feign.Hystrix.Zuul.Spri

VMware、Pivotal和Google Cloud协力推出全新基于Kubernetes的容器服务——Pivotal Container Service(PKS)

本文讲的是VMware.Pivotal和Google Cloud协力推出全新基于Kubernetes的容器服务--Pivotal Container Service(PKS)[编者的话]定制化应用不再是难题--虚拟巨头协力Pivotal与谷歌,将自家产品线与Kubernetes容器编排系统进行全面对接. [烧脑式Kubernetes实战训练营]本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理.Kubernetes DNS与服务发现.基于Kubernetes和Jenkins的