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

原创文章，欢迎转载。转载请注明：转载自 IT人故事会，谢谢！ 原文连接地址： 『高级篇』docker之了解kubernetes（31）

最后一个服务编排工具的学习k8s。kubernetes其实源于希腊语意思（舵手，领航员）。犹豫不太好挤也不太好写，就有了另外一个名称叫k8s，kubernetes是谷歌在2014年开始实施的一个项目，当时google已经有了大规模服务容器管理的经验，内部Borg系统，负责对google内部的一些服务进行调度和管理，它的目的是让用户没必要操心资源管理的问题，让他们专一本身的核心业务， 而且最大化数据中心的利用率。

什么是k8s

咱们假设有个住户社区，k8s就至关于这个社区的大房东，社区里面有一栋一栋的大楼，大楼能够看作虚拟机器，俗称的VM，大楼里面有不少的住户，每一个住户就表明一个pod，那每一个住户如何找到他们的位置呢？每一个住户如何找到他们的位置就是经过门牌号，咱们就理解为IP的位置，在每一个住户里面有很是多的家庭成员，爸爸，妈妈，兄弟姐妹，爷爷奶奶，姥爷姥姥，女儿儿子，这些角色就能够理解为container，在这个pod里面的成员，就共享了这个房间里面的资源，水电网络，那些资源就能够把它理解成计算资源，ipu，内存，硬盘。对于大房东k8s，他最主要的功能就是管理，每一个住户Pod使用多少资源，那为了就是让整栋大楼，会更有效率的使用不少资源，举例来讲：A栋大楼住了太多的住户，太多的Pod，他们直接确定会相互竞争资源的问题，那它就能够协调某一些pod，就是某一些住户搬到B大楼去，这样会让变得更加的均衡使用。

• k8s

官网： kubernetes.io/ k8s是一个自动开源系统，自动化部署，扩缩容，管理容器化的应用。 相比前面的mesos 和swarm，k8s的目的很是的单纯和明确，简单的来讲他的目的就是为了服务编排，没有别的。这么明确的明确的目的。虽然目的简单但专一因此专业，很是灵活的使用方式，它考虑到服务服务落地过程当中可能遇到的各类各样的问题，各类各样的场景，因此从简单的入手，吃透它。了解它的全部组件，而后回过头看它的架构。

• k8s 集群的样子

这张图简单的描述了，k8s集群的样子，k8s确定也须要一个集群，服务调度服务编排确定要有机器，因此须要集群，中间的七边行是Master节点，能够理解为安装了核心组件的，另外的六边形标识的是Node节点，在k8s里面叫worker节点，而后每一个节点里面有个kubelet服务和docker服务，

多了2个绿色部分，在master里面Deployment。在Node中就是Containerized app就是容器化的应用。图例就是在Master部署了一个Deployment，在三个节点选中了其中的一个部署了应用。Node中的蓝色圆圈标识的是pod。

pod 是k8s中很是重要的一个概念，全部的应用和服务都是运行在pod里面的，pod是k8s中最小的一个单元，能够理解为k8s的一个原子，pod里面就是容器。

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

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

知道了pod运行了容器，pod本身运行在哪里啊。运行在node，经过kubelet来进行的，调度kuelet把pod运行起来。一个node上面能够运行多个pod。只要资源足够能够创建多个pod。

service

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地址进行负载均衡，进行轮询，

service的概念基本了解了，怎么肯定哪些pod属于一个service，提出一个service的概念，service可能有一个或者是多个pod组成，如何定义service，怎么定义service。在k8s上经过Master的Label Selector的方式，好比s:app=A，s:app=B，有这种标签的肯定输入pod等于A 或者pod等于B，全部标签同样的都属于个人小弟。这样service和pod的耦合就很是松。

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

deployment完成应用扩容

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

滚动更新，停掉了一个旧的pod，启动一个新的pod，这时service既有新的，也有旧的存在，直到全部的旧的都更新完毕才结束。全部的更新和扩容的过程serivce的Ip始终是保持不变的。

k8s的总体架构

首先从总体上看，上边这块就是Master节点，下面有两块都是worker节点，master里面部署的都是k8s的核心模块，虚线框表明的是API Server，提供了资源的核心模块，提供了认证受权和k8s的访问控制，能够经过kubectl或者本身开发的userClient，restApi的形式访问API server。从而完成整个集群的访问。

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的设计理念

了解设计理念能够更深刻的了解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

优先规则，对node进行打分，经过优先函数进行预选规则，每一个优先函数能够返回0-10的函数，分数越高，这台主机越适合，对应一个权重。

1. selectorSpreadPriority
2. LeastRequestedPriority
3. AffinityPriority

• pod内部通信

• 同一个node上的不一样pod通信

经过pod的Ip来进行访问

• 不一样的node，不一样的pod通信

知足pod，ip不能冲突

k8s的服务发现

• kube-proxy（ClusterIp）

每一个服务，全部的pod给虚拟Ip，虚拟Ip只能在内部访问

• kube-proxy（NodePort）

服务暴露到节点，外部的能够经过NodeIp 访问pod

• kube-DNS

负责集群内部的dns解析，内部之间能够经过名称访问pod。

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