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
上还有一个问题需要解决——问题排查。
现在排查问题门槛会比较高,还没有做到简单、易用的地步!