• Kubernetes入门之系统架构


    目录

    目录 1

    1. 前言 1

    2. 系统架构 2

    2.1. 主从架构 2

    2.2. 基本概念 3

    2.3. 主控节点(Master Node 4

    2.3.1. kube-apiserver 4

    2.3.2. kube-controller-manager 4

    2.3.3. kube-scheduler 4

    2.3.4. cloud-controller-manager 5

    2.4. 工作节点(Work Node 5

    2.4.1. Kubelet 5

    2.4.2. kube-proxy 5

    2.4.3. Container Runtime 5

    2.5. 扩展插件(Addons 5

    2.5.1. DNS 5

    2.5.2. Web UI (Dashboard) 6

    2.5.3. Container Resource Monitoring 6

    2.5.4. Cluster-level Logging 6

    1. 前言

    Kubernetes简称k8s(也缩写为kube),一个开源的用于自动化部署容器化(主要针对Docker,其它如katacontainersrkt也支持)应用程序系统,通过分组容器(容器组被命名为PodPod也是Kubernetes的最小调度单元)来调度和管理容器,官方网站:https://kubernetes.io/,本文大量参考了官方的https://kubernetes.io/docs/concepts/https://kubernetes.io/zh/(官方中文)等。

    如何快速认识和上手Kubernetes?可从三方面入手,一是了解Kubernetes系统架构,二是了解Kubernetes涉及的主要概念,三是动手安装运行初体验。

    2. 系统架构

    2.1. 主从架构

    Kubernetes采用的是常见的主从架构(master-slave),注意这里的Slave并不是Master的复制节点,而是工作节点Work Node)。

    Kubernetes官方把Slave节点直接叫节点(Node),本文把它叫作工作节点Work Node),以从名称上更好的区分于主控节点(Master Node)。其中Master为单个节点,而Slave则多节点;Master负责管理、调度和监控,Slave负责执行。

    Master由三部分组成:kube-apiserverkube-controller-managerkube-schedulercloud-controller-manager,每一成员均为一独立进程,Master依赖Etcd存储各状态数据;Slave由两部分组成:kubeletkube-proxyContainer Runtime,每一成员也均为一独立进程。

     

     

    下为Kubernetes官方提供的架构图(cloud-controller manager还非正式发布):

     

    2.2. 基本概念

    前言部分已介绍PodKubernetes的最小调度单元,而不是容器ContainerPod、容器(Container)和节点(Node,这里特指工作节点)三者密切相关,可理解为一种包含关系,如下图所示:

     

    如果把Pod视作进程组,则Container可视为进程(实际上,一个容器内还可有多个物理进程)。一个Pod内可有多个容器,一个节点可有多个PodKubernetes的最基本作用就是通过Pod来管理容器,包括分配运行容器的工作节点(Work Node)和容器的启停等。因为PodKubernetes的最小调度单元,所以实际直接操作的是Pod

    Pod类似进程,是临时性的,有五种状态

    Pending

    待运行

    Kubernetes已接受Pod,但一或多个容器映射还没被创建,可能是调度正在下载容器映射等

    Running

    运行中

    Pod已被调度到工作节点,所有的容器也已创建好,至少一个容器正在运行或正在(重)启动中。

    Succeeded

    运行成功(结束)

    Pod中的所有容器都运行结束,并且全部运行成功,而且不会重启

    Failed

    运行失败(结束)

    Pod中的所有容器都运行结束,但至少有一个运行失败(容器退出状态非0)

    Unknown

    未知

    通常是因为无法和Pod所在节点通信,导致无法获取Pod状态

    2.3. 主控节点(Master Node

    2.3.1. kube-apiserver

    Kubernetes的对外窗口,是Kubernetes的控制面(control plane),操控Kubernetes需经过kube-apiserver。有两种操作Kubernetes方法:一是使用Kubernetes提供的命令行工具kube-apiserver,二是使用Kubernetes提供的APIkube-apiserver是无状态的且没有单点问题,所以没有主备之分。

    2.3.2. kube-controller-manager

    Kubernetes控制管理器是Kubernetes的大脑,通过kube-apiserver管理和监控Kubernetes的各种资源,由几大管理控制器组成:

    Node Controller

    节点控制器

    负责在节点出现故障时进行通知和响应

    Replication Controller

    副本控制器

    负责为系统中的每个副本控制器对象维护正确数量的Pod

    Endpoints Controller

    端点控制器

    填充Endpoints对象(即,加入Services&Pods)

    Service Account & Token Controllers

    服务帐户和访问令牌控制器

    为新Namespace创建默认帐户和API访问令牌

    kube-controller-manager有单点,所以有主备kube-controller-manager,通过选举的方式产生主kube-controller-manager

    2.3.3. kube-scheduler

    调度器监视新创建的未分配工作节点的Pod,将Pod调度到(分配)最佳的工作节点。Kubernetes支持自定义调度器,来取代默认的kube-scheduler调度器。

    如果调度器不能为Pod找到合适的工作节点,则Pod保持未调度状态,直到被调度分配工作节点。

    kube-scheduler通过两步操作为Pod选择一个工作节点:

    操作

    说明

    1

    Filtering

    过滤出合适的工作节点,如果没有过滤出任何工作节点,则Pod保持为未调度状态

    2

    Scoring

    对工作节点打分,选择分数最高的,分数相同的随机选择

    kube-scheduler有单点,所以有主备kube-scheduler,通过选举的方式产生主kube-scheduler

    2.3.4. cloud-controller-manager

    云控制管理器运行与底层云提供商(如AWS)交互的控制器,也由四大管理控制器组成:

    Node Controller

    节点控制器

    用于检查云提供程序,以确定节点停止响应后是否已将其删除到云中

    Route Controller

    路由控制器

    用于在基础云基础架构中设置路由

    Service Controller

    服务控制器

    用于创建、更新和删除云提供商负载平衡器

    Volume Controller

    控制器

    用于创建、附加和安装卷以及与云提供商交互以编排卷

    2.4. 工作节点(Work Node

    2.4.1. Kubelet

    运行在每个工作节点上的系统代理(Agent),确保容器运行在Pod中,Kubelet确保PodSpec描述的容器运行正常。Kubelet只管理Kubernetes所创建的容器,而不管理其它非Kubernetes创建的容器。

    2.4.2. kube-proxy

    运行在每个工作节点上的网络代理(Proxy),实现了Kubernetes Service概念的部分。kube-proxy维护工作节点上的网络规则,这些规则允许Kubernetes集群内外部与Pod进行网络通讯。如果系统的数据包过滤层可用,则kube-proxy使用它,否则kube-proxy自己转发流量。

    2.4.3. Container Runtime

    Kubernetes支持除Docker外的多种容器,运行具体的容器是通过容器运行时完成的。Kubernetes支持:Dockercontainerdcri-orktletFrakti和实现Kubernetes CRI(容器运行时接口,Container Runtime Interface)的任何容器。

    2.5. 扩展插件(Addons

    扩展插件使用Kubernetes资源实现集群特性,因为它们提供了群集级功能,所以插件的命名空间资源属于kube-system命名空间,下列是部分可选的插件。

    2.5.1. DNS

    DNS外的其它的扩展插件不是必须的,但应有集群级的DNS服务器。由Kubernetes启动的容器,会在其DNS搜索中自动包括此DNS服务器。

    2.5.2. Web UI (Dashboard)

    仪表板DashboardKubernetes集群的通用基于WebUI,它允许用户管理集群中运行的应用程序以及集群本身并进行故障排除。

    2.5.3. Container Resource Monitoring

    容器资源监视在中央数据库中记录有关容器的一般时间序指标,并提供用于浏览该数据的UI。

    2.5.4. Cluster-level Logging

    集群级日志记录,负责通过搜索/浏览接口将容器日志保存到中央日志存储中。

  • 相关阅读:
    OO第四单元作业总结暨完结撒花
    OO第三单元作业总结【自我审判】
    菜鸡学C语言之知识点简单整理
    菜鸡学C语言之混凝土(四柱汉诺塔)
    OO第二单元作业总结【自我反思与审视】
    菜鸡学C语言之寻根溯源
    菜鸡学C语言之真心话大冒险
    菜鸡学C语言之摸鱼村村长
    OO面向对象第一单元总结
    day10 python全栈学习笔记
  • 原文地址:https://www.cnblogs.com/aquester/p/12316158.html
Copyright © 2020-2023  润新知