在 K8S 节点上使用非 Nodeport 默认端口范围暴漏服务

Kubernetes Services: ClusterIP, Nodeport and LoadBalancer – Sysdig

需求背景

  • 服务 A 部署在 K8S 中,集群外的服务 B 需要调用服务 A,同时调用服务 A 的端口是指定了的,必须是 5000,无法修改。
  • K8S 集群是客户的,我们只能部署服务,不能修改集群。
  • 服务 A 需要得到真实的客户端 IP。

解决方案一

通过 Nodeport 的方式暴漏服务 A。

5000 端口不在 Nodeport 默认端口范围内(30000-32767)。

修改 Nodeport 的端口范围,需要修改 kube-apiserver 配置,行不通。

解决方案二

服务 A 的 Pod 配置hostNetwork: true

服务 A 内部还有其他进程,监听了端口,容易和节点的其他进程冲突。同时还会暴漏服务 A 内部的其他服务。

解决方案三

新增一个 nginx Pod,并配置hostNetwork: true,dnsPolicy: ClusterFirstWithHostNet,通过七层代理来转发流量到服务 A 的 service。

服务 B 调用服务 A 时,原本是使用服务 A 的 ssl 证书。但是在七层代理下,会使用这个 nginx 的证书。而证书是服务 A 生成的,不太好自动配置给 nginx。

解决方案四

新增一个 nginx Pod,并配置hostNetwork: true,dnsPolicy: ClusterFirstWithHostNet,通过四层代理来转发流量到服务 A 的 service。nginx 启用 proxy protocol用来传递真实的客户端 IP

proxy protocol 需要后端应用支持,nginx、apache 这些都是支持了的,此方案可行。

解决方案五

新增一个 ubuntu Pod,并配置hostNetwork: true,通过 iptables 来转发流量。

  • 如果客户的 K8S kube-proxy 是 IPVS 方案
    • 将服务 A 通过 nodeport 暴漏到 30001,同时设置 iptables,将 5000 端口流量转发到 30001端口。
  • 如果客户的 K8S kube-proxy 是 iptables 方案
    • 由于在nat表里面对数据包进行dnat操作过后,数据包就不再执行nat表里面的其它规则,所以不能将流量转发到 service、nodeport,只能直接转发到服务 A 的 pod ip。
    • 由于 pod ip 不固定,假如 pod 重新创建,就需要更新 iptables 规则里的 pod ip,所以需要当前服务去 watch pod。

针对方案四中,后端应用不支持 proxy protocol 协议的情况,可以用这个方案。实现较为复杂。

作者:Yuyy
博客:https://yuyy.info
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇