来源：蜘蛛抓取(WebSpider)
时间：2018-02-20 21:23
标签：
情趣用品在哪里买
中国领先的IT技术网站
51CTO旗下网站
从此，Kubernetes变得简单易用
大数据公司百分点集体和云知声两家公司，在百度硅谷AI实验室资深科学家王益的协调下，两方合作，一起开发了开源的Kubernetes“发行版”Sextant――实现几乎零操作的全自动安装和部署Kubernetes集群。
作者：赵立京来源：51CTO| 18:27
Kubernetes，是Google开源的Docker容器集群管理系统，它构建在Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等一整套功能，本质上可看作是基于容器技术的mini-PaaS平台。目前，无论是公有云还是私有云，甚至混合云，Kubernetes将作为一个为任何应用、任何环境的容器管理框架无处不在。正因为如此，受到各大巨头及初创公司的青睐，如Microsoft、VMWare、Red
Hat等，纷纷加入Kubernetes的阵营。但是，像单机操作系统Linux一样，Kubernetes虽然开源了，安装和部署却相当复杂，需要专业知识和专业团队。
大数据公司百分点集体和云知声两家公司都在使用Kubernetes。在百度硅谷AI实验室资深科学家王益的协调下，两方合作，成倍地提升了集群利用率和团队工作效率，并且一起开发了开源的Kubernetes&发行版&Sextant&&实现几乎零操作的全自动安装和部署Kubernetes集群。目前有多家互联网同仁在准备使用和参与开发。
9月9日，分布式操作系统的&发行版&：Sextant正式发布。百度硅谷AI实验室资深科学家王益、百分点集团技术副总裁刘译Z、普惠金融CTO方亮、云知声联合创始人李霄寒，接受了51CTO记者的采访，对Docker和Kubernets的运维趋势进行了深入解读。
Kubernetes的优与劣
Kubernetes提升了团队工作效率。因为所有作业都由分布式操作系统来调度，工程师们也不需要登陆到服务器。这降低了安全隐患，不需要工程师先登陆&跳板机&再从跳板机登陆服务器，从而提升了工作效率。此外，Kubernetes改变了工程师们的日常工作流程&&通过要求开发团队交付Docker
image而不只是可执行文件，Kubernetes简化了集成测试，省去了发布、打包、部署、执行、监控、清理垃圾等运维工作。Kubernetes带来的另一类工作效率提升在于降低了并行计算框架(如MapReduce、Spark、Storm等)的开发难度和成本。开发者不必再套用几个成熟的开源框架来写自己的分布式程序，而是可以基于Kubernetes方便地开发自己的并行计算框架。值得注意的是，基于Kubernetes用Go语言开发的MapReduce框架，其代码行数是Hadoop
MapReduce的百分之一，这意味着bug概率的极大降低，和处理bug的工作时间的极大节省。
Kubernetes集群的安装需要大量繁琐的手工操作。因为Kubernetes和相关技术在高速演进，很多手工操作需要重复执行。此外，手工操作数十台甚至数百台服务器很容易出错。这是目前在技术研发工作中碰到的最大痛点。
为什么是Sextant
此次将Kubernetes的发行版命名为Sextant(航海用的六分仪)，是因其和Docker(集装箱)、Kubernetes(船舵)一样，都是和航海、船相关的物品。
说到Sextant的研发初衷，百分点技术副总裁刘译Z解释说，百分点在2015年底大约有1000多台机器，
CPU的平均利用率只有18%,Hadoop整个集群利用率将近100%，2016年的数据量至少会增长50%以上，考虑到成本，百分点团队希望能够通过技术的力量解决这个问题，而不是购买新机器。
在百度硅谷AI实验室资深科学家王益的建议下，决定从Kubernetes入手，希望把百分点Web以及大数据的应用在Kubernetes搭建起来。考虑到Kubernetes安装和部署的复杂性，急需一套快捷的自动化的部署工具，把Kubernetes整个集群构建起来。云知声的主要业务是人工智能，机器学习，在这方面可以和百分点互补，于是，在王益的协调下，百分点和云知声两家公司，本着研发出快速部署、安装Kubernetes工具的目标，合作组建了研发团队。
经过一个多月的努力，Sextant的第一个版本诞生了。为了方便重装系统，Sextant会在数据中心中的一台bootstrapper服务器上部署PXE
service，然后依次重启其他服务器。这些服务器启动的时候，BIOS/EFI从PXE
service引导CoreOS，并将CoreOS安装到本地磁盘，并配置Kubernetes，随后重启服务器，这台服务器便可自动成为Kubernetes集群的一员了。为了将这种变化限定于数据中心里的一部分服务器，Sextant可以利用VLAN等隔离措施。因为Kubernetes是以容器的形式运行的，而每当Kubernetes升级时，Sextant将升级版本的容器镜像放到bootstrapper服务器上，集群即可自动升级Kubernetes。每当CoreOS升级的时候，Sextant也将新版本放到bootstrapper服务器上，CoreOS会自动升级和重启，并且保证每次同时重启的机器数量是集群总数的一个极小的比例，不影响不中断Kubernetes调度的分布式作业。所有的升级和安装，都不依赖集群可以直接访问互联网，从而保证了安全性。
强强联合，开辟全新的合作图景
云知声联合创始人李霄寒介绍说，近年来，语音和视觉技术随深度学习的进一步发展，创造了IoT、AR和无人车等新兴领域。未来的互联网会和人们的生活契合得更紧密，收集更多更细致的数据，也需要更大规模人工智能技术的支持。而这些恰好是百分点和云知声的业务基础和技术长项。Kubernetes提供了一个合作的平台：Kubernetes可以同时调度离线和在线作业。尤其是Kubernetes的service和load
balancer的概念，使其可以调度在线服务、日志收集处理和存储、AI模型的训练等各类不同的作业。在有Kubernetes之前，公司之间的合作往往是松耦合的;而在Kubernetes平台上，开发团队可以同时运行百分点的EFK技术用于收集和管理数据，以及云知声的大规模AI系统从数据中提取知识和提升服务质量。
对金融界的意义
据普惠金融CTO方亮介绍，互联网金融的核心有两点：一是去中心化，二是风控。在互联网金融领域，需要不断寻找各种各样的数据，包括像百分点这样的第三方提供的数据，自己的爬虫数据，还有一些自由数据。如何把这些数据处理好，不管是传统基于统计的风控模型，还是基于最新的一些人工智能，深度学习这种新方式做模型，都需要很大的计算资源。如何组织好这些计算资源，让它们有弹性，可以扩展，能够为风控、为真正金融消费者服务，Kubernetes等容器技术给互联网金融带来了变革。
Sextant是一个早期开源项目，随着Kubernetes技术的演进，Sextant还需要长期维护开发。百分点和云知声的技术团队以充分开放的心态，愿意分享各自业务中Kubernetes技术的使用经验。也愿意帮助业界同仁使用Sextant简化Kubernetes部署。百分点和云知声都表示欢迎相关技术人员一起合作投入到Sextant的开发工作中，为提升团队工作效率和计算能力共同努力!【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
专题头条头条头条原创
24H热文一周话题本月最赞
讲师：1人学习过
讲师：9人学习过
讲师：4人学习过
精选博文论坛热帖下载排行
本书是关于Spring 2.0的权威教程，是Java/Java EE开发者必备的参考书。本书详尽系统地介绍了Java EE的基础知识、Spring 2.0的各种功能，以...
订阅51CTO邮刊您所在的位置： &
通过三个概念看 Kubernetes 的另一面
通过三个概念看 Kubernetes 的另一面
Kubernetes 在脱离传统 VM 的思路下，将容器技术真正作为用户转身云平台的利器，其完全脱离传统云对于控制层面的掌握，加强了数据层面的介入，并利用以应用为中心的镜像机制实现了更强的云平台基础设施能力。本文简单列出 Kubernetes 的概念，然后详述 Kubernetes 在现在云背景下的角色和能力。
之前对容器圈一直不太感冒，一直以传统 VM 的角度去思考容器的作用和使用，在最近的交流中发现还是有较大的误区。正好 Ceph 社区要在容器世界里占坑，作者就存储在容器世界里的作用和使用方式做了一番深入了解，认为容器的使用的确是一种新的的 IT 架构方式，不敢说是不是下一代，但是绝对是另一个颠覆。简单说它就是以应用为中心的生产模式，这里容器这个词的本身(LXC, Solaris Zone, FreeBSD Jail) 不是核心，核心是围绕 Image 产生的应用打包和部署方式。而 LXC 这类 Namespace 技术带来的高速、简洁并不是容器技术的杀手锏，实际上利用 kvm/xen 这类虚拟化技术经过一定优化仍然能达到较快的启动速度，比如 DVM。
在容器的生态圈里，Docker 的确是名副其实的始祖，贡献了 Docker Image 这套基础，而后面的 CoreOS，Redhat 的 Atomic 作为 Host OS 提供了较好的容器环境，最后 Kubernetes 和 Mesos 以及更多的集群管理添上了最后一环。如果是仅仅这样的体系可能感觉只是一套新的轮子罢了，通过对 Kubernetes 的设计理解结合本人对云的认识，感觉&容器&是一个非常好的云平台基石。本文就跳过对容器技术的基本介绍，简单列出 Kubernetes 的概念，然后详述 Kubernetes 在现在云背景下的角色和能力。
Kubernetes 基础
Kubernetes 是 Google 开源的容器集群管理平台，用于应用的部署、维护和扩展。Google 内部一直是容器技术的重度使用者，Kubernetes 是一套经过多年容器技术使用和管理而重新设计及实现的项目。因此，在其中我们可以得到非常多 Google 对于容器技术的理解和使用。首先 Kubernetes 定义了几个非常重要的概念:
Pod: 一组 Container 实例加上共享目录的组合。因为一个应用服务往往有多个进程组成，容器化往往要求细粒度，因此一个服务往往可能由多个容器组成，细粒度又造成服务内部的松耦合带来的不便，因此 Pod 为这类困难提出了解决方案，单个 Pod 内多类资源可见，这个约束条件使得一个 Pod 内所有容器只能存在通一个 Host 上。
复制控制器: 管理 Pod 的生命周期，确保足够的 Pod 存在于集群内来保证应用和高可用需求。
服务: 其实就是用来标识一组 Pod 的地址，换句话就是负载均衡，但实际上它额外引申出的能力才是 Kubernetes 的核心。
以上三个概念是 Kubernetes 的主要承载，下面我们看看 Kubernetes 有哪些在目前云时代的亮点。
Kubernetes 服务
我们知道在应用生产环境，在对外服务往往是需要地址的，而负载均衡实际上就承担了大部分的服务注册并分发作用。因此，Kubernetes 服务就是一个负载均衡，而实现是每一个 Node 上都有有一个 proxy 进程，通过对注册服务对象的检测，动态在 Node 上绑定新的 IP:Port 地址，完成对于一组 Pod 的连接，因为一组 Pod 实际上是有一个固定(User defined) 的 IP:Port，而 Proxy 会在 Node 上随机分配一个 IP:Port 然后与 Pod 的相关联。这样解决了应用间可能的地址冲突问题。第二方面也在这一层实现了负载均衡的逻辑 Policy。
这时，我们可以注意到 Kubernetes 作为一个管理框架将自己的服务嵌入到了数据流中，这是最大的差异。大部分管理框架往往将自己定位在控制器，的确能减少对于性能和复杂度的影响，但是大大减小了其活动空间，Kubernetes 实现的负载均衡可能不能在大规模平台中承受压力，实际上它不也是这么用的。
这时候我们需要引入另外一个背景，在目前的公有云、私有云和混合云的分类下，对于云基础设施之上的颠覆性变化实际上只能发生在私有云，一个厂商的公有云是无法改变用户的架构，更谈不上整个应用平台。那么 Google 在公有云追不上 AWS 的情况下推出了一个完全以社区方式运作开发的项目实际上是意味深远的(之前这样的项目就是 Andriod 和 Chromium)。Google 仍然希望能在用户端撬动变革来改变 VM 中心化这个现实，那么 GCE 作为这个变革的云端产物，自然能四两拨千斤的改变公有云的格局。
回到 Kubernetes 本身，传统 IAAS 以 VM 为核心作为一个物理服务器的兼容，在灵活的应用业务变迁上存在一定无力。如果在涉及到私有云和混合云甚至不同云平台之间的联合，方案会非常复杂，这也是其 VM 本质决定了。那么 Kubernetes 最重要的事情就是打通不同平台、集群和利旧。因此这里的服务就充当了本地应用平台的边缘，不管是将本地应用拓展到云端，还是云端业务利用传统负载均衡分发到本地，又或者是传统应用在保持不变的情况下与 Kubernetes 打通。这些方式都是以应用为中心的方案，而不是传统的 VM 的业务迁移。
另外，云平台的多集群设计实际上是以 vm 为中心的应用多集群很难在基础设施平台做到的，Kubernetes 这里的多集群仍然跟传统 VM 方式思路不同，不仅仅是控制层面的联合，也是业务应用层面的联合。在业务的多集群化上解决本地区域 Overflow 问题，实际上也是混合云最核心的问题。本地私有云在大部分情况下都只会存储核心甚至机密数据，跟远端云平台或者跟业务需要相比都有一定差距，另外多集群对于避免 vendor lockin 也有极大帮助，因此最重要的就是实现跨集群的调度策略、location affinity、服务发现和自动迁移问题。
Kubernetes 存储
目前 Kubernetes 以 Docker 作为计算运行后端的情况下，存储方案以只能基于 LXC 的实现，也就是共享目录的方式。但是 Kubernetes 比原生 Docker 已经迈进了一步，它在原有的 EmptyDir(默认的读写目录) 和 HostDir(readonly)情况下，增加了对 NFS、iSCSI、GlusterFS 的支持。另外 GCE 和块存储和 AWS 的 EBS 也在支持之列。实际上 Kubernetes 在具备集群 Host 管理上也用于更大的存储释放空间，比如 Docker 使用 NAT 方式方式 iSCSI Target 使得网络会成为瓶颈，而 Kubernetes 采用 Host 端挂载的方式。
图来自参考[6]
而 Ceph RBD 和 CephFS 后端目前也在 Review 过程中，相信较短时间内就可以被 Merge 到主线，而 CephFS 作为 Ceph 的 Posix 接口实际上被寄予了厚望，在容器方案中文件接口实际上比块接口更合适，在强调业务无缝迁移、整合、扩张的实现上，一个没有语意的块接口面临很大的局限性。因此，CephFS 纳入 Kubernetes 并成为继 OpenStack & RBD 之后的另一个强力组合也理所当然成为 Ceph 社区的目标。另一方面，容器的 LXC 技术在文件接口上的优势就在于在 Host 端完成了 Automount，而传统 VM 在 mount 自动化上有很大的难处。
在 Kubernetes 试图改变应用架构本身的努力上仍然有许多路要走，目前聚焦的是简单但常用的 Web server，缓存服务，应用服务等等，一些核心的数据库服务、大数据处理服务仍然需要一定时间去解决。
本文简单介绍了 Kubernetes 在脱离传统 VM 的思路下如何将容器技术真正作为用户转身云平台的利器，其完全脱离传统云对于控制层面的掌握，加强了数据层面的介入，并利用以应用为中心的镜像机制实现了更强的云平台基础设施能力。
如果本文对于容器或者 Kubernetes 的理解有误还请多多指正!
Kubernetes(/GoogleCloudPlatform/kubernetes)
Kubernetes Service(/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md)
Kubernetes Ceph RBD Driver(/GoogleCloudPlatform/kubernetes/pull/6578)
Kubernetes Storage(/GoogleCloudPlatform/kubernetes/issues/5129)
Kubernetes CephFS Driver(/GoogleCloudPlatform/kubernetes/pull/6649)
iSCSI as on-premise Persistent Storage for Kubernetes and Docker Container(//5/)
原文链接：
【编辑推荐】
【责任编辑： TEL：（010）】
关于&&&&的更多文章
本书介绍最新的VMware虚拟化与云计算软件VMware Workstation 9、
180天的Windows Server 2012试用版下载（标准版或数据中心版）
讲师： 789人学习过讲师： 4085人学习过讲师： 3451人学习过
OpenStack Kilo版本已经于日正式Release，
这几年来，云计算称得上是发展最迅猛的IT潮流之一。目
PaaS(Platform as a Service)是业界一个比较热门的话
本书分为4个部分共24章，以插件开发为中心，围绕插件开发主要介绍SWT/JFace的应用、插件扩展点的实现，以及GEF、EMF和RCP的相关
51CTO旗下网站你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
【编者的话】Rook存储集群，其实是在著名的分布式存储系统Ceph的一个封装，以Kubernetes Application的方式运行了监控。
在Kubernetes v0.3正式版中，Rook将原生态的云存储系统以Kubernetes Application方式与Kubernetes结合；块存储，对象存储以及分布式文件系统已经直接与Kuberenete Application进行了融合。
Rook存储完全自动化地管理着存储集群，这点与传统上的集群管理员的自动管理方式一样，区别在于：
传统意义上的集群管理员都必须掌握安装和监控系统。而Rook存储的运行是完全自动化的；Rook存储是以通过第三方资源以Kubernetes扩展的形式运行的。
首先，创建一个名为rook-operator.yaml的文件：
apiVersion:&extensions/v1beta1
kind:&Deployment
name:&rook-operator
replicas:&1
&&&&name:&rook-operator
&&containers:
&&-&name:&rook-operator
&&&&image:&quay.io/rook/rook-operator
&&&&-&name:&ROOK_OPERATOR_NAMESPACE
&&&&&&valueFrom:
&&&&&&&&fieldRef:
&&&&&&&&&&fieldPath:&metadata.namespace
启动Rook存储。
kubectl&create&-f&rook-operator.yaml
Rook存储运行起来之后，我们可以开始创建一个存储集群了，创建rook-cluster.yaml文件：
apiVersion:&rook.io/v1beta1
kind:&Cluster
name:&my-rook
namespace:&rook
version:&latest
useAllDevices:&false
开始创建集群。
kubectl&create&-f&rook-cluster.yaml
就这样，几分钟之后，我们就拥有用于Kubernetes Applications的存储集群了。
Rook存储的目标是确保我们用于正常运行的存储集群，首次运行时，必要的Kubernetes原语都会新建，然后，Rook存储集群将会持续监控所有的存储组件。
如何使用Rook存储集群呢？声明卷为了使用Rook块存储，我们Kubernetes Application首先需要创建基于Ceph RBD卷插件的存储类型：rook-storageclass.yaml
apiVersion:&storage.k8s.io/v1beta1
kind:&StorageClass
name:&rook-block
namespace:&rook
provisioner:&kubernetes.io/rbd
parameters:
monitors:&INSERT_HERE
adminId:&admin
adminSecretName:&rook-admin
adminSecretNamespace:&rook
pool:&rook
userId:&rook-rbd-user
userSecretName:&rook-rbd-user
你可能已经注意到我们需要在yaml文件中写入monitor节点信息，我们将在下个正式版中简化。Kubernetes的Rook卷插件，虽然这个过程很痛苦。但是现在，我们仍然需要运行以下命令来声明monitor节点信息：
export&MONS=$(kubectl&-n&rook&get&pod&mon0&mon1&mon2&-o&json|jq&&.items[].status.podIP&|tr&-d&&\&&|sed&-e&'s/$/:6790/'|paste&-s&-d,&-)
最后，我们可以替换yaml文件中的monitor节点信息，并且创建存储类型：
sed&'s#INSERT_HERE#'$MONS'#'&rook-storageclass.yaml&|&kubectl&create&-f&-
现在，我们在Kuberenetes Application中创建一个卷声明，例如：
apiVersion:&v1
kind:&PersistentVolumeClaim
name:&mysql-pv-claim
annotations:
volume.beta.kubernetes.io/storage-class:&rook-block
app:&mysql
accessModes:
-&ReadWriteOnce
resources:
&&storage:&20Gi
我们在容器指定部分使用卷声明：
&&containers:
&&-&image:&mysql:5.6
&&&&name:&mysql
&&&&volumeMounts:
&&&&-&name:&mysql-persistent-storage
&&&&&&mountPath:&/var/lib/mysql
&&volumes:
&&-&name:&mysql-persistent-storage
&&&&persistentVolumeClaim:
&&&&&&claimName:&mysql-pv-claim
这个例子中的yaml中可以从获得，以及可以从获取详细的介绍。
Rook存储集群客户端连接Rook存储集群的另一个办法是通过使用Rook 客户端容器，该容器提供了简单的直接测试块设备，对象存储以及文件系统的基础环境；然而这并非是说只能这样来运用Rook存储系统，它仅仅提供了用于更加了解Kububernetes卷插件原理的一个实验环境而已。
启动并进入以下pod，然后我们就有使用rook命令来管理存储集群的基础环境。
创建client Pod： rook-client.yaml
apiVersion:&v1
name:&rook-client
namespace:&rook
containers:
-&name:&rook-client
image:&quay.io/rook/rook-client:latest
imagePullPolicy:&IfNotPresent
command:&[&sleep&,&&36500d&]
securityContext:
&&privileged:&true
volumeMounts:
&&&&-&mountPath:&/dev
&&&&&&name:&dev
&&&&-&mountPath:&/sys
&&&&&&name:&sys
&&&&-&mountPath:&/lib/modules
&&&&&&name:&libmodules
&&-&name:&dev
&&&&hostPath:
&&&&&&path:&/dev
&&-&name:&sys
&&&&hostPath:
&&&&&&path:&/sys
&&-&name:&libmodules
&&&&hostPath:
&&&&&&path:&/lib/modules
运行client pod：
kubectl&create&-f&rook-client.yml
等到pod处于运行状态，然后进入pod：
kubectl&exec&-it&rook-client&bash&
该工具将自动载入管理API的配置以及管理Rook集群的配置；
查看集群中的节点信息：
rook&node&ls
查看集群状态：
rook&status
创建S3存储：
rook&object&create
查看所有的使用方法，可以查看
或者使用help：
rook&--help
Kubernetes资源规划该存储通过创建若干Kubernetes原生资源来自动完成集群初始化，然后监控资源以保证集群的健康状态。
密钥集群首次运行，cephx admin【这里为什么是ceph admin呢，因为rook cluster仅仅是ceph cluster的封装而已】和monitor密钥将自动生成并保存在Kubernetes密钥对中。
服务三个Ceph monitor运行以Pods形式集群中运行；这些Pods对保证存储集群的健康是至关重要的。
在集群中至少有三个节点，由于反亲和性在默认情况下是被指定的；所以故障域必须是跨节点的。
在Pods运行之后，集群将在通知Ceph osd之前等待Ceph monitor选举确定；集群将启用一个Go协程来监控monitor pods的健康状态。
服务集合在标明为存储节点的机器中一对damon set将为Ceph OSDs而运行；因为osd pod运行在各个机器上，存储配置将存储为空目录形式；
默认情况下，数据将存放在该目录下，在未来，我们将赋予存储集群管理员指定节点上使用设备或目录来进行存储的能力；
pod将监控本地OSD的运行状态；
第三方资源如果管理员需要更改集群的配置，Rook提供了TPR（third party resources ）的方式来指导该如何配置；集群将监控TPR（third party resources ）以及应用该修改在集群中，将来，TPR将拥有兼容s3/swift的ceph RGW，分布式文件系统（mds），管理Ceph用户（这些用户可以使用rbd卷）等等功能。
管理 APIRooK API Deployment用以提供RESTful形式的管理平台以及简化集群周边的管理任务，API则提供了查看集群健康状态以及更新集群配置的功能，最典型的API示例就是rook client tool。
可靠性假如Rook存储由于某些原因停止运行，存储集群依然会像预期那样继续运行，Ceph Mons、OSDs、MDS和RGW服务与Rook存储没有耦合，最基础的集群监控是通过Kubernetes自身来运行的，如果Rook存储再次运行，更加完善的健康检测系统将会恢复；并且维护第三方资源的健康状态。
周边Rook存储的目标是使用集群来完成自动存储，维持集群的可靠性，维护数据的安全性；Rook存储现阶段仍旧处于起步阶段；我们期待您的反馈以及为将来的版本做出贡献；查看更多文档以及简单yaml文件，查看。
原文链接：（翻译：程鹏）
要回复文章请先或部署微服务：Spring Cloud vs. Kubernetes - 博客频道 - CSDN.NET
好雨云帮 CSDN 博客
好雨云帮是一款基于容器技术的应用管理平台，社区版开发下载，免费使用！
分类：云帮
部署微服务：Spring Cloud vs. Kubernetes
Spring Cloud vs. Kubernetes，谁才是部署微服务的最佳拍档？
Spring Cloud和Kubernetes都声称自己是开发和运行微服务的最佳环境，但两者在特性上并不相同，解决的问题点也不一样。本文将探讨这两种平台对于微服务架构的交付有何作用、两者在哪些方面表现更好以及如何利用这两种平台在微服务架构的路上取得成功。
我最近拜读了 A.Lukyanchikov关于如何利用Spring Cloud和Docker搭建微服务的，推荐大家也看一看。
想要搭建一个可以十倍、百倍扩展服务的弹性伸缩微服务系统，需要借助具有宽泛构建时间和运行时能力的工具集进行集中的管理和治理。
Spring Cloud包括了各种功能性服务（如统计服务，帐户服务和通知服务）和支持基础设施服务（如日志分析，配置服务器，服务发现，授权服务）。
下图展示使用Spring Cloud的微服务架构：
（Spring Cloud微服务架构，by A. Lukyanchikov)
该图展示了运行时的方方面面，但没有包括打包、持续集成、伸缩、高可用和自我修复等在微服务架构中重要点。本文假设大多数JAVA开发者熟悉Spring Cloud，采用类比的形式，通过解决以上要点问题，带大家了解Kubernetes和Spring Cloud之间的关系。
微服务要点
我们在此不进行特性的逐个对比，而是从大面上看一看微服务的要点并聊一聊Spring Cloud和Kubernetes如何实现。
微服务架构的一大优势是易于理解的架构风格，可实现强大的模块边界，并且具有独立的部署和技术多样性，但需要付出的代价也是显而易见的——开发分布式系统的成本和运维开销。
而微服务架构能否成功实践，利用各种工具解决潜在问题是关键。把启动过程变得快速简单很重要，但通往生产环境的旅程是漫长的，你需要不断进步才能成功。
和Kubernetes。但这也意味着对于一个完整的端到端微服务体验，Spring Cloud必须补充一个像Kubernetes这样的应用程序平台。
Kubernetes
Kubernetes是一个用于自动化部署、扩展和管理容器化应用程序的开源系统。支持多种语言并且提供用于支持、运行、扩展和管理分布式系统的操作系统。
Kubernetes是多语言且语言不敏感的容器管理平台，能够运行云原生和传统的容器化应用程序。Kubernetes提供的服务（如配置管理、服务发现、负载均衡、测试指标收集和日志聚合）可供各种语言使用。这意味着一个平台可以被多个团队（包括使用Spring的Java开发人员）使用，并提供多种用途：应用程序开发、测试环境、构建环境（源码运行、构建服务、依赖仓库）等。
与Spring Cloud相比，Kubernetes解决了更广的微服务架构问题。除了提供运行时服务，Kubernetes也可以让你制定环境、设置资源限制、RBAC、管理应用程序生命周期、允许自动扩容和自我修复（几乎表现得像一个抗脆弱平台）。
Kubernetes技术基于Google十五年的研发和容器管理经验。此外，Kubernetes有近1000个贡献者，是Github上最活跃的开源社区之一。
Kubernetes是多语言的，因此它的服务是通用的，并不针对不同的平台（如Spring Cloud for JVM）进行优化。例如，配置会作为环境变量传递给应用程序或挂载的文件系统。它没有像Spring Cloud Config提供的配置更新功能。
Kubernetes不是一个以开发者为中心的平台，更偏向于DevOps的IT人员使用。因此，Java开发人员需要学习一些新的概念，需要学习解决问题的新方法。尽管通过MiniKuber开始一个Kubernetes开发实例很简单，但手动安装一个高可用的Kubernetes集群仍显得有些复杂。
Kubernetes是一个相对较新的平台（2岁），仍然在发展和成长，每个版本都添加了很多新功能，可能很难跟上。好消息是，这一点已经被考虑到了，Kubernetes的API将是可扩展和向后兼容的。
Spring Cloud和Kubernetes的最佳实践
如你所见，Spring Cloud和Kubernetes在核心领域都很强，并且正在其他领域努力改进。Spring Cloud可以快速使用，对开发者比较友好；而Kubernetes是DevOps的绝配，虽然学起来可能有点难，但是覆盖了更广泛的微服务技术要点。
Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点，而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点，而Kubernetes方法是试图让问题消失，为开发者在平台层解决。Spring Cloud在JVM中非常强大，Kubernetes管理那些JVM很强大。看起来各取所长，充分利用这两者的优势是自然而然的趋势了。
