การจัดส่งต่อเนื่อง Kubernetes: ท่อ GitOps พร้อม ArgoCD และ Flux
สร้างท่อส่งการปรับใช้อัตโนมัติที่เชื่อถือได้สำหรับ Kubernetes โดยใช้ GitOps ด้วย ArgoCD และ Flux
การส่งมอบอย่างต่อเนื่องบน Kubernetes มีการพัฒนาที่เหนือกว่าความเรียบง่าย kubectl apply คำสั่งทีมสมัยใหม่กำลังใช้ GitOps ซึ่งเป็นกระบวนทัศน์ที่ใช้ Git เป็นแหล่งเดียวของความจริงสำหรับโครงสร้างพื้นฐานเชิงประกาศและการกำหนดค่าแอปพลิเคชันด้วยการรวมหลักการ GitOps เข้ากับเครื่องมือเช่น ArgoCD และ Flux CD องค์กรสามารถบรรลุท่อการปรับใช้ที่เชื่อถือได้ตรวจสอบได้และอัตโนมัติซึ่งขยายไปทั่วคลัสเตอร์และสภาพแวดล้อม
คู่มือนี้ครอบคลุมสถาปัตยกรรมการตั้งค่าและแนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างท่อส่งมอบอย่างต่อเนื่องระดับการผลิตบน Kubernetes โดยใช้แนวทาง GitOps
หลักการของ GitOps
GitOps สร้างขึ้นจากหลักการหลักสี่ประการที่เปลี่ยนวิธีการจัดการการปรับใช้ของทีมโดยพื้นฐาน:
- การกำหนดค่า Declarative - สถานะที่ต้องการทั้งหมดของระบบของคุณได้รับการอธิบายตามประกาศสำหรับ Kubernetes หมายถึงการปรากฏตัวของ YAML แผนภูมิ Helm หรือการปรับแต่งภาพซ้อนทับที่จัดเก็บไว้ใน GIT
- ควบคุมเวอร์ชันแล้ว - GIT ทำหน้าที่เป็นแหล่งเดียวของความจริงทุกการเปลี่ยนแปลงจะต้องผ่านการร้องขอการดึงให้เส้นทางการตรวจสอบที่สมบูรณ์และช่วยให้สามารถย้อนกลับได้ง่ายโดยการย้อนกลับความมุ่งมั่น
- การกระทบยอดอัตโนมัติ - เจ้าหน้าที่ที่ทำงานในคลัสเตอร์จะเปรียบเทียบสถานะที่ต้องการใน Git กับสถานะจริงในคลัสเตอร์อย่างต่อเนื่องและกระทบยอดการดริฟท์โดยอัตโนมัติ
- การสังเกตอย่างต่อเนื่อง - ระบบจะตรวจสอบทั้งพื้นที่เก็บข้อมูล Git และสถานะคลัสเตอร์อย่างต่อเนื่องแจ้งเตือนเกี่ยวกับไดเวอร์เจนซ์และตรวจสอบให้แน่ใจว่าคลัสเตอร์ตรงกับการกำหนดค่าที่ประกาศไว้เสมอ
หลักการเหล่านี้กำจัดขั้นตอนการปรับใช้ด้วยตนเองลดข้อผิดพลาดของมนุษย์และให้เวิร์กโฟลว์ที่สอดคล้องกันโดยไม่คำนึงถึงความซับซ้อนของคลัสเตอร์
สถาปัตยกรรมและการตั้งค่า ArgoCD
ArgoCD เป็นเครื่องมือ GitOps ที่ได้รับการยอมรับอย่างกว้างขวางที่สุดสำหรับ Kubernetes มันมี UI เว็บที่มีประสิทธิภาพ CLI และ API สำหรับการจัดการการปรับใช้แอปพลิเคชันในคลัสเตอร์
ส่วนประกอบหลัก
ArgoCD ประกอบด้วยองค์ประกอบสำคัญหลายอย่างที่ทำงานร่วมกัน:
- เซิร์ฟเวอร์ API - เปิด gRPC/REST API และให้บริการ UI บนเว็บจัดการการตรวจสอบสิทธิ์ RBAC และการผสานรวมภายนอก
- --repository-server - โคลนที่เก็บ Git และสร้าง Kubernetes ที่ปรากฏจากแผนภูมิ Helm, Kustomize หรือ YAML ธรรมดา
- ตัวควบคุมแอปพลิเคชัน - ตรวจสอบแอปพลิเคชันที่ทำงานอยู่อย่างต่อเนื่องและเปรียบเทียบสถานะสดกับสถานะที่ต้องการใน GIT
- Redis - มีแคชสำหรับเซิร์ฟเวอร์ที่เก็บและตัวควบคุมแอปพลิเคชัน
การติดตั้ง
ปรับใช้ ArgoCD ไปยังคลัสเตอร์ของคุณโดยใช้การแสดงอย่างเป็นทางการหรือแผนภูมิ Helm:
# Create namespace and install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Or via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
--namespace argocd \
--create-namespace \
--set server.service.type=LoadBalancerการกำหนดแอปพลิเคชัน
ArgoCD ใช้ Application ทรัพยากรที่กำหนดเองเพื่อกำหนดสิ่งที่จะปรับใช้และสถานที่นี่คือคำจำกัดความของแอปพลิเคชันทั่วไป:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-web-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/myorg/k8s-manifests.git
targetRevision: main
path: apps/my-web-app/overlays/production
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
retry:
limit: 5
backoff:
duration: 5s
factor: 2
maxDuration: 3mระบบ syncPolicy.automated ส่วนเปิดใช้งานการซิงโครไนซ์อัตโนมัติ prune ตัวเลือกลบทรัพยากรที่ไม่ได้กำหนดไว้ใน Git อีกต่อไปในขณะที่ selfHeal ย้อนกลับการเปลี่ยนแปลงด้วยตนเองไปยังคลัสเตอร์โดยตรง
Flux CD: วิธีการทางเลือก
Flux CD ใช้วิธีการทางสถาปัตยกรรมที่แตกต่างกับ GitOps แทนที่จะเป็นเซิร์ฟเวอร์แบบรวมศูนย์ที่มี UI Flux จะทำงานเป็นชุดตัวควบคุม Kubernetes ที่แต่ละตัวจัดการกับข้อกังวลเฉพาะ
ส่วนประกอบของฟลักซ์
- ตัวควบคุมแหล่งที่มา - จัดการที่เก็บ Git ที่เก็บ Helm และแหล่งสิ่งประดิษฐ์ OCI
- ปรับแต่งตัวควบคุม - ใช้การปรับแต่งภาพซ้อนทับและการปรากฏตัวของ YAML ธรรมดา
- ตัวควบคุม Helm - จัดการการปล่อยกราฟ Helm ผ่าน
HelmReleaseทรัพยากรที่กำหนดเอง - ตัวควบคุมการแจ้งเตือน - จัดการกิจกรรมขาเข้าและขาออกโดยผสานรวมกับผู้ให้บริการ Slack, Teams และ Webhook
- ตัวควบคุมภาพอัตโนมัติ - สแกนทะเบียนคอนเทนเนอร์และอัปเดตปรากฏเมื่อมีภาพใหม่
Flux Bootstrap
# Bootstrap Flux on a cluster with a GitHub repository
flux bootstrap github \
--owner=myorg \
--repository=fleet-infra \
--branch=main \
--path=clusters/production \
--personal
# Define a HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: nginx-ingress
namespace: ingress-system
spec:
interval: 5m
chart:
spec:
chart: ingress-nginx
version: "4.x"
sourceRef:
kind: HelmRepository
name: ingress-nginx
namespace: flux-system
values:
controller:
replicaCount: 3
metrics:
enabled: trueArgoCD vs Flux: เมื่อไหร่ควรเลือกแบบไหน
ArgoCD เหมาะอย่างยิ่งเมื่อคุณต้องการ UI เว็บที่สมบูรณ์แบบสำหรับการมองเห็นการเช่าหลายครั้งด้วย RBAC ที่ละเอียดและระนาบการจัดการแบบรวมศูนย์ Flux ส่องสว่างในสภาพแวดล้อมที่ต้องการสถาปัตยกรรมแบบคอนโทรลเลอร์ที่มีน้ำหนักเบาต้องการความสามารถในการทำงานอัตโนมัติของภาพหรือต้องการการผสานรวมที่ลึกซึ้งยิ่งขึ้นกับระบบนิเวศ Kubernetes API
การจัดการแผนภูมิ Helm ใน GitOps
แผนภูมิ Helm เป็นรูปแบบบรรจุภัณฑ์โดยพฤตินัยสำหรับการใช้งาน Kubernetes ในเวิร์กโฟลว์ GitOps การจัดการค่า HELM ในทุกสภาพแวดล้อมจำเป็นต้องมีองค์กรที่ระมัดระวัง
# Repository structure for multi-environment Helm management
k8s-manifests/
base/
my-app/
Chart.yaml
values.yaml # Default values
templates/
deployment.yaml
service.yaml
ingress.yaml
environments/
dev/
my-app/
values.yaml # Dev overrides
staging/
my-app/
values.yaml # Staging overrides
production/
my-app/
values.yaml # Production overridesทั้ง ArgoCD และ Flux สนับสนุน Helm โดยกำเนิด ArgoCD แสดงแผนภูมิฝั่งเซิร์ฟเวอร์ผ่านเซิร์ฟเวอร์ที่เก็บในขณะที่ Flux ใช้ Helm SDK โดยตรงภายในตัวควบคุม Helm
กลยุทธ์การปรับใช้
การเลือกกลยุทธ์การปรับใช้ที่เหมาะสมจะช่วยลดความเสี่ยงและทำให้มั่นใจได้ว่าจะไม่มีการหยุดทำงาน
การอัปเดตโรลลิ่งส
กลยุทธ์ Kubernetes เริ่มต้นพอดจะค่อยๆถูกแทนที่ด้วยเวอร์ชันใหม่กำหนดค่า maxSurge และ maxUnavailable เพื่อควบคุมความเร็วในการเปิดตัว
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
spec:
containers:
- name: app
image: myapp:v2.1.0
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10การปรับใช้สีน้ำเงิน - เขียว
ทำงานสองสภาพแวดล้อมที่เหมือนกัน (สีฟ้าและสีเขียว) Run two identical environment (blue and green). ปรับใช้เวอร์ชันใหม่ไปยังสภาพแวดล้อมที่ไม่ได้ใช้งานตรวจสอบแล้วเปลี่ยนการรับส่งข้อมูลซึ่งจะช่วยให้สามารถย้อนกลับได้ทันทีโดยการสลับกลับไปยังสภาพแวดล้อมก่อนหน้าใช้กับตัวเลือกป้ายกำกับบริการหรือการจัดการทราฟฟิก Istio
การปรับใช้ Canary
Gradually route a small percentage of traffic to the new version, increasing the percentage as confidence grows. Tools like Flagger and Argo Rollouts automate canary analysis with metrics-based promotion.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
replicas: 5
strategy:
canary:
steps:
- setWeight: 10
- pause: { duration: 5m }
- setWeight: 30
- pause: { duration: 5m }
- setWeight: 60
- pause: { duration: 5m }
canaryService: my-app-canary
stableService: my-app-stable
trafficRouting:
istio:
virtualService:
name: my-app-vsvc
routes:
- primaryการย้อนกลับอัตโนมัติ
GitOps ทำให้การย้อนกลับตรงไปตรงมา: เพียงแค่คืนค่าคอมมิต Git อย่างไรก็ตาม การย้อนกลับอัตโนมัติตามการตรวจสอบสภาพจะช่วยเพิ่มความปลอดภัยเพิ่มเติม
ArgoCD รองรับการย้อนกลับอัตโนมัติผ่านระบบการซิงค์และการประเมินสุขภาพ หากแอปพลิเคชันเข้าสู่สถานะลดระดับลงหลังจากการซิงค์ ArgoCD จะสามารถย้อนกลับไปยังสถานะที่ใช้งานได้ดีล่าสุดที่ทราบได้โดยอัตโนมัติ
สำหรับสถานการณ์การย้อนกลับที่ซับซ้อนยิ่งขึ้น Argo Rollouts และ Flagger สามารถวิเคราะห์ตัววัด Prometheus เรียกใช้การทดสอบอัตโนมัติ และยกเลิกการเปิดตัวที่แสดงประสิทธิภาพที่ลดลง
การจัดการความลับด้วยความลับที่ปิดผนึก
การจัดเก็บความลับใน Git ถือเป็นความท้าทายที่สำคัญสำหรับ GitOps Sealed Secrets แก้ปัญหานี้โดยการเข้ารหัสความลับที่สามารถถอดรหัสได้โดยคอนโทรลเลอร์ที่ทำงานในคลัสเตอร์เป้าหมายเท่านั้น
# Install Sealed Secrets controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
--namespace kube-system
# Encrypt a secret
kubectl create secret generic db-credentials \
--from-literal=username=admin \
--from-literal=password=s3cure-p@ss \
--dry-run=client -o yaml | \
kubeseal --format yaml > db-credentials-sealed.yamlผลที่ได้ SealedSecret ทรัพยากรสามารถคอมมิตกับ Git ได้อย่างปลอดภัย เฉพาะตัวควบคุม Sealed Secrets ในคลัสเตอร์เป้าหมายเท่านั้นที่เก็บคีย์ส่วนตัวที่จำเป็นในการถอดรหัส แนวทางทางเลือก ได้แก่ External Secrets Operator (สำหรับการดึงจาก AWS Secrets Manager, HashiCorp Vault ฯลฯ) และ SOPS สำหรับการเข้ารหัสระดับไฟล์
การตรวจสอบการปรับใช้
การมองเห็นสถานะการปรับใช้ถือเป็นสิ่งสำคัญสำหรับไปป์ไลน์ GitOps ที่ใช้งานจริง ดำเนินการตรวจสอบในหลายระดับ:
- การวัด ArgoCD - ArgoCD เปิดเผยตัววัด Prometheus สำหรับสถานะการซิงค์ ความสมบูรณ์ และระยะเวลาการดำเนินการ สร้างแดชบอร์ด Grafana เพื่อติดตามความถี่ในการใช้งานและอัตราความล้มเหลว
- เหตุการณ์ Kubernetes - ตรวจสอบการตั้งเวลาพ็อด การดึงรูปภาพ และเหตุการณ์การตรวจสอบความพร้อมเพื่อตรวจพบปัญหาตั้งแต่เนิ่นๆ
- การตรวจสุขภาพแอปพลิเคชัน - กำหนดค่าการตรวจสุขภาพแบบกำหนดเองใน ArgoCD โดยใช้สคริปต์ Lua เพื่อกำหนดความหมายของ "สุขภาพที่ดี" สำหรับทรัพยากรเฉพาะของคุณ
- การแจ้งเตือน - รวมการแจ้งเตือน ArgoCD เข้ากับ Slack, PagerDuty หรืออีเมลเพื่อแจ้งเตือนความล้มเหลวในการซิงค์ ความเสื่อมโทรมของข้อมูล หรือการตรวจจับการเคลื่อนตัว
# ArgoCD Notification ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-notifications-cm
namespace: argocd
data:
trigger.on-sync-failed: |
- when: app.status.operationState.phase in ['Error', 'Failed']
send: [slack-notification]
template.slack-notification: |
message: |
Application {{.app.metadata.name}} sync {{.app.status.operationState.phase}}.
Revision: {{.app.status.sync.revision}}
service.slack: |
token: $slack-token
channel: deploymentsการจัดส่งแบบหลายคลัสเตอร์
เมื่อองค์กรขยายขนาด การปรับใช้ในหลายคลัสเตอร์จึงกลายเป็นสิ่งจำเป็น ArgoCD รองรับการจัดการหลายคลัสเตอร์โดยการลงทะเบียนคลัสเตอร์ภายนอก Flux บรรลุเป้าหมายนี้ผ่านคลัสเตอร์การจัดการที่บูตคลัสเตอร์เวิร์กโหลด
ApplicationSet controller ใน ArgoCD มีประสิทธิภาพเป็นพิเศษสำหรับสถานการณ์แบบหลายคลัสเตอร์ สามารถสร้างทรัพยากรแอปพลิเคชันแบบไดนามิกตามรายการคลัสเตอร์ ไดเรกทอรี Git หรือเหตุการณ์คำขอดึง
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: my-app-set
namespace: argocd
spec:
generators:
- clusters:
selector:
matchLabels:
env: production
template:
metadata:
name: 'my-app-{{name}}'
spec:
project: default
source:
repoURL: https://github.com/myorg/k8s-manifests.git
targetRevision: main
path: 'apps/my-app/overlays/{{metadata.labels.region}}'
destination:
server: '{{server}}'
namespace: my-appบทสรุป
GitOps พร้อม ArgoCD หรือ Flux CD มอบรากฐานที่แข็งแกร่งสำหรับการส่งมอบ Kubernetes อย่างต่อเนื่อง ด้วยการปฏิบัติต่อ Git ในฐานะแหล่งที่มาของความจริง ทำให้การกระทบยอดเป็นแบบอัตโนมัติ และใช้ประโยชน์จากกลยุทธ์การส่งมอบแบบก้าวหน้า ทีมงานจึงสามารถปรับใช้ด้วยความมั่นใจและฟื้นตัวจากความล้มเหลวได้อย่างรวดเร็ว เริ่มต้นด้วยการตั้งค่าคลัสเตอร์เดียวง่ายๆ สร้างโครงสร้างพื้นที่เก็บข้อมูล Git ของคุณ และค่อยๆ นำรูปแบบขั้นสูงมาใช้ เช่น การใช้งานแบบคานารี การจัดการหลายคลัสเตอร์ และนโยบายการย้อนกลับอัตโนมัติเมื่อแพลตฟอร์มของคุณเติบโต
การลงทุนในโครงสร้างพื้นฐาน GitOps จ่ายเงินปันผลผ่านความน่าเชื่อถือที่ได้รับการปรับปรุง การตอบสนองต่อเหตุการณ์ที่เร็วขึ้น เส้นทางการตรวจสอบที่สมบูรณ์ และประสบการณ์ของนักพัฒนาที่ทำให้การปรับใช้งานทำได้ง่ายเพียงแค่รวมคำขอดึงเข้าด้วยกัน