K8s入门第一课:从零理解Kubernetes核心概念与架构设计

K8s入门第一课:从零理解Kubernetes核心概念与架构设计 前言说实话刚开始接触 Kubernetes 时我是有点懵的。那时候公司要上容器化leader丢给我一句话“把这套系统用K8s部署一下”。我打开官方文档迎面扑来一堆概念——Pod、Deployment、Service、ReplicaSet… 这都啥跟啥啊更崩溃的是看懂了概念实际用起来又是另一回事。Pod和容器啥关系Service到底怎么把请求转发到Pod的为什么有时候Pod起来了Service却访问不了花了一周多时间啃完官方文档翻了N篇博客踩了一堆坑才慢慢摸清楚K8s的门道。今天这篇文章把我当时的学习路径和踩坑经验分享出来帮你少走点弯路。一、Kubernetes 是什么1.1 从 Docker 到 K8s如果你用过 Docker那你一定体验过这种爽感一条命令就能启动一个应用环境隔离、快速部署简直太香了。但是当容器数量多了以后问题就来了怎么管理成百上千个容器某个容器挂了怎么自动恢复流量大了怎么自动扩容怎么实现负载均衡这就是 Kubernetes 登场的原因。Kubernetes简称K8s是 Google 在2014年开源的容器编排系统。它的名字很有意思——Kubernetes 希腊语意思是舵手而 K8s 是 Kubernetes 的缩写k和s之间有8个字母。关键认知K8s 不是替代 Docker 的而是用来管理Docker 容器的。Docker 负责造容器K8s 负责管容器。1.2 K8s 的血统K8s 可不是凭空出现的。它源自 Google 内部一个叫 Borg 的系统——Google 用 Borg 管理了十几年的容器集群支撑着搜索、Gmail、YouTube 这些超级服务。所以你可以理解为K8s 是 Borg 的开源版凝聚了 Google 十年容器管理的精华。二、K8s 到底能做什么很多人包括刚开始的我以为 K8s 就是个容器管理工具。其实它提供的是一整套容器化应用的解决方案核心能力清单能力说明实际价值自动化部署声明式配置一键部署告别手动操作减少人为错误弹性伸缩根据CPU/内存自动扩缩容应对流量高峰节省资源成本自我修复容器挂了自动重启、重新调度提升系统可用性服务发现与负载均衡自动分配IP流量分发无需手动配置Nginx滚动更新不停机更新版本零停机发布新版本资源监控集成Prometheus、Grafana可视化集群状态配置管理ConfigMap、Secret管理配置配置与代码分离三、K8s 核心对象你必须知道的7个概念K8s 的概念虽然多但核心就这几个。理解它们的关系K8s 就入门了一半。3.1 Pod最小的部署单元Pod是 K8s 中最小的部署单元。你可以把它理解为容器的容器。关键特性一个 Pod 可以包含一个或多个容器通常是紧密耦合的Pod 内的容器共享网络命名空间和存储卷Pod 是临时性的不应该被视为持久化的实体为什么设计 Pod 而不是直接用容器想象一下你有一个 Web 应用和一个日志收集 sidecar。它们需要共享网络localhost通信、共享存储日志文件。如果用独立的容器这些会很麻烦。Pod 把它们打包在一起形成一个逻辑单元。# Pod 示例apiVersion:v1kind:Podmetadata:name:my-podspec:containers:-name:webimage:nginx:latest-name:loggerimage:fluentd:latest3.2 Service稳定的访问入口Pod 是临时的IP 地址会变化。那前端怎么稳定地访问后端服务Service就是解决这个问题的。它为一组 Pod 提供一个稳定的访问入口ClusterIP并且自动实现负载均衡。Service 的核心能力为一组 Pod 提供统一的访问地址通过 Label Selector 选择目标 Pod自动负载均衡流量到后端 Pod# Service 示例apiVersion:v1kind:Servicemetadata:name:my-servicespec:selector:app:my-app# 选择带有 appmy-app 标签的 Podports:-port:80targetPort:8080⚠️踩坑记录我曾经遇到 Service 创建成功但访问不了的情况。查了半天发现是 selector 和 Pod 的 label 不匹配。K8s 不会报错只是流量转发不出去。务必检查标签是否一致3.3 Deployment管理应用的生命周期实际生产中我们很少直接创建 Pod而是通过Deployment来管理。Deployment 能做什么声明式管理 Pod 副本数量支持滚动更新Rolling Update支持版本回滚自动维护 ReplicaSet# Deployment 示例apiVersion:apps/v1kind:Deploymentmetadata:name:my-deploymentspec:replicas:3# 保持3个Pod副本selector:matchLabels:app:my-apptemplate:metadata:labels:app:my-appspec:containers:-name:my-appimage:my-app:v1.0Deployment vs ReplicaSet vs Pod 的关系Deployment (管理) └── ReplicaSet (保证副本数) └── Pod (实际运行容器)Deployment高层抽象负责声明式更新ReplicaSet中间层确保指定数量的 Pod 在运行Pod最底层实际运行容器建议直接用 Deployment不要手动操作 ReplicaSet 或 Pod。3.4 StatefulSet有状态应用的选择如果你的应用需要稳定的网络标识如数据库集群用 Deployment 就不合适了。这时候需要StatefulSet。StatefulSet 的特点Pod 有固定的网络标识hostname 不变支持持久化存储有序的部署、扩展、删除适合 MySQL、Redis、Kafka 等有状态服务# StatefulSet 示例apiVersion:apps/v1kind:StatefulSetmetadata:name:mysqlspec:serviceName:mysqlreplicas:3selector:matchLabels:app:mysqltemplate:metadata:labels:app:mysqlspec:containers:-name:mysqlimage:mysql:5.7volumeMounts:-name:datamountPath:/var/lib/mysqlvolumeClaimTemplates:-metadata:name:dataspec:accessModes:[ReadWriteOnce]resources:requests:storage:10Gi使用建议无状态应用用 Deployment有状态应用用 StatefulSet。3.5 DaemonSet每个节点一个 Pod如果你需要在每个节点上都运行一个 Pod如日志收集、监控代理用DaemonSet。典型场景日志收集Fluentd、Filebeat监控代理Node Exporter网络代理Calico、Flannel# DaemonSet 示例apiVersion:apps/v1kind:DaemonSetmetadata:name:node-exporterspec:selector:matchLabels:name:node-exportertemplate:metadata:labels:name:node-exporterspec:containers:-name:node-exporterimage:prom/node-exporter:latest3.6 Job CronJob一次性任务Job用于运行一次性任务完成后 Pod 自动退出。CronJob用于定时任务类似 Linux 的 crontab。# Job 示例apiVersion:batch/v1kind:Jobmetadata:name:data-processingspec:template:spec:containers:-name:processorimage:data-processor:latestcommand:[python,process.py]restartPolicy:NeverbackoffLimit:43.7 Volume数据持久化容器是临时的数据需要持久化保存。Volume解决了 Pod 内数据的持久化和共享问题。常用 Volume 类型emptyDir临时存储Pod 删除后数据丢失hostPath挂载宿主机目录不推荐生产环境persistentVolumeClaim (PVC)持久化存储数据独立于 Pod 生命周期# 使用 PVCapiVersion:v1kind:Podmetadata:name:my-podspec:containers:-name:my-appimage:my-app:latestvolumeMounts:-name:datamountPath:/datavolumes:-name:datapersistentVolumeClaim:claimName:my-pvc四、K8s 架构Master 和 Node 如何协作理解完核心对象再来看看 K8s 的架构设计。4.1 整体架构K8s 集群由两类节点组成Master 节点控制平面负责集群管理Node 节点工作节点负责运行应用4.2 Master 节点集群的大脑Master 节点运行着控制平面的核心组件API ServerK8s 的入口所有操作都通过它提供 RESTful API负责认证、授权、准入控制核心地位无论是 kubectl 命令、还是其他组件通信都要经过 API Server。它是整个集群的交通枢纽。etcd分布式键值存储数据库保存集群的所有配置和状态数据只有 API Server 能直接访问 etcdController Manager运行各种控制器Controller持续监控集群状态确保实际状态与期望状态一致例如Deployment Controller、Node Controller、Endpoint ControllerScheduler负责 Pod 的调度根据资源需求、亲和性/反亲和性等策略选择合适的 Node如果没有合适的 NodePod 会处于 Pending 状态4.3 Node 节点工作负载的载体每个 Node 上运行着KubeletNode 上的代理接收 API Server 的指令管理 Pod 生命周期定期向 Master 汇报节点状态Container Runtime容器运行时如 Docker、containerd负责拉取镜像、启动/停止容器Kube-proxy负责 Service 的网络代理和负载均衡维护节点的 iptables/ipvs 规则五、学习路径建议如果你刚开始学 K8s建议按这个顺序1. 理解容器基础Docker ↓ 2. 掌握核心概念Pod、Service、Deployment ↓ 3. 学习 kubectl 基本命令 ↓ 4. 实践部署一个应用 ↓ 5. 深入架构原理 ↓ 6. 学习高级特性网络、存储、调度推荐学习资源官方文档https://kubernetes.io/zh/docs/Katacoda 交互式教程已并入 O’Reilly动手实践Minikube 或 Kind 本地搭建集群六、生产环境检查清单如果你准备把 K8s 应用到生产环境别忘了检查这些集群高可用配置多 Master网络策略NetworkPolicy资源限制ResourceQuota、LimitRange监控告警Prometheus Grafana日志收集ELK 或 Loki备份策略etcd 定期备份安全策略RBAC、PodSecurityPolicy灾难恢复方案七、总结这篇文章我们聊了 K8s 的核心内容K8s 是什么Google 开源的容器编排系统源自 Borg核心对象Pod最小单元、Service访问入口、Deployment应用管理、StatefulSet有状态、DaemonSet守护进程、Job任务、Volume存储架构设计Master控制平面 Node工作节点关键认知K8s 的设计是声明式的——你告诉它想要什么而不是怎么做理解 Pod 和容器的关系是入门的关键Service 解决了 Pod 动态 IP 的问题Deployment 是管理应用的首选方式你踩过这些坑吗刚开始学 K8s 时哪个概念最让你困惑Pod 和容器的关系还是 Service 的工作原理你在实际使用 K8s 时遇到过什么坑欢迎在评论区分享对于 K8s 的 NetworkPolicy 和存储你有什么想了解的吗延伸思考如果集群规模从 10 个节点扩展到 1000 个K8s 的架构需要做哪些调整在混合云场景下K8s 如何管理不同云厂商的资源你觉得 Serverless如 Knative会取代 K8s 吗求助与交流如果你对 K8s 入门还有疑问或者有更好的学习方法欢迎在评论区交流。也欢迎分享你踩过的坑我会整理补充到文章中帮助更多初学者。建议收藏关注持续更新 K8s 系列教程