本文介绍了Kubernetes 1.25的重要变化，包括镜像仓库的迁移和CRI不再支持docker。深入讲解了K8S的基本概念，如RC（ReplicationController）升级为RS（ReplicaSet），Deployment的使用场景，以及Job在批处理任务中的角色。同时，讨论了资源限制和对象分类，并概述了K8S中资源管理和自动伸缩的概念。
k8s基本概念
一、Kubernetes 概述
定义：Kubernetes（K8s）是一个开源的容器编排平台，用于自动化容器化应用的部署、扩展与管理。
核心机制：
- 最小调度单元：Pod
- 声明式API：用户定义期望状态，系统自动驱动至该状态
- 事实标准：起源于Google Borg，由CNCF维护，云原生时代的“分布式操作系统”
核心能力：
- 自动部署与回滚
- 服务发现与负载均衡
- 自我修复（重启/替换故障容器）
- 水平扩缩容（HPA）
- 配置与密钥管理
版本变更（1.25）：
- 镜像仓库：
k8s.gcr.io→registry.k8s.io - CRI：不再支持Docker，需使用兼容CRI的运行时（containerd等）
二、基础接口定义
| 缩写 | 全称 | 作用说明 |
|---|---|---|
| CNI | Container Network Interface | 容器网络接口 |
| CRI | Container Runtime Interface | 容器运行时接口（1.25后弃Docker） |
| CSI | Container Storage Interface | 容器存储接口 |
三、控制平面组件（Master）
| 组件 | 核心职责 |
|---|---|
| API Server | 集群唯一入口，处理所有REST请求（kubectl及其他组件均通过其通信） |
| Controller Manager | 运行各类控制器，确保实际状态与期望状态一致 |
| Scheduler | 将新Pod调度至合适节点（依据资源、亲和性、污点等策略） |
| etcd | 分布式键值存储，集群唯一真相源，存储所有配置与状态数据 |
四、工作节点组件（Node）
| 组件 | 核心职责 |
|---|---|
| Kubelet | 节点代理，与Master通信，管理Pod及容器的完整生命周期 |
| Container Runtime | 底层容器运行引擎（containerd等），拉取镜像、创建容器、资源隔离 |
| Kube-Proxy | 网络代理与负载均衡，维护iptables/IPVS规则，实现Service流量转发 |
五、工作负载对象
1. Pod
定义：Kubernetes中最小可调度与部署单元，代表一个逻辑主机，封装一个或多个紧密协作的容器。
核心特点：
- 共享网络命名空间：容器间通过
localhost通信 - 共享存储卷：支持容器间数据交换
- 统一生命周期：Pod启停，内部容器同步
常见模式：
- 单容器Pod（标准）
- 多容器Pod（主容器+Sidecar）
- 无状态Pod（依赖外部存储）
- 有状态Pod（需持久化数据）
2. ReplicationController（RC，已废弃）
定义：早期副本控制器，确保指定数量Pod持续运行。
局限：仅支持等式匹配选择器，K8s v1.2起被ReplicaSet取代。
3. ReplicaSet（RS）
定义：RC的增强版本，Pod副本管理的标准控制器。
核心特性：
- 副本数控制：自动维持指定Pod数量
- 高级选择器：支持基于集合的匹配（In、NotIn、Exists）
- 自愈与扩缩容：Pod故障重建，修改
replicas即可伸缩
生产实践：RS通常由Deployment自动管理，不直接操作。
4. Deployment
定义：管理无状态应用的核心控制器，通过声明式配置维持期望状态。
工作原理：通过控制ReplicaSet实现应用生命周期管理。
核心能力：
- 滚动更新：零停机升级
- 自动修复：故障Pod自动重建
- 弹性伸缩：手动改副本数或配合HPA自动伸缩
- 版本回滚：一键回退至历史版本
- 声明式配置：统一管理镜像、资源、探针等
最佳实践：所有长期运行的无状态服务必须使用Deployment。
5. DaemonSet
定义：确保每个节点（或指定节点）运行且仅运行一个Pod副本的控制器。
适用场景：节点级系统守护进程（日志采集、监控代理、网络插件、存储客户端）。
核心特性：
- 节点全覆盖：新节点加入自动创建Pod，节点移除自动清理
- 调度控制：支持
nodeSelector、亲和性、污点容忍 - 滚动更新：支持平滑升级守护进程
最佳实践：所有需每节点运行的系统服务优先使用DaemonSet。
6. StatefulSet
定义：管理有状态应用的控制器，强调Pod身份稳定性与状态持久性。
适用场景：数据库（MySQL、MongoDB）、分布式协调（ZooKeeper、etcd）、消息队列（Kafka）。
核心特性：
- 有序部署/扩缩容：按序号顺序创建，逆序终止
- 稳定网络标识：Pod名固定，通过Headless Service提供可解析DNS域名
- 持久化存储：
volumeClaimTemplates为每个Pod自动创建独立PVC，重建后仍挂载原卷 - 服务发现：配合Headless Service实现Pod级精确访问
最佳实践：所有需保留身份、存储或启动顺序的应用必须使用StatefulSet。
7. Job
定义：管理批处理型任务的控制器，适用于有明确结束的一次性任务。
完成模式：
| 模式 | completions | parallelism | 说明 |
|---|---|---|---|
| 单次完成（默认） | 1 | 1 | 1个Pod成功即完成 |
| 固定次数完成 | N | ≥1 | N个Pod均成功才算完成 |
| 工作队列模式 | 1 | N | 任一Pod成功即完成（需应用自协调） |
注意：Pod成功退出后不再重启，
restartPolicy必须为OnFailure或Never。
六、服务发现与配置对象
1. Service
定义：为一组Pod提供稳定网络访问入口的抽象，实现服务发现与四层负载均衡。
核心特性：
- 稳定访问地址：分配ClusterIP（虚拟IP），生命周期独立于Pod
- 自动负载均衡：请求均匀分发至就绪Pod
- 动态服务发现：通过Label Selector自动关联Pod，实时更新Endpoints
- 多访问类型：
ClusterIP：集群内访问（默认）NodePort：节点IP+端口暴露LoadBalancer：云厂商LBExternalName：DNS CNAME映射
最佳实践：所有需被访问的Pod必须通过Service暴露。
2. Ingress
定义：将外部HTTP/HTTPS流量路由至集群内部服务的API对象，提供七层流量入口。
注意：Ingress本身不处理流量，需配合Ingress Controller（Nginx、Traefik等）生效。
核心特性：
- 基于规则的路由：按主机名、路径转发至不同Service
- SSL/TLS终止：Ingress层解密HTTPS，后端使用HTTP
- 负载均衡：外部请求分发至后端多Pod
- 路径重写：转发前修改请求路径
工作流程：
用户创建Ingress → Ingress Controller监听变化并生成反向代理配置 → 外部请求经Controller转发至对应Service → Pod
最佳实践：生产环境用Ingress+Controller替代多个LoadBalancer Service，统一入口管理。
3. ConfigMap
定义：将非敏感配置数据与容器镜像解耦的资源对象，以键值对形式存储配置。
核心特性：
- 注入方式：
- 环境变量（不支持热更新）
- 卷挂载为文件（支持热更新，数秒内同步）
- 与镜像解耦：配置变更无需重建镜像
- 限制：仅限非敏感数据；单个大小≤1MiB
最佳实践：配置文件优先以卷挂载方式注入，便于管理与更新。
4. Secret
定义：安全存储与管理敏感信息的资源对象（密码、密钥、证书、镜像仓库凭据等）。
核心特性：
- 支持类型：
Opaque：通用键值对kubernetes.io/dockerconfigjson：私有镜像仓库认证（最常用场景）kubernetes.io/tls：TLS证书与私钥
- 注入方式：
- 卷挂载（推荐）：文件形式，权限可控
- 环境变量（慎用）：易意外泄露
- 动态更新：挂载为文件时支持热同步
安全警示：Secret默认Base64编码（非加密）存储etcd，生产环境必须启用静态加密与RBAC访问控制。
七、存储对象
1. PersistentVolume（PV）
定义：集群级别的存储资源抽象，独立于Pod生命周期，提供持久化存储。
核心特性：
- 生命周期独立：Pod删除，PV及数据保留
- 多种后端：本地磁盘、NFS、Ceph、云存储（AWS EBS、Azure Disk等）
- 分配方式：
- 静态供给：管理员预创建PV，用户PVC绑定
- 动态供给：通过
StorageClass自动按需创建（生产推荐）
- 访问模式：
ReadWriteOnce（RWO）：单节点读写ReadOnlyMany（ROX）：多节点只读ReadWriteMany（RWX）：多节点读写（需存储后端支持）
2. PersistentVolumeClaim（PVC）
定义：用户对持久化存储的请求，声明所需容量、访问模式及存储类型。
核心特性：
- 声明式存储请求：K8s自动匹配或动态创建PV
- 支持StorageClass：指定存储类型（SSD、HDD等）
- 访问模式声明：需与PV兼容
- 动态供给：PVC创建可触发PV自动创建与绑定
工作流程：
用户创建PVC → K8s匹配/创建PV → PVC与PV绑定 → Pod挂载PVC使用存储
最佳实践：应用始终通过PVC申请存储，生产环境优先使用动态供给+StorageClass。
八、组织与策略对象
1. Namespace
定义：对集群资源进行逻辑隔离与组织的机制，将物理集群划分为多个虚拟集群。
注意：仅提供逻辑隔离，网络隔离需配合
NetworkPolicy。
核心用途：
- 资源隔离：同名资源可在不同Namespace共存
- 权限控制：RBAC细粒度授权
- 资源配额：
ResourceQuota限制总资源用量；LimitRange设置容器默认资源请求/限制
系统默认Namespace：
default：未指定时的默认空间kube-system：系统组件空间kube-public：公共资源（所有用户可读）kube-node-lease：节点心跳租约
最佳实践：生产环境按团队、环境、项目划分Namespace。
2. 资源限制
机制：基于Linux cgroups，对容器CPU和内存进行限制。
单位：
- CPU：毫核（
m），1000m=1核 - 内存：
Mi（MiB）、Gi（GiB）
命令示例：
# 限制Deployment中的nginx容器最多只用50%的CPU和128MB的内存
kubectl set resources deployment nginx-app -c=nginx \
--limits=cpu=500m,memory=128Mi
九、Kubernetes 资源对象分类
1. 工作负载（Workload）
- Pod
- ReplicaSet / ReplicationController（RC已废弃）
- Deployment
- StatefulSet
- DaemonSet
- Job / CronJob
- HorizontalPodAutoscaler（HPA）
2. 配置与发现
- Service
- Ingress
- ConfigMap
- Secret
- Namespace
- Node
- ServiceAccount
- Label（逻辑标识）
- CustomResourceDefinition（CRD）
3. 存储
- Volume（临时卷）
- PersistentVolume（PV）
- PersistentVolumeClaim（PVC）
4. 策略与安全
- ResourceQuota（命名空间资源总量限制）
- LimitRange（容器资源默认/边界限制）
- SecurityContext（Pod/容器安全上下文）
说明：实际应用中常组合多种对象（如Deployment+Service+ConfigMap）构建完整应用系统。
扫一扫
462
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
