谈谈Kubernetes

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上还有一个问题需要解决——问题排查。

现在排查问题门槛会比较高，还没有做到简单、易用的地步！