開發自定義控制器前,需要先了解的東西 Part1

前言

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

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

Read More

Share Comments

淺談 Kubernetes 自定義資源(Custom Resource)與自定義控制器(Custom Controller)

前言

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

Read More

Share Comments

利用 Device Plugins 提供硬體加速

前言

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

Share Comments

自建私有容器儲存庫(Container Registry)與實現內容信任(Content Trust)

前言

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

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

Read More

Share Comments

實作 Kubernetes 外部認證系統整合: 以 LDAP 為例

前言

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

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

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

Read More

Share Comments

實作 Kubernetes 裸機 Load Balancer Part3

前言

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

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

Read More

Share Comments

實作 Kubernetes 裸機 Load Balancer Part2

前言

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

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

Read More

Share Comments

實作 Kubernetes 裸機 Load Balancer Part1

前言

在生產環境中,通常都是以 Ingress 方式來曝露 HTTP/HTTPS 存取服務,而前幾天分享如何透過 NGINX Ingress、ExternalDNS 與 CoreDNS 等,就是在自建 Kubernetes 上實現這樣功能,讓我們以 L7 網路協定功能來達到服務存取目的。但在實際應用中,還是有很多需要以 TCP/UDP 方式存取或連接服務,這樣該如何進行呢?相信有研究過 Kubernetes 朋友都知道 NGINX Ingress 也支援了 TCP/UDP 的反向代理,這表示 Ingress 也能支援 TCP/UDP。但另一個問題來了,如果叢集有兩個服務需要用到同一個 TCP/UDP Port 時,這該怎麼辦呢?這時 Ingress 就無法很好地達到該需求,那我們該怎麼做呢?事實上,Kubernetes Service 的 LoadBalancer 類型就能達到,但是僅限於公有雲服務上才能完成,在地端的 Kubernetes 存在著一些限制,使得無法滿足需求。而這次主題就是要針對該議題進行說明與嘗試實作。

Read More

Share Comments

實現 Kubernetes Service/Ingress 同步設定 DNS 資源紀錄 Part2

前言

有時地端 Kubernetes 會需要提供給內部團隊使用,而團隊人員若希望以域名方式直接存取 Kubernetes 上的服務時,就必須建立一套機制。但這樣需求中,也增加了維運人員的負擔,因為若沒有自動化機制,就要在 Kubernetes Ingress/Service 變動時,手動處理 DNS 資源紀錄,以確保內部團隊能夠解析到位址。

基於此原因,今天延續在實現 Kubernetes Service/Ingress 同步設定 DNS 資源紀錄 Part1的文章提到的架構,實際將該架構部署到一座地端 Kubernetes 叢集上測試,並透過實作過程來了解其功能是如何運作的。

Read More

Share Comments

實現 Kubernetes Service/Ingress 同步設定 DNS 資源紀錄 Part1

前言

前幾天都在分享關於叢集部署與升級事情,今天來聊聊在地端 Kubernetes 常見的需求功能吧。在生產環境中,我們會將網站或系統放到 Kubernetes 上執行與管理,再利用 Service 機制把服務暴露給外部存取使用,但 Service 在預設情況下僅能支援第四層網路協定(L4,TCP/UDP)功能,故無法設定完整網域名稱(Fully Qualified Domain Name,FQDN)來存取服務,這時大家肯定會想到 Kubernetes 的 Ingress 功能,因為 Ingress 能夠實現第七層網路協定(L7)功能,並以域名(Domain name)形式來對應到 Service 的 Pod 端點。

但是地端環境不像公有雲有各種基礎建設服務(Infrastructure as a Service,IaaS)可以輕易使用與整合(比如:透過 Cloud Provider 讓 Service 整合負載平衡服務、利用 DNS 服務來對應到 Service 的負載平衡 IP 等等),這時如果想要實現自動同步 Kubernetes Service/Ingress 資源,來設定 FQDN 的話,就會需要建立一套網域名稱系統(Domain Name System,DNS),並實作同步 Kubernetes 物件設定 DNS 資源紀錄(DNS record)的控制器。慶幸的是,Kubernetes 社區已經有相關元件可以協助我們實踐這些機制,今天就將針對這部分來說明與實現。

Read More

Share Comments