前言

🌲K8s架构设计 - 图1
Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统,所以整体的架构和borg很相似。Borg是谷歌内部的大规模集群管理系统,负责对谷歌内部很多核心服务的调度和管理。Borg的目的是让用户能够不必操心资源管理的问题,让他们专注于自己的核心业务,并且做到跨多个数据中心的资源利用率最大化。Borg主要由BorgMaster、Borglet、borgcfg和Scheduler组成,如下图所示:
🌲K8s架构设计 - 图2
其核心组件如下:

  • BorgMaster:整个集群的大脑,负责维护整个集群的状态,并将数据持久化到Paxos存储中。
  • Scheduer:负责任务的调度,根据应用的特点将其调度到具体的机器上去。
  • Borglet:负责真正运行任务(在容器中)。
  • borgcfg:Borg的命令行工具,用于跟Borg系统交互,一般通过一个配置文件来提交任务。

    K8s基础架构

    1. 概述

    Kubernetes是一个跨主机集群的开源的容器调度平台,它可以自动化应用容器的部署、扩展和操作 , 提供以容器为中心的基础架构。一个K8s集群包含两种类型的资源:

  • Kubernetes Master:负责管理整个集群,又称控制面板(Kubernetes Control Panel)。

  • Kubernetes NodeS:负责运行应用。

    2. 特点

    K8s具有如下特点:

  • 可移植:支持公有云、私有云、混合云、多重云(multi-cloud)。

  • 可扩展:模块化,、插件化,、可挂载,、可组合。
  • 自动化:自动部署、自动重启、自动复制、自动伸缩/扩展。

    3. 架构

    集群有Master和Node节点,架构如下:
    🌲K8s架构设计 - 图3

    4. 核心组件

    image.png
    Kubernetes主要由以下几个核心组件组成:

  • etcd:保存了整个集群的状态。

  • apiserver:提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制。
  • controller manager:负责维护集群的状态,比如故障检测、自动扩展、滚动更新等。
  • scheduler:负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上。
  • kubelet:负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理。
  • Container runtime:负责镜像管理以及Pod和容器的真正运行(CRI)。
  • kube-proxy:负责为Service提供cluster内部的服务发现和负载均衡。

除了核心组件,还有一些推荐的第三方组件/插件(Add-ons):

  • kube-dns:负责为整个集群提供DNS服务。集群中的所有实例都依赖集群DNS,因此所有Kubernetes集群都应具有DNS。
  • Ingress Controller:为服务提供外网入口。
  • Heapster:提供资源监控,将关于容器的一些常见的基于时间序列的度量值保存到一个集中的数据库中,并提供用于查询这些数据的接口。
  • Dashboard:Dashboard是Kubernetes集群通用的基于Web的UI。它可以使用户通过UI来管理集群及集群中运行的应用程序,并进行故障排除。
  • Federation:联邦集群,实现单一集群统一管理多个Kubernetes集群的机制,这些集群可能是跨地区(Region),也可能是在不同公有云供应商(Cloud Provider)上,或者是公司内部自行建立的集群。
  • Fluentd-elasticsearch:提供集群日志采集、存储与查询,负责将容器的日志数据保存到一个集中的日志存储中,并提供搜索和浏览功能。
  • Promethues:监控告警工具。与Kubernetes结合可以对整个Kubernetes集群进行监控。自Heapster被废弃以后,所有的指标数据都从API接口中获取,Kubernetes又将资源指标分为了两种:

    • Core metrics(核心指标):由metrics-server提供API metrics.k8s.io,仅提供Node和Pod的CPU和内存使用情况。
    • Custom Metrics(自定义指标):由Prometheus Adapter提供API custom.metrics.k8s.io,由此可支持任意Prometheus采集到的指标。

      5. 组件关系

  • 所有组件均是通过API Server进行通信,所以API Server就是一个中枢神经,在生产中我们会把master部署为多节点,做高可用。

  • etcd主要是存储集群里的信息,比如集群状态,集群的各Node信息等,只有API能与其通信,所以我们也会把etcd做高可用,etcd是一个单独的组件,一个应用软件,做高可用建议是奇数节点,比如3,5等,节点不应过多,因为节点过多,节点之间的数据同步是会有一定的开销,影响集群的性能。
  • Schduler负责整个集群的调度,它通过API Server来检测Node上Pod的状态,然后会根据定义的策略来调度pod并绑定Node。
  • Controller manager负责pod的控制,常见的比如定义了一个Pod为replicaSet,然后因为某些原因当前pod挂掉了,这时候Controller manager就会为你在Node上重启该Pod。
  • kubelet是Node上的组件,它会检测Node上的Pod,并将其状态更新到API Server。
  • kube-proxy主要是负责代理转发,主要控制service,并将sevice状态更新到API Server。
  • kubectl是集群的管理组件,主要也是调用API Server,然后进行整个集群的管理。

    K8s详细架构

    image.png

    1. 结构图

    image.png

    2. 分层架构图

    image.png

    3. 网络拓扑图

    image.png

    K8s工作原理

    image.png
    Pod创建过程:
  1. 用户提交创建Pod的请求,可以通过API Server的REST API ,也可用Kubectl命令行工具,支持Json和Yaml两种格式。
  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内的容器。

image.png
在这期间,Control Manager同时会根据kubernetes的mainfiles文件执行rc pod的数量来保证指定的pod副本数。而其他的组件,比如scheduler负责pod绑定的调度,从而完成整个pod的创建。

K8s设计理念

分析和理解Kubernetes的设计理念可以使我们更深入地了解Kubernetes系统,更好地利用它管理分布式部署的云原生应用,另一方面也可以让我们借鉴其在分布式系统设计方面的经验。

K8s API设计理念

对于云计算系统,系统API实际上处于系统设计的统领地位,正如本文前面所说,K8s集群系统每支持一项新功能,引入一项新技术,一定会新引入对应的API对象,支持对该功能的管理操作,理解掌握的API,就好比抓住了K8s系统的牛鼻子。
🌲K8s架构设计 - 图11

K8s Controller设计理念

🌲K8s架构设计 - 图12

K8s组件简介

🌲K8s架构设计 - 图13

1. Kubernetes Control Panel

控制面板组件对集群做出全局决策(比如调度),以及检测和响应集群事件(例如,当不满足部署的replicas要求时,启动新的Pod)。控制面板组件可以在集群中的任何节点上运行。

■ etcd

所有master的持续状态都存在etcd的一个实例中。这可以很好地存储配置数据。因为有watch(观察者)的支持,各部件协调中的改变可以很快被察觉。

■ API Server

主节点上负责提供Kubernetes API服务的组件,它是Kubernetes控制面板的前端。它提供了操作所有资源/服务的入口,并提供认证、授权、访问控制、API注册和发现等机制。kube-api-server在设计上也考虑到了水平扩展的需要。

■ Controller manager

从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。负责维护集群的状态,比如故障检测、自动扩展、滚动更新等。

■ Scheduler

该组件主要监视那些新创建的未指定运行节点的Pod,按照预定的调度策略将Pod调度到相应的机器上并运行。(接受任务,并选择合适的节点分配任务)

2. Kubernetes Nodes

🌲K8s架构设计 - 图14
Kubernetes Node节点有运行应用容器必备的服务,而这些都是受Master的控制。每个节点上都要运行Docker,负责所有具体的映像下载和容器运行。Node节点**维护运行的Pod并提供Kubernetes运行环境。Node说是「硬件」,其实也可以是虚拟机、云主机。**

■ kubelet

在集群中每个节点上运行的Agent,用于和Master通信,和容器交互并负责维护容器的生命周期,同时也负责Volume和网络的管理。

■ kube-proxy

kube-proxy是集群中每个节点上运行的网络代理,它主要负责为Service提供Cluster内部的服务发现和负载均衡。Service是一组Pod的服务抽象,负责将请求分发给对应的Pod,相当于一组Pod的Load Balancer。Service会为这个LB提供IP称为Cluster IP。而kube-proxy的作用主要是负责Service的实现,具体来说,就是实现内部从Pod到Service以及外部的从Node port到Service的访问。

■ Container runtime

负责镜像管理以及Pod和容器的真正运行(CRI)。
🌲K8s架构设计 - 图15

参考

51CTO博客:浅谈kubernetes:k8s的部署架构以及工作原理
https://blog.51cto.com/blief/2386811
K8s中文文档:Kubernetes架构
http://docs.kubernetes.org.cn/251.html
K8s中文文档:Kubernetes设计理念
http://docs.kubernetes.org.cn/249.html