Kubernetes和Istio
随着微服务的理念不断深入人心，越来越多的公司、开发者尝试把以前的单体服务转向微服务架构，Container容器技术的出现，大大加速的这个过程，容器和微服务简直就是完美结合、天生一对。因为它有效的解决了N多服务快速交付和快速部署的问题。
但随着服务数量的越来越多，很多企业能够希望把相关的服务聚合在一起，进行高效的部署和管理，于是乎后面就出现了服务编排概念。在众多服务编排工具中，Kubernetes带着它在Google的沉淀以及先进的思想横空出世，一统容器编排领域，很多都人直接看傻了…。以至于后来有一批创业公司专门做Kuberntes管理的项目，甚至国内的佼佼者Rancher也更新了2.0版本，专注于Kubernetes的管理和上层服务。因为真的干不过啊，用大刘的话来说，这就是降维打击啊。
后来，再随着服务模块的细分，服务数量不断增加，服务运维势必会成为下一个要解决的问题，于是Istio出现了，带着Goole和IBM的大厂Buff，成为服务治理领域的一颗闪耀的新星，Itsio基于数据面和控制面的分离思想，允许对服务控制策略进行有效管理。
| 架构发展 | 解决的问题 |
|---|---|
| 微服务 | 解决服务高内聚、臃肿的问题 |
Container |
解决运行环境统一、交付、部署问题 |
Kubernetes |
解决服务之间有效“聚合”、部署问题 |
Istio |
解决服务上线面临的一系列治理问题 |
Kubernetes和Docker做私有云
2018年的时候，觉得利用Kuberntes思想加上Docker的原则，我觉得做私有云应该完全不是问题，乃至做公有云都可以，到今天已经证实了这个想法。
Kubernetes思想
- 不可变基础设施
利用Docker镜像的不可变性；如果容器出现异常，不再是像传统ssh上去调试，而是直接kill掉当前容器，重新启动！ - 基础设施即代码
管理基础设施就像管理代码一样，每个基础设施都是可描述的；比如Kubernetes中的node、service等概念。 - 可编程基础设施
面向Kubernetes编程，以API调用方式来管理Kubernetes中的资源。
Docker原则
Build once, Run anywhere
一次构建，任意运行All in one
一个container只运行一个应用- 以应用为中心
优雅的管理应用的生命周期 - 分层治理
从iaas-->paas-->saas，分层治理，各层之间通过接口互相调用，互不侵入
说玩这些，难道真的就是这么一帆风顺，毫无问题嘛？不，我认为在Kubernetes上还有一个问题需要解决——问题排查。
现在排查问题门槛会比较高，还没有做到简单、易用的地步！