云计算传统分类
云本身本身是为了适应一种计算抽象的一类的需求
最早期的云基本上就是iass层，所谓iass层就是用来管理基础架构层，提供一个一个的操作系统，业务只需要部署在这一个一个的操作系统上面就行了，当然这些是虚拟机了。这会带来什么问题呢？应用是面向操作系统的，本身隔离着非常非常多的东西的，比如一个高可用应用如何部署到不同节点上面去呢？这些都得应用层面上去关心，如果只给我操作系统，那么每家公司都要去解决相应的问题。
后面就逐渐的中间层面是不是可以抽象化，将操作系统的管理，中间件的管理，运行时的管理，我帮你将整个平台搭建起来，上面只需要跑你的应用就行了。这就是pass就是在iass之上做改进。
在后面就是能不能以软件为中心，以应用为中心，提供一个软件，然后你只需要使用这个软件就好了，这就是sass，提供一些软件供你直接使用。
Kubernetes生态系统
kubernetes打破了iass sass pass，边界就没有那么清晰了，因为Kubernetes基于这些标准的api，来描述所有的代管对象，这些对象向下探就是基础架构，向上探就是应用抽象。
它是通过统一的api将所有层面的对象统一纳管起来，之所以说模糊，是因为它向下是iass，可以将整个iass接入进来，它中间就有强大的pass，有了pass之后有是面向应用的，所以它本身又可以提供sass服务。
Kubernetes设计理念
对于应用本身支持了有状态副本集和无状态副本集，用来确保应用的高可用。
k8s自身也是高可用的，平面组件在搭建的时候可以部署为高可用。
分层架构
kubernetes向下实现了几个接口抽象，一个叫cri runtime抽象，下面可以接入docker containerd，还可以接crio，向下更多的是说对plugin的支持，和灵活性的选择，使得kubernetes可以运行在不同的环境里面。
API设计原则
Kubernetes如何通过对象组合完成业务描述
通过一个deployment创建一次业务部署这样的对象，deployment control会去建replicaset，replicaset会去建pod，pod会被调度器产生绑定关系，这是业务部署描述的部分，还有涉及的对象就是业务要发布的时候，我要去定义一个service，service创建之后kube-proxy会为它配置各种负载均衡的配置以及dns会为它配置域名服务，要将服务发布出去我要去定义一个service对象，service又可以通过ingress一个流量入口来发布到整个集群数据面API网关里面。
所以通过各种对象的组合来完成整个业务部署的描述。
架构设计原则
这里再强调一下，只有api server能够访问etcd，其他服务只能通过apiserver来访问集群。
我们鼓励事件监听，而不是轮询，etcd和apiserver都能够支持事件通知，大家就不需要轮询的来查了，轮询的查就把etcd和apiserver拉死了，为什么需要监听，因为你需要保持长连接，所有对象的变更是很频繁的，这些对象的变更让etcd和apiserver主动的下发，而不是轮询的一遍一遍查。
引导（Bootstrapping）原则
能不能使用kubernetes管理kubernetes控制平面，这叫做self-hosting，通过kubernetes组件把kubernetes一些基础组件，也就是整个kubernetes拉起来，这也就是kubeadm方式去加载集群，它通过kubelet以静态pod的方式加载整个集群，这就是self-hosting。
能不能使用二进制的方式去搭建集群呢，可以，在你初期学kubernetes的时候应该去理解每个服务如何的配置，这是非常好的方式，但是在生产集群集群里面不建议这么做，既然kubernetes自身可以保证应用的高可用，那我们就可以使用kubernetes来管理kubernetes平面自身，kubernets on kubernets是一个非常好的方式。