@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 也不必參與突發事件, 最後大家也輕鬆一點才是理想的狀態。

不如先看看 https://vast.ai

但最少要求是可靠的 Internet, 家中的就算了, 礦場一類的規模還是有機用的

@dcoder 你考慮的只是開發的日常, 但是真正有規模的系統, 不是單單講求你個人認為的 building processing 有多快, 重點是你熟識的工具, 還是得讓其他人 reproduce 一次。如果是常用的步驟, Docker 加速的方法多的是, 可能是你家 DevOps 太垃圾。

自己寫 Cluster manager 也笑了, k8s 主要能力是通用度, 不管在哪個 Cloud 都是一樣的作法。而且甚麼自己寫 Cluster manager 的出了 AWS 也是一團廢物, 請問一下的 cluster manager 能處理 BGP 嗎?Layer 2 不通只能用 Layer 3 的網絡上能通嗎? Persistent Volume 當你能調用 EBS 而不是 local storage 好了, 能加上 NFS 嗎? 還有 GPU 需要同時分配 nVidia 及 Intel 的方案也請解決一下, 自己寫 GPU manager 喔?

人家就是有全套的解決方案, 對 scaling 速度有要求的更可以不用 AWS EKS 去玩自建的, 整個 Eco system 就擺著任你用。

不肯合作, 自吹自擂的單打獨鬥派, 任你說得自己的方案多好, 沒人跟你用就是了。

Deepseek 34B 用來輔助 programming 也不錯, Exllamav2 處理過後在本地環境 4090 能跑, 起碼短問題比 ChatGPT 快一點也不怕私人代碼外流

@h272377502 理論上，中國大陸的公民是全球徵稅的，不管你在香港或美國工作，一天你是中國大陸的稅務居民，也是要繳稅給中國的稅務。

香港的稅務就很簡單，地域來源原則，在香港產生的收入就要在香港徵稅。

有以下例子需要在香港繳稅
1. 在香港工作的收入
2. 在香港促成的交易

詳見: https://www.ird.gov.hk/chi/paf/bus_pft_tsp.htm


你有興趣的應該是: 如何擺脫中國大陸的稅務居民身分？

拿到其他地方的永居或國籍應該能解決，只是規定本身也很不清晰。

不過拿到香港的 PR 然後取消中國戶口，應該是可以的。

OpenWRT 的開源驅動就只有 Broadcom 或 Qualcomm 一類的能用，在 MTK 上 WiFi 性能大降很多，除非用閉源驅動，最後我放棄了 OpenWRT ，直上 Opnsense + 吸頂式 AP 很爽。

@leido
我測的比你早多了, 2015 年左右就在新加坡 office 測過, 用的 Singtel 試過了電信, 都是繞美國西岸的

看看 2023 的測試, 仍然一樣, 只有移動或聯通比較有希望。
https://www.tjsky.net/tutorial/633#i-10

反正都開關了, 有時間就出去走走吧。

@kukat 移動似乎在新加坡的 PoP 還不錯。

@simplove 新加坡家寬到中國的連線, 可能還不如美國的家寬

反而我想把所有中國政府的短信都擋掉，絕大部分是垃圾內容，但無孔不入，養著一張+86 卡但長期不在中國，公益短信和中國公民出國注意事項都與我無關，但十分討厭的是 10000 也有大量垃圾內容，基本把我的未讀訊息都淹沒掉