Kubernetes第一回（架构概述）

一、kubernetes和Devops概述

1、为什么要用kubernetes

 在docker还没有出现前，我们去安装部署应用程序时，比如nginx、php等web架构站点。我们要去手动操作部署，非常繁琐耗时，后来有了ansible等运维工具。这种工具实际上是一个应用编排工具，能够实现安装、配置、启动。甚至可以按照定义好的playbook完成对多种有着依赖关系的应用程序的快速部署。代替了繁琐易出错的手动操作。而这种工具操作的对象是直接部署在操作系统中的应用程序。docker出现以后，各种应用程序都被封装在容器中运行（容器化）。由于操作对象从实际的应用程序对象变成了容器内的应用，他们本身提供的访问控制和管理接口是不同的。所以ansible等运维工具无法完成容器运行的编排工作。后来，出现了专门用于容器编排的工具

1.1、常见的3款容器编排工具

• docker compose：它是docker自主研发，它只能面向单个的docker host来执行编排操作，后来docker为了让docker compose能支持多机的编排工作，推出了docker swarm和docker machine两个组件

• mesos：mesos是Apache下的开源分布式资源管理框架，它能够把一个IDC当中所有硬件所提供的计算资源统一调度和分配，但是它面向的上层接口不是容器运行的接口，而只是资源分配工具。它不能直接托管运行容器。所以在mesos基础之上，它必须要依靠一个面向容器编排的框架（marathon）

• kubernetes：它是由google公司在2014年发布的一款开源的容器编排引擎，用来管理云平台中多个主机上的容器化的应用。kubernetes的目标是让部署容器化的应用变的简单高效。到现在为止，kubernetes已经占据了容器编排市场的80%。

2、devops概念：

DevOps是（Development和Operations的组合词）是一组过程、方法、文化与系统的统称，depvops重视的是将持续集成、持续交付再到持续部署的一整套流程的解决方案

• CI  （Continued integrate  持续集成）

• CD（Continued Delivery  持续交付 ）

• CD（Continued Deployment  持续部署 ）

2.1、devops和docker的关系

docker容器的出现和容器编排工具的出现使得devops这一套流程（持续集成、持续交付、持续部署）更容易实现了，在原来的场景中，我们需要针对目标的环境构建不同环境的应用，部署方式也不尽相同。而有了docker之后，就不需要关注这些，因为docker可以做到，一次构建，到处运行。我们可以只构建一次（构建为镜像），只要目标主机上有docker（不需要关注目标主机的环境），我们就可以将应用跑起来。

虽然docker可以很好的将devops文化实现，但是也带来一个缺点，在众多微服务中，我们每天可能需要去处理各种服务的崩溃，而服务间的依赖调用关系也及其复杂，这对我们解决问题带来了很大的复杂度。要很好的解决这个问题。我们就需要用到容器编排工具。

二、kubernetes

1、kubernetes的由来

最早在2014年对外发布，kubernetes是由google的几位工程师用Go语言根据google内部强大的容器编排工具Borg改写而来。而后在容器技术广为应用之后，kubernetes在短短几年之内，发展迅速，它深受人们的喜爱。kubernetes最早的版本1.0在2015年发布，到现在为止发布的版本已经到了1.12版。在2017年容器技术发展历史上具有里程碑意义的一年，因为在这一年中，aws、微软云、阿里云等等著名的云计算公司都开始宣布原生支持kubernetes 。还有的平台可以做到把自己的k8s对外提供服务，让用户可以直接在上面部署应用程序，提供容器级服务的环境。这些大型云厂商的支持， 使得k8s在业内已经受到了广泛的认可和支持。而且在2017年10月，docker宣布在他们的企业版发行版当中，原生同时支持swarm和kubernetes两种工具。

2、kubernetes的特性

• 自动装箱：基于资源依赖及其他约束能够自动完成容器的部署而且不影响其可用性
  

• 自我修复：一旦某一个容器崩溃，由于容器轻量级的特点，kubernetes能够在1秒中左右迅速启动新的容器。 

• 自动水平扩展：只要物理平台的资源支撑是足够得到，kubernetes就可以无限制的增加容器。

• 服务发现和负载均衡：当我们需要在k8s上运行很多应用程序的时候，一个服务可以通过自动发现的形式找到它所依赖的服务，而且每一种服务如果起了多个容器，他能实现自动负载均衡。

• 自动发布回滚：

• 秘钥和配置管理：k8s通过配置中心的方式来保存所有应用的配置信息，当容器启动时，会去配置中心加载对应的配置信息。

• 存储编排：根据容器自身的需求自动创建存储卷。

• 任务批处理运行：

3、kubernetes架构

kubernetes是从我们传统运维角度来说的集群，组合多台主机的资源整合成一个大的资源池并统一对外提供计算存储等能力的集群。每一个主机上都安装了k8s的相关应用程序，并通过这个应用程序协同工作，把多个主机当一个主机来使用。但是在k8s集群中，主机是分角色的，k8s是一个有中心节点架构的集群系统（master/nodes模型）。k8s一般有3个master节点以实现HA，N个node节点提供计算存储能力以运行容器。master负责接受客户端的请求，而后master负责分析各个node现有的可用资源状态，将请求调度到一个可运行容器的最佳的node节点。最后，node节点首先在本地检查是否有镜像（去Registry上pull镜像）最后在以Pod（node节点的最小调度单元）的形式将容器启动起来。这是kubernetes的功能模型。

3.1、master节点的核心组件

• API Server：    API Server专门负责接收、解析、接收集群中的各个状态信息、处理请求。
  

• Scheduler（调度器）：    它负责观测每一个node上总共可用的cpu计算和存储资源，并根据用户请求创建的容器所需要的资源量在众多node中挑选出一个符合条件的node来创建容器。kubernetes设计了一个两级调度的的方式来完成调度，第一步先进行预选；对每一个node进行评估，选出所有符合的node。第二步再在选出来的node上根据“调度算法”中的优选算法来选出一个最佳的node。

•  Controller Manager：   它负责监控每一个控制器的健康状态，如果控制器不健康，由Controller Manager会重新生成一个控制器接管。Controller Manager如果down机，会有从master上的Controller Manager接管

3.2、etcd节点

它是一个key：value的数据库，类似redis。但是它还具有redis不具备的集群选举功能，负责存储集群中API Server中保存的各个状态信息（持久化到共享存储），以防止集群中的主master节点宕机，其他master节点可以读取到之前的集群信息。etcd同样是restfull风格的集群，通过http或https通信。在一个k8s集群中，etcd是高可用的。防止一个etcd宕机之后不能进行集群leader选举。

3.3、node节点的核心组件

• kubelet：负责与master通信，接受master调度过来的任务并执行，可能包括；创建Pod，管理Pod的健康状态、创建存储卷、启动容器等

• 容器引擎：docker，作为容器引擎负责运行Pod中的容器

• Service：在k8s集群中，Pod故障、重新创建会导致主机名、IP地址经常变化，这就导致了客户端无法与变化之后的Pod进行通信，于是k8s为每一组提供同类服务的Pod在它的客户端之间添加了一个中间层（Service），Service将来自客户端的请求代理到众多的Pod上面，所以它同时也是调度器。而Pod故障重启之后，Service通过“label selector”来将新的Pod对象关联。最后Service在自动探测新Pod对象的IP地址、端口、主机名等信息。Service并不是k8s中的组件，它是一个iptables的Dnet规则，k8s在1.11版已经替换成了IPVS规则。

• Kube-Proxy：节点中的每一个Pod发生变化以后，结果是保存在API Server中。而后API Server会生成一个通知事件，Kube-Proxy负责接收API Server的通知事件，一旦发现了某一个Service背后的Pod信息发生了改变（IP、Port等），由Kube-Proxy负责在每一个节点上将变化后的service转换成IPVS或IPtables规则中。而每创建一个Service，Service的实现也要靠Kube-Proxy在每一个节点上创建成IPVS或规则

• namespace（名称空间）：它是k8s的名称空间，用来将集群中的不同类型的Pod隔离开来，它提供的不是真正意义上的网络边界，而是管理边界。以后我们可以删除一个名称空间，就可以将Pod全部删除。它不是Pod的边界，Pod如果没有网络策略限制，同样可以访问其他名称空间中的Pod。

3.4、Pod是什么

Pod是k8s的最小逻辑运行、调度单元。在k8s中，调度器并不直接调度容器的运行，它调度的目标是Pod，Pod是k8s中对容器抽象的封装，可以理解成一个外壳。Pod内部主要用来放容器，一般Pod中只有一个容器，Pod中也可以有多个容器，因此Pod有个特性，就是共享底层的名称空间Net、UTS、IPC，在这三个名称空间之上还可以共享第三种资源“存储卷”。这使得我们可以构建较为精细的容器间通信架构。

k8s通过在Pod上添加一些元数据信息来将k8s的资源管理（Pod资源等）变得简单，而Tag是众多元数据中的一种，，Tag是Key="Value"的形式，通过label selector（标签选择器），kubelet在管理Pod，分组Pod，识别Pod就容易了。

Pod种类：

• 自主式Pod：指的是自我管理的Pod，Pod在创建以后，提交给API Server，API Server接收以后借助于调度器将其调度至指定的node节点，由node启动此Pod，如果Pod中的容器出现故障需要重启容器，这个操作是由kubelet来完成。如果节点故障，pod将消失。

• 控制器管理的Pod：正是Pod控制器这种机制的引入，使得在k8s集群的设计中，Pod可以成为有生命周期的对象，由调度器将Pod调度至集群中的某节点运行。

  
  

3.5、Pod控制器

• ReplicationController：它可以自动管理Pod，当Pod少于或者多余指定的数量，他会根据策略自动重启Pod、删除、创建Pod。Pod控制器还可以实现滚动更新，将Pod内部运行的容器镜像从1个版本更新到另一个版本。并且可以回退镜像版本。在k8s早期版本中，只支持ReplicationController一个Pod控制器

• ReplicaSet：新版本k8s中加入，它不直接使用，它有一个声明式更新的控制器Deployment

• Deployment：只能负责管理那些无状态的应用，它还支持HPA的二级控制器，通过HPA（水平Pod自动伸缩控制器），来监控Pod是否足够，不足则创建新的Pod

• StatefulSet：负责管理那些有状态的应用Pod

• DaemonSet：如果我们要在集群中的某一个节点运行一个副本，而不是随意副本，就需要用到

• Job：管理那些需要特定时间，而时间又不固定的，执行任务就可以退出的Pod。比如脚本的执行等操作

• Cronjob：管理那些需要周期运行的任务的Pod
  

四、Kubernetes的网络模型

1、kubernetes要求整个k8s集群中要有3种网络

• 各Pod要运行在一个网络中，Pod的网络是配置在Pod内部的网络名称空间上的，相当于主机的IP地址，称为Pod网络

• 各service要运行在一个网络中，这个网络是虚拟的，无法ping通，存在于IPVS或IPtables的规则中。称为集群网络

• 各节点网络，每个节点都有一个网络。称为节点网络

要想接入外部网络，要先到达节点网络，由节点网络代理至集群网络，最后在由集群网络代理到Pod网络

2、3类通信

• 本地通信：同一Pod内多个容器间通信，通过Lo接口即可

• 各Pod之间通信：不同docker主机之间的Pod通信要通过配置IPtables规则的net规则来通信，这样经过多层转发会影响效率，而使用物理桥接通信会产生广播风暴，k8s使用Overlay Network（叠加网络），通过隧道的方式来转发2层报文。虽然跨主机，但好像工作在同一个二层网络当中
  

• Pod与Service间通信：由于Service地址只是主机上的iptables或ipvs规则中的地址，所以只需要在容器中将网关地址指向到docker0桥地址。而Service的变动或新建都由node节点上的Kube-Proxy组件管理

 

3、kubernetes的网络实现

k8s并不提供集群中的3种网络管理与网络策略功能，而是依赖于第三方插件，k8s通过CNI（Container  Network  Interface）插件体系来接入外部的网络服务解决方案，CNI要求网络解决方案必须要支持网络功能（能提供地址），还必须要支持网络策略的功能（为了安全，隔离限制不同名称空间中的Pod之间的访问或者限制相同名称空间中的各Pod之间的访问）。只要一个网络服务提供商能够遵循CNI开发这个服务，它就能作为k8s的网络解决方案来使用。这些网络解决方案可以以附件的方式托管在集群之上（可以运行为Pod），它是一个特殊Pod，它需要共享节点的网络名称空间。这样就能实现以容器的方式来运行系统管理的命令。目前可以用的CNI插件有很多，常见的有；

• flannel：只支持网络配置

• calico：支持网络配置、网络策略。基于BGP的协议来实现直接路由通信。但是它部署和使用困难。

• canel：结合上面两种插件的。