kubernetes、docker原理分析

一、背景

随着分布式应用的崛起，单台应用服务器很难支撑起业务，真实场景中往往一个应用要部署多次来解决高并发的问题。相信很多人对虚拟机都不陌生，

最早的做法就是通过在物理机上创建多个虚拟机（程序运行空间），虚拟机再运行相关应用。

这种做法可以在同一台机器上启动多个应用实例，但每个虚拟机都创建都会将计算机结构一起打包，对于用户来说创建、维护成本也太高了，每个虚拟机都会有操作系统、虚拟硬件也显得这种方式比较重。那有没有更轻的方式呢，答案是有的。

Docker技术就横空出世了，Docker相比与虚拟机的主要优势就是在于它轻，轻在哪些方面呢？它是直接运行在操作系统层面的，共享物理机的操作系统和硬件，用户创建只需关注docker内的应用程序和文件依赖库。

二、Docker生命周期

介绍完虚拟机和Docker，有的小伙伴可能还不太熟悉他们之前的优缺点

1、docker的生命周期?

主要流程如下：

1、client发送命令到docker host被deamon进程所监控。

2、deamon根据命令执行相关操作，如pull操作，会检测本地是否有相关镜像、容器。

3、如本地未有则去registey仓库里获取相关镜像。

4、最后把相关镜像、容器返回给client，client完成镜像、容器的启动。

三、kubernetes

对于多个容器，如果采用人为的方式去管理显然是不科学的，此时就急于需要一款能代替人为去管理这些容器的工具，此时k8s就出现了。

k8s是一个开源平台，能够有效简化应用管理、应用部署和应用扩展环节的手动操作流程，让用户更加灵活地部署管理云端应用。架构如下：

1、kubernetes Master

? ? ?Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master 运行 Linux 操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master，主从架构。

（1）Etcd：保存了整个集群的状态（存储状态数据库，存储pod、service、rc等信息），只为ApiServer提供操作、访问权限；

（2）Apiserver：提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；

（3）Controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

（4）Scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；

2、kubernetes Note

? ? ?Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux 操作系统，可以是物理机或者是虚拟机。

（1）kubelet：负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；

（2）kube-proxy：负责为Service提供集群内部的服务发现和负载均衡；

（3）pod：K8S管理的最小单位级，它是一个或多个容器的组合。在Pod中，所有容器都被同一安排和调度，并运行在共享的上下文中。对于具体应用而言，Pod是它们的逻辑主机，Pod包含业务相关的多个应用容器。

3、创建pod流程

（1）用户提交创建Pod的请求，可以通过API Server的REST API ，也可用Kubectl命令行工具；

（2）API Server处理用户请求，存储Pod数据到etcd；

（3）Schedule通过和API Server的watch机制，查看到新的Pod，尝试为Pod绑定Node；

（4）过滤主机：调度器用一组规则过滤掉不符合要求的主机，比如Pod指定了所需要的资源，那么就要过滤掉资源不够的主机；

（5）主机打分：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等；

（6）选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中；

（7）Kubelet根据调度结果执行Pod创建操作： 绑定成功后，会启动container，docker run，scheduler会调用API在数据库etcd中创建一个bound pod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的Kubelet也会定期与etcd同步bound pod信息，一旦发现应该在该工作节点上运行的bound pod对象没有更新，则调用Docker API创建并启动pod内的容器；

?

4、用户请求过程

在Kubernetes平台上，Pod是有生命周期，为了可以给客户端一个固定的访问端点，因此需要在客户端和Pod之间添加一个中间层，这个中间层称之为Service。

kube-proxy通过kubernetes中固有的watch请求方法持续监听apiserver。一旦有service资源发生变动(增删改查)kube-proxy可以及时转化为能够调度到后端Pod节点上的规则，这个规则可以是iptables也可以是ipvs，取决于service实现方式。

service有如下四种实现：

（1）ClusterIp

默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP

（2）NodePort

在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过: NodePort来访问该服务。

（3） LoadBalancer

在NodePort的基础上，借助Cloud Provider创建一个外部负载均衡器，并将请求转发到NodePort
（4）ExternalName

把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的kube-dns才支持。

用户访问具体应用流程

?

如上图是通过NotePort方式供外部调用，此方案不能对请求进行过滤、负载均衡，此时可以引入请求转发组件，如Ingress或LoadBalancer

a、LoadBalancer

服务是暴露服务到 Internet 的标准方式。所有通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎可以发送任何种类的流量到该服务，像 HTTP，TCP，UDP，WebSocket，gRPC 或其它任意种类。

b、Ingress

可以给 Service 提供集群外部访问的 URL、负载均衡、SSL 终止、HTTP 路由等。为了配置这些 Ingress 规则，集群管理员需要部署一个 Ingress Controller，它监听 Ingress 和 Service 的变化，并根据规则配置负载均衡并提供访问入口。