kubernetes的服务组件和概念

kubernete是架构图

image

核心组件的组成：

etcd保存了整个集群的状态；
apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；
kube-proxy:每一个节点也运行一个简单的网络代理和负载均衡

kubernetes的设计理念
熟悉和分析kubernetes的设计理念，可以让我们更深入的理解kubernetes。

API设计原则

kubernetes引入新的对象的时候，不然引入新对象的API，API对改对象的操作，掌握API就抓住了kubernetes的牛鼻子。k8s由API如下几个设计原则。

1.所以的API都是声明式的。相对于命令式操作更加可以重复操作和稳定。更容易让用户使用，可以隐藏细节，保留优化的可能性。而且API对象都是名次，表面用户的期望。
2.API对象是可以相互组合的。面向对象的设计原则，高内聚，低耦合，对业务相关的概念的合适的分解，提高分解出来对象的可重复性。
3.高层API一定是以业务出发设计。以k8s的业务出发，以调度管理容器的操作意图为基础设计。
4.低层API以被高层API控制需要设计。低层API是为高层API调用的，减少冗余，提高重用性的目的。
5.尽量不要简单的封装，不要在外部API无法显示的知道内部隐藏的机制。 比如PreSet和ReplicaSet本来就是不同的Pod集合，那么就用不听的API来定义他们。
6.API操作的赋值度和对象的数量成正比。从性能角度，不能因为操作对象的增加，而不能使用的地步，如果操作的对象是N,那么操作的复杂度不能大于N.
7.API对象状态，不能依赖网络状态，因为分布式环境的网络状态是集群不稳定的，而API的状态是不能依赖网络的连接状态的。
8.尽量避免操作机制依赖全局状态。在分布式环境在得到统一的全局状态是非常困难的。

控制机制原则

1.控制逻辑应该只依赖当前状态。如果控制逻辑只依赖当前状态，那么就容易将一个当前暂时出错的系统误恢复到正常的状态。
2.假设如何错误的可能，并且做容错处理。分布式环境中局部出错或者临时出错是大概率事件，出错可能是物理设备，系统自身的错误，
3.尽量避免复杂的状态机，控制逻辑不要依赖无法监控的内部状态。
4.假设任务操作都有可能被任何对象拒绝，甚至被错误解析。
6.每个模块都可以出错后自动恢复。
7.每个模块都可以优雅的降级服务。

API对象

kubernetes的API对象必须包含如下属性

metadata:元数据 标识API对象的每个对象必须包含如下属性
namespace: 命名空间
name: 名字
uid: 
lables:匹配不同的对象 标签

spec:规范 
用户期望在kubernetes里的理想状态，比如replication controller在期望pod的副本是3个
status:状态
系统当前达到的状态

k8s中的配置都是通过spec的设置，通过相同的理想状态来改变系统。

Pod

最小的服务和应用的部署单位，可以有多个容器，共享文件系统和进程间通信，共同作用对外提供服务。

Replication Contriller (RC) 复制控制器

RC是k8s中保证pod高可用的API对象。通过监控运行中的Pod的对象来指定pod的副本数量。

Replica Set (RS) 副本集

RS是新一代的RC,可以匹配多类型的匹配模式