Python中国社区  »  docker

『高级篇』docker之了解kubernetes(31)

IT人故事会 • 2 周前 • 19 次点击  

原创文章,欢迎转载。转载请注明:转载自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

官网:https://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集群


今天看啥 - 高品质阅读平台
本文地址:http://www.jintiankansha.me/t/NBeLhStGBF
Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/26129
 
19 次点击  
分享到微博