我构建了一个多服务 Kubernetes 应用，实际出现了哪些问题

发布: 1周前 (2026年1月31日 GMT+8 14:32)

5 分钟阅读

I’m happy to translate the article for you, but I’ll need the full text of the post (the markdown content) in order to do so. Could you please paste the article’s content here? Once I have it, I’ll provide a Simplified‑Chinese translation while preserving the original formatting, code blocks, URLs, and the source link at the top.

概述

该应用由五个独立组件组成，每个组件在各自的容器中运行，并由 Kubernetes 分别管理。这些组件之间不知晓 Pod IP；所有通信都通过 Kubernetes 服务发现进行。这与真实生产环境中的微服务工作方式相同。

组件

投票前端

用户投票的 UI。

结果前端

用户查看聚合结果的 UI。

Redis

作为传入投票的队列。

PostgreSQL

提供投票结果的持久存储。

工作服务

异步处理投票，从 Redis 读取并将结果写入 PostgreSQL。

使用的 Kubernetes 资源

Deployments, Pods, Services

Deployments 管理每个组件的期望状态。
Pods 是最小的可部署单元；在需要时会自动重新创建。
Services 为 Pod 提供稳定的网络端点和 DNS 名称。

Service Types

Type	Purpose	Typical Use
ClusterIP	仅内部通信	Redis、PostgreSQL、内部 API
NodePort	在每个节点的 IP 上公开服务（用于测试）	在 Ingress 之前临时暴露前端
Ingress	从集群外部进行 HTTP 级别的路由	生产级别的外部访问

Ingress 与 Ingress 控制器

An Ingress 资源仅定义路由规则；它本身不执行任何操作。您还必须运行一个 Ingress Controller 来监视这些规则并实际处理传入流量。没有控制器，Ingress 规则将毫无用处——这是我吃过的苦头。

流量流程

集群内部

Voting frontend 使用 redis Service 名称向 Redis 发送投票。
Worker 使用相同的 Service 名称从 Redis 读取。
Worker 使用 postgresql Service 名称将结果写入 PostgreSQL。
Results frontend 使用 postgresql Service 名称从 PostgreSQL 读取。

所有通信均使用 Service DNS；不硬编码 pod IP。

从浏览器到应用

用户发送 HTTP 请求。
请求到达 Ingress Controller。
评估 Ingress 规则。
流量转发到相应的 Service。
Service 在其后端 pod 之间进行负载均衡。

Ingress 在 HTTP 层工作，是面向生产的应用暴露方式。

常见陷阱及解决方案

问题	解决方案
Ingress 规则未生效	安装 Ingress 控制器（例如 NGINX、Traefik）。
Pod 重新创建后获得新 IP，导致硬编码地址失效	仅使用 Service；它们提供稳定的端点。
对 Service 类型感到困惑	内部流量使用 ClusterIP，仅在临时测试时使用 NodePort，外部 HTTP 流量使用 Ingress。
*Ingress 控制器 Pod 卡在 Pending* 状态**	调整节点标签和容忍度，使控制器能够调度到 control‑plane 节点（适用于本地集群）。
无法从本地基于容器的集群访问应用	将 Ingress 控制器端口端口转发到本地机器，模拟云负载均衡器。
跨命名空间的 Service 名称无法解析	记住 Service DNS 受命名空间限制；必要时使用完全限定域名（`service.namespace.svc.cluster.local`）。

经验教训

Kubernetes 网络是 面向服务 的，而不是面向 pod 的。
一个 Ingress 需要规则与 控制器 同时存在才能工作。
本地集群的行为与托管云集群不同（节点调度、负载均衡等）。
服务发现通过 DNS 进行，绝不使用硬编码的 IP。
有效的调试需要同时了解平台和应用架构。

一旦这个思维模型形成，高级主题（网络策略、服务网格等）就变得容易理解。

如何获取代码

完整的源代码和逐步设置说明可在仓库中获取：

kubernetes-sample-voting-app-project1

（如果有实际的 Git URL，请替换为相应地址。）

如果你正在学习 Kubernetes，选择一个多服务应用，部署它，然后有意让它出错。修复这些问题将帮助你获得深入的理解。Kubernetes 中对你来说最难的部分是什么？留下评论吧！

Tags: kubernetes devops learning microservices