K8S 基础概念和常用原理

K8S 基础概念和常用原理1. 镜像Image与容器Container——你的“Java程序包”2. Pod——K8s里的“最小部署单元”3. 节点Node——承载Pod的“物理/虚拟机”4. 控制器Controller——负责“维持承诺状态”的机器人5. Service——给Pod一个“固定门牌号”6. Ingress——集群的“七层路由网关”7. ConfigMap Secret——配置与密码的“外部化”8. PV PVC——让Pod的数据“不死”9. Namespace——集群里的“逻辑隔离分区” 最后用一个“部署流程”串起来✨ 理解K8s的“思维转变”我们按“应用从代码到服务”的完整生命周期来串讲你会更清楚每个概念实际扮演的角色。1. 镜像Image与容器Container——你的“Java程序包”镜像就是你的Spring Boot应用连同运行环境JDK、Linux基础系统打的一个只读包。相当于Java里的.jar文件但包含了操作系统依赖。容器是镜像的运行实例。相当于你用java -jar启动的一个进程但隔离在自己的文件系统和网络空间中。开发视角你写好代码用Dockerfile构建成镜像推送到仓库。K8s负责拉取并运行这个镜像。2. Pod——K8s里的“最小部署单元”Pod 不是一个容器而是一个或多个容器的组合。它们共享同一个网络命名空间IP和端口空间和存储卷。最典型的是主容器边车容器模式主容器跑你的业务应用边车容器负责日志收集、网络代理等辅助功能。为什么不能直接跑容器因为K8s管理的最小单位是Pod不是容器。Pod里的容器总是被一起调度、一起运行在同一个节点上。3. 节点Node——承载Pod的“物理/虚拟机”节点分为两类控制平面节点Control Plane跑管理组件API Server、Scheduler、Controller Manager等不跑业务Pod生产环境通常多节点高可用。工作节点Worker Node实际运行你的Pod的机器。上面必须安装容器运行时如 containerd 和 kubelet与主控通信的代理。4. 控制器Controller——负责“维持承诺状态”的机器人控制器是K8s的核心设计——你告诉它“要什么”它负责“做到并保持”。控制器类型作用类比JavaDeployment管理无状态应用如Spring Boot Web服务。支持滚动更新、回滚、扩缩容。像线程池管理一组工作进程的数量和版本StatefulSet管理有状态应用如数据库。每个Pod有唯一标识如mysql-0启动/停止有序。像有状态会话BeanDaemonSet在每个节点上跑一个Pod如日志采集器、监控Agent。像JVM里的守护线程Job/CronJob跑一次性或定时任务如数据库迁移、报表生成。像ScheduledExecutorService提交的任务5. Service——给Pod一个“固定门牌号”Pod 是临时存在的IP 会变。Service为动态的Pod提供一个固定的访问入口。ClusterIP默认集群内部访问用于服务间调用如订单服务调用户服务。NodePort在每个节点上开放一个固定端口用于外部访问不常用主要用于测试。LoadBalancer配合云厂商的负载均衡器对外提供公网IP。运作原理Service通过标签选择器Label Selector找到对应Pod并自动做轮询负载均衡。6. Ingress——集群的“七层路由网关”如果说Service是内部负载均衡那Ingress就是外部入口的智能路由。可以根据域名和URL路径将请求转发到不同的Service。例如api.your.com/order→ 订单Serviceapi.your.com/user→ 用户Service同时支持HTTPS证书挂载、限流等高级功能。7. ConfigMap Secret——配置与密码的“外部化”都是用来给Pod注入数据的区别在于ConfigMap存非敏感配置如application.properties里的数据库URL、超时时间。Secret存敏感信息如数据库密码、Redis密码、JWT密钥内容会做Base64编码注意只是编码不是加密需配合RBAC或外部密钥系统增强安全。注入方式可以通过环境变量或者挂载成文件比如挂载到/config/application.properties。8. PV PVC——让Pod的数据“不死”Pod 重启后数据会丢失而 PV/PVC 提供持久化存储PV集群管理员提供的存储资源NFS、云硬盘等相当于“硬盘”。PVCPod对存储的申请“我要10GB且支持读写”K8s会自动匹配符合条件的PV绑定。使用方式你在Deployment里声明PVCPod启动时就会把该存储卷挂载到容器目录如/data。9. Namespace——集群里的“逻辑隔离分区”可以把Namespace理解为集群内部的“虚拟集群”用于环境隔离如dev、test、prod或团队隔离。资源名称在同一个Namespace下唯一不同Namespace可以重名。日常操作kubectl命令常带-n namespace参数不指定则默认default。 最后用一个“部署流程”串起来你写好Spring Boot代码 → 构建Docker镜像 → 推送到镜像仓库。编写Deployment YAML指定镜像、副本数、资源限制→ 通过kubectl提交给API Server。Scheduler 找到合适的 Worker Node → kubelet 拉取镜像并启动 Pod 容器。编写 Service YAML → 为这些Pod创建固定服务的访问入口。如果有外部访问需求 → 配置 Ingress 规则。配置文件用ConfigMap/Secret管理 → 挂载到 Pod 中。需要持久化数据 → 通过PVC申请PV存储。✨ 理解K8s的“思维转变”传统运维思维K8s思维登录机器ps -ef看进程用kubectl get pods看Pod状态修改配置文件重启服务修改YAMLkubectl apply自动滚动更新机器挂了人工恢复K8s自动重新调度Pod到健康节点手工扩容部署新版本改replicas或镜像tag自动完成视频学习地址