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「in」の概念など、すべてのインフラストラクチャは説明的です。 - プログラマブルインフラストラクチャは
、Kubernetesプログラミングを指向し、APIコールモードでKubernetesリソースを管理します。
Docker原則として
Build once, Run anywhere
一度構築してどこでも実行All in onecontainer走行一つだけのアプリケーション- アプリケーション中心
のアプリケーションライフサイクルのエレガントな管理 - 階層ガバナンス
からiaas> -paas- >saas、階層的なガバナンスは、それぞれの層は、互いに侵入することなく、インターフェースを介してお互いを呼び出し
これらをプレイするといえば、本当にスムーズなセーリングですか？いいえ、Kubernetes上記のトラブルシューティングで解決すべき別の問題があると思います。
これで、トラブルシューティングのしきい値は比較的高くなり、まだ単純で使いやすいものではありません。