• 微信公众号:美女很有趣。 工作之余,放松一下,关注即送10G+美女照片!

kubernetes、docker原理分析

互联网 diligentman 2周前 (04-07) 7次浏览

一、背景

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

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

kubernetes、docker原理分析

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

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

kubernetes、docker原理分析

二、Docker生命周期

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

特性

虚拟机

容器

启动

分钟级

秒级

硬盘使用

GB级别

Mb级别

性能

若于原生

接近原生

系统支持量

一般几十个

单机支持几千个

1、docker的生命周期 

kubernetes、docker原理分析

主要流程如下:

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

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

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

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

三、kubernetes

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

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

kubernetes、docker原理分析

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内的容器;

kubernetes、docker原理分析

 

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才支持。

用户访问具体应用流程

 

kubernetes、docker原理分析

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

a、LoadBalancer

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

b、Ingress

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


程序员灯塔
转载请注明原文链接:kubernetes、docker原理分析
喜欢 (0)