简介这份资源面向具备一定容器与 Linux 基础的运维、云计算及后端开发人员聚焦 Kubernetes 1.13.3 环境下电商微服务的落地部署帮助读者打通从集群搭建到业务上线的完整链路。压缩包共 6 个文件约 950.8MB包含 gz 与 tar 格式的安装包如 JDK、Maven、微服务镜像归档、一份 ingress 控制器相关 yaml 配置以及一份 docx 详细文档笔记覆盖环境准备、服务编排与配置说明等环节。目前已有 223 人学习下载适合作为实战参考。读者可借助其中的安装包快速复现实验环境结合文档笔记理解微服务在 k8s 中的部署流程、资源对象组织方式与常见问题排查思路减少自行摸索成本尤其适合需要完成电商类微服务部署练习或搭建演示环境的技术人员对照使用。1. 从一台裸机到电商微服务跑通这套 k8s 1.13.3 实战包到底值不值得拆如果你手上只有几台干净的 Linux 机器却想完整走一遍「电商微服务从镜像到 Ingress 对外暴露」的全流程这套 k8s 1.13.3 部署电商微服务的实战案例包解决的就是这个从零到跑通的断层问题。它不是一个只丢几个 yaml 的仓库而是把 simple-microservice 的镜像包、Maven 构建环境、JDK、Nginx Ingress Controller 镜像、一份 mandatory 原版 yaml以及一份 docx 笔记一起打包等于把当年一线实施时的工作目录直接压缩给你。适合谁适合正在学 k8s 部署、需要一套能照着敲的电商微服务样例的运维和云计算方向从业者也适合想把微服务架构图落到真实集群上的后端。不适合谁不适合指望它当生产高可用方案的人1.13.3 这个版本本身就带着明显的时代印记后面我会讲清楚边界在哪。2. 拆包先看清单每个文件在部署链路里站什么位置拿到压缩包别急着解压完就 kubectl apply先搞清楚每个文件在整条链路里的角色不然报错时你连该查哪一层都不知道。这套资源里的文件不是随便堆的它们对应的是「构建 → 镜像 → 编排 → 入口」四段式流程缺一段都跑不起来。2.1 安装包与镜像文件的对应关系先把包里的东西按用途分个类下面这张表是我拆完之后整理的对应关系你照着对一遍就知道自己缺什么。文件类型在链路中的作用simple-microservice_all.tar.gz镜像归档电商微服务各模块的 Docker 镜像docker load 后直接用nginx-ingress-controller.tar镜像归档Ingress 控制器镜像负责七层入口转发apache-maven-3.5.3-bin.tar.gz构建工具编译 Java 微服务源码用版本锁死在 3.5.3jdk-8u144-linux-x64.tar.gz运行时Java 微服务的 JDK8u144 对应老版本编译产物mandatory-原.yaml编排清单核心 Deployment/Service 定义部署的主骨架k8s1.13.3部署电商微服务.docx文档笔记操作步骤与参数记录排错时的第一手参考这张表里最容易被忽略的是版本匹配。JDK 8u144 和 Maven 3.5.3 不是随便选的它们和 simple-microservice 里编译出来的 class 文件版本是对齐的。你如果拿 JDK 11 去跑很可能在启动阶段就抛 UnsupportedClassVersionError这不是集群的问题是运行时版本对不上。2.2 镜像加载与命名规范镜像 tar 包加载进来之后名字和 tag 必须和 yaml 里 image 字段完全一致否则 Pod 会卡在 ImagePullBackOff。常见做法是先 load 再 inspect确认 RepoTag。# 加载微服务镜像归档 docker load -i simple-microservice_all.tar.gz # 加载 ingress 控制器镜像 docker load -i nginx-ingress-controller.tar # 查看加载后的镜像列表确认 REPOSITORY 和 TAG docker images | grep -E microservice|ingress逻辑说明docker load 会把 tar 里的镜像层导入本地镜像库但不会自动改名字。参数上-i 指定输入文件。执行完必须用 docker images 核对因为很多 tar 包导出时带的是临时 tag而 mandatory-原.yaml 里写的是正式名字两边对不上就会拉取失败。如果发现名字不一致用 docker tag 旧名 新名 手动对齐再继续。2.3 mandatory 原版 yaml 的结构预读在 apply 之前先把 yaml 里的关键字段过一遍尤其是 namespace、image、service 端口这三处。我一般会先 dry-run 一遍把语法和字段问题提前暴露。# 只做语法与字段校验不真正提交 kubectl apply -f mandatory-原.yaml --dry-run --validatetrue # 查看清单里定义了哪些资源类型 grep -E ^kind: mandatory-原.yaml | sort | uniq -c逻辑说明--dry-run 让 apiserver 走一遍校验但不落库能在正式部署前抓出字段拼写、apiVersion 不匹配这类低级错误。--validatetrue 是默认行为显式写出来是为了提醒自己别关掉。第二条命令统计资源类型能快速判断这份 yaml 是只定义了 Deployment还是把 Service、Ingress 一起包了。如果发现缺 Service那对外访问就得自己补这是后面避坑章要展开的点。3. 部署实操从镜像到 Ingress 打通电商微服务入口这一章是整套资源的核心把镜像、编排、入口三段串起来。节奏上我会按真实实施顺序走先确认集群状态再落微服务最后配 Ingress。每一步都给出可抄的命令和参数解释你照着改改就能用。3.1 集群前置检查与命名空间准备k8s 1.13.3 这个版本对 kubectl 和集群的版本差比较敏感先确认两边版本再建独立命名空间避免和默认空间里的东西混在一起。# 查看集群与客户端版本 kubectl version --short # 查看节点状态确认 Ready kubectl get nodes -o wide # 创建独立命名空间 kubectl create namespace ecommerce逻辑说明kubectl version --short 会分别打印 Client 和 Server 版本1.13.3 集群配 1.20 的 kubectl 有时会出现 apiVersion 协商问题尽量让两边大版本接近。get nodes -o wide 除了看 Ready还要看 INTERNAL-IP后面配 Ingress 和 Service 时可能用到。命名空间单独建是为了隔离电商微服务模块多混在 default 里排错会很痛苦。参数上 namespace 名字自己定但后面所有命令都要带 -n ecommerce别忘了。3.2 微服务 Deployment 与 Service 落地把 mandatory 原版 yaml 里的镜像名、命名空间对齐后提交。如果 yaml 里没写 namespace用 -n 参数指定或者提前改文件。# 提交核心编排清单到指定命名空间 kubectl apply -f mandatory-原.yaml -n ecommerce # 观察 Pod 启动过程 kubectl get pods -n ecommerce -w # 查看 Service 暴露情况 kubectl get svc -n ecommerce逻辑说明apply 是声明式提交重复执行不会报错适合反复调试。-w 是 watch 模式能实时看到 Pod 从 Pending 到 Running 的过程卡在哪一步一目了然。get svc 看的是 ClusterIP 和端口映射电商微服务一般会有多个 Service注意区分前端网关和后端业务模块。如果 Pod 一直 Pending先 describe 看 Events多半是资源不足或镜像拉取问题。3.3 Ingress 控制器部署与入口规则配置微服务在集群内跑起来只是第一步对外能访问才算打通。Nginx Ingress Controller 镜像已经给你了部署完再配 Ingress 规则。# 加载并确认 ingress 控制器镜像 docker images | grep nginx-ingress # 部署 ingress 控制器假设已有对应 yaml或用官方 manifest 对齐版本 kubectl apply -f nginx-ingress-controller.yaml # 查看控制器 Pod 是否 Running kubectl get pods -n ingress-nginx逻辑说明Ingress 控制器本质是一个跑在集群里的 Nginx它监听 Ingress 资源变化并动态生成转发规则。镜像 tar 给你省去了拉取环节但控制器的 yaml 需要和 1.13.3 的 apiVersion 对齐常见做法是参考官方对应版本的 deploy.yaml。控制器 Pod 起来后再写 Ingress 规则把域名或路径指向电商微服务的 Service。参数上注意 ingress-class 注解多个控制器共存时要指定用哪个。# Ingress 规则示例把电商前端路径转发到对应 Service apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ecommerce-ingress namespace: ecommerce annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: shop.example.local http: paths: - path: / backend: serviceName: frontend-svc servicePort: 80逻辑说明1.13.3 时代 Ingress 还是 extensions/v1beta1新版集群里这个 apiVersion 已经废弃这是版本边界后面会再提。annotations 里指定 ingress.class 是为了让规则被正确的控制器接管。host 用本地 hosts 解析就能测serviceName 和 servicePort 必须和前面 get svc 看到的一致写错就是 503。4. 避坑与排查这套老版本资源最容易翻车的五个点这套资源的价值在于完整但它的坑也恰恰来自「老」。下面五条是我拆包和复现过程中最常遇到的每条按现象、原因、解决来写你对照着排。4.1 Pod 一直 ImagePullBackOff现象kubectl get pods 显示 ImagePullBackOff 或 ErrImagePulldescribe 里提示 manifest unknown。原因镜像 tar 加载后的名字和 yaml 里 image 字段不一致或者 tag 是 none。解决docker images 核对实际 RepoTag用 docker tag 改成 yaml 里写的名字再重新 apply。如果节点是多台记得每台都要 load或者推到内网 registry 统一拉取。4.2 Ingress 返回 503 Service Temporarily Unavailable现象域名能解析到入口但访问返回 503。原因Ingress 规则里的 serviceName 或 servicePort 和实际 Service 对不上或者 Service 的 Endpoints 为空。解决先 kubectl get endpoints -n ecommerce 看后端有没有挂上 Pod再看 Ingress 的 backend 字段是否和 get svc 输出一致。端口写错是最常见的Service 的 port 和 targetPort 别混。4.3 JDK 版本不匹配导致启动即退出现象Pod 起来几秒就 CrashLoopBackOfflogs 里报 UnsupportedClassVersionError。原因镜像里打包的 class 是用 JDK 8 编译的但基础镜像或运行环境用了更高版本或者反过来。解决确认镜像内 JDK 版本和 jdk-8u144 对齐Dockerfile 里显式指定 JAVA_HOME。这套资源给的就是 8u144别自作主张换版本。4.4 apiVersion 在集群里不识别现象apply 时报 no matches for kind Deployment in version extensions/v1beta1。原因mandatory 原版 yaml 是按 1.13.3 写的如果你拿到新版集群上跑很多 apiVersion 已经废弃。解决要么老老实实用 1.13.3 集群复现要么把 apiVersion 手动迁移到 apps/v1 并补上 selector 字段。这是版本边界不是资源本身的错。4.5 节点资源不足导致 Pod Pending现象Pod 长时间 Pendingdescribe 显示 Insufficient cpu 或 Insufficient memory。原因电商微服务模块多每个 Deployment 都设了 requests小机器扛不住。解决先 kubectl describe node 看已分配资源再适当调低 yaml 里的 requests或者加节点。别直接删 requests那会让调度失去依据生产上是大忌。5. 进阶用法把这份资源当模板改造成自己的微服务样例拆完这套包最有价值的用法不是原样跑一遍而是把它当成一个可复用的模板骨架。我一般会做三件事把镜像构建流程抽出来、把 yaml 参数化、把 Ingress 规则改成多路径路由。下面给一个参数化的思路用 envsubst 或 helm 都能实现这里用最轻量的方式演示。# 用环境变量替换 yaml 里的占位符实现一套清单多环境复用 export IMAGE_TAGv1 export NAMESPACEecommerce-test envsubst mandatory-template.yaml | kubectl apply -n ${NAMESPACE} -f -逻辑说明envsubst 会把 yaml 里的 ${IMAGE_TAG}、${NAMESPACE} 替换成实际值这样同一份模板能在测试和生产之间切换不用手改文件。参数上IMAGE_TAG 控制镜像版本NAMESPACE 控制部署位置。前提是你先把 mandatory 原版 yaml 里的硬编码值改成占位符这一步是一次性投入后面省很多事。再进一步验证部署是否真的健康别只看 Pod Running。我习惯用一条组合命令做冒烟检查# 冒烟检查Pod 状态、Service 端点、Ingress 规则一次看全 kubectl get pods,svc,ingress -n ecommerce -o wide kubectl get endpoints -n ecommerce逻辑说明第一条把三类资源一起列出来-o wide 能看到 IP 和节点信息。第二条专门看 Endpoints这是判断 Service 有没有真正挂上后端的关键。Pod Running 不代表 Service 可用Endpoints 为空的话 Ingress 照样 503。这两条命令我每次部署完都强制走一遍比事后翻日志快得多。最后说个我自己的习惯。这套 1.13.3 的资源我拆过不止一次每次都会先把 docx 笔记通读一遍再动手因为里面记的参数和顺序是当年实施时踩出来的比你自己试错快。从那以后我每次拿到这种带文档的实战包都强制先读文档再敲命令省下的排错时间远超读文档的那点功夫。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源面向具备一定容器与 Linux 基础的运维、云计算及后端开发人员聚焦 Kubernetes 1.13.3 环境下电商微服务的落地部署帮助读者打通从集群搭建到业务上线的完整链路。压缩包共 6 个文件约 950.8MB包含 gz 与 tar 格式的安装包如 JDK、Maven、微服务镜像归档、一份 ingress 控制器相关 yaml 配置以及一份 docx 详细文档笔记覆盖环境准备、服务编排与配置说明等环节。目前已有 223 人学习下载适合作为实战参考。读者可借助其中的安装包快速复现实验环境结合文档笔记理解微服务在 k8s 中的部署流程、资源对象组织方式与常见问题排查思路减少自行摸索成本尤其适合需要完成电商类微服务部署练习或搭建演示环境的技术人员对照使用。1. 从一台裸机到电商微服务跑通这套 k8s 1.13.3 实战包到底值不值得拆如果你手上只有几台干净的 Linux 机器却想完整走一遍「电商微服务从镜像到 Ingress 对外暴露」的全流程这套 k8s 1.13.3 部署电商微服务的实战案例包解决的就是这个从零到跑通的断层问题。它不是一个只丢几个 yaml 的仓库而是把 simple-microservice 的镜像包、Maven 构建环境、JDK、Nginx Ingress Controller 镜像、一份 mandatory 原版 yaml以及一份 docx 笔记一起打包等于把当年一线实施时的工作目录直接压缩给你。适合谁适合正在学 k8s 部署、需要一套能照着敲的电商微服务样例的运维和云计算方向从业者也适合想把微服务架构图落到真实集群上的后端。不适合谁不适合指望它当生产高可用方案的人1.13.3 这个版本本身就带着明显的时代印记后面我会讲清楚边界在哪。2. 拆包先看清单每个文件在部署链路里站什么位置拿到压缩包别急着解压完就 kubectl apply先搞清楚每个文件在整条链路里的角色不然报错时你连该查哪一层都不知道。这套资源里的文件不是随便堆的它们对应的是「构建 → 镜像 → 编排 → 入口」四段式流程缺一段都跑不起来。2.1 安装包与镜像文件的对应关系先把包里的东西按用途分个类下面这张表是我拆完之后整理的对应关系你照着对一遍就知道自己缺什么。文件类型在链路中的作用simple-microservice_all.tar.gz镜像归档电商微服务各模块的 Docker 镜像docker load 后直接用nginx-ingress-controller.tar镜像归档Ingress 控制器镜像负责七层入口转发apache-maven-3.5.3-bin.tar.gz构建工具编译 Java 微服务源码用版本锁死在 3.5.3jdk-8u144-linux-x64.tar.gz运行时Java 微服务的 JDK8u144 对应老版本编译产物mandatory-原.yaml编排清单核心 Deployment/Service 定义部署的主骨架k8s1.13.3部署电商微服务.docx文档笔记操作步骤与参数记录排错时的第一手参考这张表里最容易被忽略的是版本匹配。JDK 8u144 和 Maven 3.5.3 不是随便选的它们和 simple-microservice 里编译出来的 class 文件版本是对齐的。你如果拿 JDK 11 去跑很可能在启动阶段就抛 UnsupportedClassVersionError这不是集群的问题是运行时版本对不上。2.2 镜像加载与命名规范镜像 tar 包加载进来之后名字和 tag 必须和 yaml 里 image 字段完全一致否则 Pod 会卡在 ImagePullBackOff。常见做法是先 load 再 inspect确认 RepoTag。# 加载微服务镜像归档 docker load -i simple-microservice_all.tar.gz # 加载 ingress 控制器镜像 docker load -i nginx-ingress-controller.tar # 查看加载后的镜像列表确认 REPOSITORY 和 TAG docker images | grep -E microservice|ingress逻辑说明docker load 会把 tar 里的镜像层导入本地镜像库但不会自动改名字。参数上-i 指定输入文件。执行完必须用 docker images 核对因为很多 tar 包导出时带的是临时 tag而 mandatory-原.yaml 里写的是正式名字两边对不上就会拉取失败。如果发现名字不一致用 docker tag 旧名 新名 手动对齐再继续。2.3 mandatory 原版 yaml 的结构预读在 apply 之前先把 yaml 里的关键字段过一遍尤其是 namespace、image、service 端口这三处。我一般会先 dry-run 一遍把语法和字段问题提前暴露。# 只做语法与字段校验不真正提交 kubectl apply -f mandatory-原.yaml --dry-run --validatetrue # 查看清单里定义了哪些资源类型 grep -E ^kind: mandatory-原.yaml | sort | uniq -c逻辑说明--dry-run 让 apiserver 走一遍校验但不落库能在正式部署前抓出字段拼写、apiVersion 不匹配这类低级错误。--validatetrue 是默认行为显式写出来是为了提醒自己别关掉。第二条命令统计资源类型能快速判断这份 yaml 是只定义了 Deployment还是把 Service、Ingress 一起包了。如果发现缺 Service那对外访问就得自己补这是后面避坑章要展开的点。3. 部署实操从镜像到 Ingress 打通电商微服务入口这一章是整套资源的核心把镜像、编排、入口三段串起来。节奏上我会按真实实施顺序走先确认集群状态再落微服务最后配 Ingress。每一步都给出可抄的命令和参数解释你照着改改就能用。3.1 集群前置检查与命名空间准备k8s 1.13.3 这个版本对 kubectl 和集群的版本差比较敏感先确认两边版本再建独立命名空间避免和默认空间里的东西混在一起。# 查看集群与客户端版本 kubectl version --short # 查看节点状态确认 Ready kubectl get nodes -o wide # 创建独立命名空间 kubectl create namespace ecommerce逻辑说明kubectl version --short 会分别打印 Client 和 Server 版本1.13.3 集群配 1.20 的 kubectl 有时会出现 apiVersion 协商问题尽量让两边大版本接近。get nodes -o wide 除了看 Ready还要看 INTERNAL-IP后面配 Ingress 和 Service 时可能用到。命名空间单独建是为了隔离电商微服务模块多混在 default 里排错会很痛苦。参数上 namespace 名字自己定但后面所有命令都要带 -n ecommerce别忘了。3.2 微服务 Deployment 与 Service 落地把 mandatory 原版 yaml 里的镜像名、命名空间对齐后提交。如果 yaml 里没写 namespace用 -n 参数指定或者提前改文件。# 提交核心编排清单到指定命名空间 kubectl apply -f mandatory-原.yaml -n ecommerce # 观察 Pod 启动过程 kubectl get pods -n ecommerce -w # 查看 Service 暴露情况 kubectl get svc -n ecommerce逻辑说明apply 是声明式提交重复执行不会报错适合反复调试。-w 是 watch 模式能实时看到 Pod 从 Pending 到 Running 的过程卡在哪一步一目了然。get svc 看的是 ClusterIP 和端口映射电商微服务一般会有多个 Service注意区分前端网关和后端业务模块。如果 Pod 一直 Pending先 describe 看 Events多半是资源不足或镜像拉取问题。3.3 Ingress 控制器部署与入口规则配置微服务在集群内跑起来只是第一步对外能访问才算打通。Nginx Ingress Controller 镜像已经给你了部署完再配 Ingress 规则。# 加载并确认 ingress 控制器镜像 docker images | grep nginx-ingress # 部署 ingress 控制器假设已有对应 yaml或用官方 manifest 对齐版本 kubectl apply -f nginx-ingress-controller.yaml # 查看控制器 Pod 是否 Running kubectl get pods -n ingress-nginx逻辑说明Ingress 控制器本质是一个跑在集群里的 Nginx它监听 Ingress 资源变化并动态生成转发规则。镜像 tar 给你省去了拉取环节但控制器的 yaml 需要和 1.13.3 的 apiVersion 对齐常见做法是参考官方对应版本的 deploy.yaml。控制器 Pod 起来后再写 Ingress 规则把域名或路径指向电商微服务的 Service。参数上注意 ingress-class 注解多个控制器共存时要指定用哪个。# Ingress 规则示例把电商前端路径转发到对应 Service apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ecommerce-ingress namespace: ecommerce annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: shop.example.local http: paths: - path: / backend: serviceName: frontend-svc servicePort: 80逻辑说明1.13.3 时代 Ingress 还是 extensions/v1beta1新版集群里这个 apiVersion 已经废弃这是版本边界后面会再提。annotations 里指定 ingress.class 是为了让规则被正确的控制器接管。host 用本地 hosts 解析就能测serviceName 和 servicePort 必须和前面 get svc 看到的一致写错就是 503。4. 避坑与排查这套老版本资源最容易翻车的五个点这套资源的价值在于完整但它的坑也恰恰来自「老」。下面五条是我拆包和复现过程中最常遇到的每条按现象、原因、解决来写你对照着排。4.1 Pod 一直 ImagePullBackOff现象kubectl get pods 显示 ImagePullBackOff 或 ErrImagePulldescribe 里提示 manifest unknown。原因镜像 tar 加载后的名字和 yaml 里 image 字段不一致或者 tag 是 none。解决docker images 核对实际 RepoTag用 docker tag 改成 yaml 里写的名字再重新 apply。如果节点是多台记得每台都要 load或者推到内网 registry 统一拉取。4.2 Ingress 返回 503 Service Temporarily Unavailable现象域名能解析到入口但访问返回 503。原因Ingress 规则里的 serviceName 或 servicePort 和实际 Service 对不上或者 Service 的 Endpoints 为空。解决先 kubectl get endpoints -n ecommerce 看后端有没有挂上 Pod再看 Ingress 的 backend 字段是否和 get svc 输出一致。端口写错是最常见的Service 的 port 和 targetPort 别混。4.3 JDK 版本不匹配导致启动即退出现象Pod 起来几秒就 CrashLoopBackOfflogs 里报 UnsupportedClassVersionError。原因镜像里打包的 class 是用 JDK 8 编译的但基础镜像或运行环境用了更高版本或者反过来。解决确认镜像内 JDK 版本和 jdk-8u144 对齐Dockerfile 里显式指定 JAVA_HOME。这套资源给的就是 8u144别自作主张换版本。4.4 apiVersion 在集群里不识别现象apply 时报 no matches for kind Deployment in version extensions/v1beta1。原因mandatory 原版 yaml 是按 1.13.3 写的如果你拿到新版集群上跑很多 apiVersion 已经废弃。解决要么老老实实用 1.13.3 集群复现要么把 apiVersion 手动迁移到 apps/v1 并补上 selector 字段。这是版本边界不是资源本身的错。4.5 节点资源不足导致 Pod Pending现象Pod 长时间 Pendingdescribe 显示 Insufficient cpu 或 Insufficient memory。原因电商微服务模块多每个 Deployment 都设了 requests小机器扛不住。解决先 kubectl describe node 看已分配资源再适当调低 yaml 里的 requests或者加节点。别直接删 requests那会让调度失去依据生产上是大忌。5. 进阶用法把这份资源当模板改造成自己的微服务样例拆完这套包最有价值的用法不是原样跑一遍而是把它当成一个可复用的模板骨架。我一般会做三件事把镜像构建流程抽出来、把 yaml 参数化、把 Ingress 规则改成多路径路由。下面给一个参数化的思路用 envsubst 或 helm 都能实现这里用最轻量的方式演示。# 用环境变量替换 yaml 里的占位符实现一套清单多环境复用 export IMAGE_TAGv1 export NAMESPACEecommerce-test envsubst mandatory-template.yaml | kubectl apply -n ${NAMESPACE} -f -逻辑说明envsubst 会把 yaml 里的 ${IMAGE_TAG}、${NAMESPACE} 替换成实际值这样同一份模板能在测试和生产之间切换不用手改文件。参数上IMAGE_TAG 控制镜像版本NAMESPACE 控制部署位置。前提是你先把 mandatory 原版 yaml 里的硬编码值改成占位符这一步是一次性投入后面省很多事。再进一步验证部署是否真的健康别只看 Pod Running。我习惯用一条组合命令做冒烟检查# 冒烟检查Pod 状态、Service 端点、Ingress 规则一次看全 kubectl get pods,svc,ingress -n ecommerce -o wide kubectl get endpoints -n ecommerce逻辑说明第一条把三类资源一起列出来-o wide 能看到 IP 和节点信息。第二条专门看 Endpoints这是判断 Service 有没有真正挂上后端的关键。Pod Running 不代表 Service 可用Endpoints 为空的话 Ingress 照样 503。这两条命令我每次部署完都强制走一遍比事后翻日志快得多。最后说个我自己的习惯。这套 1.13.3 的资源我拆过不止一次每次都会先把 docx 笔记通读一遍再动手因为里面记的参数和顺序是当年实施时踩出来的比你自己试错快。从那以后我每次拿到这种带文档的实战包都强制先读文档再敲命令省下的排错时间远超读文档的那点功夫。希望帮到你。本文还有配套的精品资源点击获取
