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。
一个实例的运作原理:
- 通过API Server进程的Watch接口监听新建的Pod。
- 搜索所有满足Pod需求的Node列表。
- 执行Pod调度逻辑。
- 会将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的访问入口。
- 集群内的其他Pod到Service的访问。
- 从集群外访问Service。
容器运行时
负责运行容器的软件。
Kubernetes支持多种运行时,例如:
- Docker
- containerd
- cri-o(Podman 原来是 CRI-O 项目的一部分)
- rktlet
任何基于Kubernetes CRI(容器运行时接口)的实现都支持
Pod创建时各组件协作流程
- 使用kubectl创建Pod。
- kubectl命令将转换为对API Server的调用。
- API Server验证请求并将其保存到etcd中。
- etcd通知API Server新Pod产生。
- API Server调用调度器。
- 调度器决定在哪个节点运行Pod,并将其返回给API Server。
- API Server将对应节点保存到etcd中。
- etcd通知API Server。
- API Server在相应的节点中调用kubelet。
- kubelet与容器运行时API发生交互,与容器守护进程通信以创建容器。
- kubelet将Pod状态更新到API Server中。
- 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)也是一种类似的机制。
将任意键值信息附加到某一对象中。
可以包含少量结构化数据。文章来源:https://www.toymoban.com/news/detail-480562.html
向对象添加更多元数据的一种方式,但并不用于筛选。文章来源地址https://www.toymoban.com/news/detail-480562.html
到了这里,关于Kubernetes架构设计与组件的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!