前言

为什么要容器化？为什么要上编排系统？足够专业的话可以快速定位排查故障，有的可能是开发隔离运维隔离。但有的人手没有那么多的，给人感觉就是术语高大上，外面宣传ppt有排面。要是能做到包括具体操作人员隔离。那应该成本应该还挺高的。

简要感悟

docker用了几个命令build -run-  exec- tag -push ，带上参数后，命令很长

k8s用的开元源+其他人二开=自研web界面，一些界面设计东西考虑不够全面，还不适配各类型的服务类程序。看他们敲的后台命令。命令很长

简单总结这两个的命令要实现具体东西又臭又长。

docker

隔离性。对于没有那么多操作系统机器以及不容项目库版本不同。可以环境不一样的开发编译。 

对于linuxC旧项目要容器化的挑战:持续运行的服务端linuxC程序，我们虚机开发讲究程序后台启动，而容器却用前台启动。我们的程序在高IO的情况下，对于日志,我们讲究分类存储文件，但是容器化却有标准输出的倾向。我们程序在多模块协同时，讲究主要模块和次要模块分离，且效率更高因此采用共享内存，而容器化推崇单进程单容器。

在docker的默认的设置下，docker的程序容器不采用和采用-v日志映射到虚机磁盘，发现docker下单程序多线程运行效果差，导致大量close-wait的现象或者程序容器无法在正常启动。这两个现象非容器化程序在云虚机暂无发现。

 

k8s

编排系统，所谓的扩缩容，所谓的容灾，网络隔离设置相关，讲究服务发现。

旧项目融入编排系统的挑战:若是原先直接IP交互，那么服务发现要使用DNS的转变，既然要用服务发现了，那么客户端如何知道这个约定好的服务域名，人工设置？原来的程序配置文件多机部署设计细节不一样，那么单一镜像要满足多变的配置，如何和那些各式各样的自主研发适配。如果那种东西想要扩缩容，又如何让他们知道这个关键字是需要人工设置的不同配置，如何让他们知道这些网络策略要一份拷贝？并求同存异？如果程序迭代开发遇到大的配置文件变更，那么这些配置文件如何受控回滚比对？

以前就挺好奇，这扩缩容怎么就那么好说呢？我们linuxC开发需要设定上限值。不管是文件描述符还是tcp缓冲区亦或是队列，凡为资源皆有界。

我用过wireshark进行解析，这个开源程序应当属于没有界限的一种，即程序没有设置界限，基本malloc，但是会跑到系统界限。由于工作需求，我进行了一次cap文件自己生成。由于生成是数据长度设置异常，一格式数据有问题的cap文件用wireshark打开。然后电脑内存飙升了。只能重启电脑。这就是无限制的后果。

我一直认为所谓的扩缩容需要有界限。一味的忽视临界点而讲卖点。软件开发设计中会造成设计不兼容。

有了解到现在开发很多讲百度的雪花算法，可以了解到这个里面也会设计主机台数。那么这个就是有界，设置了那么扩缩容就不是任意的。而是区间内可以根据需求增减。但是这个雪花算法有个id而且字节长度很大。我们许多旧项目还受限于id没有这个雪花算法的id的大，如果说新项目用新技术。但是有的业务并不是互联网的单个公司内部自定义。有的需要交互，兼容性是一大挑战，如同拆迁。业务存在钉子户，你愿意重构，别人不愿意重构。你用5G，别人2G就是不动摇。

开发的程序都会有存在bug的可能。那linuxC程序出现core。这些自主研发的编排系统是否自动采集相关信息文件？

编排系统多集群发生全面积的网络故障呢？先恢复编排系统，再恢复业务？