IngramChen 積分 0

node 現在有 managed node & fargate 可以用

兩者都不支援 spot instances, 然後 fargate 不支援 EBS,暈倒

ingress 的話,我目前是用 ALB + traefik ingress,其實還是可以用一台 ALB 搞定一卡車小站

哎,就是麻煩啊,k8s 的難度已經很高了,還要自己搞一套。而且我個人不喜歡 traffic 在 node 間 bounce。純 ALB 可以直通 pods,這算是 EKS 的優點。

cloudsql 聽到有 downtime 是一兩年前的事了,現在還會遇到嗎?拿麼恐怖

kakashi 積分 1

恩恩 感謝回覆我的問題!!! 不過我知道有些點有改善

  • master 要錢 <--- 真的貴
  • node 現在有 managed node & fargate 可以用 (心智成本又上升了)
  • GKE 其實到最後還是要熟 VPC 的部分,我們家有踩到一些雷,最後還是自己重切過
  • ingress 的話,我目前是用 ALB + traefik ingress,其實還是可以用一台 ALB 搞定一卡車小站
  • EC2 網卡這個我認同, 這個東西每次都要查一下,蠻麻煩的 Link1

GKE 我覺得很棒,但是 GCP 的問題一直都是其他 managed service 沒 AWS 多且穩定, 像是 cloudsql 會有 downtime 就抖抖的,這方面可能再跟大家請教下 XD

indigo 積分 1

Sonos executives said they decided to sue only Google because they couldn’t risk battling two tech giants in court at once.

IngramChen 積分 0 編輯於

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 積分 0

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

changyuheng 積分 0

雖然目前還缺乏 tagging,不過編輯部分的 Ux 已經超越了 Bear1 (IMHO)。

Kros 積分 1

SFV 台灣的問題是海底電纜頻寬不夠了,連到國外都還是 lag,只有非巔峰時期正常

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

IngramChen 積分 0

值得好好讀完. 其他領域也有可能會用到

kaif 積分 0

全世界都抄s3 api啊,真的標準是cdmi沒人裡他。aws也沒差吧,沒一個能打的

IngramChen 積分 0

https://www.ithome.com.tw/news/135153

中文

haocheng 積分 0

很多人買的 VT/VXUS/VEU/BNDX/BNDW 都有調降手續費,太佛心了...

IngramChen 積分 0

即然都要寫 test 了, 何不直接標示在程式裡呢?

未來 10 年大概會是 type 的全盛時期

IngramChen 積分 1

什麼時候有 rust 版了... 我怎不知 (被打

IngramChen 積分 0

要加的功能好多,2020 做的完?

把工作從 UI thread 拔掉當然是很好,不過我觀察發現卡住的地方通常是真的算很久 (貼個 Java code 轉成 kotlin 之類的),或是修改一個 1000 行的 kotlin 程式檔。parser 不再快一點也是白搭

metavige 積分 1

是不是程式語言的缺陷有待討論 但是,的確我想,當初有這些 DP 是在解決當時發生的一些問題,所歸納出來的常用解法 但是如果要用新的語言來解釋以前的東西,好像有點怪怪的 畢竟,這些語言在設計之初,應該就已經想到了之前發生的一些問題了吧~

每個語言都應該會有自己的 Design Patterns,因為 DP 的由來,本來應該就是集結了大多數人在解決某些問題所歸納出來的解法~ 我的見解是這樣

IngramChen 積分 2

會 Swift 的人都是 iOS 開發者,和後端需要的技能差太多。我的觀察有志寫 mobile/front end 的人,通常對只有冷冰冰純數據的開發沒什麼興趣。

_hhnj 積分 1

以一位沒碰過 Swift 的開發者身份,我有想到兩個:

  1. 對於已熟悉 Swift 的開發者,不需要再學習第二種語音就能開發後端
  2. 由於會編譯成 machine code,在啟動、效能上應該有不錯的表現