1. 项目概述一个容器化时代的“瑞士军刀”训练营如果你在容器技术尤其是Docker和Kubernetes的领域里摸爬滚打过一阵子大概率会听说过“jpetazzo”这个名字。Jérôme Petazzoni这位前Docker核心工程师在社区里留下的不仅是技术贡献更有一套被无数开发者奉为圭臬的实战教程——jpetazzo/container.training。这不仅仅是一个GitHub仓库它更像是一个精心设计的、开箱即用的“容器化训练营”旨在将你从对容器概念的一知半解一路带到能够自信地构建、编排和管理生产级应用。这个项目的核心价值在于其场景化和实操性。它没有停留在枯燥的概念讲解上而是通过一系列精心编排的幻灯片、讲义和配套的、可直接运行的Docker Compose环境模拟了从单容器应用到复杂微服务编排的完整生命周期。无论是个人开发者想系统学习还是团队负责人需要一套标准化的内部培训材料container.training都提供了一个近乎完美的起点。它解决的正是“学了理论却不知如何下手”、“教程环境配置复杂劝退”这类普遍痛点让你能在一个干净、一致的环境中专注于技术本身快速获得正反馈。2. 核心内容架构与设计哲学2.1 模块化与渐进式学习路径container.training的内容组织体现了极强的教学逻辑。它不是一本平铺直叙的教科书而是一个模块化的知识图谱。整个教程大致可以分为几个核心阶段容器基础与Docker核心从“为什么需要容器”讲起深入浅出地剖析镜像、容器、仓库、网络、存储卷等核心概念。这里不仅仅是命令的罗列更重要的是解释每个操作背后的原理比如UnionFS如何工作、容器网络命名空间如何实现隔离。镜像构建最佳实践这是区分新手和老鸟的关键。教程会带你超越简单的Dockerfile探讨多阶段构建以减少镜像体积、合理利用构建缓存加速、安全扫描Security Scanning以及如何编写可维护的Dockerfile。例如它会强调使用特定的标签如alpine:3.18而非latest以及以非root用户运行进程等安全实践。容器编排入门与实践从手动管理多个容器的痛点自然过渡到编排工具。这里重点介绍了Docker Compose作为开发和小型部署的利器。教程会通过一个多服务应用比如包含Web前端、API后端和数据库的实例完整展示如何定义服务、配置网络和卷。Kubernetes深度探索这是项目的重头戏。它从Kubernetes的核心抽象Pod、Deployment、Service、Ingress等开始通过大量的kubectl命令和YAML文件示例让你理解声明式API的魅力。更重要的是它提供了在本地一键部署的Kubernetes练习环境通常基于k3d或minikube让你可以无风险地练习所有操作。生产环境考量与高级主题涉及日志收集如Fluentd/Elasticsearch/Kibana栈、监控Prometheus/Grafana、安全Secrets管理、Pod安全策略、CI/CD流水线集成等。这部分内容将你的技能从“会用”提升到“用好”。注意项目的部分高级内容或演示可能依赖于特定的云服务商如AWS ECS/EKS Google GKE的集成示例在学习时需要注意区分通用知识和平台特定实现。2.2 环境设计一切为了零摩擦上手这个项目最受赞誉的一点是其环境设计。传统的教程往往在“环境准备”这一步就卡住了很多人。container.training通过预配置的Docker Compose文件解决了所有依赖问题。当你克隆仓库并执行docker-compose up -d后通常会启动以下服务演示应用一个或多个用于练习的目标应用。辅助工具可能包括一个内置的代码编辑器如Code-Server、一个幻灯片展示服务用于播放教程内容、甚至是一个简单的注册表。练习环境对于Kubernetes部分Compose文件可能会启动一个轻量级的K8s集群如k3d在容器中运行并自动配置好kubectl的访问权限。这意味着你只需要在本地安装好Docker和Docker Compose剩下的所有事情——包括复杂的Kubernetes集群——都会由容器自动准备妥当。这种设计将学习者的心智负担降到最低可以立即开始动手操作极大地提升了学习效率和积极性。3. 核心实操从零到一运行你的训练营3.1 本地环境准备与启动假设你使用一台Linux或macOS的机器Windows用户建议使用WSL2以下是标准的启动流程# 1. 克隆仓库到本地 git clone https://github.com/jpetazzo/container.training.git cd container.training # 2. 切换到包含docker-compose.yml的目录通常在主目录或某个子目录下例如对于标准练习环境 # 你需要根据想学习的模块选择正确的目录。一个常见的起点是 cd slides # 3. 启动整个训练环境 docker-compose up -d执行完毕后使用docker-compose ps命令查看所有运行中的服务。通常会有一个服务映射了本地端口比如8080到容器的幻灯片服务。此时打开浏览器访问http://localhost:8080你就能看到交互式的教程幻灯片了。3.2 跟随教程进行动手实验教程幻灯片通常是交互式的HTML页面左侧是导航大纲右侧是内容。关键在于很多幻灯片页面都嵌入了“实战练习”部分。例如在讲解docker run命令时页面下方可能会直接给出一个终端模拟器或者指示你切换到之前docker-compose启动的“练习容器”中执行命令。一个典型的学习循环是阅读概念在幻灯片上学习一个概念例如什么是Docker卷。查看示例幻灯片给出一个命令示例docker run -v /宿主机路径:/容器路径 ...。动手执行切换到项目提供的练习终端可能通过docker-compose exec进入特定容器直接运行该命令并观察结果。完成挑战教程经常会提出一些小挑战比如“使用卷来持久化一个数据库的数据”让你独立完成巩固知识。对于Kubernetes部分环境通常会为你配置好一个名为k8s的命名空间并自动设置好kubectl的上下文。你可以直接使用kubectl get pods -n k8s来查看练习集群的状态然后根据幻灯片指示创建和修改资源。3.3 自定义与探索基础教程完成后这个环境本身就是一个极佳的沙盒。你可以修改演示应用找到演示应用的源代码目录修改代码然后重新构建镜像观察容器行为的变化。实验不同的编排配置修改docker-compose.yml文件尝试添加新的服务、改变网络配置或卷挂载方式。破坏与恢复故意“制造故障”如停止关键容器进程、删除Pod然后练习如何排查和恢复。这是理解系统弹性的最好方式。集成其他工具尝试在现有的Compose环境中加入Prometheus进行监控或加入Jaeger进行链路追踪将学到的知识串联起来。4. 深度解析超越命令行的理解4.1 Dockerfile多阶段构建的实战精要教程中会强调多阶段构建但这里可以展开一些更深入的实操心得。假设我们要构建一个Go应用# 第一阶段构建阶段 FROM golang:1.21-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o myapp . # 第二阶段运行阶段 FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --frombuilder /app/myapp . EXPOSE 8080 CMD [./myapp]为什么这么做最终镜像极小第一阶段包含了完整的Go编译工具链镜像可能超过300MB。但第二阶段只从第一阶段复制了编译好的二进制文件myapp并基于极简的alpine镜像最终镜像可能只有10MB左右。这极大地减少了镜像拉取和存储的开销。安全性提升最终运行环境不包含编译器、源代码等任何构建时依赖减少了攻击面。构建缓存优化将COPY go.mod go.sum ./和RUN go mod download单独放在COPY . .之前意味着只要go.mod和go.sum不变go mod download这一耗时步骤就可以利用Docker的构建缓存极大加速后续构建。实操心得在CI/CD流水线中可以为“构建阶段”和“运行阶段”使用不同的镜像仓库标签策略。例如构建阶段的中间镜像可以打上-builder标签并定期清理而最终产物只推送运行阶段的小镜像。4.2 Kubernetes Service与Ingress的流量管理内幕教程会教你创建Service和Ingress但理解流量如何流动至关重要。Service本质上是一个位于Pod前端的、稳定的网络抽象和负载均衡器。当你创建ClusterIP类型的Service时Kubernetes会做两件事分配一个虚拟IPVIP这个IP只在集群内可路由。更新每个节点上的kube-proxy组件规则可以是iptables或ipvs模式使得发往该VIP的流量被均匀地转发到后端Pod的真实IP上。注意kube-proxy的iptables模式在服务数量非常多时数千个可能会产生性能问题此时可以考虑切换到ipvs模式。Ingress它不是一个服务类型而是一个API对象管理着对集群内服务的外部HTTP/HTTPS访问。它需要Ingress Controller如Nginx Ingress Controller、Traefik来具体实现。Ingress规则定义了主机名、路径与后端Service的映射关系。一个常见误区认为创建了Ingress资源就万事大吉。你必须确保对应的Ingress Controller Pod正在运行。在container.training的环境里这通常是预先部署好的。实操技巧在调试Ingress问题时可以先检查Ingress Controller的日志kubectl logs -n ingress-nginx ingress-controller-pod-name。下表对比了不同服务类型和入口资源的适用场景资源类型主要作用访问范围典型场景ClusterIP内部服务发现与负载均衡仅集群内部微服务间的内部通信如API服务调用数据库服务NodePort通过节点IP和静态端口暴露服务集群外部可访问开发测试或需要固定端口的遗留系统集成LoadBalancer通过云供应商的负载均衡器暴露服务公网或内网在公有云上暴露公网服务Ingress基于HTTP/HTTPS主机名和路径的路由集群外部HTTP/S对外提供Web服务一个IP承载多个域名/应用5. 常见问题与故障排查实录即使在一个预配置好的完美环境里动手实验时也难免会遇到问题。以下是我在多次使用和教学过程中总结的常见“坑点”及解决方案。5.1 环境启动与连接问题问题docker-compose up失败提示端口冲突。排查container.training的Compose文件可能固定使用了某些端口如8080用于幻灯片8000用于应用。使用netstat -tulpn | grep :8080Linux或lsof -i :8080macOS查看哪个进程占用了该端口。解决要么停止占用端口的本地进程要么修改docker-compose.yml文件将服务端口映射改为其他可用端口例如8081:8080。问题能访问幻灯片但里面的终端无法连接或无法执行命令。排查这通常是因为Web终端服务如ttyd没有正常启动或者浏览器与终端服务的WebSocket连接被阻断。解决检查docker-compose ps确认所有服务状态都是Up。查看终端服务容器的日志docker-compose logs ttyd服务名可能不同。尝试禁用浏览器的广告拦截插件或安全扩展它们有时会拦截WebSocket连接。5.2 Docker与Kubernetes命令执行问题问题在练习容器内docker命令执行报错“Cannot connect to the Docker daemon”。原因练习容器需要访问宿主机的Docker守护进程来执行命令。这通过将宿主机的/var/run/docker.sock文件挂载到容器内实现。解决确保Compose文件中包含了类似- /var/run/docker.sock:/var/run/docker.sock的卷挂载。同时注意容器内用户是否有权限访问该socket文件。问题kubectl命令报错“The connection to the server x.x.x.x was refused”。排查这表示kubectl无法连接到Kubernetes API Server。在container.training的K3s环境中首先检查K3s server容器是否运行正常。解决docker-compose ps检查k3s-server服务状态。进入该容器查看日志docker-compose logs k3s-server。确认kubectl的配置是否正确。环境通常会自动配置但你可以检查cat ~/.kube/config或kubectl config view。确保server地址指向正确的容器IP和端口通常是6443。5.3 应用部署与访问问题问题部署了Deployment和Service但通过curl或浏览器无法访问。系统化排查流程查Podkubectl get pods -o wide。确认Pod状态是Running且READY是1/1或2/2等。如果状态是CrashLoopBackOff查看Pod日志kubectl logs pod-name。查Servicekubectl describe svc service-name。检查Selector是否与Pod的labels匹配。检查Endpoints部分是否有IP地址列表有列表说明Service找到了后端Pod。查网络从集群内部另一个Pod可以临时运行一个busyboxPod尝试curlService的ClusterIP和端口。如果内部能通外部不通问题出在外部暴露方式NodePort/LoadBalancer/Ingress。查Ingresskubectl get ingress。如果Ingress地址一直显示pending说明Ingress Controller可能没有分配公网IP在本地环境中是正常的。在本地你通常需要配置hosts文件将域名如myapp.local指向Ingress Controller所在的节点IP通常是127.0.0.1或虚拟机IP。问题Pod一直处于Pending状态。排查kubectl describe pod pod-name。查看Events部分最常见的原因是Insufficient cpu/memory节点资源不足。0/1 nodes are available: 1 node(s) had taint...Pod无法容忍节点的污点。在练习环境中可能是给master节点打了不允许调度普通Pod的污点。解决对于资源不足可以调整Pod的资源请求requests。对于污点问题可以给Pod添加对应的容忍度tolerations或者在单节点学习环境中直接移除master节点的污点kubectl taint nodes --all node-role.kubernetes.io/control-plane-。这个训练营的价值远不止于那一行行命令和一个个YAML文件。它构建的是一种肌肉记忆和排查直觉。当你反复在它提供的安全沙箱里“折腾”——部署、破坏、观察、修复——之后面对真实的、复杂的生产环境时那种因为未知而产生的焦虑感会大大降低。你会习惯性地先去检查Pod状态、查看事件日志、描述describe资源对象这种系统化的排查思路才是从新手迈向熟练的核心标志。最终jpetazzo/container.training交付的不是知识点的罗列而是一套可迁移的、基于容器和Kubernetes的云原生应用开发和运维的实战方法论。
容器化实战训练营：从Docker到Kubernetes的完整学习路径
发布时间：2026/5/17 8:10:10
1. 项目概述一个容器化时代的“瑞士军刀”训练营如果你在容器技术尤其是Docker和Kubernetes的领域里摸爬滚打过一阵子大概率会听说过“jpetazzo”这个名字。Jérôme Petazzoni这位前Docker核心工程师在社区里留下的不仅是技术贡献更有一套被无数开发者奉为圭臬的实战教程——jpetazzo/container.training。这不仅仅是一个GitHub仓库它更像是一个精心设计的、开箱即用的“容器化训练营”旨在将你从对容器概念的一知半解一路带到能够自信地构建、编排和管理生产级应用。这个项目的核心价值在于其场景化和实操性。它没有停留在枯燥的概念讲解上而是通过一系列精心编排的幻灯片、讲义和配套的、可直接运行的Docker Compose环境模拟了从单容器应用到复杂微服务编排的完整生命周期。无论是个人开发者想系统学习还是团队负责人需要一套标准化的内部培训材料container.training都提供了一个近乎完美的起点。它解决的正是“学了理论却不知如何下手”、“教程环境配置复杂劝退”这类普遍痛点让你能在一个干净、一致的环境中专注于技术本身快速获得正反馈。2. 核心内容架构与设计哲学2.1 模块化与渐进式学习路径container.training的内容组织体现了极强的教学逻辑。它不是一本平铺直叙的教科书而是一个模块化的知识图谱。整个教程大致可以分为几个核心阶段容器基础与Docker核心从“为什么需要容器”讲起深入浅出地剖析镜像、容器、仓库、网络、存储卷等核心概念。这里不仅仅是命令的罗列更重要的是解释每个操作背后的原理比如UnionFS如何工作、容器网络命名空间如何实现隔离。镜像构建最佳实践这是区分新手和老鸟的关键。教程会带你超越简单的Dockerfile探讨多阶段构建以减少镜像体积、合理利用构建缓存加速、安全扫描Security Scanning以及如何编写可维护的Dockerfile。例如它会强调使用特定的标签如alpine:3.18而非latest以及以非root用户运行进程等安全实践。容器编排入门与实践从手动管理多个容器的痛点自然过渡到编排工具。这里重点介绍了Docker Compose作为开发和小型部署的利器。教程会通过一个多服务应用比如包含Web前端、API后端和数据库的实例完整展示如何定义服务、配置网络和卷。Kubernetes深度探索这是项目的重头戏。它从Kubernetes的核心抽象Pod、Deployment、Service、Ingress等开始通过大量的kubectl命令和YAML文件示例让你理解声明式API的魅力。更重要的是它提供了在本地一键部署的Kubernetes练习环境通常基于k3d或minikube让你可以无风险地练习所有操作。生产环境考量与高级主题涉及日志收集如Fluentd/Elasticsearch/Kibana栈、监控Prometheus/Grafana、安全Secrets管理、Pod安全策略、CI/CD流水线集成等。这部分内容将你的技能从“会用”提升到“用好”。注意项目的部分高级内容或演示可能依赖于特定的云服务商如AWS ECS/EKS Google GKE的集成示例在学习时需要注意区分通用知识和平台特定实现。2.2 环境设计一切为了零摩擦上手这个项目最受赞誉的一点是其环境设计。传统的教程往往在“环境准备”这一步就卡住了很多人。container.training通过预配置的Docker Compose文件解决了所有依赖问题。当你克隆仓库并执行docker-compose up -d后通常会启动以下服务演示应用一个或多个用于练习的目标应用。辅助工具可能包括一个内置的代码编辑器如Code-Server、一个幻灯片展示服务用于播放教程内容、甚至是一个简单的注册表。练习环境对于Kubernetes部分Compose文件可能会启动一个轻量级的K8s集群如k3d在容器中运行并自动配置好kubectl的访问权限。这意味着你只需要在本地安装好Docker和Docker Compose剩下的所有事情——包括复杂的Kubernetes集群——都会由容器自动准备妥当。这种设计将学习者的心智负担降到最低可以立即开始动手操作极大地提升了学习效率和积极性。3. 核心实操从零到一运行你的训练营3.1 本地环境准备与启动假设你使用一台Linux或macOS的机器Windows用户建议使用WSL2以下是标准的启动流程# 1. 克隆仓库到本地 git clone https://github.com/jpetazzo/container.training.git cd container.training # 2. 切换到包含docker-compose.yml的目录通常在主目录或某个子目录下例如对于标准练习环境 # 你需要根据想学习的模块选择正确的目录。一个常见的起点是 cd slides # 3. 启动整个训练环境 docker-compose up -d执行完毕后使用docker-compose ps命令查看所有运行中的服务。通常会有一个服务映射了本地端口比如8080到容器的幻灯片服务。此时打开浏览器访问http://localhost:8080你就能看到交互式的教程幻灯片了。3.2 跟随教程进行动手实验教程幻灯片通常是交互式的HTML页面左侧是导航大纲右侧是内容。关键在于很多幻灯片页面都嵌入了“实战练习”部分。例如在讲解docker run命令时页面下方可能会直接给出一个终端模拟器或者指示你切换到之前docker-compose启动的“练习容器”中执行命令。一个典型的学习循环是阅读概念在幻灯片上学习一个概念例如什么是Docker卷。查看示例幻灯片给出一个命令示例docker run -v /宿主机路径:/容器路径 ...。动手执行切换到项目提供的练习终端可能通过docker-compose exec进入特定容器直接运行该命令并观察结果。完成挑战教程经常会提出一些小挑战比如“使用卷来持久化一个数据库的数据”让你独立完成巩固知识。对于Kubernetes部分环境通常会为你配置好一个名为k8s的命名空间并自动设置好kubectl的上下文。你可以直接使用kubectl get pods -n k8s来查看练习集群的状态然后根据幻灯片指示创建和修改资源。3.3 自定义与探索基础教程完成后这个环境本身就是一个极佳的沙盒。你可以修改演示应用找到演示应用的源代码目录修改代码然后重新构建镜像观察容器行为的变化。实验不同的编排配置修改docker-compose.yml文件尝试添加新的服务、改变网络配置或卷挂载方式。破坏与恢复故意“制造故障”如停止关键容器进程、删除Pod然后练习如何排查和恢复。这是理解系统弹性的最好方式。集成其他工具尝试在现有的Compose环境中加入Prometheus进行监控或加入Jaeger进行链路追踪将学到的知识串联起来。4. 深度解析超越命令行的理解4.1 Dockerfile多阶段构建的实战精要教程中会强调多阶段构建但这里可以展开一些更深入的实操心得。假设我们要构建一个Go应用# 第一阶段构建阶段 FROM golang:1.21-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o myapp . # 第二阶段运行阶段 FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --frombuilder /app/myapp . EXPOSE 8080 CMD [./myapp]为什么这么做最终镜像极小第一阶段包含了完整的Go编译工具链镜像可能超过300MB。但第二阶段只从第一阶段复制了编译好的二进制文件myapp并基于极简的alpine镜像最终镜像可能只有10MB左右。这极大地减少了镜像拉取和存储的开销。安全性提升最终运行环境不包含编译器、源代码等任何构建时依赖减少了攻击面。构建缓存优化将COPY go.mod go.sum ./和RUN go mod download单独放在COPY . .之前意味着只要go.mod和go.sum不变go mod download这一耗时步骤就可以利用Docker的构建缓存极大加速后续构建。实操心得在CI/CD流水线中可以为“构建阶段”和“运行阶段”使用不同的镜像仓库标签策略。例如构建阶段的中间镜像可以打上-builder标签并定期清理而最终产物只推送运行阶段的小镜像。4.2 Kubernetes Service与Ingress的流量管理内幕教程会教你创建Service和Ingress但理解流量如何流动至关重要。Service本质上是一个位于Pod前端的、稳定的网络抽象和负载均衡器。当你创建ClusterIP类型的Service时Kubernetes会做两件事分配一个虚拟IPVIP这个IP只在集群内可路由。更新每个节点上的kube-proxy组件规则可以是iptables或ipvs模式使得发往该VIP的流量被均匀地转发到后端Pod的真实IP上。注意kube-proxy的iptables模式在服务数量非常多时数千个可能会产生性能问题此时可以考虑切换到ipvs模式。Ingress它不是一个服务类型而是一个API对象管理着对集群内服务的外部HTTP/HTTPS访问。它需要Ingress Controller如Nginx Ingress Controller、Traefik来具体实现。Ingress规则定义了主机名、路径与后端Service的映射关系。一个常见误区认为创建了Ingress资源就万事大吉。你必须确保对应的Ingress Controller Pod正在运行。在container.training的环境里这通常是预先部署好的。实操技巧在调试Ingress问题时可以先检查Ingress Controller的日志kubectl logs -n ingress-nginx ingress-controller-pod-name。下表对比了不同服务类型和入口资源的适用场景资源类型主要作用访问范围典型场景ClusterIP内部服务发现与负载均衡仅集群内部微服务间的内部通信如API服务调用数据库服务NodePort通过节点IP和静态端口暴露服务集群外部可访问开发测试或需要固定端口的遗留系统集成LoadBalancer通过云供应商的负载均衡器暴露服务公网或内网在公有云上暴露公网服务Ingress基于HTTP/HTTPS主机名和路径的路由集群外部HTTP/S对外提供Web服务一个IP承载多个域名/应用5. 常见问题与故障排查实录即使在一个预配置好的完美环境里动手实验时也难免会遇到问题。以下是我在多次使用和教学过程中总结的常见“坑点”及解决方案。5.1 环境启动与连接问题问题docker-compose up失败提示端口冲突。排查container.training的Compose文件可能固定使用了某些端口如8080用于幻灯片8000用于应用。使用netstat -tulpn | grep :8080Linux或lsof -i :8080macOS查看哪个进程占用了该端口。解决要么停止占用端口的本地进程要么修改docker-compose.yml文件将服务端口映射改为其他可用端口例如8081:8080。问题能访问幻灯片但里面的终端无法连接或无法执行命令。排查这通常是因为Web终端服务如ttyd没有正常启动或者浏览器与终端服务的WebSocket连接被阻断。解决检查docker-compose ps确认所有服务状态都是Up。查看终端服务容器的日志docker-compose logs ttyd服务名可能不同。尝试禁用浏览器的广告拦截插件或安全扩展它们有时会拦截WebSocket连接。5.2 Docker与Kubernetes命令执行问题问题在练习容器内docker命令执行报错“Cannot connect to the Docker daemon”。原因练习容器需要访问宿主机的Docker守护进程来执行命令。这通过将宿主机的/var/run/docker.sock文件挂载到容器内实现。解决确保Compose文件中包含了类似- /var/run/docker.sock:/var/run/docker.sock的卷挂载。同时注意容器内用户是否有权限访问该socket文件。问题kubectl命令报错“The connection to the server x.x.x.x was refused”。排查这表示kubectl无法连接到Kubernetes API Server。在container.training的K3s环境中首先检查K3s server容器是否运行正常。解决docker-compose ps检查k3s-server服务状态。进入该容器查看日志docker-compose logs k3s-server。确认kubectl的配置是否正确。环境通常会自动配置但你可以检查cat ~/.kube/config或kubectl config view。确保server地址指向正确的容器IP和端口通常是6443。5.3 应用部署与访问问题问题部署了Deployment和Service但通过curl或浏览器无法访问。系统化排查流程查Podkubectl get pods -o wide。确认Pod状态是Running且READY是1/1或2/2等。如果状态是CrashLoopBackOff查看Pod日志kubectl logs pod-name。查Servicekubectl describe svc service-name。检查Selector是否与Pod的labels匹配。检查Endpoints部分是否有IP地址列表有列表说明Service找到了后端Pod。查网络从集群内部另一个Pod可以临时运行一个busyboxPod尝试curlService的ClusterIP和端口。如果内部能通外部不通问题出在外部暴露方式NodePort/LoadBalancer/Ingress。查Ingresskubectl get ingress。如果Ingress地址一直显示pending说明Ingress Controller可能没有分配公网IP在本地环境中是正常的。在本地你通常需要配置hosts文件将域名如myapp.local指向Ingress Controller所在的节点IP通常是127.0.0.1或虚拟机IP。问题Pod一直处于Pending状态。排查kubectl describe pod pod-name。查看Events部分最常见的原因是Insufficient cpu/memory节点资源不足。0/1 nodes are available: 1 node(s) had taint...Pod无法容忍节点的污点。在练习环境中可能是给master节点打了不允许调度普通Pod的污点。解决对于资源不足可以调整Pod的资源请求requests。对于污点问题可以给Pod添加对应的容忍度tolerations或者在单节点学习环境中直接移除master节点的污点kubectl taint nodes --all node-role.kubernetes.io/control-plane-。这个训练营的价值远不止于那一行行命令和一个个YAML文件。它构建的是一种肌肉记忆和排查直觉。当你反复在它提供的安全沙箱里“折腾”——部署、破坏、观察、修复——之后面对真实的、复杂的生产环境时那种因为未知而产生的焦虑感会大大降低。你会习惯性地先去检查Pod状态、查看事件日志、描述describe资源对象这种系统化的排查思路才是从新手迈向熟练的核心标志。最终jpetazzo/container.training交付的不是知识点的罗列而是一套可迁移的、基于容器和Kubernetes的云原生应用开发和运维的实战方法论。
