想在K8s上建置資料庫服務嗎？Google說需要考慮這些因素

用戶使用雲端資料庫現行有幾種方法，包括在虛擬機器或是Kubernetes上執行，或甚至是直接採用完全託管的記憶體服務，Google對此提供了一些建議，供用戶在選擇資料庫之前做參考。

Kubernetes的應用越來越熱門，許多應用程式被容器化，甚至專門將軟體容器化的服務也熱門起來，但這個熱潮並沒有發生在資料庫上，Google提到，可以容器化的工作負載，通常具有能適應頻繁地重新啟動、橫向擴展、虛擬化等其他限制，因此資料庫在服務的可用性等要求，限制了資料在分散式環境中執行的發展。

Google提到，但是仍有不少開發團隊，希望資料庫可以使用與應用程式相同的堆疊，而營運人員也能使用相同的工具管理。比起完全託管的資料庫服務Cloud Spanner、Cloud Bigtable和Cloud SQL等，和在虛擬機器上全自營運的選項，在Kubernetes上執行資料庫雖然偏向全自營運，但是Kubernetes提供的自動化功能，是能為營運人員省掉一些麻煩，但Google提醒，營運人員要有心理準備，因為Pod狀態僅為暫時性的，而且資料庫應用程式重新啟動與故障轉移機率比較高，且資料庫管理員的工作像是備份、擴展和調校等工作，會因為容器化新增的抽象層而不同。

由於Kubernetes的Pod是會消失的，因此故障轉移事件性的可能性，會高於傳統託管或是完全託管的資料庫，而換得的好處是，當要執行的資料庫，需要包含分片、故障轉移選擇或是內建的複製等功能，那在Kubernetes上營運將會更容易，部分開源專案還提供自訂義資源以及營運工具，以幫助使用者管理資料庫。

Google製作了一個決策樹圖，供用戶評估並選擇適合的雲端資料庫的方案，要在Kubernetes上建置資料庫，最先需要了解的是，資料庫的功能以及生態系的專案是否對Kubernetes友善，再來還需要評估組織營運工作負載的能量，有充足的營運能力再選擇在Kubernetes上自建資料庫。

在資料庫的選擇上，Google表示，開發人員需要考慮資料庫在應用程式和業務環境中執行的功能，儲存較多暫時狀態以及快取層的資料庫，更適合在Kubernetes上運作，因為該類型的資料庫通常擁有較高的彈性，因此也能夠在Kubernetes上提供較好的服務品質。另外，營運人員需要考量資料庫支援的複製模式，非同步複製可能產生資料遺失等問題，因為交易可能只提交到主資料庫，而沒有傳送給輔助資料庫，營運人員需要靠考慮資料遺失，以及可接受遺失的資料量。