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
對文章有興趣的別忘了參閱全文
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
「kubelet」的推薦目錄:
- 關於kubelet 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於kubelet 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
- 關於kubelet 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
- 關於kubelet 在 コバにゃんチャンネル Youtube 的精選貼文
- 關於kubelet 在 大象中醫 Youtube 的最讚貼文
- 關於kubelet 在 大象中醫 Youtube 的最佳解答
- 關於kubelet 在 Day 5 - Kubernetes kubelet, kubeadm, kubectl 介紹- iT 邦幫忙 的評價
- 關於kubelet 在 kubelet - Kubernetes 的評價
- 關於kubelet 在 Virtual Kubelet - GitHub 的評價
- 關於kubelet 在 kubeadm init shows kubelet isn't running or healthy - Stack ... 的評價
kubelet 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
本篇是一個 Kubernetes 的入門介紹文,探討 Kubernetes 內要如何透過 SSL/TLS 憑證來加強應用程式之間的連線。
本篇文章不使用任何第三方套件,反而是從 Kubernetes 內建的資源功能出發去探討,理解 Kubernetes 的能力與極限其實長久下來對於評估各種專案都滿有幫助的。
Kubernetes 的 Secret 除了使用 base64 作為編碼技術外,其實本身也提供不少類型方便管理人員使用,譬如本文提到的 tls 類型, container registry credential 以及最廣泛使用的 generic 等。
Secret(tls類型)本身創建時會吃兩個參數,分別是 tls.crt 與 tls.key,接者這類型的 secret 可以與 ingress 進行整合,將 TLS 給掛載到 Ingress 物件中並且同時執行 TLS Termination,讓 Ingres 與外部連線使用 HTTPS 而內部服務則使用 HTTP 來溝通。
文章中提到如何透過 openssl 創建一個 self-signed 的憑證,並且針對 self-signed 的特性進行討論,其列出了四個 self-signed 的缺點
1. 瀏覽器連接到這些 self-signed 憑證的網站時都會露出警告告知使用者,因此這類型的憑證不適合任何正式生產環境使用
2. 因為 self-signed 就是開發者自行創造,缺少第三方可信任機關的認證,因此惡意攻擊者可以輕鬆換掉服務上的簽證,畢竟瀏覽器本來就覺得簽證有問題,無法分辨到底是先前的自簽憑證還是被替換的憑證。
3. 第三方CA都會針對發行的憑證給予一些保固與服務,這部分是自簽沒有辦法擁有的
4. 愈來愈多的使用者會不太願意瀏覽與使用沒有合法且信任憑證的網站
作者提到 Kubernetes 內部雖然有一個 CA,但是不推薦把任何服務相關的憑證都跟其扯上關係,
因為該 CA 是給 Kubernetes 內部控制平面使用的,譬如 kubelet, API Server, Controller, Scheduler 等元件彼此溝通中間使用的。
文章最後作者示範透過 cfssl 的該指令幫一個內部服務創建一個憑證,由於內部服務會透過 Kubernetes Service 提供的 DNS 來存取,因此創建憑證時會於 CN 欄位補上 alternative 的名稱,把 service.svc.... 之類的全部都補上。
https://medium.com/avmconsulting-blog/how-to-secure-applications-on-kubernetes-ssl-tls-certificates-8f7f5751d788
kubelet 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
本篇文章帶來的是 Kubernetes 1.20 的一些整理,到底 Kubernetes 1.20 有什麼改變以及要如何升級舊有的 Kubernetes 到 1.20
官方宣稱該版本有 42 個改進,其中 11 個改進是該內容正式畢業進入 stable 版本, 15 個轉移到 beta 版本而剩下 16 個則是進入 alpha。
1. Volume Snapshot Operations (Stable)
針對容器快照的相關操作正式進入穩定版,要注意的是這個功能必須要使用的 Storage 服務有支援,同時請記得,針對任何的儲存設備,可以使用 CSI 來安裝就使用 CSI。
盡量不要繼續使用 in-tree 的方式去銜接這些設備了,因為所有的維護與修改都轉移到 CSI driver 上
2. Kubectl Debug (Beta)
Kubectl alpha 之前的子指令 debug 已經正式轉移到 beta 版本,未來可以直接使用 kubectl debug 的指令來幫忙一些資源的驗證與處理。
譬如
a. 創建一個 pod 部署到指定的節點上並存取節點上的檔案系統來提供對節點的除錯功能
b. 針對運行 crash 的 pod 除錯
3. Dual IP Stack IPv4/IPv6 (Alpha)
IPv4/IPv6 功能重新實作,未來將可以對單一 Serivce 同時指派 ipv4 + ipv6 的地址,同時也可以針對現存單一 ipv4 的 service 進行轉換
4. Graceful node shutdown (Alpha)
過往刪除 Pod 時都會有所謂的 pod lifecycle 等階段來處理一切狀態,但是當節點被關機時,節點上方運行的 Pod 並不會遵循 Pod lifecycle 來處理。
這個新的功能將會讓 Kubelet 去感知到節點正在關閉,並且能夠針對正在運行的Pod去提供 graceful shutdown 的過程
更多的討論可以參考下列文章或是直接看官方全文,滿多功能都慢慢改變
另外要注意的是,每次改版都要注意 API 是否有改變名稱,非常推薦使用如 kube-no-trouble 這類型的工具去檢查當前部署資源的 APIVersion 是否有即將要被捨棄的,避免 k8s 更新後應用程式都無法部署上去的情況發生
https://faun.pub/whats-new-in-kubernetes-version-1-20-and-how-to-upgrade-to-1-20-x-5ea72f904e7d
kubelet 在 コバにゃんチャンネル Youtube 的精選貼文
kubelet 在 大象中醫 Youtube 的最讚貼文
kubelet 在 大象中醫 Youtube 的最佳解答
kubelet 在 kubelet - Kubernetes 的解答
The kubelet is the primary “node agent” that runs on each node. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a ... ... <看更多>
kubelet 在 Virtual Kubelet - GitHub 的解答
Virtual Kubelet is an open source Kubernetes kubelet implementation that masquerades as a kubelet for the purposes of connecting Kubernetes to other APIs. ... <看更多>
kubelet 在 Day 5 - Kubernetes kubelet, kubeadm, kubectl 介紹- iT 邦幫忙 的解答
前言前面安裝好了kubelet, kubeadm, kubectl,再來就是介紹它們之間的用途為何kubelet pod 管理在kubernetes 的設計中,最基本的管理單位是pod,而不. ... <看更多>