kennylam777

你的需求是 HostPort 不是 LoadBalancer, LoadBalancer 就是獨立一個 IP 的服務。

MetalLB 有 L2 ARP 及 L3 BGP 的 IP 路由方法, 你完全沒提及過, 恐怕根本不知道 MetalLB 在幹啥。

簡單一點, 用 DaemonSet 跑 Traefik + HostPort 吧......

@mightybruce 其實在正式的 LoadBalancer 上, 也是用 NodePort 的, 不然雲服務商的 LoadBalancer 如何連接到服務上? LoadBalancer 的實作會幫你把 NodePort 至雲上的對應都處理好, 可以看看 aws-load-balancer-controller 的實作。


只是在生產環境上, Node Group 的端口不能直接全開到公網。

@lingerr 自己玩的就直接用 HostPort 吧, 一般 ingress controller 都支持, 這樣最簡單了。

就是內網單 IP 的 QoS 而已

Cangjie 對我來說就是輸入法....

我的心得是, 大型 instances 的 overhead 比小型的好, 所以如果出現 6 台以上的 static node pool, 就是利用率比較固定的那種, 倒是可以看看擴大一倍實例把 node 數量維持在 3 左右, 而 autoscale 的小型 instances 就分開一個 node pool, 控制突發用量的成本。

還有跨 AZ 的問題, Pod 之間的通訊, 如非必要就留在同一個 zone 內, 也可以省不少。

我的經驗是, 經過快速擴張後, 坐下來研究一下利用率, 最高能省 80%, 但某程度上是因為之前的 devs 不注重成本效益, 當時公司也不差錢啦。

cert-manager +1

我記得 rancher 現在是 k8s 的吧, 你還要考慮的是 ingress 能不能直接跟據 k8s secret 的 public cert 更新而自動載入, Ingress-NGINX Controller for Kubernetes 是可以的

nginx -s reload 是有缺點的, 畢竟你的證書一直增加上去, 就要經常 reload

在 Ingress-NGINX Controller for Kubernetes 就直接用 Lua 動態載入來解決。

k8s 的問題, 還是用 k8s 的方式解決吧。

香港的業主會帶著你的錢, 感謝有人去接盤而不至於全軍覆沒

@dcoder 我只想說, 沒必要把 k8s 說到一無是處。我看還是很多團隊在用 k8s 堆 GPU, 因為我也是其中之一。

隨便 Google 一下"gpu cluster management"看到不少方案都是 k8s 的, 這沒有甚麼不好吧。

因為直接在現有 k8s cluster 上堆 GPU node pool, 改動很少但就是可以解決問題, Dev 直接用 CUDA runtime docker image 打包過來就能 Deploy, 也不用花時間自行分配哪台 node 多少 GPU, 需求無論是 1 台 GPU 還是 100 台都是一樣的, 才不會跟你慢慢在查系統驅動配置或對齊 Run-time 的, 直接加一句 "nvidia.com/gpu" , 然後 Failover/Scaling 都依照既有的方法去做, 學過的都會。

k8s 的 CNI 才沒很古老好嗎? SDN 的都有相應 CNI plugin 啊, Multus 用過了嗎? Calico 用過了嗎? SR-IOV 用過了嗎? 哪裡慢了? 哪裡 SDN 不能用了? 就是有 CNI 插件設計才能讓各種專業的網絡方案都套進 k8s 啊。

快速 join cluster 的問題其實要處理的是 VM creation 的時間, 然後是 kubeadm join 前的環境安裝, 如果 kubelet/kubeadm/container engine 等等東西都預先打包準備好, 那不可能要 10 分鐘的, 但是在 Cloud Managed k8s 上能調整的東西不多, 例如有些 Cloud k8s 是在 VM 開機時才用 script 安裝 kubeadm/kubelet/containerd 的, 因為這麼做會比直接用包好的 node images 更乾淨也易於更新。有開機時間追求的話請自建 k8s, 只是大部分公司也沒有那種需要, 也沒能力, 才有 Cloud Managed k8s 產品出現。

DevOps/SRE 弄得好, 其他小問題就可以丟給當值的 Junior ops 處理, 而 Devs 也不必參與突發事件, 最後大家也輕鬆一點才是理想的狀態。