在 Kubernetes 中，ClusterIP Service 預設只能在叢集內部被存取。這樣的設計很適合讓後端服務、資料庫或內部 API 保持在叢集網路內，但在開發與除錯時，我們常常需要從本機瀏覽器或本機工具暫時連進去確認服務是否正常。
這時候可以使用 kubectl proxy 或 kubectl port-forward 建立一條臨時通道，把本機請求導向叢集內的服務。這兩個指令都不需要改 Service Type，也不需要額外建立 NodePort、LoadBalancer 或 Ingress，很適合用在本機測試、問題排查與臨時驗證。
這篇文章會使用一個 Tomcat 服務作為範例，示範如何透過這兩種方式存取 Kubernetes 內部的 ClusterIP Service。
MetalLB 是一個用於裸機 Kubernetes 叢集的負載平衡器實作。它提供了在本地環境中使用 LoadBalancer 類型 Service 的能力，填補了雲端和本地 Kubernetes 環境之間的功能差距。
在雲端 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 並測試連線。
Kubernetes LoadBalancer Service 是一種 Service 類型，用於將叢集內的應用程式暴露給外部網路。它會提供一個可從叢集外部存取的入口 IP，並透過 Service selector 將流量導向後端 Pod。
在雲端 Kubernetes 環境中，type: LoadBalancer 通常會自動建立雲端供應商的負載平衡器；在本機或裸機環境中，Kubernetes 本身不會自動分配外部 IP，因此常見做法是搭配 MetalLB，讓本地叢集也能取得 LoadBalancer IP。
相較於 ClusterIP 或 NodePort，LoadBalancer Service 更適合需要直接對外提供 IP 入口的服務：
Kubernetes Ingress 是一個 API 物件，用於管理對叢集內服務的外部存取，通常是 HTTP/HTTPS 流量。Ingress 提供了負載平衡、SSL 終止和基於名稱的虛擬主機功能。
相較於直接使用 NodePort 或 LoadBalancer 類型的 Service，Ingress 提供了更靈活的流量管理方式：
Kubernetes Service 是一個穩定的網路抽象層，用來將流量導向一組符合條件的 Pod。由於 Pod 會隨著部署、擴展、重啟或節點異動而重新建立，Pod IP 並不適合作為固定存取入口；Service 則提供固定的服務名稱、虛擬 IP 與連線方式，讓應用程式可以穩定地彼此溝通。
Service 通常會透過 selector 找到帶有指定 label 的 Pod，並把流量轉送到 Pod 的 targetPort。對使用者或其他服務來說，只需要存取 Service，就不需要關心後方 Pod 的實際位置。
在 Kubernetes 中，Deployment 負責管理 Pod 的生命週期，但 Deployment 本身不提供固定的網路入口。當應用程式需要被其他 Pod、節點外部使用者，或雲端負載平衡器存取時，就需要透過 Service 建立對應的流量入口。
Kubernetes Volume 是一個 API 物件，用於為 Pod 中的容器提供持久化或共享的儲存空間。Volume 解決了容器檔案系統的臨時性問題，讓資料能夠在容器重啟後保留，或在多個容器之間進行共享。
相較於依賴容器內建的檔案系統，Volume 提供了更可靠的資料管理方式：
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 的編輯、終端機、偵錯與擴充套件能力可以在遠端環境中執行。這代表原始碼不一定需要下載到本機，實際建置與執行也可以留在遠端主機上完成。
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 網址、帳號與專案路徑。
開始前，請先確認已具備以下條件：
sudo 權限的使用者帳號如果 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 對外連接埠。
開始設定前，請先確認環境符合以下條件：
sudo 權限的帳號登入 GitLab 主機如果 GitLab 是正式環境，建議搭配 HTTPS 與正式憑證使用；如果只是內網測試環境，也可以先使用 HTTP，但 Docker client 端通常需要額外設定 insecure registry，否則會因為未使用 TLS 而拒絕連線。