ITPub博客

首页 > 自动化运维 > DevOps > docker笔记19-k8s的介绍

docker笔记19-k8s的介绍

原创 DevOps 作者:czxin788 时间:2018-09-04 16:25:12 0 删除 编辑

     Docker的第一类编排工具:

        1) docker compose(docker原生):只能对一个主机上的容器进行编排,无法编排多个主机上的容器;

        2) docker swarm(docker原生):可以对多个主机上的容器进行编排。

        3) docker machine(docker原生):可以将一个主机迅速初始化到docker swarm集群里。

        以上三个称为docker三剑客。

     Docker的第二类编排工具:    

         mesos:它不是docker的编排工具,而是资源分配工具。所以mesos必须要依赖于容器编排框架marathon。

     Docker的第三类编排工具:

        kubernetes(简称k8s):这个容器编排工具占用了80%的市场份额。

        有了容器和容器编排技术,对持续集成(CI)、持续交付Delivery(CD)和持续部署Deployment(CD)的需求变为可能,这也就是DevOps的理念。

        注意:DevOps并不是一种技术,而是一种运动,一种文化。

k8s的介绍

    k8s是2014年google对外开放的。

    Borg是谷歌内部非常棒的容器编排工具,k8s就是站在Borg基础上开发出来的,所以k8s从一出世,就吸引了太多太多人的关注,直到今天为止,它也确实没有辜负人们的期望。

    2017年是容器技术最辉煌的一年,AWS、微软的云技术、阿里云等云厂商开始对外宣布,他们支持k8s。

     k8s的代码托管在github之上:https://github.com/kubernetes/kubernetes/releases

    k8s的特性:

        1)可以自动装箱,即可以自动完成容器的部署,而不影响可用性;

        2)可以自我修复,如果容器崩溃了,可以1s内重新启动,有了k8s后,我们不再关注个体,而是关注群体,有一个个体坏了,把它干掉,换一个新的就行了;

        3)可以自动实现水平扩展,一个容器不够,再启动一个就是了;

        4)可以自动实现服务发现和负载均衡,也就是说可以自动发现每个微服务之间的关系,同时也可以自动对容器内多个服务做负载均衡;

        5) 可以实现自动发布和回滚;

        6) 可以实现密钥和配置管理,也就是说每个容器不是加载容器内的配置文件,而是加载远程服务器上(配置中心)的配置文件;

        7)可以实现存储编排;

        8)可以实现任务的批量处理执行。

     k8s是一个有中心节点架构的集群,由master节点(至少三个)和nodes节点(运行容器的节点)组成 。客户的启动容器等请求会先发给master节点,master节点有个调度器会分析node节点资源(cpu、内存)的可用状态,找到最佳适配的node来启动用户请求的容器。

        


    master上的第一个组件叫调度器(Scheduler),它的工作原理有两步:第一步调度器先做预选,即先评估到底有多少个node是符合容器需求的;第二步调度器再做优选,即在符合的node中选择一个最佳的node来运行容器。

    如果node宕机了,那么托管在node之上的所有容器也就不见了。此时k8s可以在其他节点上创建出来和宕机node上一模一样的容器。

     另外,master上还有一个组件叫控制器,它会不停的Loop,用来周期性监控每个node的健康状态;控制器是有多个的(因为有至少三个master)。

     再者,master上还有一个组件叫控制器管理器 (Controller-Mnager) ,控制器管理器用来监控着每个控制器的健康。

     在k8s上运行的最小单元不是容器,而是pod。pod可以理解为容器外壳,pod里面装的就是放容器的。一个pod里面可以放多个容器,这些容器可以共享一个底层的网络名称空间、存储卷,这样一来,pod对外更像一个虚拟机。

    一般说来,一个pod里只放一个容器;如果一个pod必须要放多个容器,那么里面有一个是主容器,其他都是辅助容器,辅助容器主要是为了辅助主容器的主程序的某些功能而设置的。

     一个pod里面的所有容器只能运行在一个node上的。

     pod是k8s调用的原子单元,是个逻辑概念。

    最终用户无需再关注pod运行在哪个node之上,这也就是云的概念,也就是把很多的node做为一个资源池,来进行统一管理。

    pod尽量由控制器管理,而不要手工管理。

    pod可以分为两类:

        a)自主式pod:即自我管理的pod。我们创建Pod,首先交给Apiserver,然后调度器调度给指定的node节点,。如果容器需要启动,由node上kubelet组件来完成;如果node发生故障,那么pod也就消失了。

        b)控制器管理的Pod(建议创建这种Pod):这种Pod是有生命周期的对象。由master上的调度器将pod调度至某node进行运行或者停止。pod控制器后很多种, 最早的一种叫Replicaton Controller(副本控制器) ,意思是当我们启动一个pod时,如果这个pod不够了,会再启动一个,这叫副本。副本控制器就控制副本的数量,一旦副本少了,就会自动再加一个。如果副本多于定义的个数,会被停止。也就是副本必须精确符合人们定义的个数。副本个数至少要两个。如果一个pod副本所在node宕机了,那么会向ApiServer重新请求,Apiserver借助调度器,到新节点创建一个新pod。滚动更新:比如我有个1.0版本的镜像,现在又有个1.1版本的镜像,那么控制器管理的pod就会新启动一个1.1版本的Pod,然后删除1.0版本的pod,这叫滚动更新。同样,k8s也支持回滚更新。 到了k8s新版本,又出现了Replica Set(副本集控制器),但是该控制器并不直接使用, 而是使用一个声明更新的控制器Deployment,这个也是用的最多的。但是Deployment控制器只能管理那些无状态的应用。而有状态的应用是由Stateful Set控制器管理。对于Deployment控制器,它还支持二级控制器,叫 HPA(horizontalPodAutoscaler),该控制器可以自动水平扩展pod,也就是当一个pod压力大时,HPA控制器会自动水平扩展加几个新的pod来分解压力,具体加几个,HPA会根据当前节点的cpu、内存负荷来计算,一旦访问量小了,HPA还会自动减少pod个数 。如果我们想在一个Node上只运行一个副本,需要用DaemonSet控制器。如果需要运行作业(如备份,清理数据等),需要conjob控制器。以上所讲的都是pod的控制器,用来管理不同类型的pod。

     为了实现给pod分组,可以给pod打上标签(Lablel),这样就可以进行分组了。

    标签选择器(Lablel Selector)组件:是一个根据标签来过滤符合要求的资源机制。

    客户端是通过service来找到pod的,service是通过pod的标签选择器来找到pod的。service只是一个iptables方式的net地址转换路由规则,不过到了k8s最新版本1.11,支持了ipvs方式的分发规则,支持各种调度算法,这也就实现了负载均衡。。装完k8s后,就需要创建一个DNS pod,这是因为service的名字需要DNS服务器来进行解析。这种pod是k8s的组成部分,被称为k8s基础架构的pod,也被称为k8s的附件,英文名叫AddOns。这种DNS是用来解析service名字的,而不是pod的,并且DNS名称解析是K8s自动维护的,不需要我们人工干预。

     一句话,service里面的地址存在iptables net或者ipvs里面,service是用来调度流量的,而不会启动或者停止容器的。

    然而,pod的启动或者关闭、创建等是由控制器来做的,比如我们想创建一个nginx pod,就先创建一个Nginx控制器,nginx控制器自动就会帮我们创建nginx pod;然后我们再创建一个nginx service,把nginx pod发布出去。

    service有两种类型,一种是调度流量仅供k8s内部来使用,还有一种可以调度流量供k8s外部来使用。

    

    

     上图中,我们应该明白了service是用来分发流量给pod的,控制器是用来创建、启动和停止pod的,标签选择器是service用来根据标签来识别每个pod的。 

    在k8s运行中,需要三种网络,第一种网络是需要各pod在一个网络中,而service在另外一个网络,即service的地址和pod的地址是不同网段的,pod的地址是配置在pod内部的网络名称空间,是可以ping通的,但service的地址虚拟的,是假地址,只存在于iptables 或者ipvs里面。另外node又存在另外一个网络,这样就有三种网络。所以外部先到达node网络,然后再到service网络,最后才到pod网络。

    那么pod之间是怎么通信的呢。同一个pod内的多个容器间通过lo进行通信;各pod之间通过overlay network(叠加网络)进行通信,即使pod之间跨主机,通信也没问题;pod与service之间通过网关(也就是docker 零桥的地址)进行通信。

   node上有个组件叫kube-proxy,它负责和ApiServer进行通信,kube-proxy一旦发现service背后的pod地址发生变化,kube-proxy就会把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy来实现的。

    在master(注意,master是有多个的)上的数据并不存在master本地,而是存在共享存储DB中,这个共享DB叫etcd。etcd里面数据是以key-value形式存储的,集群中所有状态信息都在etcd中,所以ectd要做冗余,一般至少三个节点。etcd是通过https方式访问的。etcd有一个端口是用来集群内部通信,另外 一个端口用来对ApiServer通信。这样一来,etcd内部通讯需要点对点的专门证书,对ApiServer通信就要另外一套证书。另外,ApiServer向客户端提供服务,也需要另外一套证书。同样,ApiServer和node上的kubelet组件和kube-proxy组件通信也需要CA证书。所以做K8s的部署,需要建立5个CA,这也是最难的。


    下面我们把k8s归类为以下三类节点:master、node(上面有pod)和ectd(存储集群状态信息),它们彼此之间都是由http或https进行通信的。我们知道网络也分为:pod网络,service网络和node网络。所以我们要构建出三类网络来,但是K8s自己不提供这三类网络,而是要依赖于第三方插件CNI。

    

    k8s通过CNI(容器网络接口)插件体系接入网络。目前常见的CNI插件是flannel。其实网络只提供两个功能,一个是给pod、service等提供ip地址的功能,另外还需要网络能提供网络测试的功能,来隔离不同Pod之间的通信。

    flannel插件只支持网络配置(供ip地址的功能),但不支持网络策略。

    CNI里面的插件calico可以同时支持网络配置和网络策略,但是calico的部署和使用非常难。

    于是,又有了第三个CNI插件canel,它用flannel提供网络配置,用calico提供网络策略。这些插件可以作为k8s之上的守护进程运行,也可以在k8s里面的容器运行。

    名称空间,可以实现不同类pod运行在不同的名称空间中。比如可以把名称空间分为开发名称空间、生产名称空间等。这样通过网络策略来定义名称空间之间、同一个名称空间的pod之间的网络行为。

     本小节总结:

         1)master/node:

            a) master上包含的组件 :API Server,Scheduler(调度器),Controller-Manager(控制器管理器)

            b) node上包含的组件: kubelet (用来和master通信的一个组件,并试图启动本node上的容器等工作;另外启动容器是由容器引擎来操作的,最流行的容器引擎是docker)、 docker引擎 (也可以用其他容器引擎)、 kube-proxy( 负责和ApiServer进行通信,kube-proxy一旦发现service背后的pod地址发生变化,kube-proxy就会把pod地址反映到iptables 或者ipvs中。所以service的管理是靠kube-proxy来实现的)

         2)Pod :Lablel(标签,kv格式),Lablel Selector(标签选择器)

 生产中k8s的最终架构图(PaaS)

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28916011/viewspace-2213456/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-06-03

  • 博文量
    178
  • 访问量
    504170