服务的分类
有状态
- 代表应用
- nginx
- apache
- 优点
- 对客户端透明,无依赖关系,可以高效实现扩容,迁移
- 缺点
- 不能存储数据,需要额外的数据服务支撑
无状态
- 代表应用
- MYSQL
- Redis
- 优点
- 可以独立存储数据,实现数据管理
- 缺点
- 集群环境下需要实现主从,数据同步,备份,水平扩容负载。
资源和对象
资源等于类,对象等于通过类创建出来的对象
kubernetes中的所有内容都被抽象为“资源”,如pod,service,node等都是资源。
“对象”就是“资源”的实例,是持久化的实体。如某个具体的pod,某个具体的node。kubernetes使用这些实体去表示整个集群的状态。
对象的创建,删除,修改都是通过kubernetes的API接口实现的。这些是“restful”风格的api,与k8s的万物皆对象的思想对应。命令行工具“kubectl”,实际上也是调用kubernetes的api接口。
k8s中资源的类型有很多种,kubectl可以通过配置文件来创建。这些“对象”,配置文件更像是描述对象“属性”的文件,配置文件格式可以是“json”或“yaml”,常用“yaml”。
对象规约和状态
规约
规约(spec),规格的意思,spec是必需的,它描述了对象的期望状态(Desired State) —— 希望对象所具有的特征,当创建对象时,必须提供对象的规约,用来描述该对象的期望状态,以及关于对象的一些基本信息。
状态
表示对象的实际状态,该属性由k8s自己维护,k8s会通过一系列的控制器对应对象进行管理,尽可能的将对象的实际状态与期望状态重合。
资源和对象
元数据
对于资源的元数据描述,每一个资源都可以使用源空间的数据
-
Horizontal Pod Autoscaler(HPA)
pod自动扩容,可以根据cpu使用率或自定义指标(metrics)自动对pod进行扩/缩容
控制器每30s(可以通过horizontal pod autoscaler sync period修改),查询metrics的资源使用情况
支持三种metrics类型
- 预定义metrics(比如pod的cpu)以利用率的方式计算
- 自定义的pod metrics 以原始值的方式计算
- 自定义的object metrics
支持两种metrics查询方式,heapster和自定义的rest api
支持多metrics
使用场景类似于京东十点秒杀抢苹果20,这个时候就需要加服务器 -
PodTemplate
PodTemplate是关于pod的定义,但是被包含在其他的kubernetes对象中(例如,Deployment,StatefulSet,Job等控制器)。控制器通过PodTemplate的信息来创建pod。
-
LimitRange
可以对集群内的Request和Limit的配置做一个全国的同意的限制,相当于批量设置了某一个范围内(某个命名空间)的pod的资源使用限制
集群级
集群级别的资源,作用在集群之上,集群下的所有资源都可以共享使用
- Namespace
命名空间本身就属于集群级别的资源,用来隔离集群内的资源,每个命名空间都有自己的资源配额,资源配额可以设置在命名空间级别,也可以设置在集群级别。
- Node
节点相当于一台服务器的概念,不同于其他的资源(pod和namespace),node的本质上不是kubernetes来创建的,kubernetes只是管理node上的资源,虽然可以通过manifest创建一个node对象(如json所示),但是kubernetes也只是去检查是否真有该node的存在,如果检查失败,也并不会去往上调度pod。
- ClusterRole
声明资源
ClusterRole和Role的区别在于,ClusterRole是集群级别的,而Role是命名空间级别的。 - ClusterRoleBinding
上面只是声明资源,这个是用来进行绑定。(只能绑定集群级别的资源)
命名空间
命名空间级别的资源,作用在命名空间之上,通常只能在该命名空间范围内使用
工作负载型
pod
![img](/i/l/?n=23&i=blog/3303148/202405/3303148-20240505201334362-730976802.png)
> 简单理解为容器组
> pod(容器组)是kubernetes中最小的可部署单元,一个pod(容器组)包含了一个应用程序容器(某些情况下是多个容器,存储资源。一个唯一的网络ip地址,以及一些确定容器该如何运行的选项,pod容器组代表了kubernetes中一个独立的应用程序运行实例,该实例可能由单个的容器或者几个紧耦合在一起的容器组成)
docker 是 kubernetes pod 中使用最广泛的容器引擎;kubernetes pod 同时也支持其他类型的容器引擎。
kubernetes集群中的pod存在如下两种使用途径:
> 1. 一个pod中值运行一个容器。这种是kubernetes最常用的方式。此时,我们可以认为pod容器组是该容器的wapper。kubernetes通过pod管理容器而不是直接管理容器。
> 2. 一个pod中运行多个需要互相协作的容器。可以想多个紧密耦合,共享资源且始终在一起运行的容器编排在同一个pod中。
副本(replicas)
副本的概念: 一个pod可以被复制成多份,每一份可以被称之为一个副本。这些副本除了一些描述性信息(pod的名字,uid等)不一样之外,其他的信息都是一样的,譬如pod内部的容器,容器数量,容器里面运行的应用等,这些信息都是一样的,这些副本提供同样的功能。
pod的“控制器”通常包含一个名为“replicas”的属性。该属性则指定了特定pod的副本数量。当当前集群中该pod的数量与该属性指定的值不一致时,k8s会猜去一些策略去使得当前状态满足配置的要求。
控制器
- 控制器的类型
适用于无状态服务
- ReplicationController(RC):帮助我们动态更新pod的副本数,也就是说实现扩容和缩容的效果(在1.11版本被弃用)
- ReplicaSet(RS):帮助我们动态更新pod的副本数,与RC类似,但是RS可以通过selector和label来选择对哪些pod生效(RS只有扩容和缩容)
- Deployment
是针对RS的更高层次的封层。
- 可以创建ReplicaSet,然后通过RS创建pod。
- 可以滚动升级和回滚pod
3.平滑扩容和缩容- 暂停和恢复
适用于有状态服务StatefulSet
主要特点:
- 稳定的持久化存储
- 稳定的网络标识符
- 有序部署,有序扩展
- 有序收缩,有序删除
组成:- Headless Service
用于定义网络标志(DNS domain,域名服务,将域名与ip绑定映射关系)- VolumeClaimTemplate
用于创建持久化卷的模板
守护进程
DaemonSet
DaemonSet是保证在每个node上都运行的一个容器副本,常用来部署一些集群的日志,监控或者其他系统管理应用。典型的应用包括(日志收集,系统监控,系统程序)
类似于:为每一个匹配的node都部署一个守护进程
任务/定时任务
- Job
- 一次性任务,运行完pod销毁,不再重新启动新容器
- CronJob
- 是在job基础上加上了定时功能
服务发现
service
pod不能直接提供给外网访问,而是应该使用service,service就是吧pod暴露出来提供服务,service才是真正的服务,它的中文名就叫‘服务’。可以说service是一个应用服务的抽象,定义了pod逻辑集合和访问这个pod集合的策略。service代理pod集合,对外表现为一个访问入口,访问该入口的请求将进过负载均衡,转发到后端的容器中。
ingress
实现将k8s内部服务暴露给外网访问的服务
配置与存储
Volume
数据卷,共享pod中容器使用的数据。用来放持久化的数据,比如数据库数据。(Volume ClaimTemplate 就是申请Volume。
CSI
标准接口之一,旨在将任意存储系统暴露给容器化应用程序。
csi规范定义了存储提供商实现csi兼容的Volume Plugin的最小操作集和部署建议。csi规范的主要焦点是声明volume plugin 必须实现的接口。
特殊类型配置
ConfigMap
- 键值对类型的配置
Secret
- 键值对类型的配置,同ConfigMap类似,但Secret中的数据会加密存储
DownwardAPI
提供了两种方式用于将pod的信息直接注入容器内部
- 环境变量
- 用于单个变量,可以将pod信息直接注入容器内部
- volume挂载
- 将pod信息生成文件,直接挂载到容器内部中。
Role
role是一组权限的集合。例如,role可以包含列出pod权限及列出Deployment权限。role用于给某个命名空间中的资源进行鉴权
RoleBinding
标签:容器,kubernetes,对象,核心,概念,集群,pod,k8s,资源 From: https://www.cnblogs.com/humlogs/p/18173561绑定role,将role绑定到某个用户或者组上。(可以绑定role,也可以绑定clusterRole,他只是决定绑定到哪里去,rolebinding绑定到某个命名空间,clusterrolebinding绑定到整个集群)