本文將說明如何透過 Minikube 建立多節點 Kubernetes 叢集。一般來說 Minikube 僅提供單節點功能，即透過虛擬機建立僅有一個具備 Master/Node 節點的 Kubernetes 叢集，但由時候需要測試多節點功能，因此自己改了一下 Minikube 來支援最新版本(v1.13.2)的多節點部署，且 CNI Plugin 採用 Calico，以方便測試 Network Policy 功能。

Read More

本文說明如何從 GitHub 上的原始碼專案，來建構 Docker 與 NVIDIA Docker Package。由於過程需要修改多個專案，因此開始前需要先了解一下將修改的 GitHub repos：

• Moby: 建構 Docker server side 的開源專案，前身為 Docker Engine 專案。
• Docker CE: 建構 Docker CE 整套工具的專案，最上層沒下 License，屬於 Docker 官方產品，因此受到 EULA 限制，但該專案底下的 Engine 與 CLI 都是 Apache v2，故這邊只拿 CLI 來使用。
• NVIDIA Docker: 用以建構 NVIDIA Docker 工具。
• NVIDIA Container Runtime: 提供 NVIDIA 的 Container runtime。
• Libnvidia Container: Container runtime 的底層函式庫。

Read More

本篇將介紹如何透過 Ansible Playbooks 來快速部署多節點 Kubernetes，一般自建 Kubernetes 叢集時，很多初步入門都會透過 kubeadm 或腳本來部署，雖然 kubeadm 簡化了很多流程，但是還是需要很多手動操作過程，這使得當節點超過 5 - 8 台時就覺得很麻煩，因此許多人會撰寫腳本來解決這個問題，但是腳本的靈活性不佳，一旦設定過程過於龐大時也會造成其複雜性增加，因此這邊採用 Ansible 來完成許多重複的部署過程，並提供相關變數來調整叢集部署的元件、Container Runtime 等等。

這邊我將利用自己撰寫的 kube-ansible 來部署一組 Kubernetes HA 叢集，而該 Playbooks 的 HA 是透過 HAProxy + Keepalived 來完成，這邊也會將 docker 取代成 containerd 來提供更輕量的 container runtime，另外該 Ansible 會採用全二進制檔案(kube-apiserver 等除外)方式進行安裝。

本次 Kubernetes 安裝版本：

• Kubernetes v1.11.2
• Etcd v3.2.9
• containerd v1.1.2

Read More

Knative 是基於 Kubernetes 平台建構、部署與管理現代 Serverless 工作負載的開源專案，其目標是要幫助雲端供應商與企業平臺營運商替任何雲端環境的開發者、操作者等提供 Serverless 服務體驗。Knative 採用了 Kubernetes 概念來建構函式與應用程式，並以 Istio 實現了叢集內的網路路由，以及進入服務的外部連接，這讓開發者在部署或執行變得更加簡單。而目前 Knative 元件焦距在解決許多平凡但困難的事情，例如以下：

Read More

本篇說明如何透過 CoreDNS 自建一套 DNS 服務，並利用 Kubernetes ExternalDNS 同步 Kubernetes 的 Ingress 與 Service API object 中的域名(Domain Name)來產生資源紀錄(Record Resources)，讓使用者能夠透過自建 DNS 服務來導向到 Kubernetes 上的應用服務。

Read More

本篇將說明如何透過 Kubeadm 來部署 Kubernetes v1.11 版本的 High Availability 叢集，而本安裝主要是參考官方文件中的 Creating Highly Available Clusters with kubeadm 內容來進行，這邊將透過 HAProxy 與 Keepalived 的結合來實現控制面的 Load Balancer 與 VIP。

Read More

本篇延續過往手動安裝方式來部署 Kubernetes v1.11.x 版本的 High Availability 叢集，而此次教學將直接透過裸機進行部署 Kubernetes 叢集。以手動安裝的目標是學習 Kubernetes 各元件關析、流程、設定與部署方式。若不想這麼累的話，可以參考 Picking the Right Solution 來選擇自己最喜歡的方式。

Read More

前面幾篇提到了 Prometheus 儲存系統與 Federation 功能，其中在儲存系統可以得知 Local on-disk 方式雖然能夠帶來很好的效能，但是卻也存在著單點故障的問題，並且限制了 Prometehsu 的可擴展性，引發資料的持久等問題，也因此 Prometheus 提供了遠端儲存(Remote storage)的特性來解決擴展性問題。

而除了儲存問題外，另一方面就是要考量單一 Prometheus 在大規模環境下的採集樣本效能與乘載量(所能夠處理的時間序列資料)，因此這時候可以利用 Federation 來將不同監測任務劃分到不同實例當中，以解決單台 Prometheus 無法有效處理的狀況。

Read More

Prometheus 在效能上是能夠以單個 Server 支撐百萬個時間序列，當然根據不同規模的改變，Promethes 是能夠進行擴展的，這邊將介紹 Prometheus Federation 來達到此效果。

Prometheus Federation 允許一台 Prometheus Server 從另一台 Prometheus Server 刮取選定的時間序列資料。Federation 提供 Prometheus 擴展能力，這能夠讓 Prometheus 節點擴展至多個，並且能夠實現高可靠性(High Availability)與切片(Sharding)。對於 Prometheus 的 Federation 有不同的使用方式，一般分為Cross-service federation與Hierarchical federation。

Read More

Prometheus 系統包含了 Local on-disk storage 與 Remote storage，本節將說明兩者差異，以了解作為實現資料儲存可靠性的基礎。

Read More