為了 sharding 所以資料都不 join
跟裡面的留言一樣，我也覺得這些大 table 搬到 NoSQL 才是。但他們回 HBase 不太行。啊本來就不該用 HBase 吧，大概是不想再增加技術門檻了才不想換，從他們選擇自己做 shard 就知道 (NIH...)。
其實我還以為 quora 已經死掉了，你 google 去找根本很少是 quora 的文章說
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 都要收錢的
SSL Termination 可以用 cert-manager，用 let's encryption issuer1 其實挺無腦的。他好像沒有提到 ALB 比較貴的缺點，我怎麼看都覺得 NLB + nginx 比較好。話說我們用 GCP 也是用 L4 LB + nginx ingress 唷。
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 爛到有剩 =====