Kubernetes 基礎與微服務架構實踐

隨著網際網路的快速發展，軟體開發也從傳統的瀑布式開發轉向敏捷開發和 DevOps。為了滿足頻繁的軟體發布和日益增長的使用者需求，雲端運算和容器化技術成為現代軟體開發的根本。Kubernetes 作為領先的容器協調平台，有效解決了微服務架構下的佈署、擴充套件和管理挑戰。它能自動化容器化應用程式的生命週期管理，實作高用性、彈性擴充套件和快速佈署。相較於單體式架構，微服務架構更能適應快速變化的市場需求，但同時也增加了管理複雜度。Kubernetes 正是解決這個複雜度的關鍵工具，讓開發團隊能更專注於業務邏輯的開發，提升軟體交付速度和可靠性。

Kubernetes基礎知識：瞭解Kubernetes解決的問題

在探討Kubernetes之前，我們先來瞭解軟體開發和網際網路如何在過去20年間共同演變。這將有助於我們更好地理解Kubernetes的作用和它所解決的問題。

網際網路的成長與軟體開發的演進

自1990年代末以來，網際網路的普及率迅速增長。從最初的數十萬使用者到現在的近20億人，網際網路已經滲透到我們生活的方方面面。隨著網際網路的發展，軟體開發行業也必須演進，以滿足日益增長的使用者需求和更頻繁的軟體釋出。

在1990年代，您可以構建一個應用程式，將其佈署到生產環境中，然後每年更新一次或兩次。如今，公司必須能夠在生產環境中更新軟體，有時一天內更新多次，無論是為了佈署新功能、與社交媒體平台整合、支援最新流行的智慧手機，還是為了修補前一天發現的安全漏洞。所有的事情都比以前複雜得多，您必須比以前更快。

軟體釋出的頻率需求

為了滿足不斷增長的使用者需求和更頻繁的軟體釋出，軟體開發行業不得不演進。這意味著IT部門在組織和技術上都必須進行變革。在組織上，他們改變了管理專案和團隊的方式，轉向敏捷方法；在技術上，雲端運算平台、容器和虛擬化技術被廣泛採用，有助於將技術敏捷性與組織敏捷性相結合。

敏捷方法的組織變革

從純粹的組織角度來看，敏捷方法（如Scrum、Kanban和DevOps）成為了組織IT團隊的標準方式。傳統的IT部門通常由三個不同的團隊組成，每個團隊在開發和釋出流程生命週期中承擔單一責任。開發和維運團隊通常在不同的孤島中工作，這可能導致效率低下和溝通差距。敏捷方法有助於彌合這些差距並促進協作。

傳統IT部門的三個孤立團隊

1. 業務團隊：他們是客戶的聲音。他們的工作是解釋應用程式需要哪些功能來滿足使用者需求。他們將業務目標轉化為清晰的開發者指令。
2. 開發團隊：他們是將應用程式變為現實的工程師。他們將業務團隊的功能請求轉化為程式碼，構建使用者將與之互動的功能和特性。
3. 維運團隊：他們是伺服器的管理者。他們的主要重點是保持應用程式的平穩執行。新功能可能會帶來幹擾，因為它們需要更新，這可能是有風險的。在過去，他們並不總是知道即將到來的新功能，因為他們沒有參與規劃。

這種孤立的組織方式導致了重大問題，例如顯著延長的開發時間、佈署風險增加等。敏捷方法和DevOps透過建立多學科團隊來解決這些問題。

敏捷團隊的協作方式

敏捷團隊由產品負責人、開發人員和測試人員組成，大家共同合作。產品負責人透過撰寫使用者故事來描述具體功能，開發人員根據這些故事進行開發，並使用持續整合和持續佈署（CI/CD）方法佈署到生產環境。測試人員也參與其中，編寫測試使用案例。

透過這種協作方式，團隊對整體情況有了更好、更清晰的瞭解，從而提高了效率和品質。

DevOps文化與實踐

DevOps是一種協作文化和實踐，旨在彌合開發（Dev）和維運（Ops）團隊之間的差距。DevOps促進了軟體生命週期中的協作和自動化，從開發、測試到佈署和維護。

透過採用敏捷方法和DevOps，企業能夠更快速、更可靠地交付軟體，從而滿足不斷變化的市場需求和使用者期望。Kubernetes作為容器協調工具，在這個過程中扮演著重要的角色，它有助於自動化佈署、擴充套件和管理容器化應用程式，從而進一步提高軟體交付的速度和可靠性。

從傳統開發到敏捷與 DevOps 的轉變

在傳統的軟體開發過程中，不同部門之間存在著明顯的隔閡，例如開發部門和維運部門各自為政，缺乏有效的溝通與協作。然而，隨著敏捷開發方法論和 DevOps 的引入，這些隔閡被打破，多學科團隊得以形成，能夠完整地將需求實作、測試、發布和維護在生產環境中。表 1.1 展示了從傳統開發到敏捷與 DevOps 方法論的轉變。

傳統開發 vs 敏捷與 DevOps

表 1.1：DevOps 與傳統開發的比較 – 協作的轉變

從本地佈署到雲端的轉變

擁有敏捷團隊固然很好，但敏捷性也必須應用於軟體的構建和託管方式上。為了實作更快、更頻繁的發布，敏捷軟體開發團隊必須重新審視軟體開發和發布的兩個重要方面：

• 託管
• 軟體架構

如今，應用程式不再只是為幾百個使用者設計，而是可能同時服務數百萬使用者。使用者數量的增加意味著需要更強大的計算能力來處理他們的需求。因此，託管應用程式成為了一項巨大的挑戰。

本地佈署的挑戰

在早期的網頁託管時代，企業主要依賴兩種方法來託管他們的應用程式：本地佈署和租用伺服器。本地佈署涉及物理擁有和管理執行應用程式的伺服器。有兩種主要的方式來實作本地佈署：

1. 專用伺服器：從建立的資料中心供應商租用物理伺服器。這涉及從託管公司租用專用伺服器硬體。託管提供商管理物理基礎設施（電源、冷卻、安全），但伺服器組態、軟體安裝和持續維護的責任則歸企業所有。這相比分享託管提供了更大的控制和自定義，但仍然需要大量的內部技術專長。
2. 建立自己的資料中心：構建和維護私有資料中心。這種選擇涉及公司投入大量資金來建立和維護自己的物理資料中心設施。這包括購買伺服器硬體、網路裝置和儲存解決方案，並實施強大的電源、冷卻和安全措施。雖然提供了最高的控制和安全級別，但這種方法非常昂貴和資源密集，通常只有具有大量 IT 資源的大型企業才會採用。

本地佈署還包括管理伺服器的作業系統、安全補丁、備份和災難還原計劃。公司通常需要專門的 IT 工作人員來管理和維護其本地基礎設施，這增加了整體成本。

雲端運算的優勢

當使用者群增長時，您需要更強大的機器來處理負載。解決方案是購買更強大的伺服器並從一開始就將應用程式安裝在上面，或者如果您管理自己的資料中心，則訂購並架設新的硬體。這並不是很靈活。如今，許多公司仍在使用本地佈署解決方案，而且往往不是很靈活。

雲端運算的採用改變了這一局面。雲端運算是大型公司如亞馬遜、谷歌和微軟在其龐大的基礎設施上建立虛擬化的結果，以確保虛擬機器的建立和管理可以透過 API 存取。換句話說，您只需點選幾下或執行幾個命令即可獲得虛擬機器。

下表提供了有關雲端運算為組織帶來的好處的高層次資訊。

本地佈署 vs 雲端

Kubernetes 的基本概念

隨著雲端運算的發展，容器化和容器協調技術應運而生，其中 Kubernetes 成為最流行的容器協調工具。Kubernetes 提供了一種自動化佈署、擴充套件和管理容器化應用程式的方法，從而進一步提高了應用程式的可移植性和可擴充套件性。

Kubernetes 的出現使得管理大規模容器叢集變得更加容易，並且能夠實作自動化的滾動更新、自我修復和資源管理。這對於需要高用性和可擴充套件性的現代應用程式來說至關重要。

程式碼範例：使用 Kubernetes 佈署應用程式

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-app
        image: example-app:latest
        ports:
        - containerPort: 80

內容解密：

• apiVersion 和 kind 指定了 Kubernetes 資源的版本和型別。在這個例子中，我們建立了一個 Deployment。
• metadata 部分包含了 Deployment 的名稱和其他後設資料。
• spec 部分定義了 Deployment 的規格，包括副本數量、選擇器和範本。
• replicas 指定了要建立的副本數量。
• selector 和 template 中的 labels 用於匹配 Pod 和 Deployment。
• containers 部分定義了容器列表，包括名稱、映像和埠。

這個 YAML 檔案定義了一個簡單的 Deployment 物件，用於佈署一個名為 example-app 的應用程式。它指定了要建立三個副本，並使用 example-app:latest 映象。容器監聽埠 80。

Kubernetes Deployment 的流程

此圖示展示了 Kubernetes 中建立 Deployment 的流程，從建立 Deployment 物件到提取映象、建立 Pod、啟動容器，最後監控 Pod 狀態。

圖表說明：

• 圖表以建立 Deployment 物件開始。
• 提取指定的 Docker 映象。
• 使用映象建立 Pod。
• 在 Pod 中啟動容器。
• Kubernetes 不斷監控 Pod 的狀態，以確保其按照預期執行。

透過使用 Kubernetes，我們可以實作應用程式的自動化佈署、擴充套件和管理，從而提高開發效率和系統可靠性。

雲端運算對組織的重要性

在探討雲端運算技術如何幫助組織擴充套件其IT基礎設施之前，我們先來瞭解雲端運算的基本特性與傳統本地佈署的差異。

傳統本地佈署 vs. 雲端運算

為何雲端適合擴充套件

如今，幾乎任何人都可以透過簡單的點選，從雲端供應商（如Amazon Web Services、Google Cloud Platform和Microsoft Azure）取得數百或數千台伺服器，以虛擬機器或例項的形式建立在物理基礎設施上。許多公司決定將其工作負載從本地佈署遷移到雲端供應商，並且在過去幾年中，它們的採用率大幅增加。

由於雲端供應商的虛擬機器組態、CPU、作業系統、網路規則等都是公開顯示且完全可組態的，因此對於團隊來說，瞭解生產環境的組成並不困難。因為雲端供應商具有可程式設計性，所以很容易在開發或測試環境中複製生產環境，為團隊提供更大的靈活性，幫助他們面對開發軟體時的挑戰。這對於圍繞DevOps理念構建的敏捷開發團隊來說，是非常有用的優勢，需要管理應用程式在生產中的開發、發布和維護。

雲端供應商提供了許多好處，包括：

• 彈性和可擴充套件性
• 有助於打破孤島，強化敏捷方法
• 適合敏捷方法和DevOps
• 低成本和靈活的計費模式
• 無需管理物理伺服器
• 可以隨意銷毀和重新建立虛擬機器
• 比租用裸機伺服器更具彈性

Kubernetes基礎

由於這些好處，雲端是敏捷開發團隊寶貴的資產。基本上，您可以無需自行管理物理機器，就可以建立和重複複製生產環境。雲端使您能夠根據使用應用的使用者數量或他們消耗的計算資源來擴充套件應用。您將使應用具有高用性和容錯能力。結果是為您的終端使用者提供了更好的體驗。

既然我們已經解釋了雲端所帶來的變化，那麼讓我們繼續討論軟體架構，因為多年來，一些事情也發生了變化。

探索單體式架構

過去，應用程式大多由單體組成。典型的單體應用程式由一個簡單的程式、單個二進位制檔案或單個套件組成，如圖1.3所示。

此圖示顯示了單體應用的基本結構。

內容解密：

1. 單體應用的定義：單體應用是一個自包含的應用程式，所有元件都封裝在一個單元中。
2. 圖表說明：圖表顯示單體應用的主要特點，包括其包含所有業務邏輯和作為單一元件存在。
3. 結構解析：此結構易於開發和佈署，但可能導致擴充套件困難和維護挑戰。

這個唯一的元件負責軟體必須回應的整個業務邏輯實作。單體是開發簡單應用程式的好選擇，如果這些應用程式在生產中不一定會頻繁更新。為什麼？因為單體有一個主要缺點。如果您的單體由於某種原因變得不穩定或當機，您的整個應用程式將變得不可用。

單體式架構的優缺點

單體式架構可以讓您在開發過程中節省很多時間，這可能是選擇這種架構的唯一好處。然而，它也有很多缺點。以下是一些缺點：

• 生產中的佈署失敗可能會破壞整個應用程式。
• 縮放活動變得難以實作；如果無法擴充套件，所有應用程式可能會變得不可用。
• 單體上的任何故障都可能導致應用程式完全停機。

在2010年代，這些缺點開始引起真正的問題。隨著佈署頻率的增加，有必要考慮一種新的架構，能夠支援頻繁的佈署和更短的更新週期，同時減少風險或應用的一般不可用性。這就是為什麼設計了微服務架構。

探索微服務架構

微服務架構包括將軟體應用程式開發為一套獨立的微應用程式。每個應用程式，即微服務，有其自己的版本控制、生命週期、環境和依賴關係。此外，它可以有自己的佈署生命週期。您的每個微服務必須只負責有限數量的業務規則，所有微服務一起組成了應用程式。可以將微服務視為具有自己生命週期和版本控制過程的真正的全功能軟體。

由於微服務應該只包含整個應用程式的一部分功能，因此必須使其可存取，以便公開其功能。您必須從微服務取得資料，但也可能希望將資料推播到其中。您可以透過廣泛支援的協定（如HTTP或AMQP）使微服務可存取，並且它們需要能夠相互通訊。這就是為什麼微服務通常被構建為透過明確定義的API公開其功能的Web服務。雖然HTTP（或HTTPS）REST API由於其簡單性和廣泛採用而成為流行的選擇，但其他協定（如GraphQL、AMQP和gRPC）正在獲得關注並被廣泛使用。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes 基礎與微服務架構實踐

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

此圖示顯示了微服務架構的基本結構。

內容解密：

1. 微服務架構的定義：微服務架構是一種將應用程式分解為多個小型、獨立服務的架構風格。
2. 圖表說明：圖表顯示微服務架構的主要特點，包括多個獨立微服務和透過API相互通訊。
3. 結構解析：此結構提供了更高的靈活性和可擴充套件性，但也增加了管理的複雜性。

關鍵要求是微服務提供一個有良好檔案記錄和可發現的API端點，無論選擇哪種協定。這允許其他微服務無縫地互動和交換資料。

微服務架構與容器技術的基礎

在現代應用程式開發中，微服務架構因其敏捷性和 DevOps 實踐而備受推崇。這種架構方式與單體式架構有著本質的不同。

微服務架構的特點

微服務架構強調將應用程式分解為多個獨立的服務，每個服務都可以獨立開發、擴充套件和佈署。這些服務之間透過標準化的協定（如 HTTP）進行通訊，從而實作了技術環境和語言的多樣性。

獨立性與解耦

每個微服務可以擁有自己的資料函式庫、技術堆積疊和依賴項，這使得它們能夠獨立運作而不會影響其他服務或整個應用程式的穩定性。

技術多樣性

由於微服務之間透過標準化協定進行通訊，因此它們可以使用不同的程式語言和技術堆積疊。例如，一個應用程式可能包含用 Go、Java 和 PHP 分別開發的微服務。

容器技術的優勢

容器技術（如 Docker）為微服務提供了理想的執行環境。容器能夠封裝微服務及其依賴項，從而實作與主機作業系統的解耦。

為何容器適合微服務

1. 獨立的技術環境：每個微服務可以在自己的容器中執行，擁有獨立的技術環境和依賴項。
2. 與主機解耦：容器確保了微服務與主機作業系統之間的解耦，使得微服務可以在不同的機器上自由佈署。

容器解決了什麼問題？

在同一台 Linux 機器上佈署多個微服務時，可能會遇到依賴項衝突和版本管理的問題。容器技術透過為每個微服務建立獨立的執行環境，解決了這些問題。

單體式架構 vs 微服務架構

在選擇應用程式架構時，需要考慮專案規模、團隊結構和所需的靈活性。

• 單體式架構：適合小型專案或資源有限的團隊，開發和初始佈署簡單。
• 微服務架構：適合大型、功能豐富的專案和具有多樣技能的團隊，提供靈活性和快速開發週期，但也引入了額外的複雜性。

Kubernetes 的靈活性

Kubernetes 支援兩種架構方式，能夠滿足不同專案的需求。無論是快速變化的單體式應用程式還是微服務架構，Kubernetes 都能提供靈活的管理和佈署能力。