Kubernetes第一回（架构概述）

1、kubernetes和Devops概述

一、为何要用kubernetes

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

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%。

二、devops概念：

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

• CI  （Continued integrate  持续集成）

• CD（Continued Delivery  持续交付 ）

• CD（Continued Deployment  持续部署 ）

2.一、devops和docker的关系

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

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

2、kubernetes

一、kubernetes的由来

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

二、kubernetes的特性

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

• 自我修复：一旦某一个容器崩溃，因为容器轻量级的特色，kubernetes可以在1秒中左右迅速启动新的容器。 

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

• 服务发现和负载均衡：当咱们须要在k8s上运行不少应用程序的时候，一个服务能够经过自动发现的形式找到它所依赖的服务，并且每一种服务若是起了多个容器，他能实现自动负载均衡。

• 自动发布回滚：

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

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

• 任务批处理运行：

三、kubernetes架构

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

3.一、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.二、etcd节点

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

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.四、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.五、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
  

4、Kubernetes的网络模型

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

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

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

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

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

二、3类通讯

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

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

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

 

三、kubernetes的网络实现

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

• flannel：只支持网络配置

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

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