Kubernetes 本地環境建置與應用程式部署實務

在現代雲端原生開發流程中，於本地端建立功能完整的 Kubernetes 叢集是開發與維運人員的基礎技能。此舉不僅能降低雲端資源成本，更能在開發初期模擬生產環境，驗證應用程式的容器化配置與部署策略。本文聚焦於此實踐流程，從環境基礎驗證工具 kubectl 出發，探討如何部署與配置 Kubernetes Dashboard 這個視覺化管理介面。接著，文章將引導完成身份驗證，並透過標準的 Deployment YAML 配置文件，實際部署一個具備高可用性副本的 Web 應用程式。此流程完整涵蓋從環境建置到應用上線的關鍵步驟，是掌握 Kubernetes 容器編排技術的核心起點。

本地 Kubernetes 環境設置與 Dashboard 部署

本節將繼續探討本地 Kubernetes 環境的設置，包括驗證 kubectl 的安裝，以及部署和訪問 Kubernetes Dashboard。

驗證 Kubernetes 安裝與 `kubectl` 工具

在成功啟用 Docker Desktop 中的 Kubernetes 選項後，Docker Desktop 會自動下載並配置一個本地 Kubernetes 集群，同時也會安裝 kubectl 命令行工具。為了驗證安裝是否成功，我們需要檢查 kubectl 的版本。

檢查 kubectl 版本: 打開終端，執行以下命令：
```
kubectl version --short
```
此命令會顯示 kubectl 客戶端和 Kubernetes 服務端的版本信息。如果命令成功執行並顯示版本號，則表示 kubectl 已正確安裝並能夠連接到本地 Kubernetes 集群。
kubectl 是與 Kubernetes 集群進行交互的主要工具，所有後續的 Kubernetes 操作都將通過此命令執行。

安裝與配置 Kubernetes Dashboard

Kubernetes Dashboard 是一個基於 Web 的用戶界面，提供了對 Kubernetes 集群狀態、組件和資源的直觀可視化。它極大地簡化了對集群的管理和監控。

部署 Kubernetes Dashboard: 要安裝 Kubernetes Dashboard，我們需要應用一個預先打包好的 YAML 配置文件。在終端中執行以下命令：
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
```
此命令會將 Dashboard 的各種組件（如 Secrets、Web 應用程式、RBAC 角色、權限和 Services）部署到 Kubernetes 集群的 kubernetes-dashboard 命名空間中。
訪問 Kubernetes Dashboard: 安裝完成後，我們需要創建一個代理來從本地機器訪問 Dashboard。
- 創建代理: 在終端中運行 kubectl proxy 命令。
```
kubectl proxy
```
  此命令會在本地啟動一個代理服務，通常監聽在 127.0.0.1:8001。
- 打開 Dashboard 登錄頁面: 在 Web 瀏覽器中，訪問以下 URL： http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login 這個 URL 指向本地代理，並轉發到 Kubernetes Dashboard 的登錄頁面。
Dashboard 身份驗證: 登錄頁面會要求您提供身份驗證信息。有兩種主要方式：
- 使用 kubeconfig 文件: 直接選擇您的本地 kubeconfig 文件進行身份驗證。
- 使用 Token: 生成一個 Kubernetes Service Account 的 Token 來進行身份驗證。
為了生成 Token，我們通常需要創建一個具有必要權限的 Service Account，然後獲取其 Secret 中的 Token。這通常涉及執行一系列 kubectl 命令來創建 Service Account、獲取 Secret，並提取 Token 值。

視覺化 Dashboard 部署與訪問流程

以下圖示展示了 Kubernetes Dashboard 的部署和訪問流程。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

title Kubernetes Dashboard Deployment and Access Flow

component "Kubernetes Cluster" {
  artifact "kubectl Client" as KUBECTL
  artifact "API Server" as APISERVER
  artifact "Controller Manager" as CONTROLLER_MGR
  artifact "Scheduler" as SCHEDULER
  artifact "etcd" as ETCD
  artifact "Kubelet (on Nodes)" as KUBELET
  artifact "Kube-proxy (on Nodes)" as KUBE_PROXY
  artifact "Pods" as PODS
  artifact "Kubernetes Dashboard Deployment\n(kubernetes-dashboard namespace)" as DASHBOARD_DEPLOY
  artifact "Kubernetes Dashboard Service" as DASHBOARD_SVC
  artifact "Kubernetes Dashboard Pod" as DASHBOARD_POD
}

component "Local Machine" {
  artifact "Terminal" as TERMINAL
  artifact "Web Browser" as BROWSER
  artifact "kubectl Proxy" as KUBECTL_PROXY
  artifact "Kubeconfig File" as KUBECONFIG
  artifact "Service Account Token" as TOKEN
}

TERMINAL --> KUBECTL : `kubectl apply -f ...`
KUBECTL --> APISERVER : Creates Dashboard Resources
APISERVER --> ETCD : Stores Cluster State
CONTROLLER_MGR : Manages Dashboard Pod Lifecycle
SCHEDULER : Assigns Dashboard Pod to Node

KUBELET : Runs Dashboard Pod
KUBE_PROXY : Manages Dashboard Service Network

DASHBOARD_DEPLOY --> DASHBOARD_SVC : Creates Service
DASHBOARD_SVC --> DASHBOARD_POD : Exposes Dashboard Pod

TERMINAL --> KUBECTL : `kubectl proxy`
KUBECTL_PROXY --> APISERVER : Establishes Proxy Connection

BROWSER --> KUBECTL_PROXY : Accesses Dashboard URL (localhost:8001/...)
KUBECTL_PROXY --> APISERVER : Forwards Request to Dashboard Service

BROWSER --> KUBECONFIG : Selects Kubeconfig for Auth (Option 1)
BROWSER --> TOKEN : Enters Service Account Token for Auth (Option 2)

stop

@enduml

看圖說話：

此圖示描繪了 Kubernetes Dashboard 的部署和訪問流程。首先，用戶通過終端執行 kubectl apply 命令，將 Dashboard 的部署資源應用到 Kubernetes 集群中。Kubernetes 的 API Server、Controller Manager 和 Scheduler 等組件協同工作，最終在節點上創建並運行 Dashboard 的 Pod。

部署完成後，用戶在本地終端運行 kubectl proxy 命令，啟動一個代理服務。接著，用戶通過 Web 瀏覽器訪問一個本地 URL，該 URL 通過代理連接到 Kubernetes API Server，進而轉發到 Dashboard Service，最終訪問到 Dashboard Pod。

在登錄界面，用戶可以選擇使用本地的 kubeconfig 文件進行身份驗證，或者生成並輸入一個 Service Account Token。這個 Token 通常是通過創建一個具有適當權限的 Service Account 並從其關聯的 Secret 中提取出來的。整個流程展示了 Dashboard 如何作為一個 Web 應用被部署在集群內部，並通過代理和身份驗證機制對外提供訪問。

Kubernetes Dashboard 身份驗證與首個應用程式部署

本節將完成 Kubernetes Dashboard 的身份驗證流程，並開始部署第一個應用程式到本地 Kubernetes 集群。

Kubernetes Dashboard 身份驗證詳情

在成功創建了 Kubernetes Dashboard 的部署後，我們需要進行身份驗證才能訪問其管理界面。

生成 Service Account Token: 為了獲得訪問 Dashboard 的 Token，我們通常需要創建一個具有足夠權限的 Service Account，並從其關聯的 Secret 中提取 Token。這通常通過執行一系列 kubectl 命令來完成。例如，在 PowerShell 中，可以執行以下腳本來生成 Token：
```
$TOKEN=((kubectl -n kube-system describe secret default | Select-String "token:") -split " +")[1]
```
此腳本會查找默認 Service Account 的 Secret，並提取其中的 Token 值。
配置 kubectl 使用 Token: 將獲取的 Token 配置到本地 kubectl 的配置文件中，以便 Dashboard 可以使用此 Token 來驗證用戶。
```
kubectl config set-credentials docker-for-desktop --token="${TOKEN}"
```
這會在您的 kubectl 配置中創建一個名為 docker-for-desktop 的憑證，並關聯上生成的 Token。
選擇配置與登錄: 在 Dashboard 的登錄頁面，您可以選擇使用 kubeconfig 文件進行身份驗證。該文件通常位於您的用戶主目錄下的 .kube 文件夾中（例如，在 Windows 上是 C:\Users\<user name>\.kube\）。選擇正確的 kubeconfig 文件後，點擊「SIGN IN」按鈕即可登錄。
登錄成功後，您將看到 Kubernetes Dashboard 的主界面，其中列出了集群中的各種資源，如 Pods、Deployments、Services 等。

首個 Kubernetes 應用程式部署

在成功設置了本地 Kubernetes 集群和 Dashboard 後，我們將部署第一個應用程式。在 Kubernetes 中，部署應用程式意味著創建一個 Kubernetes Pod 對象，該 Pod 將運行一個包含您應用程式的 Docker 映像。

準備 Docker 映像: 我們將使用一個之前在 Docker Hub 上推送過的 Web 應用程式 Docker 映像。這個映像包含了我們要在 Kubernetes 中運行的應用程式。
創建 Deployment YAML 文件: 在本地創建一個名為 k8sdeploy 的文件夾，並在其中創建一個名為 myapp-deployment.yml 的 Kubernetes Deployment 配置文件。內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  selector:
    matchLabels:
      app: webapp
  replicas: 2
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: demobookk8s
        image: mikaelkrief/demobook:latest
        ports:
        - containerPort: 80
```
此 YAML 文件定義了一個名為 `webapp` 的 Deployment：
*   **`apiVersion: apps/v1`**: 指定了 API 版本。
*   **`kind: Deployment`**: 表明這是一個 Deployment 對象，用於聲明式地管理應用程式的部署。
*   **`metadata.name: webapp`**: 為 Deployment 指定一個名稱。
*   **`spec.replicas: 2`**: 指定 Kubernetes 應創建兩個 Pod 的副本。這確保了應用程式的高可用性，即使一個 Pod 發生故障，另一個副本也能繼續提供服務。
*   **`spec.template`**: 定義了用於創建 Pod 的模板。
    *   **`metadata.labels`**: 為 Pod 標記標籤，用於 Deployment 的選擇器匹配。
    *   **`spec.containers`**: 定義 Pod 中運行的容器。
        *   **`name: demobookk8s`**: 容器的名稱。
        *   **`image: mikaelkrief/demobook:latest`**: 指定要使用的 Docker 映像，從 Docker Hub 拉取。
        *   **`ports.containerPort: 80`**: 指定容器內部暴露的端口。

視覺化 Deployment 配置結構

以下圖示展示了 myapp-deployment.yml 文件中定義的 Deployment 對象的結構。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

title Kubernetes Deployment Object Structure

object "Deployment Object" as DEPLOYMENT {
  apiVersion: apps/v1
  kind: Deployment
  metadata {
    name: webapp
  }
  spec {
    selector {
      matchLabels {
        app: webapp
      }
    }
    replicas: 2
    template {
      metadata {
        labels {
          app: webapp
        }
      }
      spec {
        containers {
          - name: demobookk8s
            image: mikaelkrief/demobook:latest
            ports {
              containerPort: 80
            }
        }
      }
    }
  }
}

DEPLOYMENT --> DEPLOYMENT : spec.selector.matchLabels
DEPLOYMENT --> DEPLOYMENT : spec.template
DEPLOYMENT --> DEPLOYMENT : spec.template.metadata.labels
DEPLOYMENT --> DEPLOYMENT : spec.template.spec.containers

@enduml

看圖說話：

此圖示直觀地展示了 Kubernetes Deployment 對象的結構。頂層是 Deployment Object，包含 apiVersion、kind、metadata 和 spec 四個主要部分。

metadata 部分定義了 Deployment 的名稱（webapp）。spec 部分是核心，它描述了 Deployment 的期望狀態。其中：

selector 定義了 Deployment 如何查找和管理其管理的 Pod，通過 matchLabels 指定了標籤選擇器 app: webapp。
replicas: 2 表明期望集群中運行兩個 Pod 的副本。
template 部分定義了創建 Pod 的藍圖。template.metadata.labels 為 Pod 設置了相同的標籤 app: webapp，這與 Deployment 的選擇器相匹配。
template.spec.containers 定義了 Pod 中要運行的容器。在這個例子中，有一個名為 demobookk8s 的容器，它使用 mikaelkrief/demobook:latest 映像，並暴露了容器內部的 80 端口。

這個結構清晰地展示了如何聲明式地定義一個應用程式的部署，包括副本數量、選擇器以及容器的配置。

結論

縱觀現代應用程式部署的演進軌跡，從手動配置到容器化管理，其核心已從「執行指令」轉變為「定義狀態」。本節所闡述的 Kubernetes 環境建置與應用部署，正是此一範式轉移的具體實踐，展現了從理念到落地的完整路徑。

這套流程看似由 kubectl 指令、Dashboard 視覺化界面與 YAML 配置文件等獨立工具組成，實則體現了一種高度整合的管理哲學。相較於傳統指令式部署的繁瑣與不確定性，聲明式的 Deployment 文件提供了一種可預期、可重複且可版本控制的「期望狀態藍圖」。真正的挑戰不在於執行命令，而在於建立這種「管理終局狀態，而非過程」的思維模式，並將其內化為團隊的標準作業流程。

未來三至五年，隨著雲原生生態系的持續成熟，對於「狀態定義」的精準度與彈性要求將遠超「部署執行」的技巧。技術領導者的核心價值，將更多體現在如何設計出兼具韌性、擴展性與可觀測性的應用程式狀態定義，而非僅僅是操作工具。

玄貓認為，掌握此聲明式部署範式，已不僅是技術能力的提升，更是戰略思維的躍遷。它代表著從被動應對故障，轉向主動設計系統韌性的根本轉變，是所有追求卓越工程文化的管理者必須精通的核心修養。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

Kubernetes 本地環境建置與應用程式部署實務

本地 Kubernetes 環境設置與 Dashboard 部署

驗證 Kubernetes 安裝與 kubectl 工具

安裝與配置 Kubernetes Dashboard

視覺化 Dashboard 部署與訪問流程

看圖說話：

Kubernetes Dashboard 身份驗證與首個應用程式部署

Kubernetes Dashboard 身份驗證詳情

首個 Kubernetes 應用程式部署

視覺化 Deployment 配置結構

看圖說話：

結論

玄貓 BlackCat

驗證 Kubernetes 安裝與 `kubectl` 工具