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 都要收錢的
node 現在有 managed node & fargate 可以用
兩者都不支援 spot instances, 然後 fargate 不支援 EBS，暈倒
ingress 的話，我目前是用 ALB + traefik ingress，其實還是可以用一台 ALB 搞定一卡車小站
哎，就是麻煩啊，k8s 的難度已經很高了，還要自己搞一套。而且我個人不喜歡 traffic 在 node 間 bounce。純 ALB 可以直通 pods，這算是 EKS 的優點。
cloudsql 聽到有 downtime 是一兩年前的事了，現在還會遇到嗎？拿麼恐怖
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 爛到有剩 =====
要加的功能好多，2020 做的完？
把工作從 UI thread 拔掉當然是很好，不過我觀察發現卡住的地方通常是真的算很久 (貼個 Java code 轉成 kotlin 之類的)，或是修改一個 1000 行的 kotlin 程式檔。parser 不再快一點也是白搭