Pcion's Blog

什麼是 MetalLB？

MetalLB 是一個用於裸機 Kubernetes 叢集的負載平衡器實作。它提供了在本地環境中使用 LoadBalancer 類型 Service 的能力，填補了雲端和本地 Kubernetes 環境之間的功能差距。

MetalLB 的主要功能：

• IP 位址分配：為 LoadBalancer Service 自動分配外部 IP 位址
• 流量路由：將外部流量路由到正確的 Service 與後端 Pod
• 高可用性：支援多節點部署與故障轉移
• 協定支援：支援 Layer 2 (ARP/NDP) 和 BGP 模式

為什麼需要 MetalLB？

在雲端 Kubernetes 環境中，當我們建立 type: LoadBalancer 的 Service，雲端供應商通常會自動配置一組外部 IP 或負載平衡器，讓叢集外部可以連進服務。

但在 Minikube、裸機伺服器或本機實驗環境中，Kubernetes 本身不會幫你分配外部 LoadBalancer IP。這時候如果直接建立 LoadBalancer Service，很常看到 EXTERNAL-IP 一直停在 <pending>。

MetalLB 解決的就是這個問題。它會從指定的 IP 位址池分配外部 IP 給 LoadBalancer Service，讓本機或內網 Kubernetes 也能用接近雲端的方式對外暴露服務。

本篇會使用 Minikube 作為示範環境，先啟用 MetalLB，接著配置 192.168.49.100-192.168.49.150 作為 LoadBalancer IP 位址池，最後沿用前面文章建立好的 dockertest Spring Boot 應用程式，透過 MetalLB 取得外部 IP 並測試連線。

什麼是 LoadBalancer Service？

Kubernetes LoadBalancer Service 是一種 Service 類型，用於將叢集內的應用程式暴露給外部網路。它會提供一個可從叢集外部存取的入口 IP，並透過 Service selector 將流量導向後端 Pod。

在雲端 Kubernetes 環境中，type: LoadBalancer 通常會自動建立雲端供應商的負載平衡器；在本機或裸機環境中，Kubernetes 本身不會自動分配外部 IP，因此常見做法是搭配 MetalLB，讓本地叢集也能取得 LoadBalancer IP。

LoadBalancer Service 的主要功能：

• 外部存取：讓叢集外部可以透過固定 IP 與連接埠存取應用程式
• 服務入口：透過 Service 提供穩定入口，避免直接依賴會變動的 Pod IP
• 負載分配：將進入 Service 的流量分配到符合 selector 的後端 Pod
• 流量策略：支援來源 IP 保留、會話親和性與內外部流量策略等設定

為什麼使用 LoadBalancer Service？

相較於 ClusterIP 或 NodePort，LoadBalancer Service 更適合需要直接對外提供 IP 入口的服務：

1. 外部連線更直覺：使用者可以直接透過 LoadBalancer IP 與 Service port 存取服務
2. 部署設定更清楚：Service 負責穩定入口，Deployment 負責維護後端 Pod
3. 適合非 HTTP 場景：除了 HTTP 服務，也能暴露 TCP 或 UDP 類型的服務

什麼是 Ingress？

Kubernetes Ingress 是一個 API 物件，用於管理對叢集內服務的外部存取，通常是 HTTP/HTTPS 流量。Ingress 提供了負載平衡、SSL 終止和基於名稱的虛擬主機功能。

Ingress 的主要功能：

• 路由管理：根據 URL 路徑或主機名稱將流量路由到不同的服務
• 負載平衡：在多個後端服務之間分配流量
• SSL/TLS 終止：處理 HTTPS 加密和解密
• 域名綁定：支援基於域名的虛擬主機

為什麼使用 Ingress？

相較於直接使用 NodePort 或 LoadBalancer 類型的 Service，Ingress 提供了更靈活的流量管理方式：

1. 成本效益：一個 Ingress Controller 可以處理多個服務的外部存取
2. 統一管理：集中管理所有外部流量的路由規則
3. 高級功能：支援路徑重寫、認證、限流等進階功能

什麼是 Kubernetes Service？

Kubernetes Service 是一個穩定的網路抽象層，用來將流量導向一組符合條件的 Pod。由於 Pod 會隨著部署、擴展、重啟或節點異動而重新建立，Pod IP 並不適合作為固定存取入口；Service 則提供固定的服務名稱、虛擬 IP 與連線方式，讓應用程式可以穩定地彼此溝通。

Service 通常會透過 selector 找到帶有指定 label 的 Pod，並把流量轉送到 Pod 的 targetPort。對使用者或其他服務來說，只需要存取 Service，就不需要關心後方 Pod 的實際位置。

Service 的主要功能：

• 穩定入口：即使 Pod 被重新建立，Service 名稱與 IP 仍能維持穩定
• 服務發現：透過 Kubernetes DNS 使用 Service 名稱存取服務
• 負載分散：將請求分配到多個符合 selector 的 Pod
• 對外暴露：依照不同 Service Type，提供叢集內或叢集外的存取方式

為什麼需要 Service？

在 Kubernetes 中，Deployment 負責管理 Pod 的生命週期，但 Deployment 本身不提供固定的網路入口。當應用程式需要被其他 Pod、節點外部使用者，或雲端負載平衡器存取時，就需要透過 Service 建立對應的流量入口。

什麼是 Volume？

Kubernetes Volume 是一個 API 物件，用於為 Pod 中的容器提供持久化或共享的儲存空間。Volume 解決了容器檔案系統的臨時性問題，讓資料能夠在容器重啟後保留，或在多個容器之間進行共享。

Volume 的主要功能：

• 資料持久化：確保重要資料在容器重啟或 Pod 重新調度後不會遺失
• 容器間共享：讓同一 Pod 內的多個容器能夠共享資料
• 外部儲存整合：連接到各種外部儲存系統，如雲端儲存、網路檔案系統等
• 臨時儲存管理：提供高效能的臨時工作空間

為什麼使用 Volume？

相較於依賴容器內建的檔案系統，Volume 提供了更可靠的資料管理方式：

1. 資料安全性：避免因容器故障導致的資料遺失
2. 靈活性：支援多種儲存後端，適應不同的應用需求
3. 效能最佳化：可選擇適合的儲存介質來提升應用效能
4. 統一管理：集中管理所有持久化資料的儲存策略

簡介

GitHub Copilot CLI 除了可以在本機終端機中使用，也支援 Remote Control 功能，讓你從 GitHub.com 或 GitHub Mobile 查看正在執行的 CLI session，並在需要時遠端回覆提示、批准權限要求，或繼續下達新的指令。

這個功能很適合用在需要長時間執行的開發任務。例如你讓 Copilot CLI 在本機分析專案、修改程式、跑測試，但人暫時離開座位時，仍然可以透過手機確認進度。如果 Copilot CLI 在過程中需要你批准檔案存取、URL 存取或工具執行權限，也可以直接從遠端介面回覆，不必特地回到原本那台電腦前面。

不過要先釐清一件事：Remote Control 不是把開發環境搬到雲端，也不是讓 GitHub 直接接管你的電腦。Copilot CLI session 仍然在你啟動它的本機上執行，所有 shell command、檔案讀寫與工具呼叫也都發生在本機。遠端介面只是提供一個可以監看與控制該 session 的入口。

簡介

VS Code Remote Tunnel 是 VS Code Remote Development 生態系中的一種遠端開發方式。它可以讓我們透過安全通道連線到另一台機器，例如家中的桌機、公司內網中的工作站、雲端 VM，或沒有完整桌面環境的 Linux 主機，並直接在 VS Code 中操作遠端檔案、終端機、擴充套件與開發環境。

和常見的 SSH 遠端開發相比，Remote Tunnel 的最大特色是不需要先設定 SSH Server，也通常不需要調整防火牆或路由器連接埠。遠端機器只要能主動連到外部服務，就可以透過 VS Code 建立 Tunnel；開發端則可以使用 VS Code Desktop、安裝 Remote - Tunnels 擴充套件的 VS Code，或直接透過瀏覽器開啟 vscode.dev 進行連線。

官方文件說明，Remote Tunnel 背後會在遠端機器上啟動 VS Code Server，讓 VS Code 的編輯、終端機、偵錯與擴充套件能力可以在遠端環境中執行。這代表原始碼不一定需要下載到本機，實際建置與執行也可以留在遠端主機上完成。

官方參考文件：Developing with Remote Tunnels

Git 是目前最常見的版本控制工具，無論是個人專案、團隊協作，或是 CI/CD 流程，幾乎都會透過 Git 來管理程式碼版本。若團隊使用 GitLab 作為 Git repository 平台，開發者除了要先在本機安裝 Git，也需要準備好 GitLab 的存取權限，才能順利 clone 專案。

本文會示範如何在 Ubuntu 環境安裝 Git，並使用 GitLab 的 Personal Access Token 透過 HTTPS clone repository。範例會以 https://inner.gitlab.dev/pcion123/docker-test.git 作為 repository URL，實際操作時請替換成自己的 GitLab 網址、帳號與專案路徑。

前置需求

開始前，請先確認已具備以下條件：

• 一台可以使用終端機操作的 Ubuntu 主機
• 具備 sudo 權限的使用者帳號
• 可以連線到 GitLab 服務的網路環境
• 已經擁有 GitLab 帳號，且有目標 repository 的讀取權限

如果 GitLab 是公司內部或實驗環境自架的服務，也要先確認主機能解析 GitLab 的網域名稱。例如本文範例使用 inner.gitlab.dev，因此 Ubuntu 主機必須能正確連到這個位址。

GitLab 除了可以管理 Git repository、Merge Request 與 CI/CD，也內建 Container Registry 功能。開啟後，每個專案都可以擁有自己的映像檔倉庫，讓團隊把 Docker image 與程式碼放在同一個 GitLab 專案中管理，後續也能搭配 GitLab CI/CD 自動 build、push 與部署。

本文會示範如何在 GitLab Self-Managed 環境中開啟 Container Registry，並透過 Docker CLI 完成登入、build、tag、push 與 GitLab Web UI 驗證。範例環境使用 inner.gitlab.dev 作為 GitLab 網域，並使用 5050 作為 Container Registry 對外連接埠。

前置需求

開始設定前，請先確認環境符合以下條件：

• 已經安裝 GitLab Self-Managed，並可正常登入 GitLab Web UI
• 可以使用具備 sudo 權限的帳號登入 GitLab 主機
• GitLab 主機的網域名稱或 IP 可以被 Docker client 解析與連線
• Docker client 已安裝 Docker Engine 或 Docker Desktop
• 防火牆、VM port forwarding、安全群組或上層網路設備已開放 Container Registry 使用的連接埠

如果 GitLab 是正式環境，建議搭配 HTTPS 與正式憑證使用；如果只是內網測試環境，也可以先使用 HTTP，但 Docker client 端通常需要額外設定 insecure registry，否則會因為未使用 TLS 而拒絕連線。

GitLab Community Edition，也就是常見的 gitlab-ce，是 GitLab 提供的自架版本。它會把 Git repository、Issue、Merge Request、CI/CD、Wiki 與基本專案管理功能整合在同一套 Web 服務中，很適合用來架設團隊內部的 Git 平台，或是在測試環境中熟悉 GitLab Self-Managed 的操作方式。

本文會依照 GitLab 官方 Ubuntu Linux package 安裝文件，示範如何在 Ubuntu 上安裝 gitlab-ce，並完成第一次登入。官方文件可以參考：Install the Linux package on Ubuntu。

前置需求

開始安裝前，請先確認環境符合以下條件：

• Ubuntu 22.04 或 Ubuntu 24.04
• 可以使用具備 sudo 權限的帳號
• 主機可以連線到 https://packages.gitlab.com/* 與 https://storage.googleapis.com/packages-ops/*
• 若要讓外部使用者連線，需要先準備好 GitLab 使用的網域名稱或固定 IP
• 若使用 HTTPS 網址，需要確認 80 與 443 連接埠可以從外部連入，讓 GitLab 可以透過 Let’s Encrypt 申請憑證

GitLab 是一套資源需求相對高的服務，正式部署前也建議先閱讀官方的 installation requirements，確認 CPU、記憶體與儲存空間是否足夠。若只是本機測試或 VM 練習，也要預留足夠的記憶體與磁碟空間，避免安裝或重新設定過程中失敗。