Docker系列(九)：Kubernetes架构深度解析

Kubernetes重要概念

Docker解决了打包和隔离的问题，但我们需要更多：调度的问题，生命周期及健康状况，服务发现，监控，认证，容器聚合。

Kubernetes概述

开源DOcker容器编排系统

轻量级，简单

公有云，私有云以及混合云中部署

模块化，可插拔化，可挂接，可组合

自动恢复，自动重启，自动复制



master管理节点，所有的用户都是跟master进行交互的

kubernetes从多个动作节点上（node）调度应用。

Namingspace

多租户，每个租户的对象是相互隔离的，只能看到自己的命名空间内定义的资源

Names

命名的对象（pods、service、rc等的命名），是一个全局唯一的值

Annotations

key value值，不作为可选择的，可过滤的参数，有时候想定义一些key value值去pods一个简单的记录，简单的用途。

Resource

Lable

简介

用以标识对象（如Pod）的key/value 对

组织并选择对象子集

lables使用户可以使用松耦合的方式来映射子集应用的组织结构，而不需要存储这些映射表， 与命名和uid不同的是，lable不需要提供唯一性，反而我们希望多个对象使用相同的lable，通过lable选择器，用户可以指定一些对象子集，来进行分组合并。

示例

vi lables.yaml

kunectl create -f lables.yaml //创建
kubectl get pods //查看所有的pods
kubectl get pods  -l app=nginx //给查看的pods加上lable，相当于加了过滤器

Master节点

Node

Pod

简介

创建、调度以及管理的最小单元

共存的一组容器的集合

容器共享pid，网络，IPC以及UTS命名空间（共享pid：同一个pods内的容器可以看到彼此的进程，共享网络：同一个pods内的容器可以共用相同的ip地址和端口，也可以通过localhost来访问，共享IPC:同一个pods内的容器可以通过systemvipc和消息队列的方式进行通信，共享UTS命名空间：同一个pods内的容器使用了相同的主机名。）

容器共享存储卷

短暂存在

生命周期

Pending：pods已经被系统接受但是一个或多个容器镜像还没有创建。包括容器被调度之前的时间以及下载镜像的时间。

Runnning：pods已经被部署到一个节点上了，并且所有的容器都已经被创建了。

Successded：pods中的容器都已经被成功的停止了，并且不会被重启

Failed：pods中所有的容器都被停止了，并且有至少一个容器停止的时候出现了错误。

示例

vi pod.ymal   k8s中通过ymal文件定义对象的

kubectl create  -f pod.ymal
创建上面的pod

kubectl get pods
查看所有的pods，发现上面的nginx已经运行了

kubectl delete pods nginx    //删除pods
kubectl get pods

Service

简介

每个pods都有自己的IP地址，并且这些地址并不是固定的，如果一些pods是为另一些pods提供服务的，该如何被发现呢？

抽象一系列pod并定义其访问规则，

固定ip地址和dns域名

通过环境变量和dns发现服务

负载均衡

外部服务:

ClusterIp(当前集群内访问)

NodePort （是使用了clusterIp同时还会在集群的每一个节点上暴露一个服务的端口，可以通过集群上的某一个工作节点 和IP地址和端口来访问这个服务)

Loadbalancer（如果云服务提供商支持web服务的话）

示例

vi service.yaml

kubectl create -f service.ymal //创建service
kubectl get services

看下图会分配一个虚拟ip



切换到一个工作节点:curl http://10.247.252.165：8000,发现是成功的

通过serviece的方式我们并不需要知道pods的id，service的ip是一个固定的ip，可以通过kubenetes提供的dns的服务去进行查询 ，service通过负载均衡到每一个pods上，用户只需要知道kubenetes提供的唯一的ip就可以了。

Replication Controller

简介：

在任何时刻运行指定数目的pod ，当pods所在的问题出现问题的时候，会被调度到其他正常的节点上运行。

容器重新调度。

规模调整（ 只需要修改指定的数目，rc便会删除多余的容器，或者启动新的容器，以达到指定的数目）

在线升级（可以增加一个新版本的pod，删除一个旧版本的pod，最后在pod的数目为零的时候，可以删除rc，需要注意新版本和旧版本的rc需要至少有一处不同的lable以标记不同版本的pods）

多发布版本跟踪

示例

vi rc.yaml

template是对pods的定义

kubectl crate -f rc.yaml
kubectl get rc //查看rc
kubectl get pods -l app=nginx //查看lable过滤的pods，会发现有两个，因为上图中的replicas设定的2
kubectl delete pods nginx //删除一个
kubectl get pods -l app=nginx//会发现还是有两个

Volumes

容器中的文件是短暂存在的，当容器crash的时候数据将会被丢失

简介

数据持久化

pod中容器共享数据

生命周期，和pod的生命周期相同，当pod停止退出的时候volume也会停止退出

支持多种类型的数据卷

emptyDIr(本地主机生成，pod被调度到一个节点上的时候生成，只要pods运行在当前节点上，并一直存在，其初始是一个空文件夹， pods内的容器可以读写此文件夹中的文件。当此pod被从此节点上删除的时候，数据卷也会相应的被删除，此处注意容器crash的时候数据卷是不会被删除的)

hostpath（本地主机生成，将当前宿主机上的一个路径 映射到pods内）gcepersistentDidsk（云端云存储的支持）

awsElasticBlockStore（云端云存储的支持）

nfs（网络磁盘）

iscsi（网络磁盘）

glusterfs（网络磁盘）

secrets（保存比较敏感的数据，不希望别人看到，比如用户的密码。）

示例

vi pod.ymal  //修改ymal文件

kubectl get pods redis -o yaml //-o yaml 输出是yaml，更详细的查看pods 信息。

Kuberetes架构及原理

典型的分布式架构

简介

APIserver负责与外界进行通信

kubctl通过rest命令kubenetes中对象的操作发送到APIserver

调度器Scheduler

控制器Controller Manager

所有的对象持久化存储到分布式的key value中etcd

docker容器试运行在工作节点上的（node）

node上有kubelet定期和APIserver进行通信，proxy为容器提供网络的代理

etcd

存储了kubenetes中所有可用的镜像

高可用的key value存储

只有APIserver有权限读写

使用etc集群确保数据可靠性

APIserver

作为kubenetes系统的入口，对外童工了基于restful的管理接口，支持对kubenetes对象（pod、service等）进行增减改 查以及监控的操作 ，维护的对象将会被持久化道etcd中

APIs的访问需要通过认证，目前支持认证的方式包括客户证书认证，basic认证、tocken认证

在认证的基础上有授权的模块，可以对http的请求设置alwaysdenied（永远拒绝，测试环境） 、alwaload（永远接受）、abac（设置不同用户的访问权限）三种模式

访问控制：任何请求在访问APIserver的时候，都要经过一系列的验证，任何一个环节拒绝了请求， 都会返回错误，包括全不允许、全部拒绝、资源限制确保了资源不会违反本命名空间的资源限制以及资源分配的规则，安全限制 确保了请求不违反本命名空间中对安全的策略

服务账号：当pods里面的进程需要访问APIserver或其他需要认证的服务的时候使用服务账号作为pods id

资源限制

kube-scheculer

负责集群的资源调度， 为新建的pod提供机器

资源需求

服务需求

硬件、软件、策略限制

关联性和非关联性

数据本地化

kube-controller-manager

负责执行各种控制器，分为四类

Replication controller：定期关联replication controller和pod，确保replication controller定义的数量与实际运行的pod的数量总和是一致的

Endpoint controller:定期挂链service和pods，关联信息是由endpoint对象维护的保证service到pod的映射总是最新的

Namespace controller ：命名空间

ServiceCount controller：服务账号

kubelet

管控docker容器，启动停止，监控运行状态等，它会定期的通过APIserver从etcd获取分配到本机的pod，并根据pod信息，启动或停止相应的容器，同时会接受APIserver的http请求，回报pods的运行状态。

节点管理器

确保调度到本节点的pod的运行和健康

kube-porxy

pod网络代理，定期从APIserver通过etcd获取所有的service，并根据service的信息提供代理，当某个客户pod需要访问其他pod的时候，请求会经过本机的proxy做转发，

TCP\UDP转发

负载均衡（Round Robin插件的形式）

服务发现

一开始通过环境变量来服务发现，但是会环境变量泛滥的问题

后来是DNS kube2sky （从apiserver上获取当前所有的service的名称以及IP地址，并将数据持久化到etcd中）etcd skydns（定期访问etcd上的内容，修改自己dns服务器上的信息，注意这里的etcd和我们master上的etcd是不同的，）

Kuberetes架构及原理——运行机制

Kuberetes架构及原理——网络机制

首先看一下docker的网络：

默认情况下，docker会创建一个虚拟的网桥，所有的docker容器连接到这个网桥上，通过dhcp分配一个在同一个自网内的ip，这种情况下docker容器只能与 部署在同一台主机上的docker容器进行通信，无法做到跨主机的docker容器通信，而且从外部访问容器则需要，在主机上映射一个端口，多个容器映射同一个端口会导致主机端口冲突， 应设随机的端口又对管理带来很大的隐患

kubenetes的通信主要包括以下几个方面：

耦合度非常高的容器间的通信，通过pods的概念，将耦合度非常高的容器放在了同一个命名空间当中，可以通过localhost访问，pod间的通信是不需要net的，pod到service的通信通过kubeproxy实现的，kubeproxy通过APIserver得知指定的service下的几个pod其ip分别是多少。

支持：

容器间的通信

节点和容器间的相互通信

每个pod使用全局唯一的ip

openseich的方式：



docker网桥被一个linux网桥所代替，pod连接到子网桥上，同时创建一个ovs的网桥，并以一个端口的形式添加到docker使用的网桥上， 所有节点上的ovs之间，通过jretone进行连接，所以每个pods都会有自己唯一的ip，通过ip可以访问到其他节点上pods，在每一个工作节点上添加了路由的规则导向其他节点的子网，

高可用

保证每一个master加点的正常进行

系统监控程序确保kubenetes正常运行

etcd集群保证数据高可用和数据的备份

多个APIserver进行负载均衡

master选举确保kube-scheduler和kube-controlle-maanager高可用



多个master节点，里面的APIserver通过load balance实现高可用，每个节点上的etcd组成etcd集群，通过选举确保scheduler和controller manager，通过kubelet监控，kubelet通过monit（系统程序）来监控，来达到高可用