Kubernetes 升級規劃 - InfuseAI - Medium
(medium.com)
IngramChen
積分 1
我們用 AWS EKS，目前的更新計畫是 慢一版 (例如 EKS 升到 1.15 了，我們才會從 1.13 升到 1.14)，週期大概是半年，更新的時候順便會一起升工具鍊 (helm 什麼的)
K8s 沒有 LTS 版，所以我傾向慢一版才更新 (等 bug 都抓完了)，然後 EKS 又特別慢 ，官方已經 1.17 了，AWS 到現在 1.15 還沒生出來，所以大部份的情況我們團隊會慢 3~4 版左右。
雖然更新很慢但 k8s 到了 1.1x 版左右就很成熟了，目前沒什麼大問題。有問題的是 EKS。
===== EKS 爛到有剩 =====
kakashi
積分 0
其實蠻想知道爛在哪 XD 有比 EKS 好的選擇嗎？求解
Google GKE 大概是做最好的吧，這也是去年 GCP 用戶上升的原因。
EKS 就是個拼裝車，把 AWS 現有的服務硬裝上 k8s，所以變成用戶除了使用 k8s 外，還要處理 AWS 本身的服務，以及橋接的部份。
- EKS 的 master 要錢，mdfk
- EKS 的 node 要自己安裝升級，還要一台台自己手動升，mdfk
- EKS 還要先設好 VPC，VPC 除了設一堆 route table 外還要買固定 IP，然後超級難懂，mdfk
- EKS 的 ingress 是不能共用 Load Balancer (ALB) 的，所以每個對外的網址都要開一台 LB，你開十個小站就要花十台 LB 的錢，mdfk
- EKS node 延用 EC2 的網卡架構，舉例一台小 node 如果能配四張網卡，而一張網卡只能配四個 IP 的話，你一台 node 就只能裝 16 pods 左右，不論你 cpu/ram 還剩多少空間，mdfk
kakashi
積分 1
恩恩 感謝回覆我的問題！！！ 不過我知道有些點有改善
- master 要錢 <--- 真的貴
- node 現在有 managed node & fargate 可以用 (心智成本又上升了)
- GKE 其實到最後還是要熟 VPC 的部分，我們家有踩到一些雷，最後還是自己重切過
- ingress 的話，我目前是用 ALB + traefik ingress，其實還是可以用一台 ALB 搞定一卡車小站
- EC2 網卡這個我認同， 這個東西每次都要查一下，蠻麻煩的 Link1
GKE 我覺得很棒，但是 GCP 的問題一直都是其他 managed service 沒 AWS 多且穩定， 像是 cloudsql 會有 downtime 就抖抖的，這方面可能再跟大家請教下 XD
IngramChen
積分 0
node 現在有 managed node & fargate 可以用
兩者都不支援 spot instances, 然後 fargate 不支援 EBS，暈倒
ingress 的話，我目前是用 ALB + traefik ingress，其實還是可以用一台 ALB 搞定一卡車小站
哎，就是麻煩啊，k8s 的難度已經很高了，還要自己搞一套。而且我個人不喜歡 traffic 在 node 間 bounce。純 ALB 可以直通 pods，這算是 EKS 的優點。
cloudsql 聽到有 downtime 是一兩年前的事了，現在還會遇到嗎？拿麼恐怖
popcorny
積分 0
popcorny
積分 1
SSL Termination 可以用 cert-manager，用 let's encryption issuer1 其實挺無腦的。他好像沒有提到 ALB 比較貴的缺點，我怎麼看都覺得 NLB + nginx 比較好。話說我們用 GCP 也是用 L4 LB + nginx ingress 唷。
nginx cert-manager 大概只要是 bare metal 都是這樣做，在自己的主機玩都這樣。
一開始我們先用 ALB，因為 ALB controller 雖然現在沒有可以共用 path rule，但其實已經做好了，等待 alpha 測試完畢就可以用了。結果沒想到一等就等半年 (作者太忙，他們都 AWS 的人)。所以現在卡的不上不下的，如果打掉重練的話可以重新考慮 nginx 的作法。
不過， NLB 進來的封包，會先經過 kube-proxy (iptables 吧?)，再到 nginx pods，再到 app pods，一個封包在 nodes 間 bounce 兩次以上這種事我實在是受不了… 如果 node 是跨 Availability Zone 的話，每次 bounce AWS 都要收錢的