前言

在生產環境中，通常都是以 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

前言

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

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

Read More

前言

前幾天都在分享關於叢集部署與升級事情，今天來聊聊在地端 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

前言

昨天分享了如何使用 Kubeadm 工具來升級既有叢集，過程中可以發現 Kubeadm 升級時，將許多複雜的工作做了許多簡化，因此讓不熟悉 Kubernetes 的人也能輕易達成叢集元件更新事情。雖然工具協助我們更簡單的達成某些功能是很好的事，但不是所有狀況都能透過 Kubeadm，假設在升級時，發生問題的話，要該怎麼辦呢?這時可能會因為不熟悉整個升級過程，而不知如何下手來解決問題。基於上述原因，今天就是要來分析 Kubeadm 的叢集更新是如何實作的，以讓我們能夠在發生問題時，更快的解決。

Read More

前言

許多人都知道，讓應用程式保持較新的狀態，以優化安全性與效能是一種好習慣，這點套用在 Kubernetes 元件升級上也適用，因為 Kubernetes 每三個月左右就會有新的功能發布或改變，且隨著 Kubernetes 盛行，越來越多安全漏洞被揭露後，升級叢集慢慢變成一件重要議題。但 Kubernetes 並不像升級叢集中的應用程式那麼簡單，因為需要考慮各層面問題，就如昨天提到的內容一樣，要針對每一種可能發生狀況先有個認知，以盡可能在發生狀況時，能夠化險為夷。很慶幸的是，這方面越來越受到重視，有許多 Kubernetes 部署工具開始試圖引入一些機制與流程來簡化更新叢集的過程，雖然這並不能解決所有會發生問題，但至少我們可以善用工具來增加更新的正確性與成功率。

Read More

前言

在 Kubernetes 的快速發展下，每隔三個月左右，我們就會看到新版本的推出，以及舊版本進入 EOL(End of Life) 狀態，這時一但想要嘗試新功能與特性，或者是由於安全漏洞關析需要進行補丁時，就必須面對升級 Kubernetes 叢集元件問題。但是若在生產環境中，隨意升級 Kubernetes 叢集元件會不會發生什麼問題?

是的，若對於 Kubernetes 不熟悉的話，很容易掉入陷阱，比如說:已被棄用的 API、不相容的 Add-ons 版本、已棄用的元件參數、不正確的升級方式等等，這些都是有可能在升級後，導致 Kubernetes 叢集功能無法正常工作的原因。

Read More

前言

隨著團隊越來越多地在生產環境使用 Kubernetes 管理雲原生應用程式，我們必須考量在各種故障下，Kubernetes 能正常運行的情況，比如說:在流量高峰期間，將工作負載分散到更多節點或轉往公有雲、跨多個 Availability Zones/Regions 部署、建構高可靠(Highly Available，HA)架構等等要求。其中高可靠架構在昨天的淺談 Kubernetes 高可靠架構文章中，簡單地複習了高可靠架構。而今天將說明如何實現與利用 kubeadm 建立一座架構大致如下圖所示的 HA 叢集。

Read More

前言

近幾年來容器的興起，重塑了我們對於開發、部署與維運軟體的方式。容器允許我們透過打包應用程式成容器映像檔，並透過容器引擎部署到一組虛擬或實體的機器上執行。也正因為這樣過程與需求，產生了所謂的容器編排系統(Container Orchestration)，以自動化、基於容器應用程式的方式部署、管理與擴展。其中 Kubernetes 就是近年來的一套容器編排系統標準，它能允許大規模部署與管理基於容器的應用程式，而 Kubernetes 的特性還能實現分散式的應用程式，以帶來更高的可靠性與穩定性。但是，當 Kubernetes 重要元件或是其主節點(Master Node)發生故障時，那 Kubernetes 會發生什麼事呢?又該如何確保 Kubernetes 本身保持正常運行呢?

Read More

前言

在昨天文章中，我針對開發環境(Development)與測試環境(Testing)使用情境下，選擇 Kubernetes 工具的看法，而今天將延續 淺談 Kubernetes 的部署工具選擇 Part2 未講完的部分繼續分享預備環境(Staging)與生產環境(Production)看法。

Read More

前言

上一篇 淺談 Kubernetes 的部署工具選擇 Part1 提到選擇部署工具時，需要思考的幾件事情，並簡單提了一下目前 Kubernetes SIG cluster lifecycle 的發展。而今天我將依據不同環境與情境來說明自己怎麼選用 Kubernetes 部署工具。

原本這篇是要放在第一天一起講，但是發現一天超過 6000 字似乎有點壓力… 感覺三天後我就放推了，但因為是團隊報名，所以不能放棄!!!只好拆成三篇來分享。

Read More