基本概念
Master
kube-apisever
接口服务,基于REST风格开放的k8s接口的服务
kube-controller-manager
控制器管理器kube-controller-manager 是控制平面的组件,负责运行控制器进程。
从逻辑上讲,每个控制器都是一个单独的进程, 但是为了降低复杂性,它们都被编译到同一个可执行文件,并在同一个进程中运行。
这些控制器包括:
- 节点控制器(Node Controller):负责在节点出现故障时进行通知和响应
- 任务控制器 (Job Controller):监测代表一次性任务的 Job
- 端点分片控制器 (EndpointSlice controller):填充端点分片 (EndpointSlice)对象(以提供 Service 和 Pod 之间的链接)
- 服务账号控制器 (ServiceAccount controller):为新的命名空间创建默认的服务账号 (ServiceAccount)
cloud-controller-manager
云控制管理器:第三方云平台提供的控制器API对接功能
kub-scheduler
调度器:负责将Pod基于一定的算法,调度到合适的节点上
etcd
理解为k8s的数据库,键值类型的数据库,提供了基于Raft算法实现自主的集群高可用
老版本基于内存,新版本持久化存储
Slave
kubelet
负责Pod的生命周期、存储、网络的管理
kube-proxy
网络代理,负责service的服务发现以及对弈的负载均衡(4层负载)
contrainer runtime
容器的运行时环境:docker、containerd、CRI-O
Pod
https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/
附加组件(Add-ons)
kube-dns
作用:提供集群内 DNS 服务。 用途:
- 允许 Pod 之间通过服务名通信,如 my-service.default.svc.cluster.local。
- 实现服务发现。
说明:Kubernetes 1.11 之后默认使用
CoreDNS
替代 kube-dns,但 kube-dns 在早期版本仍然常见。
Ingress Controller
作用:管理 Ingress 资源,将外部 HTTP(S) 请求路由到集群内服务。七层网络 用途:
- 实现基于域名、路径的路由。
- 支持 HTTPS、证书管理(如结合 cert-manager)。
- 常见实现:NGINX Ingress Controller、Traefik、HAProxy、Istio Gateway 等。
Heapster
作用:早期用于收集集群资源指标(CPU、内存等)。 用途:
- 为 Dashboard 和自动扩缩容(HPA)提供指标数据支持。
❌ 说明:Heapster 已被弃用,现多用 Metrics Server 替代。
Dashboard
作用:提供 Web UI 用于集群管理。 用途:
- 可视化管理 Pod、Service、Deployment 等资源。
- 监控资源使用情况。
- 可通过 RBAC 控制权限访问。
Federation
作用:用于多集群管理和资源同步(如多地域部署)。 用途:
- 统一调度多个集群的服务、副本等资源。
- 实现跨区域高可用。
⚠️ 注意:K8s Federation v1 已停止开发,v2 由社区维护,使用场景较少,建议谨慎评估。
Fluentd-elasticseach
作用:日志采集与存储。 用途:
- Fluentd:收集 Pod、Node、系统日志。
- Elasticsearch:日志索引与存储。
- Kibana(通常搭配使用):日志查询与可视化界面。
资源和对象
资源
元数据
Horizontal Pod Autoscaler(HPA)
Pod 自动扩容: 可以根 CPU 使用率或自定义指标 (metrics)自动对 Pod 进行扩/缩容。
- 控制管理器每隔30s (可以通过horizontal-pod-autoscaler-sync-period修改)查询metrics的资源使用情况
- 支持三种metrics类型
- 预定义metrics(比如Pod的CPU) 以利用率的方式计算
- 自定义的Pod metrics,以原始值 (raw value) 的方式计算
- 自定义的object metrics
- 支持两种metrics查询方式: Heapster和白定义的REST API
- 支持多metrics
PodTemplate
Pod Template是关于Pod的定义,但是被包含在其他的Kubernetes对象中 (例Deployment、StatefulSet、DaemonSet等控制器)。控制器通过Pod Template信息来创建Pod
LimitRange
可以对集群内Request和Limit的配置做一个全局的统一的限制,相当于批量设置了某一个范围内(某个命名空间)的 Pod 的资源使用限制。
集群
Namespace
Node
不像其他的资源(如Pod和 Namespace),Node本质上不是Kubernetes来创建的,Kubernetes只是管理Node上的资源虽然可以通过Manifest创建一个Node对象(如下json所示)但Kubernetes也只是去检查是否真的是有这么一个Node,如果检查失败,也不会往上调度Pod。
ClusterRole
ClusterRoleBinding
命名空间
Pod(工作负载型)
Pod(容器组)是Kubernetes中最小的可部署单元。一个Pod(容器组)包含了一个应用程序容器(某些情况下是多个容器)、存储资源、一个唯一的网络IP地址、以及一些确定容器该如何运行的选项。Pod容器组代表了Kubernetes中一个独立的应用程序运行实例,该实例可能由单个容器或者几个紧精合在一起的容器组成。
Docker是Kubernetes Pod中使用最广泛的容器引擎
Kubernetes Pod同时也支持其他类型的容器擎
Kubernetes集群中的Pod存在如下两种使用途径:
- 一个Pod中只运行一个容器。“one-container-per-pod”是Kubernetes中最常见的使用方式。此时,您可以认为Pod容器组是该容器的wrapper,Kubernetes通过Pod管理容器,而不是直接管理容器。
- 一个Pod中运行多个需要互相协作的容器。您可以将多个紧密拥合、共享资源且始终在一起运行的容器编排在同一个,Pod中,可能的情况有:
副本(replicas)
先引入“副本”的概念,一个Pod可以被复制成多份,每一份可被称之为一个“副本”,这些”副本”除了一些描述性的信息 (Pod的名字、uid 等)不一样以外,其它信息都是一样的,譬如Pod内部的容器、容器数量、容器里面运行的应用等的这些信息都是一样的,这些副本 提供同样的功能。
Pod 的“控制器”通常包含一个名为“replicas”的属性。“replicas”属性则指定了特定Pod的副本的数量,当前集群中该Pod的数量与该属性指定的值不一致时,k8s会采取一些策略去使得当前状态满足配置的要求。
控制器
- 适用无状态服务
- ReplicationController(RC):帮我们动态更新Pod的副本数量
- ReplicaSet(RS):RC(ReplicationController)主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出,会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收 (已经成为过去时),在 v1.11版本废弃Kubernetes官方建议使用 RS(ReplicaSet)替代RC(ReplicationController)进行部署,RS跟RC没有本质的不同,只是名字不一样,并且RS支持集合式的 selector。
- Label
- Selector:扩容时,通过selector来确认对那些Pod生效
- Deployment:针对RS更高层次的封装,提供了更丰富的部署相关功能
- 创建Replica Set / Pod
- 滚动升级/回滚
- 平滑扩容/缩容
- 暂停与恢复
- 适用有状态服务
- StatefulSet
- 特点
- 稳定的持久化存储
- 稳定的网络标志
- 有序部署,有序扩展
- 有序收缩,有序删除
- 组成
- Headless Service:用于定义网络的 DNS Domain
- VolumeClaimTemplate:
- 注意事项
- kubernetes v1.5版本以上才支持
- 所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建
- 为了保证数据安全,删除StatefulSet不会删除Volume
- StatefulSet需要一个Headless Service来定义DNS Domain,需要再StatefulSet之前创建好
- 特点
守护进程
- DaemonSet:保证在每个 Node 上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:
- 日志收集,比如fluentd,logstash等
- 系统监控,比如Prometheus Node Exporter,collectd,New Relic agent,Ganglia gmond等
- 系统程序,比如kube-proxy,kube-dns,glusterd,ceph等
- DaemonSet:保证在每个 Node 上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:
任务/定时任务
- Job:一次性任务,运行完成后销毁Pod
- CronJob:周期性,运行时创建Pod,执行完成
服务发现
Service
”Service”简写“svc”。Pod不能直接提供给外网访问,而是应该使用service。Service就是把Pod暴露出来提供服务,Service才是真正的“服务”,它的中文名就叫“服务”。
可以说Service是一个应用服务的抽象,定义了Pod逻辑集合和访问这个Pod集合的策略。Service代理Pod集合,对外表现为一个访问入口,访问该入口的请求将经过负载均衡,转发到后端Pod中的容器。
存储
volume
数据卷,共享Pod中容器使用的数据。用来放持久化的数据,比如数据库数据。
CSI
特殊类型存储
ConfigMap
Secret
DownwardAPI
downwardAPI这个模式和其他模式不一样的地方在于它不是为了存放容器的数据也不是用来进行容器和宿主机的数据交换的,而是让pod里的容器能够直接获取到这个pod对象本身的一些信downwardAPI提供了两种方式用于将pod的信息注入到容器内部
环境变量:用于单个变量,可以将pod信息和容器信息直接注入容器内部
volume挂载:将pod信息生成为文件,直接挂载到容器内部中
其他
Role
RoleBinding
对象的规约和状态
- 规约(Spec):”spec”是“规约”、“规格”的意思,spec 是必需的,它描述了对象的期望状态 (Desired State)— 希望对象所具有的持征。当创建 Kubernetes 对象时,必须提供对象的规约,用来描述该对象的期望状态,以及关于对象的一些基本信息(例如名称)。
- 状态(Status):