『高级篇』docker之了解kubernetes（31）

什么是k8s

• k8s

• k8s 集群的样子

1. 第一个pod有独立的IP地址，一个容器
2. 第二个pod有独立的Ip地址，一个容器，一个磁盘存储
3. 第三个pod有独立的Ip地址，两个容器，一个磁盘存储，这2个容器可以共享IP的，共享网络，共享磁盘的。
4. 第三个pod有独立的Ip地址，三个容器，2个的磁盘存储，这3个容器可以共享IP的，共享网络，共享磁盘的。

PS：通过上边的4个小图，可以明白同一个pod里面可以有任意多个容器和存储。

1. 中间是master节点
2. 其余的是node节点
3. 下面的这个node，里面运行了一个pod，pod的外边，有一层虚线，虚线标识service，pod的Ip（10.10.10.1），service（10.10.9.1），service和pod的Ip不同，pod是具体运行在一个node上的，如果pod或者node突然挂掉了，编排工具肯定在其他的node节点下重新起一个pod，这个pod肯定的ip也就变了。所以就需要一个serivce的概念，当pod出问题了，产生一个新的pod，新的pod就是一个新的ip，我们就可以通过service的方式找到pod。
4. serivce的Ip跟service的生命周期是一致的，如果service不被删除的话，IP一直不发生变化。
5. 上边这个2个node，三个pod，其实就是从一个实例变成了3个实例，进行了扩容，对外提供想通的服务，这时这个service，ip就有了另外2个作用，除了可以定位pod的地址，可以对pod地址进行负载均衡，进行轮询，

PS：（梳理概念）pod里面包括N个容器，service里面包括pod，Deployment可能包括service或者是pod。

1. Master里面发布了一个Deplyment，想给service 进行扩容
2. 其实内部是扩容的pod，service只是一个逻辑存在的东西
3. 把一组pod形成一个逻辑组就是service，扩容完成后，其他两个节点就有了pod实例。
4. service就开始对外的负载均衡endpoint找到对应的pod

k8s的整体架构

1. ControllerManager负责维护集群的状态，比如故障检测，扩缩容，滚动更新等等。
2. Scheduler负责资源的调度，按照预定的策略把pod调度到指定的node节点
3. ETCD 用做已执行存储，pod，service的集群等信息，k8s需要持久化的数据都存储在这个上边。
4. Kubelet负责维护当前节点上的容器的生命和volumes，网络。
5. 每个Node上可以运行一个kube-proxy，负责service 提供内部的服务发现和负载均衡，为service方法做个落地的功能。
6. kube-dns负责整个集群的dns服务，这个组件不是必须的，一般通过名字访问比较方便。
7. dashboard集群数据的GUI界面。

PS：全过程梳理

1. kubectl 发起一个请求，请求经过认证。
2. scheduler的策略和评分计算得到目标的node。
3. APIServer请求Node，通过kublet把这个Node运行pod起来。
4. APIServer把信息发送给ETCD保存起来。
5. pod运行起来之后，通过ControllerManager管理每个pod的状态，如果突然挂了，就想办法创建一个pod。给pod分个独立的ip地址，可以在整个集群内使用这个ip来访问它。但是pod的ip是易变的，异常重启和升级的时候，不可能关注某个pod的Ip的。
6. 下面虚线的部分表示的是一个service，service里面有3个pod，不在虚线里面的是单独存在的pod，并没有提供service的入口，完成service的具体工作的模块就是kube-proxy，在每个node上都有一个kube-proxy，然后给service分配一个ip，可以访问service里面的pod，所以kube-proxy对应的service都会有一个ip的指向，负载均衡的访问他们。
7. kube-proxy（service） 可以把端口和ip直接暴露在node上。外边的请求可以访问node上的ip就可以关联到这个service上了。
8. kube-dns 就是为了方便名字直接访问node节点。任何一个pod都可以通过名字来进行访问。

k8s的设计理念

• API设计原则

1. 所有的api都是声明式的（对于重复的操作是稳定的，所有的对象都是名词，不是动词，用户很容易的期望用户的样子，当前的系统是否满足需求，明确用户的目的，用系统管理的业务意图触发设计）
2. 控制机的设计原则（假定各种可能存在错误的可能，并做容错处理，出现局部错误和临时错误是很正常的事情，错误可能存在于物理故障磁盘，外部系统的故障啊，系统本身的代码问题，考虑到任何可能的错误，并且做容错处理，每个模块出现错误后，恢复处理，在系统中不可能保证每个模块始终是连接的，因此任何一个模块都要有自动修复的能力，保证连接不到其他模块而形成的自我崩溃。很多情况下可以做到优雅的降级，要求在设计的过程中，有基本功能和高级功能，同时不会导致高级功能的崩溃，影响到这个模块 的使用，更容易的引入高级功能，而会导致高级功能影响基本功能。）

• k8s网络

1. CNI
2. Flannel，Calico，Weave
3. Pod网络

• scheduler-preselect

1. NodiskConflict 挂载冲突
2. checkNodeMemMemoryPressure 内存的压力
3. Nodeselect 节点的选择器
4. FitRescoure CPU，内存的限制
5. Affinity 满足pod的连接状态的限制

• scheduler-optimize-select

1. selectorSpreadPriority
2. LeastRequestedPriority
3. AffinityPriority

• pod内部通讯

  
  

  

• 同一个node上的不同pod通讯

• 不同的node，不同的pod通讯

k8s的服务发现

• kube-proxy（ClusterIp）

• kube-proxy（NodePort）

• kube-DNS

PS：k8s的理论就讲这么多，重点还是实践，下次开始搭建k8s集群