盘点人人都爱Kubernetes，难道Docker就不香

gy7231101

提起D，有很多人第一印象会认为它就是一个虚拟化容器，所以大家特别容易陷入到一种误区，就是觉得D只是在L操作系统之上又增加了一层，就跟OS上跑了一个VMW一样。D一定变得又慢又复杂。还不如原生安装的服务看起来舒服。一、开篇[url=http:///www.wangsu.com/]IPv6[/url]的相关资讯可以到我们网站了解一下，从专业角度出发为您解答相关问题，给您优质的服务！[align=center]

                               
登录/注册后可看大图

[/align]
提起D，有很多人第一印象会认为它就是一个虚拟化容器，所以大家特别容易陷入到一种误区，就是觉得D只是在L操作系统之上又增加了一层，就跟OS上跑了一个VMW一样。D一定变得又慢又复杂。还不如原生安装的服务看起来舒服。





际上这是误区，D管理的各种服务，都是操作系统原生的进程，并不是一个虚拟化产物，它的正确定义是应用容器引擎。


那怎么去理解这个应用容器引擎呢?就要说说D的核心原理了其中主要机制之一，通过L的机制现了资源隔离，这个资源隔离就包括了：



UTS，对主机和域的隔离
IPC，对信号量、消息队列和共享内存的隔离
PID，对进程编号的隔离
N，对络设备、络协议栈、络端口对隔离
M，对挂载点(文件系统)的隔离
U，对用户和用户组的隔离。

这些隔离机制都是L内核的机制现，也是D容器设计的精髓。


就好像原来是一个00平米的大房子，就住着一家人，卧室、厨房、卫生间这一家人独享。可是房子太大完全可以住个家庭，不仅能公摊一部分费用，还能为主家带来额外的收益。那么就要对这个大房子重新进行规划设计，满足个家庭的需要，制定一些生活制度，有些资源是可以共享的，但关键资源就必须隔离开，保护隐私嘛!其大家说到底还是在一个大房子内平等的生活。


用了这个比喻其就是告诉大家，你就把D理解为一个房子多个家庭的规划安排包租婆，D管理了很多的容器服务，容器服务就是在宿主机上跑着的，例如MSQL、N、微服务等等都是容器服务，大家都是在一个OS上平等的运行着，只不过进了自己房间，你对别人房间的情况就一所知了。那么这不仅保护了各个服务之间不会产生对资源争用，而且还能根据预先入户的协议，分配好CPU、内存、磁盘的容量。这样大家住在一起也是明明白白的，谁也不能沾了谁的便宜。当然了对外的络端口还是需要各家分配不同的。


有了这个本事，你就能在有限的云资源上跑很多服务啦!我自己做的跑在阿里云的ECSCOS7，就跑了个D容器：N、MSQL、W，我才给分配了512M内存，够抠门吧，但是运行地妥妥的，只是物理内存是在太小，有时候重启服务，OS报内存资源就不够了，必须把D也重启，清空一下内存就好了。


我给当时老东家的两个互联平台产品用了台ECS性能不错的服务器，4核，16G内存，足足跑了50多个微服务和其他基础服务，真的是把资源榨得是干干净净。关键还有服务日志隔离、环境变量隔离、全局配置隔离等待，好处在太多了。关键对我们产品在互联架构上的D提供了良好的基础支撑，我可以在一台虚拟机上跑两套微服务，一套生产、一套测试，测试好的微服务升级版本号，变成新的生产微服务，老的微服务进入过渡替换期。


二、问题集锦
1、D必须联吗?
连接互联不是必要的。可以内部搭建DR服务。我曾经就是在阿里云的多台机器的其中一台做了R服务，然后让其他机器通过内的5000端口访问就可以了，记得给每台服务器的D服务都配置一下都不走SSL。


我们也只有远程发布才让自己的开发客户端，访问N的HTTPSSL端口，反向代理到R仓库，那么就需要在服务端装一个D版的，因为公尽量走HTTPS。如下图所示：





关于内怎么装D的问题，你需要先找一个能上的机器，通过D做好你自己的D，最好会怎么做，这是个脚本技术，主要有一些本地化和参数优化需要再做一下D，然后D到内私有服务仓库就可以了，其他内机器只要D命令，就可以使用你制作的D了。


系统下开发，就下载安装的D使用和版本一样。


2、D里面的程序如何现热更新?
用D构建一个镜像，并生成了一个容器来运行程序，现在程序代码发生了变更，想要现热更新如何现呢?


一般D更新的方式，都是下来新的，然后重启容器，当然也有一些讨巧的办法，通过对D内的发布程序目录镜像到本地目录，那么每次只上传程序包，更新服务器本地目录之后再进行D重启，这种方式免去了D体量太大，上传慢的问题。


但是这些都需要重启容器，不算真正意义上的热更新，在线业务系统往往允许的抖动时长会很严苛，而且即便是D镜像在测试环境都已经测试的没有问题了，放到生产服务器上也不能没有经过验证就直接替换，若是系统，我建议用关+D-+多版本运行的方式来现热更新，而且这也会使得升级抖动的影响降到最低。如下图所示：T为测试，P为生产，1、2就是D-的多版本发布，通过API关重定向微服务新版本跳转，现最小升级抖动。





具体意思我简要说一下，就是让D-作为你的应用发布的整体，这样论是微服务也好，单体应用也好，就都统一作为一个单元部署管理了!


然后对需要更新的新版本程序，发布出新版本的D-，验证误后，再由关现动态切换，D热更新的大体思路就是这样。


、D挂载数据卷的时候映文件会出现不同步?
学习D的时候发现映会出现这种情况难道一定要先从容器中拷贝一份再运行吗?


D映配置文件的时候，一定是先要有这个文件，记住，而不是等其内部会创建这个文件，否则它只会创建出目录。


因此D映文件不存在就走映目录了。


所以第一种方式：是配置文件已经存在，也就是自己上传到服务器自定义配置目录，然后D直接映过去，这时候映文件或者映目录一个道理。


第二种方式：配置目录映到自定义目录，容器运行过程脚本自动化写入，那么配置目录的各项文件就需要在容器初始化过程中，由脚本对镜像内的打包配置文件完成写入。


其我做过一个R的优化过的生产级的D，走的是第一种方式，需要你自己上传一下配置，可以看看我的源代码仓库，仓库也就做了这一个面向R中文化、性能调参过的D以及配置文件。在中搜索读字节有个我写的不错的单机版RD文件，里面对性能做过优化，大家可以用来学习。


、结束语
总之在目前K如日中天的时代，我们有时候要冷静思考一下，到底我们有必要搞得那么复杂吗?难道D还不够用吗?如果配合上P这种在线免费的D管理工具，能让你的云上服务群管理的很好。


但是有一点是有门槛的，那就是玩D一定要不断历练自己的L能力，包括脚本编写能力，因为有些DI并不能按照你的际环境满足你的使用需求，需要自建D，我就在以前的工程中配合M编写了自己的D和S脚本，微服务从打包到发布，一气呵成，而且可以灵活去选择哪个微服务进行更新。这就真的需要深刻的去理解L了。


际上面对更复杂的K8，熟悉L这个问题一样是绕不过去的。因此还是关键的那一步，容器时代，用好容器引擎是从简单的D开始，并且在搞定程序之外历练自己的L功力，你的技术将提升得更!