在末日降臨之際，殭屍肆虐全球，你身為DevOps一員，必須運用你的技術知識，建立一套堅不可摧的防禦系統。幸運的是，我還記得，Kubernetes 其實非常適合用於持續整合與交付（CI/CD），自動更新防禦塔，抵禦殭屍的入侵。
為何選擇 Kubernetes 應對殭屍末日？
面對殭屍末日的混亂景象：成群的殭屍、持續的威脅、脆弱性，稍有不慎就會全盤皆輸。這與管理 Kubernetes 叢集的情況極為相似。
- 塔防系統（Towers）：代表你的 Kubernetes 叢集。
- 倖存者單位（Survivor units）：代表 Pod。
- 殭屍（Zombies）：代表各種威脅，例如故障、漏洞、失敗的版本、資料函式庫等。
我們的目標是建立一套架構與自動更新流程（CI/CD），確保在任何攻擊下，塔防系統都能屹立不搖。
什麼是 CI/CD？為何末日求生需要它？
CI/CD (持續整合/持續交付，Continuous Integration/Continuous Delivery) 是兩個關鍵的 DevOps 實踐：
- 持續整合（CI, Continuous Integration）：將新的變更整合到程式碼函式庫並自動檢查其穩定性。
- 持續交付（CD, Continuous Delivery）：自動將經過驗證的變更（例如安全修補程式、更新的防禦措施）佈署到實際生產環境（也就是我們的「塔防系統」），將風險降至最低。
在殭屍末日的背景下，這意味著每個新的防禦措施都能自動進行測試，並在成功後立即佈署到前線。如果更新導致系統當機，我們也能快速回復至先前的版本。
步驟 1：在 Kubernetes 中使用 GitLab CI 設定 CI/CD Pipeline
準備儲存函式庫epository）
在 GitLab 中建立一個儲存函式庫含所有程式碼及 Kubernetes 的清單檔案（例如 deployment.yaml 和其他必要的設定檔）。確保 GitLab 中的專案已連線到 GitLab CI（通常在根目錄中存在 .gitlab-ci.yml 時會自動完成）。
建立 GitLab CI Pipeline
主要的 GitLab CI 設定檔為 .gitlab-ci.yml。它定義了我們與殭屍「戰鬥」的各個階段：建置（build）、測試（test）和佈署（deploy）。以下是一個基本的 .gitlab-ci.yml 範例：
stages:
- build
- test
- deploy
variables:
DOCKER_REGISTRY: registry.gitlab.com
DOCKER_IMAGE: $CI_REGISTRY_IMAGE/myapp
before_script:
- echo "Logging in to Docker registry"
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
build:
stage: build
script:
- docker build -t $DOCKER_IMAGE .
- docker push $DOCKER_IMAGE
test:
stage: test
script:
- docker run $DOCKER_IMAGE test
deploy:
stage: deploy
script:
- kubectl apply -f kubernetes/deployment.yaml
- Build (建置)：我們正在建置應用程式的 Docker 映像（就像為殭屍準備新的陷阱），並將其傳送到容器映像登入檔（Container Registry）。
- Test (測試)：在容器內部執行測試，確保陷阱正常運作，殭屍無法輕易摧毀它。
- Deploy (佈署)：最後，將 YAML 清單套用到 Kubernetes 叢集，以便在城市周圍佈署陷阱。
為了讓 Kubernetes 能夠信任你，你需要設定存取許可權。在 GitLab 中，這非常簡單：
前往 Settings → CI/CD → Variables。
設定以下變數：
$CI_REGISTRY_IMAGE（GitLab 自動提供的變數）。$CI_JOB_TOKEN（也由 GitLab 提供）。$KUBECONFIG或其他設定，以便kubectl能夠與你的叢集互動。
步驟 2：滾動更新與金絲雀佈署，將風險降至最低
滾動更新（Rolling Updates）
滾動更新是指逐步更新應用程式，以新版本替換舊版本。想像一下，你的塔樓上有三名戰士，你依序更換他們，確保塔樓不會失去防禦能力。以下是一個 Deployment 清單的範例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: survivor-deployment
spec:
replicas: 3
selector:
matchLabels:
app: survivor
template:
metadata:
labels:
app: survivor
spec:
containers:
- name: survivor-container
image: nginx:latest
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
在這個範例中，Kubernetes 會逐步更新 Pod：新的「戰士」啟動後，舊的戰士會繼續執行。只有當新的戰士準備好接替，系統才會撤換舊的戰士。
金絲雀佈署（Canary Deployments）
金絲雀佈署是指將新版本「緩慢地」釋放給少部分使用者或流量。就像在黑暗的小巷中，先派出一小隊戰士進行偵查。如果他們沒有變成殭屍的午餐，那麼更新就可以安全地釋放給所有戰士。
Argo Rollouts 是一個常用的工具，可以執行金絲雀佈署。你可以指定需要在新映像上更新多少百分比的 Pod。
apiVersion: rollouts.k8s.io/v1alpha1
kind: Rollout
metadata:
name: survivor-rollout
spec:
replicas: 3
strategy:
canary:
steps:
- setWeight: 50
- pause: {}
- setWeight: 100
template:
spec:
containers:
- name: survivor-container
image: nginx:latest
首先，只有 50% 的流量會匯入到新版本的「超級武器」上。如果測試成功與運作正常，則會再增加 50% 的流量。
步驟 3：自動化測試與復原變更
為了確保一切運作正常，需要進行自動化測試。你可以編寫單元測試（例如 JUnit、PyTest、Go test），以及整合測試（例如 Selenium、Cypress），確保所有元件都能正常協作。
在殭屍末日中，透過 Kubernetes 進行 CI/CD，我們能夠快速佈署新的防禦措施、修復漏洞，並且在出現問題時迅速復原。這套自動化的防禦系統，能讓我們在末日中存活下來，並重建人類文明。掌握 Kubernetes CI/CD，你就能成為末日英雄，帶領倖存者走向勝利。
在數位世界中，應用程式的穩定性和安全性至關重要，尤其是在面對突如其來的挑戰時。想像一下，您正在構建一座城市，而Kubernetes叢集就是這座城市的基礎。為了保護這座城市免受潛在的「殭屍」（也就是錯誤、故障或意外事件）入侵，您需要一個強大的防禦系統。而持續整合和持續佈署（CI/CD）流程，就是保護這座城市的關鍵。
構建堅固的CI/CD防禦體系
一個完善的CI/CD流程就像城市的自動化防禦系統，它能夠快速佈署新的「防護裝置」（也就是應用程式更新），並在出現問題時迅速撤退。透過GitLab CI，您可以輕鬆地在Kubernetes中設定CI/CD流程，確保您的應用程式能夠快速、安全地更新。
首先，您需要在.gitlab-ci.yml檔案中定義CI/CD管道（Pipeline）。這個檔案描述了構建、測試和佈署應用程式所需的步驟。例如，您可以設定自動化的單元測試（Unit Test）和整合測試（Integration Test），以確保新程式碼的品質。更進階地，您可以進行負載測試（Load Testing，例如使用JMeter或Locust），以評估系統在高負載下的效能。
佈署策略：逐步推進與選擇性暴露
在佈署新的應用程式版本時，風險管理非常重要。全盤式的更新可能會導致系統當機，因此，我們需要採用更謹慎的策略。
- 滾動更新（Rolling Updates）： 滾動更新是一種逐步替換舊版本Pod的策略。Kubernetes會一次更新一部分Pod，確保服務不中斷。
- 金絲雀佈署（Canary Deployments）： 金絲雀佈署是一種將新版本應用程式佈署到一小部分使用者的方法。透過監控這些使用者的體驗，您可以評估新版本的穩定性和效能，然後再逐步推廣到所有使用者。
- 藍綠佈署（Blue/Green Deployments）： 藍綠佈署涉及同時執行兩個版本的應用程式：藍色（舊版本）和綠色（新版本）。在將流量切換到綠色版本之前，您可以充分測試新版本。如果出現問題，您可以立即切換回藍色版本。
快速復原：回到安全地帶
即使是最周全的計劃也可能出錯。因此，快速復原（Rollback）至關重要。Kubernetes提供了簡單的復原機制。如果您使用kubectl管理佈署，可以使用以下命令復原到之前的版本：
kubectl rollout undo deployment/survivor-deployment
此外，Helm和Argo Rollouts等工具也提供了更進階的復原功能。這些工具可以幫助您管理應用程式的版本，並在出現問題時輕鬆地回復到之前的穩定版本。
CI/CD如何保護Kubernetes城市
透過GitLab CI在Kubernetes中設定CI/CD，您可以：
- 快速建立和發布新的應用程式版本。
- 不斷測試應用程式，以防止意外情況發生。
- 透過逐步更新和選擇性佈署來降低風險。
- 在出現問題時立即回復。
這些實踐確保您的Kubernetes叢集安全無虞，就像一個堅固的城市，能夠抵禦任何「殭屍」入侵。無論是錯誤、故障還是意外情況，您的自動化防禦系統都能夠保護您的應用程式。
總而言之，在Kubernetes中建立強大的CI/CD流程就像為您的應用程式建立了一個堅不可摧的堡壘。透過自動化測試、謹慎的佈署策略和快速回復能力，您可以確保應用程式的穩定性、安全性和可靠性。當您聽到「腦！」，別擔心，您的CI/CD系統正在守護著您的應用程式。
