入门指南

开发背一半运维：你的 K8s 职责边界在哪 云原生时代，开发工程师的职责边界变了。以前是"写完代码扔给运维"，现在是"应用怎么跑也写进代码"——Dockerfile、探针、资源申请、优雅停机，这些曾经属于运维的东西，现在都是开发要交付的代码的一部分。 但反过来，开发也不该全包运维：集群的节点、证书、网络插件，那不是你的活。这篇给 Java 开发工程师一张清单——必须会什么、不用学什么、Java 专属的坑有哪些、边界到底划在哪。本系列的十篇文章是这个清单的展开，这篇是入口。 1. 一句话框架：开发背一半运维 判断职责归属，用一条标准就够： “我写的这个应用，在集群里能不能健康地跑起来、出问题我自己能不能查”——这是开发的活；“集群本身能不能稳定运转”——这是平台的活。 应用的健康 = 镜像、探针、资源配置、优雅停机、指标暴露——开发用代码负责； 集群的稳定 = 节点、etcd、CNI、证书、升级——平台/运维负责，开发只需要知道它们存在。 至于中小公司没有专职运维、开发被迫全包——那是资源约束下的现实，不是理想的职责划分。能力可以全栈，但边界心里要有数：“运维的事"永远会挤占开发时间，不清边界就会被无限稀释。 2. 必须会：八项清单 每一项都标注了"怎么算会了”——能独立完成才算过关。 # 技能 一句话原理 验证标准 对应文章 1 镜像构建 多阶段 Dockerfile 把构建与运行分离，体积从 500MB 级压到 300MB 级 能写出 JRE 运行镜像，知道层缓存 课1：镜像构建 2 Deployment 声明式滚动更新，改清单而不是手工 docker run 能改镜像滚动升级、回滚 课1：Deployment 实战 3 配置注入 ConfigMap/Secret 让配置外部化，改配置不重建镜像 能注入环境变量和文件，知道 Secret 只是 base64 课3：配置注入 4 Service/Ingress ClusterIP 内部调用、NodePort/LB 对外暴露、Ingress 管域名路由 能说清三种类型各给谁用 课2：Service/Ingress 5 探针 readiness 摘流量、liveness 重启、startup 保护慢启动 能给 Spring Boot 配齐三件套 课4：探针 6 资源申请 requests 管调度、limits 管上限，不设就是裸奔 能给应用填合理数值并解释依据 课5：资源管理 7 优雅停机 readiness 摘流 + preStop 缓冲 + graceful 处理在途 发版时在途请求不断连 课5：优雅停机 8 可观测性 应用暴露指标端点，监控才有意义 能说出 /actuator/prometheus 暴露了什么 课6：可观测性 贯穿八项的还有一个基本功：排障—— kubectl logs 、 kubectl describe 、 kubectl exec 是开发者的手电筒，遇到问题第一反应是"进 Pod 看一眼"而不是"重启试试"。 ...

八篇博客、两台服务器：K8s 学习资产清点 这个系列写到这里，第八篇了。从一台退役的笔记本服务器（i3 双核、7.6G 内存）搭起 kind 集群开始，到 Prometheus 抓出第一根指标曲线、Grafana 画出第一张仪表盘结束——六课实战、八篇博客，一路踩的坑全记在了文章里。 这篇不教新东西，做三件事：清点两台服务器上现在跑着的资产（写文章时我重新登服务器核实过，不是凭记忆）、按课时梳理"看+复现"分别能学到什么、把整个系列的复现成本交代清楚。想入坑的读者可以从这篇倒着挑文章看。 1. 资产清点：两台服务器，各司其职 先说分工：一台云服务器（有公网 IP）当唯一公网入口——跑博客站点、接收反向隧道；一台内网笔记本服务器（没有公网 IP）当学习环境主力——跑 kind 集群和全套监控。本机（开发机）通过 SSH 经云服务器中转，随时能进内网服务器干活。 %% 全局拓扑: 本机 -> 云服务器(入口) -> 内网 debian(学习主力) flowchart TD LAP["本机 Windows + WSL2\n开发写作 + SSH 运维入口"] ECS["云服务器 ECS\n唯一公网入口"] DEB["debian 笔记本服务器\n内网, 学习环境主力"] BLOG["blog-nginx 容器\nyaocat.cloud 博客站点"] MIH["mihomo 代理\n7890/7891/9090"] KIND["kind 集群 learn\n1 主 2 从 v1.36.1"] LAP -->|"SSH 经云服务器中转"| DEB DEB -->|"autossh 常驻加密隧道"| ECS ECS -->|"公网 80/443"| BLOG DEB -->|"拉镜像走代理"| MIH DEB --> KIND 1.1 内网笔记本服务器（学习主力） 写这篇时登上去核实过的真实清单： ...

一主二从的 K8s，kind 半小时就位 想学 Kubernetes，第一道坎不是概念，是环境：三台物理机？买不起。云厂商的托管集群？按小时计费，练手都心疼。直到某开发者把 kind（Kubernetes IN Docker）跑起来——一条命令，一台普通服务器，1 主 2 从三节点集群直接立起来，用完 kind delete cluster 一键销毁，成本几乎为零。 这篇文章完整记录这次实操：硬件要什么配置、国内网络怎么绕过、kind / kubectl / k9s 怎么装、那个 9 行的 YAML 到底在说什么、以及集群里跑起来的每个组件是什么。跟着走一遍，你也能拥有一套属于自己的 K8s 练手环境。 这次要做什么 目标：在一台 Linux 服务器上，用 kind 创建一个 1 控制面 + 2 工作节点的 Kubernetes 集群 产出：kind + kubectl + k9s 三件套，集群可通过 kubectl 正常管理 用途：本地化学习 K8s，为日后云 ECS（阿里云等）快速上手打底 📌 前置知识：需要会用 Linux 基础命令（curl、systemctl、docker）、知道容器是什么。K8s 概念零基础也可以，本文会讲清楚每个装好的组件是干嘛的。 开始之前，先把丑话说在前头——kind 的边界： flowchart LR A["kind 能学"] --> A1["API 对象 / 编排逻辑"] A --> A2["多节点调度 / 污点亲和"] A --> A3["Service / Ingress / 存储抽象"] B["kind 学不到"] --> B1["kubeadm 安装流程"] B --> B2["CNI 插件选型与安装"] B --> B3["证书 / etcd 集群 / HA 高可用"] style A fill:#1e1e24,stroke:#9ca3af,stroke-width:2px,color:#ffffff style A1 fill:#1e1e24,stroke:#9ca3af,stroke-width:2px,color:#ffffff style A2 fill:#1e1e24,stroke:#9ca3af,stroke-width:2px,color:#ffffff style A3 fill:#1e1e24,stroke:#9ca3af,stroke-width:2px,color:#ffffff style B fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#ffffff,font-weight:bold style B1 fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#ffffff,font-weight:bold style B2 fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#ffffff,font-weight:bold style B3 fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#ffffff,font-weight:bold style startEnd fill:#701a4c,stroke:#e11d48,stroke-width:2.5px,color:#ffffff,font-weight:bold kind 是用 Docker 模拟节点（每个"节点"是一个跑着完整 Linux 的容器），所以它教不会你"怎么在裸机上装出 K8s"——那些是上云前的功课，本文不展开。先把 kind 能教的部分学扎实。 ...

Go Web 开发：从 Gin 到微服务 一个 Spring Boot 程序员打开 Go 的 Web 项目，看到的是这样的代码： // 这是什么？Controller 在哪？@Autowired 在哪？ func main() { db, _ := sql.Open("mysql", "user:pass@/dbname") repo := NewUserRepo(db) svc := NewUserService(repo) handler := NewUserHandler(svc) r := gin.Default() r.GET("/users/:id", handler.GetUser) r.Run(":8080") } 没有 @Controller 、没有 @Service 、没有 @Autowired 、没有 application.yml 。依赖是一个个手动拼起来的，路由是函数式注册的，连配置文件都得自己选库来读。 习惯 Spring Boot 全家桶的开发者，第一次面对 Go 的 Web 生态，大概有两类困惑： 框架选型：Gin、Echo、Fiber、Iris、go-zero、Kratos……每个都说自己性能好，到底该用哪个？ 组织方式：没有注解驱动的 DI、没有 AOP、没有 Filter 接口——同样的需求在 Go 里怎么写？ 本文用 Spring Boot/Spring Cloud 的对应视角，把 Go Web 开发的技术栈讲清楚。 ...

Java vs Go：语法对比 打开 .go 文件，第一眼看到这些，脑子直接宕机： func getUser(id int) (*User, error) { if user, ok := cache.Load(id); ok { return user.(*User), nil } defer func() { metrics.Record("getUser") }() // ... } := 是什么？ *User 和 error 为什么挤在返回值里？ defer 又是什么鬼？ ok 从哪冒出来的？ 写了 5 年 Spring Boot，习惯了 var user = new User() 、 try-catch-finally 、 public class 之后，Go 的语法看起来像是故意反着来。这篇文章的目的就是一句话：把所有 Java 里习以为常的语法点，在 Go 里找到对应写法 。没有废话，全是代码对比。 📌 前置知识：本文假定读者有 Java 基础（Java 8+），了解基本的编程概念（变量、函数、循环、异常）。Go 版本为 1.22。 ...

开发者 K8s 全景图 一、目标说明 前四篇文章把 K8s 的概念地基、YAML 编写、探针配置、kubectl 命令全拆完了。这篇是收网篇——把剩下的重要但散落的知识点串起来，然后画一条清晰的线：什么归你管，什么扔给运维。 读完这篇文章，读者能： 写出完整的 Ingress YAML，理解域名路由规则 用 Helm 安装和管理应用（ helm install / upgrade / rollback ） 选择适合自己场景的本地 K8s 环境 知道 StatefulSet、HPA、Job/CronJob、PVC 是干什么的、什么时候需要 认清 Dev vs Ops 的分界线，不再背不该背的锅 二、前置条件 前置条件 要求 理解 Service（ClusterIP/NodePort） 第 0 ~ 1 步已覆盖 会基本的 kubectl 操作 第 3 步已覆盖 了解域名和 HTTP 路径的基本概念 api.example.com/users 这种格式能看懂 三、分步实践 3.1 Ingress —— 域名路由，外部流量的大门 3.1.1 为什么需要 Ingress？ Service 的三种类型： Service 类型 外部访问 问题 ClusterIP 不能 只能集群内用 NodePort 能（ NodeIP:30000-32767 ） 端口丑、不能基于域名路由，一个端口只能绑一个 Service LoadBalancer 能（云 LB 分配公网 IP） 每个 Service 都要创建一个 LB，烧钱 Ingress 解决的问题：用一个入口（一个 LB / 一个公网 IP），根据域名和路径把流量分发到不同的 Service。 ...

Docker 与 K8s：从困惑到搞懂 一、目标说明 这篇文章要解决一个问题：一个从来没碰过容器的后端开发，怎么搞懂 Docker 和 K8s 那一堆名词？ 读完这篇文章，读者能搞清楚以下事情： Docker 的 Image（镜像）和 Container（容器）到底是什么关系 为什么有了 Docker 还不够，还要搞一个 K8s 出来 K8s 的 Master / Worker Node 上各自跑了哪些组件，它们怎么配合 Pod、Deployment、Service、ConfigMap、Secret、Namespace 这些概念分别解决什么问题 一个 kubectl apply 命令背后，K8s 集群里发生了什么 ⚠️ 新手提示：这篇文章不会让你动手敲任何命令。目的是在脑子里建一张"K8s 全景地图"。有了这张地图，后面写 YAML、敲 kubectl 的时候才知道每一行是在操作什么东西。 二、前置条件 读者需要具备以下基础（都很基本）： 前置知识 要求程度 验证方式 Linux 基本命令 会用 cd 、 ls 、 cat 、 ps 打开终端敲一下看看 进程概念 知道一个程序运行起来就是一个进程 打开任务管理器看一眼 IP + 端口 知道 127.0.0.1:8080 是什么意思 用过浏览器访问 localhost 即可 YAML 格式 见过 YAML，知道缩进表示层级 写过 Spring Boot 的 application.yml 就算 如果以上都 OK，往下看。 ...

把 15 步手动操作变成一次 git push 一、⚡ 周五下午 5 点上线——你手动执行了 15 步操作——到第 12 步出错了 回想一下你现在的发布流程： 发布一个微服务的流程： ① git pull latest ② mvn clean package -DskipTests（"测试先跳过——着急"） ③ 手动改 application-prod.yml 中的配置（"这个值上次没改对"） ④ docker build -t order-service:v1.2.3 . ⑤ docker tag order-service:v1.2.3 harbor.internal/order-service:v1.2.3 ⑥ docker push harbor.internal/order-service:v1.2.3 ⑦ ssh root@k8s-master ⑧ kubectl set image deployment/order-service order-service=harbor.internal/order-service:v1.2.3 ⑨ kubectl rollout status deployment/order-service ⑩ curl 验证——啊——404——服务没起来 ⑪ kubectl logs——发现是 application.yml 中的 Nacos 地址配错了 ⑫ kubectl rollout undo——回滚 ⑬ 改配置——重新来——docker build + push + deploy ⑭ 又发现 product-service 没同步上线——接口报错了 ⑮ 告警响了——用户已经在群里骂了 → 每次发布都像拆炸弹——不知道哪一步会出问题 CI/CD 要解决的就是：把人从 15 步中解放出来——每次 git push——自动编译、自动测试、自动构建镜像、自动部署——15 步变成 1 步。 ...

SkyWalking 分布式链路追踪 📖 前置阅读：本文假设读者已了解微服务基本概念和 Docker。如果已搭建 Prometheus + Grafana，理解本文会更快——两者互补。建议先阅读 Prometheus + Grafana 环境搭建与指标采集。 一、⚡ QPS 正常——但用户说"下单很慢"——是哪个服务慢了？ 前两篇搭好了 Prometheus + Grafana——指标面板很漂亮——QPS、RT、错误率一目了然。 但凌晨 3 点的告警是这样的： PagerDuty：order-service P99 延迟从 50ms 涨到 3s——错误率 2%——还没触发告警阈值（5%） 你打开 Grafana： ✅ order-service：QPS 正常——RT 涨了但不知道原因 ✅ user-service：所有指标正常——没问题 ✅ product-service：所有指标正常——没问题 ✅ inventory-service：所有指标正常——没问题 ✅ payment-service：所有指标正常——没问题 → 你盯着仪表盘——所有服务看起来都"还行"——但订单就是慢了 有了 SkyWalking 链路追踪： ① 找到那条慢了 3s 的 /api/orders 请求的完整调用链路 ② 看到调用链：order-service → user-service(50ms) → product-service(45ms) → inventory-service(2800ms!!!) ← 找到了 ③ 展开 inventory-service 的 Span——MySQL SELECT 语句执行了 2.5s ④ 点开 SQL——SELECT * FROM inventory WHERE product_id = ?——没有索引——全表扫描 → 2 分钟定位——加索引——P99 回到 50ms Prometheus 告诉你"出问题了"——SkyWalking 告诉你"为什么出问题"。两者不是替代关系——是互补关系： ...

核心概念与快速上手 一、⚡ 服务多了——两个最头疼的问题 微服务写到第 6 个的时候——你会发现两个问题越来越痛： 问题 ①：服务之间怎么找到对方？ OrderService 调 UserService——以前一个 IP:Port 写死就行了 现在 UserService 有 3 个实例——10.0.1.1:8081、10.0.1.2:8081、10.0.1.3:8081 明天扩容到 5 个——OrderService 难道重新改配置上线？ → 需要"服务发现"——调用方不关心实例在哪——找注册中心问 问题 ②：改了配置怎么让所有服务生效？ 数据库连接池从 20 改到 50——5 个服务 × 3 个实例 = 15 个 yml 文件要改 改完还得一个个重启——重启顺序还不能乱 → 需要"配置中心"——一处修改——所有实例自动感知 这两个问题的答案就是 Nacos——一个组件同时搞定服务发现和配置中心。 二、🧩 Nacos 是什么——一句话 Nacos（NAming and COnfiguration Service）= 服务发现 + 配置中心。它是阿里开源的微服务基础设施——Spring Cloud Alibaba 的核心组件。 在 Nacos 之前——Spring Cloud 微服务需要两个组件： 没有 Nacos 的时代： Eureka（服务注册/发现） + Spring Cloud Config（配置中心） + Spring Cloud Bus（配置刷新） 三个组件——三套配置——三种部署方式 有了 Nacos： Nacos 一个组件 = Eureka + Config + Bus 一套配置——一种部署方式——学习成本砍一半 三、🏗️ 部署 Nacos Server——3 分钟跑起来 # 方式一：Docker——最快 docker run -d \ --name nacos \ -p 8848:8848 \ -p 9848:9848 \ -e MODE=standalone \ nacos/nacos-server:v2.3.0 # 方式二：直接运行——下载后解压 # https://github.com/alibaba/nacos/releases # 解压后 cd nacos/bin # Windows: startup.cmd -m standalone # Linux/Mac: sh startup.sh -m standalone # 访问 http://localhost:8848/nacos # 用户名/密码：nacos/nacos 两个端口的作用： ...