京东从2016年底启动从OpenStack切换到Kubernetes的工作，截止目前(2017年2月）已迁移完成20%，预计Q2可以完成全部切换工作。Kubernetes方案与OpenStack方案相比，架构更为简洁。在这个过程中，有这些经验可供业界借鉴。

背景介绍

2016年底，京东新一代容器引擎平台JDOS2.0上线，京东从OpenStack切换到Kubernetes。到目前为止，JDOS2.0集群2w+Pod稳定运行，业务按IDC分布分批迁移到新平台，目前已迁移20%，计划Q2全部切换到Kubernetes上，业务研发人员逐渐适应从基于自动部署上线切换到以镜像为中心的上线方式。JDOS2.0统一提供京东业务，大数据实时离线，机器学习（GPU）计算集群。从OpenStack切换到Kubernetes，这中间又有哪些经验值得借鉴呢？

本文将为读者介绍京东商城研发基础平台部如何从0到JDOS1.0再到JDOS2.0的发展历程和经验总结，主要包括：

• 如何找准痛点作为基础平台系统业务切入点；

• 如何一边实践一边保持技术视野；

• 如何运维大规模容器平台；

• 如何把容器技术与软件定义数据中心结合。

集群建设历史

物理机时代（2004-2014）

在2014年之前，公司的应用直接部署在物理机上。在物理机时代，应用上线从申请资源到最终分配物理机时间平均为一周。应用混合部署在一起，没有隔离的应用混部难免互相影响。为减少负面影响，在混部的比例平均每台物理机低于9个不同应用的Tomcat实例，因此造成了物理机资源浪费严重，而且调度极不灵活。物理机失效导致的应用实例迁移时间以小时计，自动化的弹性伸缩也难于实现。为提升应用部署效率，公司开发了诸如编译打包、自动部署、日志收集、资源监控等多个配套工具系统。

容器化时代（2014-2016）

2014年第三季度，公司首席架构师刘海锋带领基础平台团队对于集群建设进行重新设计规划，Docker容器是主要的选型方案。当时Docker虽然已经逐渐兴起，但是功能略显单薄，而且缺乏生产环境，特别是大规模生产环境的实践。团队对于Docker进行了反复测试，特别是进行了大规模长时间的压力和稳定性测试。根据测试结果，对于Docker进行了定制开发，修复了Device Mapper导致crash、Linux内核等问题，并增加了外挂盘限速、容量管理、镜像构建层级合并等功能。

对于容器的集群管理，团队选择了OpenStack＋nova-docker的架构，用管理虚拟机的方式管理容器，并定义为京东第一代容器引擎平台JDOS1.0（JD DataCenter OS）。JDOS1.0的主要工作是实现了基础设施容器化，应用上线统一使用容器代替原来的物理机。

在应用的运维方面，兼用了之前的配套工具系统。研发上线申请计算资源由之前的一周缩短到分钟级，不管是1台容器还是1千台容器，在经过计算资源池化后可实现秒级供应。同时，应用容器之间的资源使用也得到了有效的隔离，平均部署应用密度提升3倍，物理机使用率提升3倍，带来极大的经济收益。

我们采用多IDC部署方式，使用统一的全局API开放对接到上线系统，支撑业务跨IDC部署。单个OpenStack集群最大是1万台物理计算节点，最小是4K台计算节点，第一代容器引擎平台成功地支撑了2015和2016年的618和双十一的促销活动。至2016年11月，已经有15W+的容器在稳定运行。

在完成的第一代容器引擎落地实践中，团队推动了业务从物理机上迁移到容器中来。在JDOS1.0中，我们使用的IaaS的方式，即使用管理虚拟机的方式来管理容器，因此应用的部署仍然严重依赖于物理机时代的编译打包、自动部署等工具系统。但是JDOS1.0的实践是非常有意义的，其意义在于完成了业务应用的容器化，将容器的网络、存储都逐渐磨合成熟，而这些都为我们后面基于1.0的经验，开发一个全新的应用容器引擎打下了坚实的基础。

新一代应用容器引擎（JDOS 2.0）

1.0的痛点

JDOS1.0解决了应用容器化的问题，但是依然存在很多不足。

首先是编译打包、自动部署等工具脱胎于物理机时代，与容器的开箱即用理念格格不入，容器启动之后仍然需要配套工具系统为其分发配置、部署应用等等，应用启动的速度受到了制约。

其次，线上线下环境仍然存在不一致的情况，应用运行的操作环境，依赖的软件栈在线下自测时仍然需要进行单独搭建。线上线下环境不一致也造成了一些线上问题难于在线下复现，更无法达到镜像的“一次构建，随处运行”的理想状态。

再次，容器的体量太重，应用需要依赖工具系统进行部署，导致业务的迁移仍然需要工具系统人工运维去实现，难以在通用的平台层实现灵活的扩容缩容与高可用。

另外，容器的调度方式较为单一，只能简单根据物理机剩余资源是否满足要求来进行筛选调度，在提升应用的性能和平台的使用率方面存在天花板，无法做更进一步提升。

平台架构

鉴于以上不足，在当JDOS1.0从一千、两千的容器规模，逐渐增长到六万、十万的规模时，我们就已经启动了新一代容器引擎平台(JDOS 2.0)研发。JDOS 2.0的目标不仅仅是一个基础设施的管理平台，更是一个直面应用的容器引擎。JDOS 2.0在原1.0的基础上，围绕Kubernetes，整合了JDOS 1.0的存储、网络，打通了从源码到镜像，再到上线部署的CI/CD全流程，提供从日志、监控、排障、终端、编排等一站式的功能。JDOS 2.0的平台架构如下图所示。

在JDOS 2.0中，我们定义了系统与应用两个级别。一个系统包含若干个应用，一个应用包含若干个提供相同服务的容器实例。一般来说，一个大的部门可以申请一个或者多个系统，系统级别直接对应于Kubernetes中的namespace，同一个系统下的所有容器实例会在同一个Kubernetes的namespace中。应用不仅仅提供了容器实例数量的管理，还包括版本管理、域名解析、负载均衡、配置文件等服务。

不仅仅是公司各个业务的应用，大部分的JDOS 2.0组件(Gitlab/Jenkins/Harbor/Logstash/Elastic Search/Prometheus)也实现了容器化，在Kubernetes平台上进行部署。

开发者一站式解决方案

JDOS 2.0实现了以镜像为核心的持续集成和持续部署。

1. 开发者提交代码到源码管理库

2. 触发Jenkins Master生成构建任务

3. Jenkins Master使用Kubernetes生成Jenkins Slave Pod

4. Jenkins Slave拉取源码进行编译打包

5. 将打包好的文件和Dockerfile发送到构建节点

6. 在构建节点中构建生成镜像

7. 将镜像推送到镜像中心Harbor

8. 根据需要在不同环境生产/更新应用容器

在JDOS 1.0，容器的镜像主要包含了操作系统和应用的运行时软件栈。APP的部署仍然依赖于以往运维的自动部署等工具。在2.0中，我们将应用的部署在镜像的构建过程中完成，镜像包含了APP在内的完整软件栈，真正实现了开箱即用。

网络与外部服务负载均衡

JDOS 2.0继承了JDOS 1.0的方案，采用OpenStack-Neutron的VLAN模式，该方案实现了容器之间的高效通信，非常适合公司内部的集群环境。每个Pod占用Neutron中的一个port，拥有独立的IP。基于CNI标准，我们开发了新的项目Cane，用于将Kubelet和Neutron集成起来。

同时，Cane负责Kubernetes中service中的LoadBalancer的创建。当有LoadBalancer类型的service创建/删除/修改时，Cane将对应的调用Neutron中创建/删除/修改LBaaS的服务接口，从而实现外部服务负载均衡的管理。另外，Cane项目中的Hades京东开源在GitHub上组件为容器提供了内部的DNS解析服务。

灵活调度

JDOS 2.0接入了包括大数据、Web应用、深度学习等多种类型的应用，并为每种应用根据类型采用了不同的资源限制方式，并打上了Kubernetes的不同标签。基于多样的标签，我们实现了更为多样和灵活的调度方式，并在部分IDC实验性地混合部署了在线任务和离线任务。相较于1.0，整体资源利用率提升了约30%。

推广与展望

有了1.0的大规模稳定运营作为基础，业务对于使用容器已经给予了相当的信任和支持，但是平台化的容器和基础设施化的容器对于应用的要求也不尽相同。比如，平台化的应用容器IP并不是固定的，因为当一个容器失效，平台会自动启动另一个容器来替代，新的容器IP可能与原IP不同。这就要求服务发现不能再以容器IP作为主要标识，而是需要采用域名，负载均衡或者服务自注册等方式。

因此，在JDOS2.0推广过程中，我们也推动了业务方主要关注应用服务，减少对单个容器等细节的操作，以此自研了全新智能域名解析服务和基于DPDK高性能负载均衡服务，与Kubernetes有效地配合支持。

近两年，随着大数据、人工智能等研发规模的扩大，消耗的计算资源也随之增大。因此，我们将大数据、深度学习等离线计算服务也迁移进入JDOS2.0。目前是主要采用单独划分区域的方式，各自的服务仍然使用相对独立的计算资源，但是已经纳入JDOS2.0平台进行统一管理，并通过机器学习方法，提升计算资源使用效率。

灵活的标签给予了集群调度无限的可能。未来我们将丰富调度算法，并配以节能的相关技术，提高集群整体的ROI，从而为打造一个低能耗、高性能的绿色数据中心打下基础。

回望与总结

Kubernetes方案与OpenStack方案相比，架构更为简洁。OpenStack整体运营成本较高，因为牵涉多个项目，每个项目各自有多个不同的组件，组件之间通过RPC（一般使用MQ）进行通讯。为提高可用性和性能，还需要考虑各个组件的扩展和备份等。这些都加剧了整体方案的复杂性，问题的排查和定位难度也相应提升，对于运维人员的要求也相应提高。

与之相比，Kubernetes的组件较少，功能清晰。其核心理念（对于资源和任务的理解）、灵活的设计（标签）和声明式的API是对Google多年来Borg系统的最好总结，而其提供的丰富的功能，使得我们可以投入更多精力在平台的整个生态上，比如网络性能的提升、容器的精准调度上，而不是平台本身。尤其是，副本控制的功能受到了业务线上应用运维工程师的追捧，应用的扩容缩容和高可用实现了秒级完成。JDOS 2.0目前已经接入了约20%的应用，部署有2个集群，目前日常运行的容器有20000个，仍在逐步推广中。

真诚感谢Kubernetes社区和相关开源项目的贡献者，目前京东已经加入CNCF组织，并在社区排名达到TOP30。

作者简介

鲍永成，京东基础平台部技术总监，带领基础平台部集群技术团队从2014年上线京东容器引擎平台JDOS1.0到现在的JDOS2.0，作为坚实的统一计算运行平台承载京东全部业务稳定运行。目前主要工作方向是JDOS2.0研发和京东第一代软件定义数据中心建设。

作为一名程序员，设计程序架构、优化算法已经是一件很头疼的事了，然而，还有更让人烦躁的，那就是环境配置，想必各位同学们都深有体会。每个人的电脑都不一样，不管是软件还是硬件，或者是要依赖的环境，因此同样的安装流程在别人那里是好使的，在你这就处处 bug，在电脑 A 上能顺利安装，在电脑 B 上就遇到问题了。于是有人就想出了一个办法，大家何不把自己配置好的环境打包成镜像呢?当需要配置同样的环境时，就把别人的镜像拿过来，进入镜像之后，就进入了别人搭建好的环境，而我们只需要提供硬件支持即可，而这个镜像就是 docker 容器。什么是镜像呢?简单来说，镜像就类似操作系统光盘介质，docker 容器相当于通过光盘安装后的系统。通过光盘(镜像)，我们能在不同机器上部署系统(容器)，系统内的操作只会保留限制在当前的系统(容器)中。需要了解的是，像 docker 这样的容器有很多种，而 docker 只是其中之一，但它是最受欢迎的，也因此占据了大半的市场份额。其他容器还有 CoreOS rkt、Mesos、lxc 等。

OpenStack 的诞生

我们都知道，全球云市场被三大巨头垄断，分别是亚马逊(Amazon)、微软(MicroSoft)和 阿里巴巴(Alibaba)，而亚马逊正是云计算的开山鼻祖。

早在 2003 年，Amazon 向客户推出了一项全新的业务——包括存储空间、计算能力等资源服务的 Web Service，这就是大名鼎鼎的 AWS(Amazon Web Service)。说白了，就是给大家提供了远程电脑，上面配置了各种满足你需求的服务，你可以远程使用它，这就是云计算最早的形式。到了 2006 年，亚马逊又推出了一种配置更简单、方便的弹性计算云(Elastic Compute Cloud)，又称 EC2 。而在同年的 8月9日，Google首席执行官埃里克·施密特在搜索引擎大会上首次提出“云计算”(Cloud Computing)的概念。从此，云计算进入了高速发展阶段。时间转到了 2010 年，一家名叫 Rackspace 的公司，同样在做云主机和云储存服务，和 Amazon PK 了多年，但是在竞争中一直处于下风。最终，他们把云服务代码给开源了。随后，NASA 也步后尘，开放了其在云领域多年的研究成果，并与 Rackspace 联手共同成立了一个开源项目。这个项目，就是 OpenStack，也是云计算发展的里程碑。

OpenStack 是什么

现在的云上资源(计算、存储、网络等)都是以集群的形式存在，这些集群里的物理机(Host)可以放在一个机房里，也可以分布式放在各个地方，而一个 host 上又可以虚拟出多个虚拟机(VM)。而 OpenStack 从一开始，就是为了云计算服务的，它就是一套软件，一套 IaaS 软件，用来管理集群里所有 Host(物理机)上的所有 VM(虚拟机)。什么是 IaaS?Infrastructure as a Service，基础设施即服务。这里的关键字是“基础设施”，也就是物理机。各大公司在 OpenStack 上进行了二次开发，形成了自己的 Iaas 软件，比如华为的 FusionSphere平台 和中兴的 TECS 平台。OpenStack 的安装部署非常快速，兼容性和适用性极强，而且便宜，一直很受市场欢迎。

Docker 的出现

按理说，Host 虚拟化出来了许多 VM，云上资源粒度划分已经很细了，也已经能做到资源的充分利用。然而，虚拟机的性能开销很严重。主要由于两点原因：一是虚拟层的引入;其二是因为 VM 的操作系统和 Host 的操作系统不一致，导致与操作系统有关的性能优化手段不能应用到所有的 VM 上。如果说虚拟机技术开启了云计算时代，那么 Docker 容器作为下一代虚拟化技术，将云计算推向了高潮。

• 虚拟机和 Docker 的区别

首先，你要明确一点：Docker 容器不是虚拟机，但你可以把它近似看成一种轻量级的虚拟机。

一个 VM 里可以创建多个 Docker 容器。

Docker 比虚拟机更节省内存，启动更快，数量级上”虚拟机需要数分钟启动，而 Docker 只需要50毫秒”，这是因为 Docker 是利用宿主(VM)的系统内核。

K8S - 为 Docker 而生

当只需要一个容器时，你可以手工部署，没有问题。然而在集群里要部署海量的 Docker，还要管理它们时，手工显然不现实了，于是 Kubernetes 这种更高维度的容器编排工具应运而生。Kubernetes 简称 K8S， 它抽象了所有物理机资源，将所有云主机抽象成一个资源池，而这个池子里装的就是一个个容器。容器就是孩子，而 K8S 就是这些孩子们的亲妈，为啥这么说呢?比如，应用程序发现 CPU 不够用时，K8S 就将其调度到另一台 CPU 足够用的机器上，内存不满足要求时，K8S就会帮忙寻找一台有足够内存的机器，并在上面创建对应的容器。更重要的是，一旦应用程序由于某些原因挂掉了， K8S 还会帮它自动迁移重启， 照顾得简直无微不至。而开发者只关心自己的代码，容灾备份、服务资源扩充则由 K8S 保证。

说到这里，你可能认为”K8S“的调度单位是一个容器(container)。事实上，K8S 调度的基本单位为 pod， 一个 pod 表示一个或多个容器。引用一本书里所说“之所以没有使用容器作为调度单位，是因为单一的容器没有构成服务的概念;例如 Web 应用做了前后端分离，需要一个 NodeJS 与 Tomcat 才能组成一个完整的服务，这样就需要部署两个容器来实现一个完整的服务，虽然也可以把他们都放到一个容器里，但这显然违反了一个容器即一个进程的核心思想 --《Service Mesh实战 - 用 istio软负载实现服务网格》”

背景：模拟用户真实场景，在windows 2012R2上部署MSSQL ，并用HammerDB跑压力

1.创建新的数据库

在windows开始菜单，打开SQL Server Management Studio，创建一个新的数据库--->用HammerDB跑压力

2.运行Hammer DB

3.使用HammerDB在windows下跑MSSQL

3.1双击SQL Server，选择MSSQL Server，点击ok

3.2选择“TPC-C”-->"Schema Build"-->"Options"

3.3双击“Options”，会弹出“Microsoft SQL Server TPC-C Build  Options”对话框

把“Number of warehouses”至少设置为800；“Virtual User to Build Schema”设置为3。点击ok，回到主窗口

3.4双击“Schema Build”下“Build”，开始构建schema。通常需要几个小时才能完成（具体时间长短因前面设置的warehouse、virtual users大小而异）。

schema构建完成后，“status”下扳手图标会变成绿色“√”。

3.5点击交通灯形状的按钮（从左到右第十个）

3.6点击展开“Driver Script”，双击options按钮--->弹出另一个窗口，点击“ok”回到主窗口，点击‘load’载入脚本

3.7在‘virtual user’下双击‘options’，其中‘virtual users’数量不应超过50，最好和server cpu核数相等；‘Iteration’为设置迭代次数（让压力跑多少次）

3.9 ‘creat’创建用户，‘run’开始进行压力测试

————————————————

版权声明：本文为CSDN博主「西域火龙油」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/u012439646/article/details/78348159

K网很多优秀的软件或源码都是通过Github分享的，但是国内Github访问的速度实在不敢恭维，今天偶然发现了这款插件，特意推荐给大家！

简介：国内Github下载很慢，用上了这个插件后，下载速度嗖嗖嗖的~！用途：能提高中国开发者访问GitHub的速度，提升克隆Git仓库的速度，提升下载release包的下载速度。用户为何安装：提高中国软件开发者的工作效率，使他们能跟专注的开发软件。

使用方法：
直接安装到chrome浏览器或chrome内核浏览器扩展程序中

访问github的页面时，访问缓慢或者直接无法打开时，就直接点击插件，再次点击GitHub加速即可加速访问Github页面。


本插件Github地址：https://github.com/fhefh2015/Fast-GitHub

蓝奏下载地址：https://xiaok.lanzoux.com/i5llThzttsd

加速Github访问下载的6种方案

1、GitHub 镜像访问

2、Github 加速下载

3、加速你的Github

4、谷歌浏览器Github加速插件（推荐）

5、通过Gitee中转fork仓库下载

6、通过修改HOSTS文件进行加速

1、GitHub 镜像访问

这里提供两个最常用的镜像地址：

https://github.com.cnpmjs.org

https://hub.fastgit.org

也就是说上面的镜像就是一个克隆版的Github，你可以访问上面的镜像网站，网站的内容跟Github是完整同步的镜像，然后在这个网站里面进行下载克隆等操作。

2、Github 加速下载

只需要复制当前 GitHub 地址粘贴到输入框中就可以代理加速下载！

地址：http://toolwa.com/github

3、加速你的Github

使用git clone，将原来的地址换成生成的加速地址。

4、谷歌浏览器Github加速插件（推荐）

谷歌浏览器Github加速插件.crx 下载

百度网盘:

链接：https://pan.baidu.com/s/15sS0nu3vLyKHtNrGbfftgA

提取码：be5z

插件安装参考链接

安装成功之后加速链接如下图：

5、通过Gitee中转fork仓库下载

1、访问gitee网站：https://gitee.com/ 并登录，在顶部选择“从GitHub/GitLab导入仓库” 如下：

2、在导入页面中粘贴你的Github仓库地址，点击导入即可：

3、等待导入操作完成，然后在导入的仓库中下载浏览对应的该GitHub仓库代码，你也可以点击仓库顶部的“刷新”按钮进行Github代码仓库的同步。

6、通过修改HOSTS文件进行加速

为什么github下载速度这么慢？

GitHub 我们都知道是世界上最大的开源及私有软件项目的托管平台，全世界每天有海量优秀的开源软件在这里产生，而 GitHub 在国内很多时候获取到的下载链接是亚马逊的服务器。

中国因为不可言说的原因，经常抽疯或龟速。想要加快 GitHub 下载速度就需要用到 GitHub 国内加速服务，对于有条件的可以使用代理加快访问速度，而没有条件的就可以用到网上热心人士维护的加速服务了。

如何提高github的下载速度？

手动把cdn和ip地址绑定。

第一步：获取github的global.ssl.fastly地址

访问：http://github.global.ssl.fastly.net.ipaddress.com/#ipinfo 获取cdn和ip域名：

得到：199.232.69.194 https://github.global.ssl.fastly.net

第二步：获取github.com地址

访问：https://github.com.ipaddress.com/#ipinfo 获取cdn和ip：

得到：140.82.112.4 http://github.com

第三步：修改host文件映射上面查找到的IP

windows系统：

1、修改C:\Windows\System32\drivers\etc\hosts文件的权限，指定可写入：

右击->hosts->属性->安全->编辑->点击Users->在Users的权限“写入”后面打勾。如下：

2、右击->hosts->打开方式->选定记事本（或者你喜欢的编辑器）->在末尾处添加以下内容：

199.232.69.194 github.global.ssl.fastly.net

140.82.112.4 github.com

————————————————

版权声明：本文为CSDN博主「Kunaly」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/qq_33406883/article/details/109284871