其實蠻想知道爛在哪 XD 有比 EKS 好的選擇嗎？求解

我們用 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 爛到有剩 =====

話說回來AWS有一堆複雜到不行的計價公式，而且基本上也是他說多少錢就多少錢

其實大部分傳產都寧可要傳統的quota而不是pay as you go。這部分微軟就老經驗了

笑一笑

不過 AWS 很複雜就是了, 即使我用了快十年還是很多東西不熟

這個比例蠻威的，不知道是不是真的這麼強

port-forward 實用

重力子 這個名字有夠中二...

看到效能居然比 M5 還好，有點想試試 arm 的 openjdk..

看照片我就飽了

出包的是 container/cgroup ，看來 kernel 要常更新才行。

k8s 雖然是多了一層，但奇特的是你把 control plane 整個關掉， container 其實還會繼續跑，只是不能更新而已。從這角度來看 k8s 其實和真正部署的 app 隔的很開

SQL 有標準，因此 JPA 的意義少了一半。但雲端平台一直沒有標準 ，好不容易大家都服了 k8s，紛紛抬轎，長遠來看還是優點大於缺點。

感覺k8s/container還是只用在純吃CPU的業務邏輯比較好。吃disk/network IO的東西很容易踩到kernel/kernel module/filesystem的雷，要tuning也麻煩。

k8s很常讓我聯想到JPA...一層美好的抽象層。

當然有platform team負責就沒差拉。

神乎奇技的 trace

所以通通都要升到 kernel 4.19 ?

每次升 k8s 重要元件都很緊張

managed k8s 都要一段時間才成熟可用，個人建議多等等…

GKE 也出了大包了

看起來是進入k8s前有的吧，最後那張也沒看到了

另外 format 應該是各子團隊開始 refactor 成統一格式才對，而不是再做一層轉換層 (都已經變慢了還不做最佳化？)

是沒錯，但是在分割之前公司內沒有統一的要求或堅持，終究會發生多種 protocol/format...只是看這個文章也沒特別寫到他們的狀況就是。
但最後一張圖如果能拔掉，表示他們重點可能是 lookup ?

其實進入 k8s 後就有 service discovery，不需要這層了，等於是多出來。

另外 format 應該是各子團隊開始 refactor 成統一格式才對，而不是再做一層轉換層 (都已經變慢了還不做最佳化？)

看內文像用來統一 api service lookup 跟 format 之類的吧。有時團隊太多各自管的話，根本不知道公司內部有哪些 API， endpoint 在哪或誰在管之類。

ESB 那邊比較不解，有必要加這層？

現在都習慣先找 postgres 有沒有現成的作法，真的不行才去找專屬的 server

terraform + k8s

Ansible 就跟這兩個重疊太多

換teraform?

結果我現在努力的要去 Ansible 化…

還拍照留念，很機車 XD

感覺有硬要用AWS的感覺。不用AWS還有很多方案阿，直接用datadog (最近上市發大財??) 或是自幹方案應該都很成熟了而且不用被綁死。

自己刪掉吧, 你貼的已經是 spam 了.

不刪就是停權