请问自建 k8s 集群， 自建 loadbalancer 还是直接 nodeport？

如果你是运维，nodeport 最后会累死你，nodeport 不推荐生产使用

@tudou1514 老哥细说

@jitongxi nodeport 前后端口不一致，某些应用层面 cmdline 之类的要配置 external-urls ，然后 nodePort 是 nat ，你要封端口，必须 nat 加 mark 很繁琐，还有源 ip 问题

metallb 的二层模式 网络 ip 地址会有限制，BGP 模式可以更灵活

想从所有 node 上协商出一个相同的 port 来也不容易吧
端口号一共才六万多

nodeport 这玩意，都不知道为啥要发明出来

关注下帖子

上面都说 node 是陀屎，可是，gcp 缺省的就是 nodeport

看你们有没有网络工程师，如果没有不要选 metalb 。

出了事情你搞不定的。

正常都是 ingress 呀.不过可以 loadbalancer+ingress 一起使用. nodeport 在一般排查问题或者验证部署的情况下会用到

@defunct9 “诉诸权威”是不对的

LVS + nginx ingress nodeport 就可以

每个 pod 一个 ip

MetalLB 、OpenELB 、PureLB 走起。

nodeport 和 loadbalancer 我怎么感觉差不多啊，loadbalancer 也会起 nodeport 的端口啊，所以说运维问题的我感觉不太对。
区别在于 loadbalancer 的 vip 可以稳定下来，nodeport 你无法指定集群中的一个节点 ip ，因为这个节点可能会挂，你得再搞个 keepalive 之类的。
当然如果是 BGP 的，那肯定是 loadbalancer 了。

如果大多数服务要依赖于自编译的 nginx 的插件获取一些值，nodeport 是不是一个好选择？老哥们有其他好方法说一说

@jitongxi 默认是 30000-32767 ，你会发现有些开发竟然不够用（实际真的遇到过），而且要不你亲自下场维护每个端口的意义，要不就是最后你都不知道这个端口是哪个服务，你身为一个运维，服务器环境的端口不知道是哪个服务，你觉得你会不会背锅？另外集群任意 ip+nodeport 都可以访问服务，如果小集群，无所谓也就那几个 ip ，大集群呢？你们运维或者运维领导超级强势还好说，不然等着天天背锅吧。开发不会吊你的规范，也不会考虑你的工作，你想想总有“大神”想把 pod 当服务器用，他不管是不是前台进程的，就要实现远程开发。所以最好就是日常不要给自己留坑，如果运维领导不强势，那就另说。

我直接 Kubesphere 建集群，nodeport 暴露出来一个统一网关端口，外面套个 nginx 全转发到这个端口，内部就是 ingress nginx 的事了

其实还要看你是什么应用，如果是那种分布式服务上 k8s 的，比如 tidb ，那用 ingress 啥的肯定不合适，流量转发扛不住的。如果是 http 或者小型的应用，那省事儿完全没问题。
当应用规模大了，就可以考虑 MetalLB 、OpenELB 这些，并且最好是 bgp 的，在路由层就做转发了，或者使用类似 terway 的插件，一个 pod 一个 ip 。

@3andwich 我觉得可以，但是要考虑 nodeport 选什么 ip 的问题，集群中任意 ip 都可以访问，但任意节点都有可能挂掉，所以最好有 vip ，或者干脆上 metallb 之类的，提前分配 vip

既然你都强调“K8S 集群”了，那是 metallb 直接按 IP 段分配,这样方便管理.
比如 10.0.0.2-10.0.0.254 开发环境
10.0.1.2-10.0.1.254 测试环境
10.0.3.2-10.0.3.254 随用随扔环境
10.0.5.2-10.0.5.254 暴露外网环境

metallb 还可以配合 l2 l3 的交换机、路由用，如果虚拟的路由/交换机不够用你甚至可以直接用 vlan vxlan trunk 带到外面的物理交换机上减负,当然如果集群长期 20 个 pod 以内自己玩这么来有点重.但是如果打算长期用,这么规划好后面就不用怎么操心基本上开好 pod 看看 pod ip 地址就可以了

一开始 all in one 一台宿主机的话可以用 openwrt 虚拟机这种来做交换机/路由用,配置网络出入策略的话直接根据网段来方便很多

还有个别 pod 需要翻墙的话直接在这个段网关上配置，会方便很多

@jerrycmht 新版 loadbalancer 应该是直接通到 endpoints 了吧？不经过 nodeport 那一段了