前言

Kubernetes 控制器主要目的是協調(Reconcile)某個 API 資源的狀態，從實際狀態轉換為期望狀態，換句話說，在 Kubernetes API 資源上的說法，就是讓 API 資源的.status狀態，達到.spec所定義內容。而為了達到這點，控制器會透過 client-go 一直監視這兩種狀態的變化，並在發現變化時，觸發協調邏輯的循環，以更改當前狀態所需的任何操作，並使其往資源的預期狀態進展。Kubernetes 為了實現這樣機制，在 API 提供了一組 List 與 Watch 方法，用於監視任何 API 資源的事件。而自定義控制器就是以 client-go 操作這些 API 方法，監視其主要的自定義資源與其他任何相關的資源。

Read More

前言

前面文章中，了解到 Kubernetes 的架構一直以擴展性與靈活性為主，從 Extension Points 可以看到上至 API 層，下至基礎建設層都有各種擴展的介面、標準與 API，其中 API 的擴展，我們在介紹自定義資源(Custom Resource)時，有提及能透過CustomResourceDefinition(CRD)與API Aggregation來達成，一方面在開發自定義控制器時，很多情況下，會透過增加新的 API 資源來讓控制器實現功能，因此我們必須先瞭解這兩者擴展 API 的作法與選擇。

Read More

前言

昨天提到 Kubernetes GitHub 組織上，有許多豐富的程式函式庫可以使用，除了昨天介紹的一些關於 API 的函式庫外，還有用於跟 Kubernetes API 伺服器溝通的客戶端函式庫，如: client-go，而這些客戶端函式庫在開發 Kubernetes 自定義控制器時，是幾乎避免不了，甚至整個 Kubernetes 控制器架構都是圍繞這些函式庫上實現，而今天就是要針對這些客戶端函式庫做初步認識。

Read More

前言

由於 Kubernetes 控制器是主動調和(Reconciliation)資源過程的程式，它會透過與 API 伺服器溝通，以監視叢集的資源狀態，並依據 API 物件的當前狀態，嘗試將其推向預期狀態。而本系列文章是說明如何採用官方 API client 函式庫來編寫 Kubernetes 自定義控制器。因此需要在開發之前，先了解會使用到的函式庫與工具等等。

Kubernetes 組織在 GitHub 上，維護了許多可以使用的程式函式庫，如: api、client 與 api-machinery 等等都被用於不同的功能實現。而要使用這些函式庫只需要以k8s.io/..方式，在 Go 語言的專案下導入即可。在接下來個小部分中，我將介紹一些會用於開發自定義控制器的 API 相關函式庫。

Read More

前言

使用 Kubernetes 時，大家都能感受到其容器編配能力，當有一個容器發生異常時，Kubernetes 會透過自身機制幫你把容器遷移或重新啟動，或者能利用副本機制讓容器同時存在於叢集的不同節點上，甚至提供滾動升級(Rolling Update)容器機制。這些酷炫的功能，大家肯定都知道如何去使用，因為 Kubernetes 透過一些方式，將複雜的功能進行了抽象化與封裝，因此使用者只需要了解如何操作 API 物件，就能完成需要的功能，比如:Deployment 修改參數就會進行滾動升級。然而這些『抽象化』與『封裝』的過程究竟是如何實現呢?今天文章就是要針對這個部分進行探討。

Read More

前言

Device Plugins 是 Kubernetes v1.8 版本開始加入的 Alpha 功能，目標是結合 Extended Resource 來支援 GPU、FPGA、高效能 NIC、InfiniBand 等硬體設備介接的插件，這樣好處在於硬體供應商不需要修改 Kubernetes 核心程式，只需要依據 Device Plugins 介面來實作特定硬體設備插件，就能夠提供給 Kubernetes Pod 使用。而本篇會稍微提及 Device Plugin 原理，並說明如何使用 NVIDIA device plugin。

P.S. 傳統的alpha.kubernetes.io/nvidia-gpu將於 1.11 版本移除，因此與 GPU 相關的排程與部署原始碼都將從 Kubernetes 核心移除。

Read More

前言

在地端的環境中，有許多原本能透過網路取的資源(如: 系統套件、容器映像檔等等)，有可能會基於公司一些考量(如:安全、網路等)，而將這些資源建立在本地端，然後再提供給叢集使用。其中容器儲存庫(Container Registry)是最常見的需求，因為有些團隊會要求公司測試與服務的容器映像檔，都必須從公司內部取得，這時自建一套私有容器儲存庫就非常重要。尤其是基於安全考量，還需要對映像檔進行安全掃描，或對映像檔內容進行加密等等。

而今天將說明如何自建一套容器儲存庫，並實現映像檔內容信任功能，以確保叢集使用的映像檔處於安全受信任的。在開始前，先來了解一下今天要使用到的開源軟體吧。

Read More

前言

在一座 Kubernetes 叢集中，通常都會透過不同的使用者來給予不同的存取權限，因為若讓任何人擁有叢集最高權限的話，有可能帶來一些風險。而在 Kubernetes 中都會有兩種類型的使用者:

• 由 Kubernetes 管理的服務帳號(Service Account)。
• 普通使用者。

假設普通使用者是由外部獨立系統進行管理(如 LDAP)，那麼管理員分散私鑰、儲存使用者資訊等等功能，都必須由外部系統處理，因為在這方面，Kubernetes 並沒有普通使用者的 API 物件可以使用，因此無法透過 API 將普通使用者資訊添加到叢集中。

Read More

前言

在公有雲環境中，負載平衡器建立與外部 IP 位址分配都能由雲平台完成，且 Kubernetes 也能輕易地用 Cloud Provider 來進行整合。但在地端(或裸機)環境中，原生 Kubernetes 就無法達到這樣功能，必須額外開發系統才能達到目的。而慶幸的是前 Google 工程師也看到這樣問題，因此開發了 MetalLB 來協助非雲平台 Kubernetes 能實現網路負載平衡的提供。且 MetalLB 以 Kubernetes 原生方式，直接在 Kubernetes Service 描述LoadBalancer 類型來要求分配負載平衡器 IP 位址。雖然 MetalLB 確實帶來了好處，但它使用起來沒問題嗎?另外它究竟是怎麼實作的?會不會影響目前叢集網路環境呢?

基於這些問題，今天想透過深入了解 MetalLB 功能與實作原理，以確保發生問題時，能夠快速解決。

Read More

前言

昨天文章中，我們提到想要讓同一個叢集能夠支援兩個同樣的 TCP/UDP 曝露給外部存取，雖然能夠利用 Service LoadBalancer 或 NodePort 類型來達到需求，但是這兩者依然存在著限制，比如說 NodePort 使用叢集節點 IP:Port 方式來提供存取，這存在著單點故障問題，且建立一個 Port 就會在所有節點綁定;而 LoadBalancer 則不支援地端分配負載平衡 IP 的機制，只能透過手動在externalIPs欄位指定，若沒指定的話，其功能只是繼承 NodePort 機制，多了個 Target Port 能夠直接存取而已，而且儘管能夠在externalIPs指定 IP，但這些 IP 又該從哪邊來呢?又怎麼分配呢?那該怎麼解決呢?

很慶幸的是有人開發了一個開源專案 MetalLB 來幫助我們解決這些問題，而今天就是要來探討這個專案如何使用。

Read More