我們都知道 Kubernetes 有很多特性可以確保系統與應用程式能夠更加穩定、部署更加流暢與管理更加簡單，而且使用起來也相對容易，但在自建(或地端)部署時，卻與想像的不同，有很多需要關注的問題與事情，例如:高可靠性(Highly Available，HA)、如何安全地更新叢集、裸機負載平衡器(Bare-metal Load Balancer)、動態 DNS 更新、硬體設備整合、分散式儲存整合與離線安裝(Offline Installation)等等，除了上述問題外，還要為了客戶能夠對部署的 Kubernetes 更有信心，因此必須進行壓力測試、E2E 測試、一致性測試與叢集安全掃描等等。從上述簡短的描述中，可以了解到自己蓋一套可以用的 Kubernetes 叢集，並且自己維運是多麼麻煩的事，這對公司來說都是成本支出。也正因此大多數人會偏向使用公有雲的 Kubernetes 服務，如 EKS、GKE 與 AKS 等等來減少維運成本的支出。下圖顯示不同部署的方式需要管理的部分。
Kubernetes Federation(聯邦) 一直是很有趣的議題，並被重視的功能，Federation 目的是希望實現單一叢集統一管理多個 Kubernetes 叢集的機制，這些叢集可能是跨地區(Region)，也可能是在不同公有雲供應商(Cloud Provider)上，亦或者是公司內部自行建立的叢集。一但叢集進行聯邦後，就可以利用 Federation API 資源來統一管理多個叢集的 Kubernetes API 資源，如定義 Deployment 如何部署到不同叢集上，其叢集所需的副本數等。
而 Kubernetes Federation 的誕生正是希望利用聯邦機制來解決一些問題，並達到一些好處，如以下：
本文將說明如何透過 Minikube 建立多節點 Kubernetes 叢集。一般來說 Minikube 僅提供單節點功能，即透過虛擬機建立僅有一個具備 Master/Node 節點的 Kubernetes 叢集，但由時候需要測試多節點功能，因此自己改了一下 Minikube 來支援最新版本(v1.13.2)的多節點部署，且 CNI Plugin 採用 Calico，以方便測試 Network Policy 功能。
本文說明如何從 GitHub 上的原始碼專案，來建構 Docker 與 NVIDIA Docker Package。由於過程需要修改多個專案，因此開始前需要先了解一下將修改的 GitHub repos：
本篇將介紹如何透過 Ansible Playbooks 來快速部署多節點 Kubernetes，一般自建 Kubernetes 叢集時，很多初步入門都會透過 kubeadm 或腳本來部署，雖然 kubeadm 簡化了很多流程，但是還是需要很多手動操作過程，這使得當節點超過 5 - 8 台時就覺得很麻煩，因此許多人會撰寫腳本來解決這個問題，但是腳本的靈活性不佳，一旦設定過程過於龐大時也會造成其複雜性增加，因此這邊採用 Ansible 來完成許多重複的部署過程，並提供相關變數來調整叢集部署的元件、Container Runtime 等等。
本篇延續過往手動安裝方式來部署 Kubernetes v1.11.x 版本的 High Availability 叢集，而此次教學將直接透過裸機進行部署 Kubernetes 叢集。以手動安裝的目標是學習 Kubernetes 各元件關析、流程、設定與部署方式。若不想這麼累的話，可以參考 Picking the Right Solution 來選擇自己最喜歡的方式。
前面幾篇提到了 Prometheus 儲存系統與 Federation 功能，其中在儲存系統可以得知 Local on-disk 方式雖然能夠帶來很好的效能，但是卻也存在著單點故障的問題，並且限制了 Prometehsu 的可擴展性，引發資料的持久等問題，也因此 Prometheus 提供了遠端儲存(Remote storage)的特性來解決擴展性問題。
而除了儲存問題外，另一方面就是要考量單一 Prometheus 在大規模環境下的採集樣本效能與乘載量(所能夠處理的時間序列資料)，因此這時候可以利用 Federation 來將不同監測任務劃分到不同實例當中，以解決單台 Prometheus 無法有效處理的狀況。
Prometheus 在效能上是能夠以單個 Server 支撐百萬個時間序列，當然根據不同規模的改變，Promethes 是能夠進行擴展的，這邊將介紹 Prometheus Federation 來達到此效果。
Prometheus Federation 允許一台 Prometheus Server 從另一台 Prometheus Server 刮取選定的時間序列資料。Federation 提供 Prometheus 擴展能力，這能夠讓 Prometheus 節點擴展至多個，並且能夠實現高可靠性(High Availability)與切片(Sharding)。對於 Prometheus 的 Federation 有不同的使用方式，一般分為Cross-service federation與Hierarchical federation。
Prometheus 系統包含了 Local on-disk storage 與 Remote storage，本節將說明兩者差異，以了解作為實現資料儲存可靠性的基礎。
前言昨天分享了 LINE Infrastructure 團隊為何導入 Cloud Native 的原因，從中可以看出 LINE 面臨服務開發的資源需求快速增長問題，因此必須更加有效的利用資料中心的資源，而 Cloud Native 的導入對他們來說是個關鍵點，利用容器、服務網格(Service Me
前言昨天主要分享 LINE Dev Day 當天開場的 Keynote 內容，而今天將針對我最想要了解的 Infrastructure & Cloud Native 議程來分享，因為自己在這方面技術比較有著墨，因此想一探究竟 LINE 團隊是如何建構這麼大規模的平台，也非常想了解他們在技術選
前言今年很榮幸被 LINE 以 Influencer 形式邀請到日本參加 LINE Dev Day，這也是人生第一次踏入那長年陪伴我長大的影片的國家 - 日本。原本在這期間會參與 KubeCon NA 的活動，但因為一些變故，因此最後沒能去成，於是就來到了 LINE Dev Day，這次參與 LIN
前言在動手實作 Kubernetes 自定義控制器 Part5 文章結束後，基本上已經完成了這個自定義控制器範例的功能，這時若我們想要部署這個控制器的話，該怎麼辦呢?因為過去文章中，我們都是以 Go 語言指令直接建構程式進行測試，且使用 client-go 與 API Server 溝通時，都是以c
前言在動手實作 Kubernetes 自定義控制器 Part4 文章結語部分，我有提到目前實作的自定義控制器還存在著問題(如下圖)，其中就是自定義資源 VirtualMachine 的實例被刪除前，未正確透過 VM Driver 刪除實際管理的虛擬機，這樣情況下的虛擬機都會變成失去控制器管理的殭屍
Who is Kyle Bai?一名喜愛開源專案的工程師，喜歡在開源社區與在地社群中，貢獻、分享與討論相關技術議題。另外，他目前在 Cloud Native Taiwan User Group 社群擔任活動共同舉辦人/講者，並定期的籌辦 Meetup 來推廣與分享雲原生(Cloud Native)的
