Feb 10, 2019 - latex summary

使用latex撰写elsevier论文,latex表格,插图以及调用的安装包

最近尝试用latex书写elsevier的论文,因为word的公式排版太难看了,但elsevier给出的latex模板十分简单,很多地方还需要自己去调整,对于latex的新手来说,还是有点吃力。自己先慢慢总结,然后将使用心得和技巧撰写在博客上。

推荐使用 www.overleaf.com 在线latex网站编辑,可以在上面找到elsevier的模板。

  1. 首先设置使用的模板

elsevier 给出了下列选项,选择其中之一。这些模板设置了页边距,是否分栏,默认的字体类型及大小。

\documentclass[preprint,review,12pt]{elsarticle} \documentclass[final,1p,times]{elsarticle} \documentclass[final,1p,times,twocolumn]{elsarticle} \documentclass[final,3p,times]{elsarticle} \documentclass[final,3p,times,twocolumn]{elsarticle} \documentclass[final,5p,times]{elsarticle} \documentclass[final,5p,times,twocolumn]{elsarticle}

投稿时我选择的是 \documentclass[final,1p,times]{elsarticle}

  1. 使用的安装包,导言区添加命令

根据需要,调用不同的安装包,我列出了以下安装包,并有中文注释。

\usepackage{graphicx}%插入图片

\usepackage{amssymb}%数学符号

\usepackage{amsthm}%数学定理

\usepackage{amsmath}%数学公式、矩阵、积分求和等

\usepackage{lineno}%显示行号

\usepackage{txfonts} %默认字体times new roman

\usepackage{enumitem}%项目编号

\usepackage{multirow} %多行合并

\usepackage{caption} %改变图表标题

\usepackage{txfonts} %默认字体times new roman

\usepackage{array} %\调用公式宏包的命令应放在调用定理宏包命令之前,也能控制表格

\usepackage{booktabs} %调整表格线与上下内容的间隔

\usepackage{longtable}%调用跨页表格

\usepackage{bm}%数学字体加粗

\usepackage{setspace} %调整一段文字的行间距

\usepackage{natbib} %参考文献管理包

导言区命令:

\biboptions{sort&compress}%参考文献可以压缩显示例如1-3

\allowdisplaybreaks[4] %允许公式跨页

\captionsetup[figure]{font=small,labelfont=bf,labelsep=period}%修改标题文字格式

\renewcommand{\figurename}{Fig.} %修改标题样式

\newcommand{\tabincell}[2]{\begin{tabular} {@{ }#1@{ }}#2\end{tabular}}

%让表格内容自动换行,但仍然需要用到换行\

  1. 表格与图片

表格有两种,一种是普通表格,另一种是长表格

代码:

\begin{table}[ht] \centering\small \begin{tabular}[b]{*{9}{p{0.8cm}<{\raggedright}}} \multicolumn{9}{l}{\small{\textbf{Table 4}}}
\multicolumn{9}{l}{\small{Solution of our algorithm without trade credit}}\\specialrule{0.05em}{3pt}{3pt} $X_{t}$ &9 &18 &0 &0 &0 &0 &0 &25\\specialrule{0.05em}{2pt}{2pt} $y_{t}$ &1 &1 &0 &0 &0 &0 &0 &1
$w_{t}$ &0 &0 &0 &0 &0 &20 &20 &0
$z_{t}$ &0 &0 &0 &0 &0 &0 &0 &0
$I_{t}$ &0 &9 &0 &9 &0 &0 &0 &0
$B_{t}$ &280 &153 &531 &531 &531 &531 &531 &1181
\specialrule{0.05em}{2pt}{0pt} \end{tabular} \end{table} \normalsize

显示效果如下:

长表格(可以跨页)

代码:

\small \begin{longtable}{m{2.8cm}m{2.8cm}m{5cm}} \multicolumn{3}{l}{\small{\textbf{Table 7}}}
\multicolumn{3}{l}{\small{Randomized generation scheme for the test problems}}\\specialrule{0.05em}{3pt}{3pt} Parameter &No. &Values\\specialrule{0.05em}{2pt}{2pt} $T$ &7 & 12,18,24,36,48,60,72
&&
\multirow{4}{\emph{pdf} of $d_{t}$} &\multirow{4}{4} &1. \emph{Exponential} with $\mu=150$
& &2. \emph{Normal} with $\mu=150$, $\sigma^{2}=2500$
& &3. \emph{Normal} with $\mu=150$, $\sigma^{2}=900$
& &4. \emph{Normal} with $\mu=150$, $\sigma^{2}=100$
&&
\multirow{3}{$c_{t}$ and $h_{t}$} &\multirow{3}{2} &1. Both constant: $c_{t}=13$ and $h_{t}=1$
& &2. $c_{t}$ seasonally varying in [12 13 11 10]
& &~~~~$h_{t}$ seasonally varying in [0.5 1 1.5 1]\ &&
\multirow{2}{$p_{t}$} &\multirow{2}{2} &1. Uniformly distributed in [15 25]\
& &2. Seasonally varying in [15 25 16 18]
&&
\multirow{3}{$B_{c}$} &\multirow{3}{3} &1. $B_{c}=s_{index}+c_{index}\max{d_{t}}$\
& &2. $B_{c}=s_{1}+c_{1}(d_{1}+d_{2})$
& &2. $B_{c}=s_{1}+c_{1}(d_{1}+d_{2}+d_{3})$
&&
\multirow{4}{$\beta$} &\multirow{4}{4} &1. $\beta=0.5$
& &2. $\beta=0.3$
& &3. $\beta=0.1$
& &4. $\beta=0$
&&\
$s_{t}$ &1 &Constant: $s_{t}=1000$
\specialrule{0.05em}{2pt}{0pt} \end{longtable}\label{tab7}

显示效果如下:

插入图片就没有表格那么复杂了,没有那么多需要修改的地方,直接改动模板对应文字:

\begin{figure}[ht] %插入图形时用latex编译[h]使图表不浮动 \centering\includegraphics[scale=1,trim=0 0 0 0]{1-1.eps} \caption{Sketch of the production arrangement} \end{figure}

显示效果:

  1. 参考文献

用latex的 natbib 包管理参考文献比较好,将用到的参考文献复制到 那个bib 文件里。

elsevier 自带的模板格式有时候不符合特定杂志要求,需要修改 那个 bst 文件,推荐一个博客:http://blog.csdn.net/tinkle181129/article/details/49822171,修改后替换原 bst文件就行。

Jan 20, 2019 - openstack vs kubernetes

referenceopenstack vs kubernetes

Kubernetes vs OpenStack

前言

最近2年相信大家都听过kubernetes这种新容器编排工具,越来越多的公司也去学习相关技术,并运用它去解决公司的问题,它在开源社区也是非常火,大小不断的k8smeeting以及容器相关的会议。这火爆程度和在2011年到2016年之间非常火的Openstack非常相似,不论是社区还是公司都是积极的去推动。笔者处在互联网之中,也接触学习过这两套系统,对他们相关技术也是非常的热爱,也在慢慢的根据不同应用场景在公司去推动相关业务转型,如相关服务的容器化技术转型等等,我就在这表达一下自己的一些看法与意见。加深理解大家对openstack 和kubernetes相关体系的理解与学习。

趋势

先简单说下目前的趋势,目前来看Openstack整个项目趋向于稳定,活跃程度相比之前有所下滑,从整个发版速度来看,由原来的半年一个release转为一年一个release, 团队的整个核心也将更多精力放在关于系统的可用性和稳定性优化,不过这并不是说他已经过时了,他是经过了上万台服务器的检验,是一个非常好的云操作系统,还是有拥有大量的用户和热爱者,如ebuy, 沃尔玛,京东,美团以及相关的私有云企业服务。

而kubernetes则是业界的新宠,可以用如日中天来形容,首先是Google自家对它的大力支持,包括前段时间Google Cloud捐赠给kubernetes社区800万美元的捐赠就能看出重视程度;其次是开源社区和各大公司对其的热爱程度,它在开源社区击败了docker官方推出的swarm容器编排工具和其他等类似编排工具,成为容器平台的编排标准,同时各个公有云也推出了基于kubernetes和自身IAAS服务结合的云容器引擎,例如AWS, Aurze,阿里云,腾讯云和网易云等等。所以说从目前来看,大家对kubernetes的偏爱会更多一些,特别是受开发者的热爱。

给笔者的感觉是Openstack是一个相对完善的云操作系统,很多公司可以很方便利用他进行自己公司的资源管理,资源分配,是一个已经长大30岁成熟的老大哥,而kubernetes是一个初出茅庐富有活力的新青年,特别是大家的热爱与追捧,看起来有点像Python和Golang的关系。

他们是什么

openstack https://www.openstack.org/

是一个云操作系统,通过数据中心可控制大型的计算、存储、网络等资源池。所有的管理通过前端界面管理员就可以完成,同样也可以通过web接口让最终用户部署资源。

简单理解: 可以把它类比公有云,它将各种基础资源虚拟化,并提供简化的方式去管理。偏向IAAS服务

kubenretes https://kubernetes.io/

是用于自动部署、扩展和管理容器化(containerized)应用程序的开源系统。

简单理解: 容器编排,管理多机的容器状态. 偏向PAAS服务

区别

**使用场景:

openstack

应用场景其实更偏向于是IAAS层,它有能力很好地对我们计算,存储,网络资源的管理,并且以标准服务的方式提供出来,例如在计算方向, 有nova,glance, cinder等相关服务,能很好的编排管理我们的物理机,虚拟机,甚至是容器。 网络方向,有Netruon这样的杀手级项目实现虚拟网络,能更好的管理我们的网络资源。存储的话,有自家的cinder, swift等等项目,还有更有很多其他的项目,像VPN, 负载均衡,数据库等等高级服务,提供我们可能需要的其他基础服务。从这些可以看出它能更好的做数据中心,它刚出来的时候,是想对标AWS,后来也对Vmware私有云造成了很大冲击。更重要的是它是开源的,像国内很多公司都是基用Openstack做内部的私有云,像传统企业移动,电信,互联网企业,美团和京东等等,公有云的话像Ucloud, 华为也用了很多Openstack的组件实现自身的需求。

Kubernetes

更像是一个云容器时代的一个杀手级应用,更偏向于PAAS,他的目的是高效的管理服务容器,是一个高效的容器编排引擎,它不仅实现了基本的容器调度,还实现了微服务调度框架,具体像集中的配置管理中心, ConfigMap, 服务发现与负载均衡 Service & Ingress, 服务调度编排, Controller, 服务动态缩,Heapster, Autoscaling, 容错和高可用, Health Check &resource isolation, Deployment。所以可以看出,kubernetes是一个能更好构建微服务的工具,在平台层解决了微服务的问题(其他Spring Cloud相关比较本文不与介绍),能快速的将公司的架构服务化。像我们公司内部就用它解决了很多问题,比如系统的弹性,服务化,提高资源利用等等。

**维护性

openstack : 难度相对高

有大量的组件依赖,包括依赖mysql, rabbitmq, apache, nova, nova-api, nova-conduction, nova-scheduler, cinder-api, cinder-scheduler, netruon等几十个项目,具体大家可以去官网看。其实也可以理解,目标是对标aws的项目肯定会不简单。

kubernetes : 简单

组件简单, kube-proxy, kubelet, kube-api, kube-shecduler, etcd, controller等10来个项目,所以可以看到它所依赖的组件不会太多,会更好维护。最关键的是kubernetes的很多项目都可以直接运行在容器中,这就意味着你可以不需要去管理你的系统,让系统自动的去解决问题,减少人工成本,这一点是非常非常赞的。

**系统架构

openstack : 各个项目设计简单,容易扩展和维护,存在较少的性能问题,不过所有项目整和起来会相对难运维。

openstack项目几乎都是基于服务化设计,项目都实现了REST http协议的api和暴露api,各个项目都是用的各自的数据库, 服务之间解耦用了消息队列,性能服务会用到内存数据库memcache, 这些设计在很大程度上提升整个系统的可用性和稳定行,你可以直接将应用分布式系统中的一些解决思路放在openstack项目中,像负载均衡,服务发现,熔断等等。不过所有项目加起来一起维护就会相对较复杂,需要做好系统架构,然后配合一套相对自动化的运维体系,最后还做好自身的监控告警等。

kubernetes: 各个项目设计简单,中心化设计相对较少,性能问题主要集中在etcd。

kubernetes自身的服务就比较简化, 服务之间设计主要通过grpc, http协议进行通信,也是进行服务化设计,会用到etcd去注册发现, 中心化服务相对好扩展。唯一相对严峻问题是大量主机(>5000)或大量Pods(>10万)级别下的etcd横向扩展的性能问题,当然单单从kubernetes的设计去考虑,也有其他的方式去解决问题,所以系统架构会比较精简。

**网络

openstack : 实现了基于软件的虚拟化SDN网络

openstack虚拟网络(Neturon)是它非常核心的一个模块,完全用软件的方式实现了网络控制器,利用linux birdge, openvswitch等技术实现网络隔离与网络虚拟化,同时有高度的自定义功能,可以有多种vlan, vxlan, gre协议去可配置的实现overlayer网络,让用户自定义的去操作虚拟路由器,交换机等等, 在架构上各个计算节点会有专门的服务云二层节点,也会有专门的网络节点做三层网络节点。

kubernetes : 利用开源组件实现overlay网络

kubernetes 利用开源组件实现了overlay, 网络不是它的专注核心,它重点关注的是服务编排与调度,这有很多开源的网络插件像flannel, calico, weave,router等等,每个组件都有自己的优势,有通过vxlan, 有直接是基于二层路由协议的, 应用场景和性能也会有所不同。相对来说kubernetes没有指定某种实现,而主要去实现一种网络接口,让各大厂商或云可以利用各自的优势去实现不同的overlayer,所以他也不会有专门的网络节点。

**存储

openstack : 提供对象存储,块存储

openstack 根据自己的需求实现了块存储和对象存储,自身的对象存储会用在像glance这样的镜像服务中,块存储会用在vm之间的共享和自定义挂载,它的存储都是独立的项目,独立的去解决各自的问题,而且从最开始的设计思路就像标准化的存储去实现,可扩展强,支持分布式,对接部署维护相对容易,也有很多公司会单独的使用其中的项目如新浪以前使用对象存储swift, 当然openstack也很灵活, 也能对接其他的存储,比如像ceph,glusterfs文件系统等。

kubernetes : 不实现存储, 而是实现存储驱动和接口。

kuberntes 只是一个使用者的角度, kuberntes不是去实现一种针对容器较好的存储,而是去实现一个接口,同时自身也会对接各个存储引擎。像比较主流的Nfs, Glusterfs, ceph, 以及像各个公有云的云存储组件,相信在以后社区会出现一些在容器方向特有的存储系统。

**资源隔离

openstack 隔离性相对较高

完善的多资源的多租户隔离,对vm是针对内核层面的隔离,网络方面是也有一些流量控制工具Linux Traffic Control进行隔离,网络环境用clan,vxlan,gre等进行三层隔离,存储有各自的配额管理,整体来说隔离程度相对教高,其实也是一种面对用户的服务拆分。

kubernetes 隔离性相对较低

隔离程度相对较低,不支持多租户,对资源池的管理基于resource, 和 namespace,隔离性相对较弱,对具体pods容器的管理基于cgroup,和namespace,不是基于内核层面。所有容器公用内核,隔离性相对较差。

看了这么多openstack与kubernetes的相关比较,看起来他们有很多不同,不管是从应用场景,还是系统架构都是不同的。不过他们并不是完全不相干的,他们也有很多共性,也有很多相互结合地方,他们都是为了更好的对资源进行管理。

结合

1 openstack 天生提供了多租户,这对于kubernetes来说是非常重要的,我们完全可以在openstack的环境中搭建Kubernetes服务,提供对多租户的服务支持,由openstack提供基础设施,包括基础服务vm, 负载均衡, 路由器,流量控制,租户管理等高级功能,由kubernetes实现容器编排。不过这种情况下,最好openstack 的网络模式用vlan隔离,否则相当于overlay上做overlay,网络性能会下降很多, 也可以让kubernetes网络模式走netruon,减少性能消耗。

2 openstack 服务用kubernets服务管理。 大家都知道openstack的服务默认是非容器化的,要运维好openstack就需要管理好他们的基础服务,包括mysql, mq, apache,网络组件等相关服务,这需要一套高效的自动化运维系统,而如果用kubernetes去管理opensetack基础服务,像mq, apache, 网络组件,那么运维就可以不去关心了,一切都交给kubernetes就好了。

展望

国内有公司像腾讯,网易都给客户提供私有云解决方案,目前来看有直接用openstack,也有直接用kubernetes,还有的是相互结合。同时也有公有云的容器引擎是用openstack + kubernetes 实现,像网易的蜂巢。所以说他们的关系是一个相互促进,相辅相成的,大家会越来越喜欢这两个项目,他们都在努力的为开源社区作贡献,都在各自的方向走向极致。

最后

感谢这两个项目,让我们学到超级多的架构知识,也感谢身处在的这个移动互联网时代,有这么棒的开源项目和开源社区。

Jan 15, 2019 - Kubernetes vs OpenStack

Kubernetes vs OpenStack

最近2年相信大家都听过kubernetes这种新容器编排工具,越来越多的公司也去学习相关技术,并运用它去解决公司的问题,它在开源社区也是非常火,大小不断的k8smeeting以及容器相关的会议。这火爆程度和在2011年到2016年之间非常火的Openstack非常相似,不论是社区还是公司都是积极的去推动。笔者处在互联网之中,也接触学习过这两套系统,对他们相关技术也是非常的热爱,也在慢慢的根据不同应用场景在公司去推动相关业务转型,如相关服务的容器化技术转型等等,我就在这表达一下自己的一些看法与意见。加深理解大家对openstack 和kubernetes相关体系的理解与学习。

先简单说下目前的趋势,目前来看Openstack整个项目趋向于稳定,活跃程度相比之前有所下滑,从整个发版速度来看,由原来的半年一个release转为一年一个release, 团队的整个核心也将更多精力放在关于系统的可用性和稳定性优化,不过这并不是说他已经过时了,他是经过了上万台服务器的检验,是一个非常好的云操作系统,还是有拥有大量的用户和热爱者,如ebuy, 沃尔玛,京东,美团以及相关的私有云企业服务。

而kubernetes则是业界的新宠,可以用如日中天来形容,首先是Google自家对它的大力支持,包括前段时间Google Cloud捐赠给kubernetes社区800万美元的捐赠就能看出重视程度;其次是开源社区和各大公司对其的热爱程度,它在开源社区击败了docker官方推出的swarm容器编排工具和其他等类似编排工具,成为容器平台的编排标准,同时各个公有云也推出了基于kubernetes和自身IAAS服务结合的云容器引擎,例如AWS, Aurze,阿里云,腾讯云和网易云等等。所以说从目前来看,大家对kubernetes的偏爱会更多一些,特别是受开发者的热爱。

给笔者的感觉是Openstack是一个相对完善的云操作系统,很多公司可以很方便利用他进行自己公司的资源管理,资源分配,是一个已经长大30岁成熟的老大哥,而kubernetes是一个初出茅庐富有活力的新青年,特别是大家的热爱与追捧,看起来有点像Python和Golang的关系。

他们是什么

是一个云操作系统,通过数据中心可控制大型的计算、存储、网络等资源池。所有的管理通过前端界面管理员就可以完成,同样也可以通过web接口让最终用户部署资源。

简单理解: 可以把它类比公有云,它将各种基础资源虚拟化,并提供简化的方式去管理。偏向IAAS服务

是用于自动部署、扩展和管理容器化(containerized)应用程序的开源系统。

简单理解: 容器编排,管理多机的容器状态. 偏向PAAS服务

**使用场景:

openstack

应用场景其实更偏向于是IAAS层,它有能力很好地对我们计算,存储,网络资源的管理,并且以标准服务的方式提供出来,例如在计算方向, 有nova,glance, cinder等相关服务,能很好的编排管理我们的物理机,虚拟机,甚至是容器。 网络方向,有Netruon这样的杀手级项目实现虚拟网络,能更好的管理我们的网络资源。存储的话,有自家的cinder, swift等等项目,还有更有很多其他的项目,像VPN, 负载均衡,数据库等等高级服务,提供我们可能需要的其他基础服务。从这些可以看出它能更好的做数据中心,它刚出来的时候,是想对标AWS,后来也对Vmware私有云造成了很大冲击。更重要的是它是开源的,像国内很多公司都是基用Openstack做内部的私有云,像传统企业移动,电信,互联网企业,美团和京东等等,公有云的话像Ucloud, 华为也用了很多Openstack的组件实现自身的需求。

Kubernetes

更像是一个云容器时代的一个杀手级应用,更偏向于PAAS,他的目的是高效的管理服务容器,是一个高效的容器编排引擎,它不仅实现了基本的容器调度,还实现了微服务调度框架,具体像集中的配置管理中心, ConfigMap, 服务发现与负载均衡 Service & Ingress, 服务调度编排, Controller, 服务动态缩,Heapster, Autoscaling, 容错和高可用, Health Check &resource isolation, Deployment。所以可以看出,kubernetes是一个能更好构建微服务的工具,在平台层解决了微服务的问题(其他Spring Cloud相关比较本文不与介绍),能快速的将公司的架构服务化。像我们公司内部就用它解决了很多问题,比如系统的弹性,服务化,提高资源利用等等。

**维护性

openstack : 难度相对高

有大量的组件依赖,包括依赖mysql, rabbitmq, apache, nova, nova-api, nova-conduction, nova-scheduler, cinder-api, cinder-scheduler, netruon等几十个项目,具体大家可以去官网看。其实也可以理解,目标是对标aws的项目肯定会不简单。

kubernetes : 简单

组件简单, kube-proxy, kubelet, kube-api, kube-shecduler, etcd, controller等10来个项目,所以可以看到它所依赖的组件不会太多,会更好维护。最关键的是kubernetes的很多项目都可以直接运行在容器中,这就意味着你可以不需要去管理你的系统,让系统自动的去解决问题,减少人工成本,这一点是非常非常赞的。

**系统架构

openstack : 各个项目设计简单,容易扩展和维护,存在较少的性能问题,不过所有项目整和起来会相对难运维。

openstack项目几乎都是基于服务化设计,项目都实现了REST http协议的api和暴露api,各个项目都是用的各自的数据库, 服务之间解耦用了消息队列,性能服务会用到内存数据库memcache, 这些设计在很大程度上提升整个系统的可用性和稳定行,你可以直接将应用分布式系统中的一些解决思路放在openstack项目中,像负载均衡,服务发现,熔断等等。不过所有项目加起来一起维护就会相对较复杂,需要做好系统架构,然后配合一套相对自动化的运维体系,最后还做好自身的监控告警等。

kubernetes: 各个项目设计简单,中心化设计相对较少,性能问题主要集中在etcd。

kubernetes自身的服务就比较简化, 服务之间设计主要通过grpc, http协议进行通信,也是进行服务化设计,会用到etcd去注册发现, 中心化服务相对好扩展。唯一相对严峻问题是大量主机(>5000)或大量Pods(>10万)级别下的etcd横向扩展的性能问题,当然单单从kubernetes的设计去考虑,也有其他的方式去解决问题,所以系统架构会比较精简。

**网络

openstack : 实现了基于软件的虚拟化SDN网络

openstack虚拟网络(Neturon)是它非常核心的一个模块,完全用软件的方式实现了网络控制器,利用linux birdge, openvswitch等技术实现网络隔离与网络虚拟化,同时有高度的自定义功能,可以有多种vlan, vxlan, gre协议去可配置的实现overlayer网络,让用户自定义的去操作虚拟路由器,交换机等等, 在架构上各个计算节点会有专门的服务云二层节点,也会有专门的网络节点做三层网络节点。

kubernetes : 利用开源组件实现overlay网络

kubernetes 利用开源组件实现了overlay, 网络不是它的专注核心,它重点关注的是服务编排与调度,这有很多开源的网络插件像flannel, calico, weave,router等等,每个组件都有自己的优势,有通过vxlan, 有直接是基于二层路由协议的, 应用场景和性能也会有所不同。相对来说kubernetes没有指定某种实现,而主要去实现一种网络接口,让各大厂商或云可以利用各自的优势去实现不同的overlayer,所以他也不会有专门的网络节点。

**存储

openstack : 提供对象存储,块存储

openstack 根据自己的需求实现了块存储和对象存储,自身的对象存储会用在像glance这样的镜像服务中,块存储会用在vm之间的共享和自定义挂载,它的存储都是独立的项目,独立的去解决各自的问题,而且从最开始的设计思路就像标准化的存储去实现,可扩展强,支持分布式,对接部署维护相对容易,也有很多公司会单独的使用其中的项目如新浪以前使用对象存储swift, 当然openstack也很灵活, 也能对接其他的存储,比如像ceph,glusterfs文件系统等。

kubernetes : 不实现存储, 而是实现存储驱动和接口。

kuberntes 只是一个使用者的角度, kuberntes不是去实现一种针对容器较好的存储,而是去实现一个接口,同时自身也会对接各个存储引擎。像比较主流的Nfs, Glusterfs, ceph, 以及像各个公有云的云存储组件,相信在以后社区会出现一些在容器方向特有的存储系统。

**资源隔离

openstack 隔离性相对较高

完善的多资源的多租户隔离,对vm是针对内核层面的隔离,网络方面是也有一些流量控制工具Linux Traffic Control进行隔离,网络环境用clan,vxlan,gre等进行三层隔离,存储有各自的配额管理,整体来说隔离程度相对教高,其实也是一种面对用户的服务拆分。

kubernetes 隔离性相对较低

隔离程度相对较低,不支持多租户,对资源池的管理基于resource, 和 namespace,隔离性相对较弱,对具体pods容器的管理基于cgroup,和namespace,不是基于内核层面。所有容器公用内核,隔离性相对较差。

看了这么多openstack与kubernetes的相关比较,看起来他们有很多不同,不管是从应用场景,还是系统架构都是不同的。不过他们并不是完全不相干的,他们也有很多共性,也有很多相互结合地方,他们都是为了更好的对资源进行管理。

1 openstack 天生提供了多租户,这对于kubernetes来说是非常重要的,我们完全可以在openstack的环境中搭建Kubernetes服务,提供对多租户的服务支持,由openstack提供基础设施,包括基础服务vm, 负载均衡, 路由器,流量控制,租户管理等高级功能,由kubernetes实现容器编排。不过这种情况下,最好openstack 的网络模式用vlan隔离,否则相当于overlay上做overlay,网络性能会下降很多, 也可以让kubernetes网络模式走netruon,减少性能消耗。

2 openstack 服务用kubernets 服务管理。 大家都知道openstack的服务默认是非容器化的,要运维好openstack就需要管理好他们的基础服务,包括mysql, mq, apache,网络组件等相关服务,这需要一套高效的自动化运维系统,而如果用kubernetes去管理opensetack基础服务,像mq, apache, 网络组件,那么运维就可以不去关心了,一切都交给kubernetes就好了。

国内有公司像腾讯,网易都给客户提供私有云解决方案,目前来看有直接用openstack,也有直接用kubernetes,还有的是相互结合。同时也有公有云的容器引擎是用openstack + kubernetes 实现,像网易的蜂巢。所以说他们的关系是一个相互促进,相辅相成的,大家会越来越喜欢这两个项目,他们都在努力的为开源社区作贡献,都在各自的方向走向极致。

感谢这两个项目,让我们学到超级多的架构知识,也感谢身处在的这个移动互联网时代,有这么棒的开源项目和开源社区。