Kubernetes架构设计与组件

Kubernetes简述

简介:

  • 一套容器集群管理系统
  • 一个开源平台
  • 实现容器集群的自动化部署、自动扩缩容、维护等功能

两个核心角色:

  • Master:Master管理Node
  • Node:Node管理容器

Master

主要负责整个集群的管理控制。
通常Master会占用一台独立的服务器,基于高可用原因,也有可能是多台。

组成:

  • kube-apiserver
  • etcd
  • kube-scheduler
  • kube-controller-manager

kube-apiserver

为Kubernetes中各类资源对象提供了增删改查等HTTP REST接口。
于资源的任何操作,都需要经过API Server进程来处理。

访问API Server进程的3种方式:

  • REST Request的方式
  • 官方提供的客户端
  • 命令行工具kubectl

etcd

Kubernetes的“数据库”。
一种轻量级的分布式键值存储。
可以在单台Master服务器上配置,也可以配置到多台服务器。
保存集群中所有的配置和各个对象的状态信息

只有API Server进程才能直接访问和操作etcd。

kube-scheduler

kube-scheduler是Pod资源的调度器。
监听最近创建但还未分配Node的Pod资源,会为Pod自动分配相应的Node。

一个实例的运作原理:

  1. 通过API Server进程的Watch接口监听新建的Pod。
  2. 搜索所有满足Pod需求的Node列表。
  3. 执行Pod调度逻辑。
  4. 会将Pod绑定到目标Node上。

Pod:Kubernetes的最小可操作单元,一个Pod包含一个或多个容器。

kube-controller-manager

大部分功能是由控制器执行的。
为了方便使用和学习,控制器由多个功能模块组合到一起,合成一个进程。
这些功能模块原本应该是各个独立的进程。

功能模块:

  • Node控制器:Node出现故障时做出响应
  • Replication控制器:对系统中的每个ReplicationController对象维护正确数量的Pod
  • Endpoint控制器:生成和维护所有Endpoint对象的控制器
  • ServiceAccount及Token控制器:为新的命名空间创建默认账户和API访问令牌

Endpoint:用于监听Service和对应的Pod副本的变化。

kube-controller-manager所执行的各项操作也是基于API Server进程。

Node

Kubernetes集群中的各个工作节点。
Node由Master管理,提供运行容器所需的各种环境,对容器进行实际的控制,而这些容器会提供实际的应用服务。

组成:

  • kubelet
  • kube-proxy
  • 容器运行时

kubelet

每个Node上都运行的主要代理进程。
kubelet负责维护容器的生命周期。
也负责存储卷(volume)等资源的管理。
以PodSpec为单位来运行任务。
kubelet会定期向API Server进程报告自身状态,API Server进程将状态更新到etcd中。

PodSpec是一种描述Pod的YAML或JSON对象。

不是Kubernetes创建的容器将不属于kubelet的管理范围。

kube-proxy

主要用于管理Service的访问入口。

  1. 集群内的其他Pod到Service的访问。
  2. 从集群外访问Service。

容器运行时

负责运行容器的软件。

Kubernetes支持多种运行时,例如:

  • Docker
  • containerd
  • cri-o(Podman 原来是 CRI-O 项目的一部分)
  • rktlet

任何基于Kubernetes CRI(容器运行时接口)的实现都支持

Pod创建时各组件协作流程

  1. 使用kubectl创建Pod。
  2. kubectl命令将转换为对API Server的调用。
  3. API Server验证请求并将其保存到etcd中。
  4. etcd通知API Server新Pod产生。
  5. API Server调用调度器。
  6. 调度器决定在哪个节点运行Pod,并将其返回给API Server。
  7. API Server将对应节点保存到etcd中。
  8. etcd通知API Server。
  9. API Server在相应的节点中调用kubelet。
  10. kubelet与容器运行时API发生交互,与容器守护进程通信以创建容器。
  11. kubelet将Pod状态更新到API Server中。
  12. API Server把最新的状态保存到etcd中。

Kubernetes的核心对象

虽然底层为容器。
为了屏蔽底层的技术细节,
Kubernetes抽象出各种对象实例(概念),
用户操作对象实例,便可以操控容器。

Pod

Kubernetes处理的最基本单元。
容器本身并不会直接分配到主机上,而是会封装到名为Pod的对象中。

特性:

  • 一个Pod代表单个应用程序。
  • 一个Pod由一个或多个关系紧密的容器构成。
  • 一个Pod中的容器拥有同样的生命周期。
  • 一个Pod中的容器作为一个整体一起编排到Node上。
  • 一个Pod中的容器共享环境、存储卷和IP空间。

注意:用户不应自行管理Pod,因为Pod并没有提供应用程序通常会用到的一些特性,如复杂的生命周期管理及动态伸缩。

控制器

Pod由控制器来管理。
在控制器中定义Pod的部署方式(如有多少个副本、需要在哪种Node上运行等)。

根据不同的业务场景,Kubernetes提供了多种控制器:

  • ReplicationController和ReplicaSet控制器
  • Deployment控制器
  • StatefulSet控制器
  • DaemonSet控制器
  • Job控制器和CronJob控制器

ReplicationController和ReplicaSet控制器

ReplicationController和ReplicaSet控制器功能类似。

相同功能:

  • 定义Pod模板
  • 保证在集群中部署的Pod数量与配置中的Pod数量一致。

ReplicationController更多的功能:

  • 执行滚动更新,将一组Pod逐个切换到最新版本。

ReplicaSet更多的功能:

  • Pod识别功能。
  • 副本筛选功能。

都没有的功能:

  • 更细粒度的生命周期管理功能。

Deployment控制器

基于ReplicaSet控制器。
有部分功能和ReplicationController相似。
最常用的工作负载对象之一。

优势:

  • 增加了更灵活的生命周期管理功能。
  • 管理应用程序不同版本之间的切换。
  • 自动维护事件历史记录及自动撤销功能。

Deployment控制器可能是使用频率最高的对象。

StatefulSet控制器

提供了排序和唯一性保证的特殊Pod控制器。
部署顺序、持久数据或固定网络等相关的特殊需求时使用。

可以通过Pod转移持久性数据卷。即使删除了Pod,这些卷也依然存在,以防止数据意外丢失。

虽然各个Pod的定义是一样的,但是因为其数据的不同,所以提供的服务是有差异的。

  • 分布式存储系统。
  • 服务端会话,不同会话的Pod提供的服务也不尽相同。

主要用于有状态的应用(例如,数据库)。

DaemonSet控制器

在集群的各个节点上运行单一的Pod副本。
非常适合部署那些为节点本身提供服务或执行维护的Pod。

  • 日志收集和转发、监控
  • 运行以增加节点本身功能为目的的服务

用于提供基本服务的,并且每个节点都需要。

可以绕过某些用于阻止控制器将Pod分配给某些主机的调度限制。
例如:原本Master服务器不可用于常规的Pod调度,但DaemonSet控制器可以越过基于Pod的限制,确保基础服务的运行。

Job控制器和CronJob控制器

Job控制器:

  • 基于特定任务而运行。
  • 运行任务的容器完成工作后,Job就会成功退出。
  • 适合执行一次性的任务。

CronJob控制器:

  • 在Job控制器的基础上增加了时间调度。
  • 在给定的时间点运行一个任务。
  • 也可以周期性地在给定时间点运行一个任务。

服务与存储

Service组件和Ingress

Service组件:

  • 内部负载均衡器中的一种组件。
  • 将相同功能的Pod在逻辑上组合到一起,让它们表现得如同一个单一的实体。
  • 通过Service组件可以发布服务。
  • 跟踪并路由到所有指定类型的后端容器。

    当需要给另一个应用程序或外部用户提供某些Pod的访问权限时,就可以配置一个Service组件。

Ingress:

  • 通过Ingress来整合Service组件。
  • 充当多个Service组件的统一入口。
  • 支持将路由规则合并到单个资源中。

    通过同一域名或IP地址下不同的路径来访问不同的Service组件。

存储卷和持久存储卷

存储卷(volume):

  • 允许Pod中的所有容器共享数据。
  • 在Pod终止之前一直保持可用。
  • Pod中的容器故障不会影响对共享文件的访问。
  • Pod终止后,共享的存储卷会被销毁。

持久存储卷(persistent volume):

  • 允许管理员为集群配置存储资源。
  • 用户可以为正在运行的Pod请求和声明存储资源。
  • 可预防节点级的故障。
  • 分配比本地更多的可用存储空间。

持久存储卷的Pod一旦使用完毕,存储卷的回收策略将决定是保留存储卷(直到手动删除),还是立即删除数据。

资源划分

命名空间

对Kubernetes集群资源进行划分。
实现多租户的资源隔离。

逻辑划分

标签和注解

标签(label):一种语义化标记。

附加到Kubernetes对象上,对它们进行标记或划分。
针对不同的实例进行管理或路由,可以用标签来进行选择。
每种基于控制器的对象都可以使用标签来识别需要操作的Pod。
Service组件也可以使用标签来确定应该将请求路由到哪些后端Pod。

每个单元可以拥有多个标签。
每个单元对于每个键只能拥有一个值。

键值对形式。标签的使用更像是对资源进行划分细类。

注解(annotation)也是一种类似的机制。

将任意键值信息附加到某一对象中。
可以包含少量结构化数据。

向对象添加更多元数据的一种方式,但并不用于筛选。

你可能感兴趣的:(kubernetes,kubernetes)