【K8s从零到实战】一个真实项目带你理解K8s是什么和Docker什么关系YAML文件怎么配别再死记概念了我带你从一份真实的k8s/目录配置读懂Kubernetes一、引言从一段真实的开发经历说起小张是个后端开发他花了一周时间用Python FastAPI写了一个资产管理平台Docker打包后在本地跑得很欢。老板说“上线吧。”小张把Docker镜像推到服务器docker run -d ...搞定。第二天服务挂了同事重启了一下。第三天服务又挂了这次是内存爆了。第四天并发量上来了一台机器扛不住小张手动启动了第二台然后发现两个容器访问的是不同的本地数据库数据不一致……小张崩溃了。这些问题的根源是什么没有自愈能力——挂了没人自动重启没有资源限制——内存爆了就OOM没有负载均衡——多实例需要手动管理没有服务发现——实例之间不知道怎么找到对方没有滚动更新——升级停服而这些问题正是Kubernetes要解决的。今天我们就通过一个真实的开源项目——CAMP云资产管理平台的k8s/配置文件来彻底搞懂Kubernetes是怎么解决这些问题的。二、Docker vs Kubernetes它们到底是什么关系在开始解析YAML之前我必须先帮你理清楚这两个“出镜率最高”的概念。很多人学了很久还是模糊的这里用一个“盖房子”的比喻让你一辈子忘不掉概念类比职责Docker标准化的砖块生产厂把应用打包成镜像Image让同一个应用在任何机器上都能跑Kubernetes智慧建筑工地总指挥管理容器Container在哪里跑、跑几个、挂了怎么办、怎么对外提供服务一句话总结Docker负责“打包”Kubernetes负责“调度”。在你要学习的这个项目中这个关系体现得非常清晰text┌─────────────────────────────────────────────────────────────────┐ │ 开发者写代码 (Python / JavaScript) │ │ ↓ │ │ Dockerfile (定义如何打包) │ │ ↓ │ │ docker build → camp-backend:latest (镜像) │ │ ↓ │ │ docker push → GHCR (镜像仓库) │ │ ↓ │ │ Kubernetes拉取镜像 按YAML配置运行 → Pod、Service、Ingress │ └─────────────────────────────────────────────────────────────────┘Docker解决了“环境不一致”的问题——开发环境能跑生产环境就能跑。Kubernetes解决了“容器规模化运维”的问题——当你需要管理几十上百个容器时手动操作已经不现实了。三、这个项目中的K8s配置长什么样一个项目的k8s/目录下有这些核心文件textk8s/ ├── namespace.yaml # 命名空间把资源隔离开 ├── configmap.yaml # 非敏感配置 ├── secret.yaml # 敏感配置密码、密钥等 ├── backend-deployment.yaml # 后端服务的Pod编排 ├── web-frontend-deployment.yaml # 主前端 ├── auth-frontend-deployment.yaml # 认证前端 ├── service.yaml # 服务发现与负载均衡 ├── ingress.yaml # 外部访问入口 ├── persistent-volumes.yaml # 持久化存储 ├── horizontal-pod-autoscaler.yaml # 自动伸缩 ├── network-policy.yaml # 网络隔离规则 ├── resource-quota.yaml # 资源配额限制 ├── monitoring.yaml # 监控组件 ├── deploy.sh # 一键部署脚本 └── cleanup.sh # 一键清理脚本这些文件之间是什么关系用一张图就能看清核心逻辑Namespace是“容器”所有资源都装在里面。Deployment管Pod的“生老病死”副本数、镜像版本、探针等。Service给Pod一个“固定门牌号”不管Pod怎么重启通过Service总能找到。Ingress是“大门”外部流量从这里进来再分发给各个Service。ConfigMap/Secret是“配置中心”把配置从镜像里抽出来便于修改。PVC是“硬盘”容器重启数据不丢。HPA是“自动升降机”流量大了自动加Pod小了自动减Pod。四、逐文件深度解析每个YAML到底在说什么1.namespace.yaml—— 资源的“文件夹”yamlapiVersion: v1 kind: Namespace metadata: name: camp labels: app: cloud-asset-management-platform environment: production作用创建一个叫camp的命名空间。为什么要用Namespace场景不用Namespace用Namespace查看所有资源kubectl get pods→ 全部混在一起kubectl get pods -n camp→ 只看camp的资源隔离开发环境可能误删生产环境的Pod不同环境用不同Namespace互不影响权限控制无法精细控制可以给不同用户授予不同Namespace的权限大白话Namespace就像你电脑里的“文件夹”把项目A和项目B的文件分开存放免得乱七八糟。2.configmap.yaml—— 配置的“公开文件夹”yamlapiVersion: v1 kind: ConfigMap metadata: name: camp-config namespace: camp data: DATABASE_URL: sqlite:///./camp.db DEBUG: false LOG_LEVEL: info CORS_ORIGINS: http://localhost:3004,http://localhost:3000 MAX_FILE_SIZE: 52428800作用存储应用的非敏感配置。为什么要用ConfigMap分离配置和代码改配置不用重新构建镜像同一套代码不同环境用不同配置DEBUG: true开发vsDEBUG: false生产大白话ConfigMap就是给容器注入环境变量的“说明书”想让程序怎么跑改这里就行不用重新打包镜像。3.secret.yaml—— 配置的“加密保险柜”yamlapiVersion: v1 kind: Secret metadata: name: camp-secrets namespace: camp type: Opaque data: SECRET_KEY: ZGV2LXNlY3JldC1rZXk # Base64编码 JWT_SECRET: ZGV2LWp3dC1zZWNyZXQ DEFAULT_PASSWORD: YWRtaW4xMjM注意Secret里的值必须是Base64编码的不是明文为什么要用Secret问题解决方案密码明文写在YAML里 → 安全隐患用Secret存储且值用Base64编码任何人能看到YAML文件 → 泄露密码配合RBAC权限控制只有特定角色能读取Secret大白话Secret和ConfigMap功能一样都是存配置。区别是Secret存的是密码、密钥、Token这些见不得光的东西。4.backend-deployment.yaml—— 最核心的“Pod说明书”这是整个项目里最重要、最核心的一个YAML文件。理解了它Kubernetes你就懂了一半。yamlapiVersion: apps/v1 kind: Deployment metadata: name: camp-backend namespace: camp labels: app: camp component: backend spec: replicas: 2 selector: matchLabels: app: camp component: backend template: metadata: labels: app: camp component: backend spec: containers: - name: camp-backend image: ghcr.io/elishatheodore/camp-backend:latest imagePullPolicy: Always ports: - containerPort: 8000 # ... 以下是重点①replicas: 2—— 我要2个“分身”这告诉Kubernetes“我要2个一模一样的Pod同时运行。”一个挂了另一个还能顶上去 →高可用流量大了2个一起分担 →负载均衡解决小张的问题一台机器不够就多开几台Kubernetes自动管理。② 探针Probe—— Kubernetes的“体检系统”yamllivenessProbe: httpGet: path: /test port: 8000 initialDelaySeconds: 30 # 等30秒再开始检查 periodSeconds: 10 # 每10秒查一次 failureThreshold: 3 # 连续失败3次就判定为“死了” readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 3livenessProbe存活探针检查容器是否“活着”。访问/test接口返回200说明活着连续失败3次 → Kubernetes认为容器“死亡”自动重启这是Kubernetes的自愈能力无需人工干预readinessProbe就绪探针检查容器是否“准备好接客”。访问/health接口返回200说明准备好了如果失败 → Kubernetes不会把流量转发给这个Pod直到它恢复这确保了用户不会访问到“正在启动中”或“有故障”的服务解决小张的问题服务挂了不用手工重启Kubernetes会自动处理。③ 资源限制Resources—— 防止“一个坏邻居拖垮整栋楼”yamlresources: requests: memory: 256Mi cpu: 250m limits: memory: 512Mi cpu: 500m概念含义比喻requests最低保障申请“我要至少256MB内存”调度器才会把你安排到有这个资源的机器上limits最高上限“最多给你512MB超过就杀掉”防止某个程序吃光所有资源解决小张的问题内存爆了不会把整个服务器搞死只会杀掉这个Pod然后Kubernetes自动重建。④ 环境变量注入——连接ConfigMap和Secretyamlenv: - name: DATABASE_URL valueFrom: configMapKeyRef: name: camp-config key: DATABASE_URL - name: SECRET_KEY valueFrom: secretKeyRef: name: camp-secrets key: SECRET_KEY这些环境变量注入到容器后Python代码直接os.getenv(DATABASE_URL)就能读到。这就是配置与镜像分离的精髓镜像不变换个ConfigMap/Secret就能在不同环境跑。⑤ 存储挂载Volumes—— 数据不丢失的秘密yamlvolumeMounts: - name: uploads-storage mountPath: /app/uploads - name: database-storage mountPath: /app/camp.db subPath: camp.db volumes: - name: uploads-storage persistentVolumeClaim: claimName: camp-uploads-pvc - name: database-storage persistentVolumeClaim: claimName: camp-database-pvc原理PVCPersistentVolumeClaim相当于“申请单”向Kubernetes申请一块“硬盘”volumeMounts把这块“硬盘”挂载到容器里的某个目录容器重启了数据还在“硬盘”上解决小张的问题SQLite数据库文件存在PVC里Pod重启了数据也不会丢。5.service.yaml—— 给Pod一个“永不改变的门牌号”yamlapiVersion: v1 kind: Service metadata: name: camp-backend-service namespace: camp spec: type: ClusterIP ports: - port: 8000 targetPort: 8000 selector: app: camp component: backend问题Pod的IP是动态的每次重启都可能变化。前端怎么知道后端的IP答案Service提供一个固定的虚拟IP和DNS名称。前端访问camp-backend-service.camp.svc.cluster.local就能找到后端Service自动把请求负载均衡到所有匹配selector的Pod上大白话Pod就像不断换住址的租客Service就是那个“永不改变的门牌号”找Service就能找到所有租客。6.ingress.yaml—— 互联网的“大门”yamlapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: camp-ingress namespace: camp spec: rules: - host: camp.example.com http: paths: - path: /api pathType: Prefix backend: service: name: camp-backend-service port: number: 8000 - path: / pathType: Prefix backend: service: name: camp-web-frontend-service port: number: 80作用外部用户通过域名访问时Ingress根据路径把请求路由到不同的Service路径目标camp.example.com/api/*→ 后端Service (FastAPI)camp.example.com/auth/*→ 认证前端Servicecamp.example.com/*→ 主前端Service大白话Ingress就是大楼的“门厅接待处”——有人来了根据他要去几楼指引他到对应的电梯。五、如何部署这些YAML文件方式一直接用kubectl传统方式bash# 部署整个k8s目录下的所有资源 kubectl apply -f k8s/ # 或者先切到k8s目录再部署 cd k8s kubectl apply -f .方式二使用Kustomize推荐方式这个项目的k8s/目录使用了Kustomize——Kubernetes原生的配置管理工具。bash# 在项目根目录执行 kubectl apply -k k8s/-k参数告诉kubectl“这个目录里有一个kustomization.yaml请按它描述的构建方式部署。”常用管理命令bash# 查看部署状态 kubectl get pods -n camp kubectl get svc -n camp kubectl get ingress -n camp # 查看日志 kubectl logs -f deployment/camp-backend -n camp # 扩容/缩容 kubectl scale deployment camp-backend --replicas3 -n camp # 更新镜像 kubectl set image deployment/camp-backend camp-backendghcr.io/xxx/camp-backend:v2.0.0 -n camp # 滚动重启不改变镜像用于刷新配置 kubectl rollout restart deployment/camp-backend -n camp # 查看滚动更新状态 kubectl rollout status deployment/camp-backend -n camp # 回滚到上一个版本 kubectl rollout undo deployment/camp-backend -n camp # 删除所有资源 kubectl delete -k k8s/ # 或 kubectl delete -f k8s/六、Kubernetes应用场景总结通过这个项目你可以看到Kubernetes解决了以下几个核心场景的问题场景痛点K8s解决方案项目中的体现服务高可用容器挂了要人手工重启自愈能力livenessProbe探针自动检测重启流量分发多个实例需要手动负载均衡Service负载均衡Service自动分发流量滚动更新升级需要停服滚动更新策略kubectl set imagerollout配置管理改配置要重新打镜像ConfigMap/Secret配置独立于镜像数据持久化容器重启数据丢失PersistentVolumeClaimPVC独立于Pod生命周期自动伸缩流量高峰需要手动加机器HorizontalPodAutoscaler根据指标自动扩缩容网络隔离服务之间没有访问控制NetworkPolicy精细控制Pod间通信资源管理单个服务吃光所有资源ResourceQuota LimitRange资源限制防“吵闹邻居”七、一张图总结这个项目中Docker和K8s如何协作核心一句话Docker负责“造砖”Kubernetes负责“盖楼、修楼、扩容、防塌”。八、写在最后通过这个真实项目的k8s/目录我们完整地看到了Docker和K8s的分工Docker打包K8s调度K8s的核心资源Namespace、Deployment、Service、Ingress、ConfigMap、Secret、PVCK8s如何解决实际问题自愈、负载均衡、滚动更新、配置分离、数据持久化一个微服务应用在K8s上完整运行的全貌如果你正在学习Kubernetes不要只背概念去跑一个真实项目。把项目里的YAML文件一个个看过去跑起来改一改看看效果。这才是最快的学习方式。九、当Kubernetes遇见AI智能运维时代已经到来如果说Kubernetes是云原生时代的“操作系统”那么AI就是给这个操作系统装上“大脑”。前面我们详细解析了Kubernetes的各个组件和工作原理。但你可能不知道的是AI正在深刻改变Kubernetes的运维方式和应用场景。在这一章我们从三个层面来看K8s与AI的结合。9.1 AI K8s 智能运维AIOps传统的Kubernetes运维依赖人工配置、人工排查、人工决策。但当集群规模达到成百上千个节点时人已经跟不上节奏了。AI的介入让K8s从“自动化”走向“智能化”。 AI辅助YAML智能生成与校验还记得你刚学K8s时被YAML折磨的日子吗现在AI可以帮你做了。yaml# 你只需要用自然语言描述需求AI帮你生成YAML “我要部署一个Python FastAPI服务副本数3内存限制512Mi暴露端口8000” ↓ # AI自动生成的Deployment YAML apiVersion: apps/v1 kind: Deployment metadata: name: fastapi-app spec: replicas: 3 selector: matchLabels: app: fastapi template: spec: containers: - name: app image: python:3.11 command: [uvicorn, main:app, --host, 0.0.0.0, --port, 8000] ports: - containerPort: 8000 resources: limits: memory: 512Mi实操工具GitHub Copilot在IDE里写YAML时自动补全ChatGPT/Claude用自然语言描述需求生成完整的K8s YAMLk8sgpt开源工具用AI扫描集群并给出修复建议bash# 安装k8sgpt brew install k8sgpt # 扫描集群问题 k8sgpt analyze --explain # 输出AI分析Pod为什么一直CrashLoopBackOff并给出具体修复建议 AI预测智能自动伸缩KEDA AI传统的HPA基于当前的CPU/内存指标做伸缩决策是被动的——流量来了才开始扩容已经有点晚了。AI驱动的预测性伸缩会分析历史流量模式提前预测高峰主动扩容。yaml# 使用KEDA (Kubernetes Event-driven Autoscaling) AI预测 apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: camp-backend-ai-scaler spec: scaleTargetRef: name: camp-backend triggers: - type: prometheus metricName: http_requests_total threshold: 100 # AI模型会分析历史数据预测未来5分钟的流量 # 提前扩容而不是被动响应实际效果传统HPA流量高峰到来 → 指标上升 → 扩容有延迟用户可能已经感受到卡顿AI预测伸缩AI识别出“每天下午3点流量会翻倍” → 2:55提前扩容 → 用户无感知 AI诊断故障根因分析当一个Pod出问题时传统方式是你去看日志、看事件、看监控凭经验猜测原因。AI可以通过分析海量日志和指标直接告诉你text❌ Pod camp-backend-7d8f9-abc12 处于 CrashLoopBackOff 状态 AI诊断结果 - 根因内存限制512Mi不足以处理当前请求量 - 证据过去1小时内OOMKilled事件出现 7 次 - 建议将 memory.limits 从 512Mi 提升到 1Gi - 同时建议检查代码中是否有内存泄漏重点关注 /api/upload 接口实操工具k8sgpt开源的K8s AI诊断工具Robusta结合Prometheus和AI的自动化运维平台bash# 使用k8sgpt分析特定Pod k8sgpt analyze --namespace camp --pod camp-backend-7d8f9-abc12 --explain # 输出AI分析结果直接告诉你问题和修复建议9.2 AI应用跑在K8s上在K8s中部署AI工作负载除了“AI帮我们管K8s”还有另一个方向——“在K8s上跑AI应用”。现代AI/ML工作负载正大规模迁移到Kubernetes。 AI推理服务部署假设你的CAMP平台想增加一个“智能资产标签”功能——用户上传图片AI自动识别设备类型并打标签。在K8s上部署AI推理服务就像部署普通微服务一样只需多关注GPU资源yamlapiVersion: apps/v1 kind: Deployment metadata: name: ai-inference-service namespace: camp spec: replicas: 2 selector: matchLabels: app: ai-inference template: metadata: labels: app: ai-inference spec: containers: - name: inference image: ghcr.io/camp/ai-classifier:v1.0 ports: - containerPort: 8080 resources: requests: nvidia.com/gpu: 1 # 请求1张GPU limits: nvidia.com/gpu: 1 env: - name: MODEL_PATH value: /models/resnet50.onnx - name: BATCH_SIZE value: 32 volumeMounts: - name: model-storage mountPath: /models volumes: - name: model-storage persistentVolumeClaim: claimName: ai-models-pvc --- # Service暴露AI服务 apiVersion: v1 kind: Service metadata: name: ai-inference-service namespace: camp spec: type: ClusterIP ports: - port: 8080 targetPort: 8080 selector: app: ai-inference关键变化resources里指定了nvidia.com/gpu告诉Kubernetes这个Pod需要GPU需要提前安装NVIDIA GPU Operator让K8s能识别和管理GPU资源 使用KubeflowK8s上的ML平台如果AI服务变得复杂需要模型训练、超参数调优、多版本管理可以使用Kubeflow——专门在K8s上运行AI/ML工作负载的平台。yaml# Kubeflow Pipeline定义自动化AI模型训练→评估→部署 apiVersion: pipelines.kubeflow.org/v1beta1 kind: Pipeline metadata: name: model-training-pipeline spec: tasks: - name: data-preprocessing component: data-prep - name: model-training component: train dependencies: [data-preprocessing] parameters: epochs: 50 learning_rate: 0.001 - name: model-evaluation component: evaluate dependencies: [model-training] - name: model-deployment component: deploy-k8s dependencies: [model-evaluation]Kubeflow让数据科学家也能用K8s他们不需要懂复杂的K8s概念只需定义Pipeline就能完成模型训练和部署。9.3 这个项目如何与AI结合回到我们的CAMP云资产管理平台可以在多个环节引入AI 场景一AI驱动的智能告警用AI分析Prometheus监控数据当检测到异常趋势时主动告警而不是等阈值触发。bash# 部署AI告警引擎 ./scripts/deploy.sh -c aks-dev -e dev -t ai-alerting-v1效果传统告警CPU超过80%才报警 → 可能已经出问题了AI告警AI识别出“CPU增长曲线异常预测10分钟后超限” → 提前预警 场景二智能日志分析把Pod日志接入AI模型自动识别异常日志模式无需人工翻日志。yaml# 在monitoring.yaml中增加AI日志分析组件 - name: ai-log-analyzer image: ghcr.io/camp/log-analyzer:v1 env: - name: OPENAI_API_KEY valueFrom: secretKeyRef: name: ai-secrets key: openai-key - name: LOG_SOURCE value: camp-backend 场景三自然语言查询K8s状态用自然语言查询集群状态AI自动转换成kubectl命令text你“帮我看看camp命名空间下有哪些Pod在跑” AI → 自动执行kubectl get pods -n camp 你“后端服务最近有报错吗” AI → 自动执行kubectl logs -f deployment/camp-backend -n camp --tail50 | grep ERROR 你“帮我把后端的副本数从2扩到5” AI → 自动执行kubectl scale deployment camp-backend --replicas5 -n camp实操工具KubeAIKubernetes的AI助手K8sGPT自然语言查询K8s状态9.4 AI K8s技术栈总览层级AI相关技术作用集群资源层NVIDIA GPU Operator让K8s能调度GPU资源工作负载层Kubeflow, Ray, MLflow在K8s上运行AI训练和推理可观测性层k8sgpt, RobustaAI自动诊断集群问题弹性伸缩层KEDA AI预测模型智能预测性伸缩交互层KubeAI, 自然语言接口用自然语言操作K8s应用层CAMP AI推理服务在资产管理平台中嵌入AI功能9.5 技术展望K8s AI 的未来阶段特征典型能力阶段一当前AI辅助运维YAML智能生成、问题诊断建议、日志智能分析阶段二近未来AI驱动自动化预测性伸缩、自动修复、自动优化资源配置阶段三远期AI原生K8s集群自我优化、零人工干预、意图驱动运维一句话展望未来的Kubernetes集群不再是“你告诉它怎么做”而是“你告诉它你想要什么结果AI帮你实现”。十、写在最后通过这个真实项目的k8s/目录我们完整地看到了Docker和K8s的分工Docker打包K8s调度K8s的核心资源Namespace、Deployment、Service、Ingress、ConfigMap、Secret、PVCK8s如何解决实际问题自愈、负载均衡、滚动更新、配置分离、数据持久化AI如何赋能K8s智能诊断、预测伸缩、自然语言操作、AI工作负载调度一个微服务应用在K8s上完整运行的全貌如果你正在学习Kubernetes不要只背概念去跑一个真实项目。把项目里的YAML文件一个个看过去跑起来改一改看看效果。这才是最快的学习方式。相关文章推荐《别再手动写K8s YAML了Helm保姆级入门指南》《从零理解Kubernetes核心概念Pod、Service、Ingress》《Kubernetes AI智能运维落地实践》本文基于开源项目 kubernetes-microservices 的k8s/目录分析整理。欢迎Star和Fork学习
