一次业务投诉引发的思考:如何优雅地将K8s服务暴露给外部?

前言

不知道你们有没有同样的感受,不管是测试还是开发,最怕公司产品问题反馈群中的投诉,尤其是 有领导在群里的时候。这不怕啥来啥,早上上班刚坐到工位,还没来的及泡杯茶,群里就有投诉信息了, 大概问题就是"有用户需要退款,但是因为有冻结费用,导致退款失败,重点是这个用户已经没有排课了"。这里简单说一下我们的业务场景: 用户在平台上排课后,会将钱包中的钱冻结,课程取消或者结算后,会将冻结的钱解冻。

收到投诉不要慌,先在群里回复一句"正在处理",表明技术在积极响应,然后再去看看问题具体是什么。

问题定位

经过排查用户的上课信息等等,发现2023年11月份有一节课结束后,没有进行结算,导致冻结的钱没有解冻。这个课程时间有点长了,日志也没有, 很难定位到为啥没有进行结算。

解决诉求

排查代码,并没有发现哪里会造成结算失败,用户迫切要退款,现在的方案有两种:

  • 方案一:修复数据
  • 方案二:调接口重新走一遍结算逻辑 显然方案二是比较好的,修数据太麻烦了,然后去看了看对应的服务,发现这个服务的TYPE是LoadBalancer,简单一查,原来可以通过此IP 来访问接口,这样就将用户的诉求解决了。

我的疑问

但是我有个疑问,为什么这个服务的TYPE是LoadBalancer,而不是NodePort呢?,他们之间有啥区别呢?如何将Service暴露到集群外部呢?

进入正题

K8s为Service创建的ClusterIP是对后端Pod列表的一层抽象,对于集群外部没有任何意义,但是现实是许多Service需要对集群外部 提供服务,所以K8s提供了多种方式来暴露Service,供集群外部访问。

设置方式

通过Service资源对象的类型字段"type"进行设置。

  • ClusterIP:默认值,仅在集群内部可访问。
  • NodePort:将Service的端口号映射到每个Node的端口号上,使得集群外部可以通过Node的IP和NodePort访问Service。
  • LoadBalancer:将Service映射到一个已存在的负载均衡器的IP地址上,使得集群外部可以通过该IP地址访问Service。
  • ExternalName:将Service映射到一个外部的域名上,使得集群外部可以通过该域名访问Service。
  • 还可以通过Ingress将服务暴露到集群外部

NodePort:快速测试,慎用生产

原理 :通过节点IP+静态端口(30000-32767)暴露服务。

yaml 复制代码
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 31000  # 手动指定(可选)
  selector:
    app: my-app

适用场景 :开发测试、临时演示。

致命缺陷:

  • 端口管理混乱(需人工避免冲突)
  • 单点故障(节点宕机服务不可用)
  • 无负载均衡能力

LoadBalancer:云厂商的"一键解决方案"

原理 :自动创建云负载均衡器(如阿里云SLB),分配独立IP。

yaml 复制代码
spec:
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 443
      targetPort: 8443

优势:

  • 自动健康检查
  • 支持HTTPS终结
  • 云厂商提供高可用保障

坑点:

  • 成本高 :每个Service一个LB实例($$$)
  • 速度慢 :LB创建可能需要1-2分钟

Ingress:HTTP/HTTPS流量的统一网关

原理 :通过Ingress Controller(如Nginx)实现域名路由和反向代理。

yaml 复制代码
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: foo.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

核心能力:

  • 基于域名的路由
  • 支持TLS证书自动化

方案选型决策

根据业务需求快速匹配方案:

graph TD A[需要暴露服务?] --> B{流量类型} B -->|HTTP/HTTPS| C[Ingress/Gateway API] B -->|TCP/UDP| D[LoadBalancer] A --> E[临时测试?] E -->|是| F[NodePort] E -->|否| G[生产环境?] G -->|是| H[云厂商?] H -->|有预算| I[LoadBalancer] H -->|控制成本| J[Ingress+LB]

最后

在K8s中暴露服务时, 没有绝对的最佳方案 ,只有最适合当前业务场景的选择。理解每种技术的优势和成本,才能在设计架构时游刃有余。

附录:

相关推荐
钟离墨笺17 分钟前
Go 语言-->指针
开发语言·后端·golang
前端梭哈攻城狮36 分钟前
dify二开示例
前端·后端·python
该用户已不存在38 分钟前
Node.js 真的取代了PHP吗?
前端·后端·node.js
二闹1 小时前
OpenCV识物:用代码“认出”物体
后端·opencv
花落人散处1 小时前
SpringAI——接入高德MCP服务
java·后端
超浪的晨1 小时前
Java 代理机制详解:从静态代理到动态代理,彻底掌握代理模式的原理与实战
java·开发语言·后端·学习·代理模式·个人开发
天天摸鱼的java工程师1 小时前
🧠 MySQL 索引结构有哪些?优缺点是什么?【原理 + 场景实战】
java·后端·面试
阿宙ppppp1 小时前
基于yolov5+LPRNet+flask+vue的车牌识别(1)
后端·图像识别
Java水解2 小时前
Spring AI模块化RAG架构解析:三阶段设计与实现详解
后端·spring
蓝倾2 小时前
京东商品SKU数据采集方式及接口说明
前端·后端·api