从2014年docker提出集装箱模式的打包机制之后，服务的部署方式发生了天翻地覆的变化，国内外的云厂商陆续发布了云原生相关架构和白皮书、定制各自上云标准；并介绍自己的真实业务场景及最佳实践，介绍自己通过Kubernetes节省了45%的物理资源、人力成本等等量化指标。云原生这一术语逐渐步入大家的视野；无论开发、测试、运维等等岗位，你要是说你没有用过docker、Kubernetes、Prometheus等最基本的云原生基础设施，你就out了。
一线大公司搞了，中小型公司（日活跃不足500的那种）不也得跟跟风，搞云原生（以Kubernetes为主线）这套基础设施出发点很多，但总结起来大概两种，一种就是技术领导喜欢尝鲜，试试新技术，成功了都跟着受益，失败了也算收获了经验教训（反正也是是花公司的钱办事）；还有一种偏管理型的领导，想想未来几年公司的业务要增长不知道多少倍，顶不住了怎么办，说白了就是为将来做打算（真的有必要吗？不是有大把的云厂商在守株待兔么，有钱了还非得自己搞？万一技术人员没有这方面热情怎么办？）。
这两种情况从本质上来说并没有绝对的对错，但要规划好做到那种程度，我知道一中型传统软件公司，10几个人，搞了将近一年多云原生技术，最后没办法，重新开始使用docker-swarm，其实用过Kubernetes都应该清楚原因是什么。
刚开始的大家学习云原生相关技术一般都是从docker开始，docker并不是什么黑科技，它正是利用了cgroup namespace配合linux文件系统打成镜像，运行起来变成一个容器。说到容器总想再多说几句废话，很早之前CNCF大使张磊在普及容器知识时就说，容器其实就是一种特殊的进程而已，所以要想管理多进程就要使用Kubernetes的Pod，其实我猜测他说这句话的含义并不是单纯的说容器就是进程，你docker exec进入容器内部ps看下，肯定不止一个进程（ps自身就是一个进程）。
既然可以运行多个进程，这样问题就来了，有些对服务设计没追求的领导开始说了，docker容器启动速度快，用起来比虚拟机方便，所以你要把咱们所有的应用放在一个docker容器里面启动起来，然后方便持续集成持续部署。其实能做到吗？肯定可以啊，你搞个脚本放在前台启动，脚本里面启动你的服务不久Ok了。仔细想想，这跟直接写个脚本在linux上执行起来有啥区别？区别还是有的，docker可以把服务运行时依赖环境统一起来。所以有时感觉扯不清楚，但逻辑是有问题的，微服务不就是讲究的低耦合吗？啥都放在一起出问题了，谁的锅？
接着上面的问题，为啥张磊还要说容器就是一种普通的进程呢？其实他是站在虚拟机的角度教我们理解容器，容器仅仅只能管理一个进程，其它的都是野进程，无法被管理，所以你要借助Pod的多进程管理能力。
其实上述这些问题，说白了就是docker容器思路看起来还可以，保证了基础环境的一致性，但是线上环境不仅要保证一致，还要真枪实弹的部署和运维。这恰恰也是docker自身的问题，它不支持编排、调度、集群管理等功能，再加上自身没有这种大规模集群管理、调度、编排经验，所以后面注定干不过Kubernetes。
那就引入Kubernetes工业级编排平台，解决扩容和编排以及容器管理等问题；除了组件比较多之外，确实很强大，几乎我们能够想到的资源对象，Kubernetes都进行了高度抽象，无状态的Deployment、有状态的StatefulSet、Job等等。
没过太久，这服务到底运行是否正常，怎么监控啊？不用问，问就是Prometheus Grafana AlertManger啥都有了。你看Grafana黑色大屏简直是酷毙了，CPU、内存、硬盘、Pod运行状态都有了，一般人看见都喜欢。有技术追求的人会接着搞，我要把接口返回状态码给搞下来，这样我就能看到我们接口请求错误率了，如果你用最新的框架，比如Java生态的nacos、springcloud，很简单，已经有完全有开箱即用的方案。但现实和理想总是有差距，总会存在各种参差不齐的老项目，Prometheus说了，你只要给我暴露出来Http接口就行，我会定期拉数据指标（网络协议可是跨语言的） 这样你只能默默搞一套sdk集成到服务里面了（搞得好还行，搞不好，原来的服务都会有问题）。
因为之前的日志打印时文件输出，现在扩容之后，有可能一个服务的两个副本在一台机器上，这就导致日志文件输出会有冲突，有时排查问题，根本看不出问题所在，怎么办？问就是Loki、EFK，云原生有的就是解决方案。（话虽如此，看看方案和真正方案实施和推进是tmd的两回事）
不知不觉一年多过去了，领导问你搞得咋样了，你把领导说的一愣一愣的。领导直接反问，我怎么听很多程序员说，大家还得打镜像、还得写各种编排文件，大家根本不会用，现在上线和发布速度比以前更慢了。
领导一般只会关注结果及带来的价值，不会关注具体如何实现以及这个编排平台有多牛逼，平台本身是不值钱的，你看看安卓系统，没人愿意为它付费。
查了查发现，要想把Kubernentes真正在整个用起来，必须有自己的一套CI/CD发布流程，这个流程可以使用Gitlab或者Jenkins等工具完成。目前公司还没有搭建这样一套流程，如果搭建可能需要招聘这方面经验的人员。wtf，到底是我征服了Kuberetes?还是Kubernetes征服了我？加上这些人的工资到底是增加了成本还是降低了成本？如果编排平台本身出问题了如何升级？很多大厂用着为啥没问题？难道他们可以自己修理Kubernetes编排平台？
不禁产生了深深的怀疑，原来造了一个航空母舰，用来旅游观光了
啰啰嗦嗦说了一大堆，并没有劝退的意思，云原生是一个很广泛且一直在变化的概念，它是一套技术、也是一套方法论。使用过程中一定要有自己的目标和边界。还是那句话，如果公司有这种文化（领导支持、技术人员有热情）和场景（上百个Pod，如果你就个位数的服务，还是省省吧，云原生相关的组件都比你的服务多），即使你没有贴近云原生，也已经成功了一半。
推荐
容器中的网络延迟相较于宿主机到底高多少？
Service Mesh与Istio简述
