關於 gcp container ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://medium.com/k8slens/most-popular-lens-extensions-june-2021-8f88ef79aab6

這篇文章是作者推薦 Lens 這套 Kubernetes Dashboard 上相當熱門的擴充功能。

1. Mirantis Container Cloud Extensions
這項功能是由 Mirantis 所開發的，可以讓使用者更輕鬆的去使用 Mirantis Container Cloud 上的資源

2. Starboard Extension
該擴充功能是由 Aqua Security 所開發的功能，可以更方便地去檢視 Kubernetes 中部署 Image 的安全性報告，
該報告主要會列出該 Image 已知的 vulnerability 列表。

3. Kubernetes Resource Map Extension
該擴充功能會透過視覺化的方式來呈現 Kubernetes 內的資源關係，譬如 Service, Deployment, Pod...等彼此關係，可以讓使用者更清楚的知道
目前叢集中不同資源的彼此關係

4. Kubecost Extension
如果有使用 Kubecost 這個專案來管理 Kubernetes 叢集內的相關資源成本的話，可以使用這個擴充工具將這個資訊直接已視覺化的方式呈現到 Lens 的介面中

5. GKE Sync Extension
該擴充功能會自動地透過 gcloud 指令來同步 GCP 上的資源，包含了 projects 以及 GKE Clusters。
透過這個擴充功能，使用者可以不需要去準備相關的 kubeconfig 就可以管理新加入的 GKE Clusters。

6. Capsule Extension
該擴充功能由 Clastix 所開發的，Clastix 提供了一個讓 Kubernetes 支援多租戶的功能，而該擴充功能是讓使用者可以透過 Lens 來輕鬆管理這些多租戶的資源與使用情況

ref: https://medium.com/swlh/quick-fix-sharing-persistent-disks-on-multiple-nodes-in-kubernetes-ef5541fd8376

這篇文章是 kubernetes 與 Storage 整合的經驗分享文，該文章包括了下列內容
Cloud Storage, NFS, Kubernetes, PV/PVC.

Kubernetes 內針對這些儲存相關的使用方式有
1. 使用 ephemeral 的儲存設備
ephemeral 只適合暫存資料使用，因為該儲存設備不是持久保存的，這意味 Container 如果重啟，資料就會消失。
2. 使用 Bind Mount 的方式將資料從節點掛載到容器中
就如同過往使用 Docker 時會使用 -v 的方式將同節點中的儲存目錄給掛載到容器中來使用。

基本上有任何永久性儲存的需求都會採用(2) 這個方式來處理，而目前很多 Cloud Provider 都有提供相關的儲存裝置讓你的 VM(k8s Node)
可以輕鬆存取與使用。

舉例來說，AWS 有 EBS， GCP 有 GPD，這類型的 Block Storage Device 本身支援動態掛載與卸載，所以就算 Kubernetes 將目標 Container 重新部署到
不同節點上也不需要擔心資料會不同，因為這些 Storage 可以隨者不同節點動態掛載上去，讓你的 Container 看到相同的資料。
但是以上兩個裝置都有一個限制，就是並不支援同時多人寫入的動作，於 Kubernetes 只能使用 Read/Write 模式。
這意味每個 Storage 同時只能有一個 Container 去進行讀寫操作(but Azure 的服務就沒有這個限制)

作者假設今天有一個服務底層是由三個元件組成，這些元件會需要針對相同一個資料集一起處理。
舉例來說有服務 A,B,C
A: 將資料寫入到儲存系統中
B: 從儲存系統中讀入資料進行二次處理，處理完畢再寫回去儲存系統中
C: 將資料從儲存系統中讀出並且供外部使用

上述情境簡單說就是一個儲存設備，會有三個服務同時想要讀取，一個專心寫，一個同時讀寫，一個專心讀。
這種需求就沒有辦法單純使用 EBS/GPD等裝置來使用，因此作者接下來就會針對如何使用 NFS 這套網路儲存系統來搭建一個符合上述需求的用法。
該解決方案流程如下
1) 透過 EBS/GPD 的方式掛載一個儲存空間到 k8s 節點中
2) 部署一個 NFS Server 的容器到 Kubernetes 中，該 NFS Server 會使用 EBS/GPD 作為其儲存空間的來源
3) NFS Server 透過 service 分享服務
4) 部署 PV/PVC 物件到 Kubernetes 中
5) A,B,C 三種容器透過 PVC 的方式來存取 NFS Server

因為 NFS 本身就是一個可多重讀寫的解決方案，作者透過這種方式讓多個應用程式可以同時讀寫，同時將這些資料保存到 EBS/GPD 的儲存空間中。
不過這種用法帶來的問題可能就是速度問題，從同節點直接存取變成透過網路存取，所以如果本身對於存取有非常高的頻寬需求時，使用這種解決方案也許會遇到
很難解決的瓶頸，畢竟大部分人的 k8s 叢集都是 data/control 兩種資料交雜於底層的網路架構中，沒有辦法將 data plane/control plane 給分開來。

有興趣看作者如何一步一步搞定上述流程的可以參考全文

作者今天想要針對自己的應用程式準備一個滿足下列的條件的運行環境

1. 該環境所需要的金錢成本盡可能地低
2. 能夠針對流量而自動地去 scale out/in 整個環境
3. API 後端應用程式是否能夠有 self healing 的能力

考量過後，作者考慮使用 Kubernetes 作為其運作平台，因此開始了成本探險之旅，想瞭解一個最便宜的 Kubernetes 服務可以多少錢。

為了滿足作者的應用程式，作者針對該 k8s 環境考慮了下列五個方向

1. K8s 的 Control Plane
2. 運作的 VM
3. Load Balancer
4. Disk 大小
5. Container Registry

作者針對三大公有雲，分別是 Azure/GCP/AWS 來進行分析，比較上述五大類型下分別的每個月成本多少

結果因為 Aks 的 Control Plane 目前不用錢，因此與其他兩家比起來價錢落差非常大。
考慮五個元件後， Azure/GCP/AWS 每個月最低價格為 $38.40 $102.75 $107.58

這也是為什麼作者的標題是用每天一美元的價格來運行一個 kubernetes cluster。

本文最有趣的應該是相同元件下，不同公有雲之間的比較與價目表，算是幫助大家去挖掘與比較，有興趣的可以參考原文

https://georgepaw.medium.com/how-to-run-the-cheapest-kubernetes-cluster-at-1-per-day-9287abb90cee