ref: https://loft.sh/blog/the-cost-of-managed-kubernetes-a-comparison/
本篇文章探討不同 Cloud Provider kubernetes 服務的差異，作者列舉了四個常見的 kubernetes 服務，包含 GKE, EKS, AKS 以及 DOKS。
這四個 kubernetes 服務所部署的 Kubernetes 叢集都有獲得 CNCF Kubernetes Certification 的認證，不同 Cloud Provider 都有自己的優缺點。
使用 Kubernetes 服務帶來的好處就是使用者通常不太需要去擔心如何處理
1. Kubernetes 核心元件之間的 Certificate (API Server, Controller, Scheduler, Kubelet ...etc)
2. 動態調整 Kubernetes 節點
3. 相較於單純靠社群， Cloud Provider 可以提供更快速且更好的支援(畢竟有付錢給對方)
因此該文章接下來就會針對這四個 Kubernetes 服務來探討一下彼此的差異。
註: 有興趣的話都可以用 Sonobuoy 這個開源專案來檢測自己維護的 Kubernetes 叢集，通過測試就可以把測試報告送到 GitHub 開 Issue 申請認證
GKE
1. Kubernetes 正式公開後一個月就 GKE 就出現了 (08/2015), 是最早的 Kubernetes 服務
2. GKE 會使用 gVisor 專注於安全層級的容器隔離技術來部署服務。
3. 有機會使用針對 Container 最佳化的 OS，有些 cloud provider 只能使用 Ubuntu image 之類的。
4. 服務出現問題時，可以啟動 auto-repair 來修復叢集，一種典型作法就是將一直回報為 NotReady 的 k8s 節點給重建
5. GKE 提供自動升級 Kubernetes 版本的功能，如果不想要的話記得要去關閉這個功能，否則自動升級是有可能讓某些應用程式無法正常運作的。
6. 使用 GKE 的話，要付每小時 $0.1 美元的管理費。如果使用 on-prem 的解決方案 (Anthos) 的話就可以免去這些管理費。
EKS
1. 06/2018 創立
2. 可以使用 Ubuntu Image 或是 AWS 針對 EKS 最佳化的 EKS AMI 來獲得更好的效能。
3. EKS 沒有提供自動升級 Kubernetes 版本的功能，官方有提供大量詳細的文件介紹如何手動升級 Kubernetes 版本
4. 沒有類似 auto-repair 的機制去幫忙監控與修復出問題的 k8s node，因此 EKS 使用者需要自己去監控與維護這些節點。
5. EKS 也是每小時 $0.10 的管理費用。 AWS Outposts/EKS Anywhere 這些 2021 啟動的專案讓你有機會將 EKS 部署到 on-prem 的環境中。
AKS
1. 06/2018 創立
2. AKS 沒有提供任何最佳化的 OS，你只能使用常見的那些 OS image 作為你的 k8s 節點
3. 預設情況不會自動升級 kubernetes 版本，不過 AKS 提供選項去開啟自動升級。Cluster 有四種不同策略(none,patch,stable,rapid)來自動更新你的 k8s 叢集。
4. AKS 預設不會啟動 auto-repair 功能。對於一直持續回報 NotReady 的節點， AKS 會先重起該節點，如果問題無法解決就會砍掉重建節點。
5. AKS 不收管理費
6. Azure 沒有特別提供一個供 on-prem 的 AKS 解決方案，不過透過 ARC 是有機會於 on-prem 的環境運行 AKS.
DOKS(DigitalOcean)
1. 05/2019 創立
2. 有提供 kubernetes 版本自動更新功能，但是只有針對 patch 版本的變化
3. 沒有 auto-repair 的功能
4. 文章撰寫的當下， DOKS 沒有任何文件說明如何於 on-prem 的環境運行 DOKS
5. 不收管理費
6. 相對其他三家來說，底層架構相對便宜，一個 DOKS 最低可以低到每個月 $10 美元。
價錢比較:
1. 假設需要創建一個擁有 20 節點並且有 80vCPU, 320GB RAM 的叢集 (GKE 因為每個節點都是 15GB，所以最後只能湊到 300GB)
2. 每個月為單位去計算價格，AKS/EKS/GKE 都使用其提供的價格計算機來粗估， DOKS 需要手動計算。
3. 價錢評比
a. AKS: $3416
b. EKS: $2928
c. DOKS: $2400
d. GKE: $1747
對文章有興趣的別忘了參閱全文
gke費用 在 [心得] PressPlay從AWS搬家到GCP一年的心得- 看板Soft_Job 的推薦與評價
這篇比較偏心得分享，沒有太多的技術細節。
Medium好讀版: https://tinyurl.com/yy8auqdy
PressPlay好讀版: https://www.pressplay.cc/link/82A2CAD5C4?oid=829D3F275F
PressPlay平台服務在2016年問世，一直放在AWS上，直到2018年中才搬遷至GCP上。
至今也一年了，讓我們回顧一下這幾年PressPlay的主機的成長過程吧。
# AWS時期
PressPlay草創初期資源有限人力有限，只有一台伺服器運行所有的服務，一台資料庫，
主機在東京AWS，CDN是用Cloudflare的CDN，服務也挺單純的，伺服器上只有網站服務，
然後用戶上傳圖片也放在這台主機上，裡還有一個跑定期扣款的Cron服務，
S3的用途是暫時放上傳的影片，為什麼是暫時呢？因為我們的影片是使用Vimeo服務，
所以我們上傳到S3只有一個功用，就是讓Vimeo可以抓影片，過了三天影片就會被刪掉。
配置圖大概是長這樣子：
最早期的AWS主機配置: https://tinyurl.com/yyfmglex
那時候每天大概幾千人造訪而已，機器都應付得來。
然後到了2017年3月情況就開始不一樣了。囧星人專案上線帶來一波流量，
然後我們在3月下旬作了第一次的改版，流量開始多起來了，
高峰期甚至到了一天兩萬多人進站。
2017–01–2017–03 GA數據: https://tinyurl.com/y6jnd5ym
我們在2018–01到2018–06搬家之前，平均每天進站人數大約在25,000至30,000人左右，
一台Server還蠻緊蹦的，最後決定搬家，搬到Google Cloud Platform(GCP)。
這是搬家前最終的伺服器配置。
AWS後期的主機配置: https://tinyurl.com/yx9tl8yl
# 為什麼要搬到GCP
或許有人會問「AWS用得好端端的幹嘛搬家呢？」我們選擇GCP的原因有幾個原因：
* 價格比AWS便宜
* 地點在台灣，速度快
* AWS介面很醜（我承認我是外貌協會）
公司草創時期資金沒有那麼多，選擇機器都是以省錢、高C/P值為目標。
PP的機器建在AWS的時候，CDN是Cloudflare，雖然我們買的是Pro方案(USD 20/月)
但連線的節點是在洛杉機。也就是說用戶要連線PressPlay的網站，
用戶的連線會先台灣出發，到達洛杉機Cloudflare的機房，
然後連線到東京AWS機房取資料，然後再經過洛杉機才回到台灣。
開個網站就要跑遍大半個地球，再加上PressPlay一開始網站還沒有優化連線數或
圖片size，所以以一個從來沒進入過PressPlay的人，從連線到完全跑出網站，
要90秒左右...
GCP的費用大約是AWS的六折左右，而且在AWS都沒有作HA(High Availability)，
就算有也是人品HA。因此我們常常一爆量主機攤瘓了，光2018上半年就平均1–2月
就一起攤瘓事件。GCP的設定簡單，就連我對配置伺服器沒有很熟都可以輕鬆入門，
開啟CDN也是一個鍵就完成了，在人力和相關知識都缺乏的情況下，選擇GCP還蠻不錯的。
於是我們在2018年4月的時候，決定搬遷到GCP。
# 搬遷的困難
就是人！因為公司內部缺乏熟悉伺服器管理的人，於是我們就想找一個人來管理伺服器、
調整效能、管理辦公室網路和設備，然後進公司來的第一件事就是協助我們搬伺服器。
我們找到一位從業很久的資深工程師，他一進來看到我們公司的網路架構、伺服器架構
跟本是初學者等級，來了五天就跑了，說是不想從那麼基礎的東西做起。
那麼怎麼辦呢？只好我硬上了。雖然GCP操作簡單，但是有關Server調校、
資料庫調校這些我沒有什麼經驗，而且這一次要大調架構，我的要求：
* 讓我們可以撐住爆量的時刻，機器不要掛。
* 並加速網站的運行速度。
* 伺服器狀態的監控機制。
* 備援機制，不要伺服器倒一台就服務全死。
因為GCP比AWS便宜多了，所以機器比較能放心的開，為了未來PressPlay發展，
我們是以3年內不需要再次優化架構的前提之下去做規劃，原本一台網站主機
就可以打天下的配置，擴充成APP、Web各兩台，另外再把負責金流的服務獨立出來，
也是做成兩台，然後由Load Balancer來分配流量，就算APP死一台機器還有一台會
繼續服務，就算WEB全死，但APP還是可以用。
還好有在6月有一位資深的後端工程師加入，我和他經過一整個月的試驗、調整、搬遷，
上線前一天我召集了幾位工程師一起協助搬資料和測試，老闆還以來辦公室拿東西為藉口
送宵夜來，揪甘心～
終於在2018–06–29 正式上線了！！這是搬到GCP時的配置圖：
https://tinyurl.com/y6z53rxu
# 搬到GCP之後…?
2018–06–29上線早上八點，網站就炸了!!
原因是主機掛載Google Storage時的參數錯誤，讓所有資料夾和檔案清單必須讀完
才能正常服務，半夜搬家在測試時也是小貓兩三隻在測試所以沒什麼問題，
早上八點的尖峰時間一到，大量的人潮湧入PressPlay，I/O卡住，導致服務停擺。
那兩天我的睡眠時間只有三個小時，不過當一切都搞定且正常運行時，疲憊的感覺
全部冒出來了，於是我就伴隨著成就感一起入睡。
換到GCP後，PressPlay有變得比較好嗎？有的，當時我們還做個記錄：
1. 台灣地區網頁讀取速度之影響 6/30日(六) 比較6/2(六)
網頁讀取 時間從3.9秒，提昇至2.78 (台灣地區) ，提昇28.58%
https://tinyurl.com/y3lbuzbr
2. Ping值之影響從平均100ms提昇至10ms
https://tinyurl.com/y6spu8z6
3. 完成網站瀏覽取樣報告比較 6/29–6/30 對比上週 6/22–6/23
各式的載入、連線時間、回應時間都大大地的減少。
https://tinyurl.com/y5mnpfvx
搬完GCP後從此就高枕無憂了嗎？錯了，挑戰開始來了。
2018–08–23攻擊事件
當天晚上我們受到DDOS攻擊，我們抓到大約200多個國外IP向我們進行攻擊，
這些IP應該都是跳板。之後我們在兩個小時之內，把主機關掉、換IP，
然後建置fail2ban和nginx的防DDOS機制止血，隔天我們進行了檢討，
我們需要更明確的自動監測回報機制。
被攻擊的隔天PressPlay粉絲團所發的聲明:
https://tinyurl.com/y3wmyojk
於是我們就建置了監控主機的功能，只要CPU使用量超標，或是一段時間主機沒有回應，
都會跳出通知
PressPlay內部監控Channel:
https://tinyurl.com/yxtnnqaa
後續還有幾次攻擊事件，不過因為前一此的事件我們作了防護措施，所以只是跳跳通知，
然後隔天去看Log而已，用戶、工程師和老闆都睡了好覺。
2019–03–31阿滴英文愚人節活動爆衝
PressPlay的GA在2019年有個顯著的peak，就是阿滴英文愚人節活動，在我們沒有準備好
的情況之下，當天衝進快十萬人，大約是平常日的4倍量。我記得當天我還在家裡一面
吃鹹酥雞一面看動物朋友，然後就看到「救救PressPlay」頻道一直叫，然後老闆一直
在戳我，才發現這起事件。
還好架構有規劃好，整個活動順利的結束，Server沒有爆炸，可喜可賀。
https://tinyurl.com/y52eekx2
因為這次的虛驚，所以我們就立刻進行一個我很想要玩的東西：Auto Scaling。
10天後，也就是4月9日，Auto Scaling正式上線。之後我們更能高枕無憂地渡過
每一個動畫夜。
這個架構運行至今都沒什麼問題，下面這個是目前PressPlay的主機架構。
現今PressPlay主機架構:
https://tinyurl.com/y3nqcpdj
# PressPlay功能現在與未來
PressPlay目前產品功能是著重在數據開發和應用，今年招募兩位數據背景的RD，
開始著手進行訂閱者的行為，為創作者帶來新的收益和減少流失。
或許大家會注意到我們網站開始有推薦的版位了，首頁的訂閱專案排名也不是像以前
一樣單純用金額去排名，而是透過演算法算出綜合性的指標。
我相信創作者們想知道算法是怎麼算的，在這邊只能透露創作者越投入在經營專案、
訂閱者的互動越深就能得到更好的排名。
目前我們也在密謀一個對創作者更有實質幫助的功能，預計在八月會問世，
還有秘密策劃第三條產品線，也即將在九月和大家見面。
未來PressPlay工程部會持續地深化你所見到的一切，和我們在麥塊中的世界。
最後，歡迎按讚追蹤我們的FB粉專：https://www.facebook.com/PressPlayTech/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.34.49.142 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1562948175.A.FB1.html
※ 編輯: UniFish (1.34.49.142 臺灣), 07/13/2019 00:23:26
真的！很好設定。
我們有用stackdriver，我們的自動監控的通知是利用stackdriver去作的
logging server我們是用來收集nginx的accesslog，還有類mixpanel的服務
不客氣
幫QQ
有點不太懂你的描述XD
GCP load balancer是指定連線進到哪一個VM群組，我們有專門服務APP的機器
iOS/Android用戶使用PressPlay APP會連到APP Server
就連裡頭的webview開網頁也都是由APP Server服務，完全地和Web切開
你沒看到文章封面的Logo嗎？XDD
是我們部門的員工福利(?)
GCP有一年300美金的試用金額，只要有Gmail都可以使用，
任何人都可以開來玩玩
現行Web & App Server是用2VCPU + 8G Ram + SSD
一台一個月大概40-50美金吧，同等級AWS要70-80美金
不過我有綁合約，一台合約價在30美金左右
我們沒有使用Docker，我們走的是效能置上路線。
不過GCP的Auto scaling需要一個範本，才能用這個範本去增開機器。
所以我們會開一台範本的主機，然後把Web & APP服務建在上面，作成範本映像檔，用它
來開機器。
這樣的概念也和Docker很像呢，只是沒有再包一層，這樣費用也比較便宜，效能也比較好
等到未來PressPlay成長到這種架構維護成本大到比使用Docker大之後，
我們再考慮使用Docker
是的，GCP比較便宜，而且重點是在台灣。
我們的服務目前是以台灣為主，它在台灣這個優點就很吸引人了
有用ab打一下，不過最近在想clone一組架構來測試，
但還沒有決定哪個時辰要來做
哈哈哈～我可以確定他不是菜鳥啦。
但在知道架構的前提之前答應了offer但又不想做，我也不知道究竟發生什麼事XD
GCP也有喔，超級便宜，不過目前還沒試過。
目前我們的web & app server突然被關掉重啟也不會影響服務，
看來蠻適合的，找個良辰吉時來試試看好了
是的，所以我們S3有挑便宜的地區，我進公司前就是放在AWS東京了
要搬乾脆索性搬到台灣，為了速度 & $$
真的，一生難有的機會
clodflare的proxy CDN是小型服務首選，而且CDN流量是吃到飽，而且防DDOS，
一個月20米金很佛！！哪家CDN可以如此的省錢啊！！
估算下來我們用aws CDN，都會超過100米金。對於草創初期，都是能省則省。
當時GCP的Cloud Armor還在beta，怕怕的不敢用，fail2ban擋著先
是GCE喔，GAE貴貴，而且不想綁在不好轉移的架構上。
萬一哪天有更棒的服務商出現了，綁太死移不走
偷說，20米金的方案節點在LA，然後我以為商務方案(200米金)會可以用台灣節點
直到我寫信去cloudflare問說台灣節點要用哪個方案。
他們回覆要用企業方案，一個月5,000米金！！夭壽啊！！！！
哈哈哈，細節我記不太得了。
基本上是我們另外一個後端工程師處理的。
來唷（招手
Ya~網上眾說紛云，我就直接寫信給Cloudflare問個清楚，
答案的確讓我倒抽口氣。不過十萬出頭也很夭壽。
現在我們每月主機全部加一加支出連一半都不到啊 XD
我們公司加班費和補休都是照實報照時給～
有時候工程師不好意思報太多還會被我退件說報太少。
伺服器搬家前天我們分成兩組：搬家組和維護組。
搬家組不用來上班，當晚九點集合。辦完後就早上五六點，然後回家睡覺，白天換維護組
接手。
搬家組就在家睡覺。因為我很討厭操勞的生活，所以我自然地會要求組員們不能操勞，該
休就休，改報加班就報加班。
哈哈哈，這個也很重要，我也很感謝公司能不畏懼財務的壓力，能讓我們找正常且符合人
性的方式工作。
也因為我們有好好的休息，許多創意或是複雜的東西，我們都有足夠精神來實現。
是啊 XD
... <看更多>