node 現在有 managed node & fargate 可以用
兩者都不支援 spot instances, 然後 fargate 不支援 EBS，暈倒
ingress 的話，我目前是用 ALB + traefik ingress，其實還是可以用一台 ALB 搞定一卡車小站
哎，就是麻煩啊，k8s 的難度已經很高了，還要自己搞一套。而且我個人不喜歡 traffic 在 node 間 bounce。純 ALB 可以直通 pods，這算是 EKS 的優點。
cloudsql 聽到有 downtime 是一兩年前的事了，現在還會遇到嗎？拿麼恐怖
恩恩 感謝回覆我的問題！！！ 不過我知道有些點有改善
- master 要錢 <--- 真的貴
- node 現在有 managed node & fargate 可以用 (心智成本又上升了)
- GKE 其實到最後還是要熟 VPC 的部分，我們家有踩到一些雷，最後還是自己重切過
- ingress 的話，我目前是用 ALB + traefik ingress，其實還是可以用一台 ALB 搞定一卡車小站
- EC2 網卡這個我認同， 這個東西每次都要查一下，蠻麻煩的 Link1
GKE 我覺得很棒，但是 GCP 的問題一直都是其他 managed service 沒 AWS 多且穩定， 像是 cloudsql 會有 downtime 就抖抖的，這方面可能再跟大家請教下 XD
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
我們用 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 爛到有剩 =====
出包的是 container/cgroup ，看來 kernel 要常更新才行。
k8s 雖然是多了一層，但奇特的是你把 control plane 整個關掉， container 其實還會繼續跑，只是不能更新而已。從這角度來看 k8s 其實和真正部署的 app 隔的很開
SQL 有標準，因此 JPA 的意義少了一半。但雲端平台一直沒有標準 ，好不容易大家都服了 k8s，紛紛抬轎，長遠來看還是優點大於缺點。
其實進入 k8s 後就有 service discovery，不需要這層了，等於是多出來。
另外 format 應該是各子團隊開始 refactor 成統一格式才對，而不是再做一層轉換層 (都已經變慢了還不做最佳化？)