t2系列的優點

CPU是按用量算的

平時用剩的可以累積，當然是有上限啦 到需要爆發的時侯把儲起來的credit消費掉(?) 好處是你一些難以估算用量的service你可以放心的跑起來

性價比高

跟同樣配置的c4.large (2vCPU, 4GB Ram) 比起來便宜一半有多($33.97 vs $73.20)

---

所以我在kubernetes當中用的機器大部份都是t2.medium 雖然大部份的情況下都活得很好 但也有發生意外的時侯 那就是CPU credit不夠

這裡要先說明一下t2系列的機制 t2系列的CPU用量跟其他的不同 AWS會為每個機器每個小時發一定量的CPU Credit 然後扣取你該小時的用量(1 credit = 100% CPU 運行一分鐘) 而不同的instance type可以儲存的credit 也有上限

如果你連續200%CPU跑了好長的一段時間，你的cpu credit很快就會變成0 而這個時侯機器上所有的進程基本上都會卡住不動 等到有CPU credit回復時才跑一點點 簡單來說就是卡死了

所以如果要拿t2系列的機器來做kubernetes的node的話 有幾樣事情是必需的

有效利用t2　

CPU credit 監控

Prometheus 可以安裝一個插件去監控AWS的E2 CPU Credit 於CPU credit用量異常或者是不夠的時便發通知(我是利用telegram) 當然你也可以用AWS的cloudwatch直接監控及發通知，原理上是一樣的

合適的資源配置

在設計每個服務時應該先考慮到實時的同量 不然kubernetes在分配資源的時侯很有可能把一堆消耗CPU/內存的大戶放在同一node上

當然在初期很難作出有效的估算，所以我建議初期應該花更多的時間去做監控 密切留意每個服務的資源需求，以便有效作出調整 當發現部份服務的資源需求過高，你就需要作出決定 一是把他的resource request調高，把其他服務擠走 又或者專門配置一些node給他們單獨跑

最後吐槽一下 gcloud沒有類似的brustable instance，差評

參考

• {% post_link grafana-prometheus “利用Prometheus去監控AWS EC2的CPU credit”%}