前一陣子利用 NFS 來將使用者上傳上來的檔案儲存在伺服器端的檔案目錄中，但是當使用者想要檢視當前已經上傳上來的檔案並且查看檔案建立的時間時，卻發現無法取得檔案建立時間。雖然可以在設計上稍做調整，例如當檔案上傳上來時，將當前時間紀錄並儲存起來，待後續檢視使用。不過這樣的方法雖然可行，但是缺點就是需要額外成本來維護所儲存的檔案建立時間。因此本篇筆者就希望利用 Linux 檔案系統所儲存的建立時間來提供檢視檔案使用。

在網路上可以找到大量使用 kubeadm 等類似工具建置 Kubernetes Cluster 的教學，雖然使用這類工具可以快速建立一個 Kubernetes Cluster ，甚至連 HA 也考量進去了。但以手動方式建置好處莫過於可以了解每個元件之間的關係與建置過程可能會遇到的問題以及從中學習排除問題的經驗。因此筆者就開始了這條不歸路….本篇主要紀錄建置一個 HA Kubernetes Cluster 的過程，從 Github 下載 Source Code 開始到建置完成。

時常在開發任何應用服務時，會利用 HTTP 協定來串接服務與服務之間的通訊，然而這樣的方式可能存在著一定的風險，因此就有人會想是否可以在傳輸過程中加入驗證機制，來提高資料的安全性，進而衍伸出 TLS 雙向驗證機制。

筆者最近在部署 Kubernetes 過程中，好奇每個元件究竟安裝與不安裝對 Kubernetes 造成什麼影響？CoreDNS 主要的功能之一是當 Pods 做套件更新或安裝時，可以提供 DNS Forward 功能，將請求轉發至外部進行 Domain 解析，並從正確的位址下載套件進行安裝。

本篇就聚焦在 CoreDNS 將 Pods 的請求轉發至外部 DNS Server 進行解析的運作流程。

Vitess 是一套基於 MySQL 或 MariaDB 的叢集式資料庫系統，並且提供 Sharding 的概念達到水平擴展的機制。
Vitess 採用單一端口的方式，使用者僅需透過單一端口進行資料庫的寫入，讀取或刪除行為，不必在意底層資料庫如何處理該行為，就能達到資料的分散儲存效果。
Vitess 目前已經從 CNCF 專案中畢業，已有許多世界級大廠使用，如 Youtube, slack, GitHub… 等等。

在現在任何的雲端服務開發或部署時，都會面臨如何能處理大量使用者同時存取服務所產生大量請求的問題。然而大多數的處理方式免不了需要透過負載平衡服務，來將使用者請求分派至不同的實體或虛擬機器進行處理，因此負載平衡服務就扮演極為重要的角色。

本篇就以 HAProxy 為例，將使用者的請求以 Round Robin 的方式平均分派至不同機器進行處理，並結合 Data Plane API 提供一個 RESTful API 介面以提供動態修改 HAProxy 配置的功能。

本篇要介紹如何將 Ceph RGW 與 OpenStack Barbican 進行整合，將使用者透過 Ceph Radosgw 上傳的檔案在 Server Site 進行 Server Side Encription - SSE(伺服器端加密)，可以有效提升資料安全性，讓儲存在伺服器端的資料不再是明碼。但相對也存在一定的風險，若儲存在 OpenStack Barbican 的 Secret 刪除，則可能導致資料無法正常被解碼，因此讀者在使用上需特別注意。

事隔多日來繼續介紹後續 Ceph RGW 與 OpenStack Keystone 的整合配置，還沒有讀上篇的讀者可以先閱讀上篇，若有興趣也可逐步跟著這系列的文章進行操作，或許你會對於內容更有感覺唷！

Ceph Object Storage 除了可以自身管理使用者訊息與驗證外，也可以透過 OpenStack Keystone 進行管理。本篇會先介紹如何在 CentOS 7 上安裝 OpenStack Keystone (Version Stein)，後續會在下篇時介紹如何與 Ceph 進行串接！

在使用儲存服務的時候，時常會根據使用者的權限(付的錢？XD)來決定這個使用者可以使用哪些硬體支援，常見的像是 SSD, HDD 或者 Tape 等等。

本篇就是專門介紹在 Ceph 中透過 Crush Rule 將硬體支援歸納出多種不同的 Partitions，並且配置每個 RGW 使用者可以儲存的 Placement tags 與 default Placement，以達到如上述限制使用者可儲存的硬體支援。