ข้ามไปยังเนื้อหา

บล็อก

การจัดส่งต่อเนื่อง Kubernetes: ท่อ GitOps พร้อม ArgoCD และ Flux

สร้างท่อส่งการปรับใช้อัตโนมัติที่เชื่อถือได้สำหรับ Kubernetes โดยใช้ GitOps ด้วย ArgoCD และ Flux

  • อ่าน 4 นาที
  • Updated

การส่งมอบอย่างต่อเนื่องบน Kubernetes มีการพัฒนาที่เหนือกว่าความเรียบง่าย kubectl apply คำสั่งทีมสมัยใหม่กำลังใช้ GitOps ซึ่งเป็นกระบวนทัศน์ที่ใช้ Git เป็นแหล่งเดียวของความจริงสำหรับโครงสร้างพื้นฐานเชิงประกาศและการกำหนดค่าแอปพลิเคชันด้วยการรวมหลักการ GitOps เข้ากับเครื่องมือเช่น ArgoCD และ Flux CD องค์กรสามารถบรรลุท่อการปรับใช้ที่เชื่อถือได้ตรวจสอบได้และอัตโนมัติซึ่งขยายไปทั่วคลัสเตอร์และสภาพแวดล้อม

คู่มือนี้ครอบคลุมสถาปัตยกรรมการตั้งค่าและแนวทางปฏิบัติที่ดีที่สุดสำหรับการสร้างท่อส่งมอบอย่างต่อเนื่องระดับการผลิตบน Kubernetes โดยใช้แนวทาง GitOps

หลักการของ GitOps

GitOps สร้างขึ้นจากหลักการหลักสี่ประการที่เปลี่ยนวิธีการจัดการการปรับใช้ของทีมโดยพื้นฐาน:

CI/CD Pipeline ด้วย GitOpsGit Pushแฟ้มต้นฉบับ@ info: whatsthisลงมือสร้างสรรค์สิ่งใหม่คอมไพล์และผ้าสำลีTestยูนิตและการบูรณาการการค้าการดันรูปภาพปรับใช้กับ K8sArgoCD/FluxArgoCDซิงค์และปรับความเข้าใจแผ่นซีดี FluxGit Reconcilerพื้นที่เก็บข้อมูล Git = แหล่งความจริงเดียว
  • การกำหนดค่า Declarative - สถานะที่ต้องการทั้งหมดของระบบของคุณได้รับการอธิบายตามประกาศสำหรับ Kubernetes หมายถึงการปรากฏตัวของ YAML แผนภูมิ Helm หรือการปรับแต่งภาพซ้อนทับที่จัดเก็บไว้ใน GIT
  • ควบคุมเวอร์ชันแล้ว - GIT ทำหน้าที่เป็นแหล่งเดียวของความจริงทุกการเปลี่ยนแปลงจะต้องผ่านการร้องขอการดึงให้เส้นทางการตรวจสอบที่สมบูรณ์และช่วยให้สามารถย้อนกลับได้ง่ายโดยการย้อนกลับความมุ่งมั่น
  • การกระทบยอดอัตโนมัติ - เจ้าหน้าที่ที่ทำงานในคลัสเตอร์จะเปรียบเทียบสถานะที่ต้องการใน Git กับสถานะจริงในคลัสเตอร์อย่างต่อเนื่องและกระทบยอดการดริฟท์โดยอัตโนมัติ
  • การสังเกตอย่างต่อเนื่อง - ระบบจะตรวจสอบทั้งพื้นที่เก็บข้อมูล Git และสถานะคลัสเตอร์อย่างต่อเนื่องแจ้งเตือนเกี่ยวกับไดเวอร์เจนซ์และตรวจสอบให้แน่ใจว่าคลัสเตอร์ตรงกับการกำหนดค่าที่ประกาศไว้เสมอ

หลักการเหล่านี้กำจัดขั้นตอนการปรับใช้ด้วยตนเองลดข้อผิดพลาดของมนุษย์และให้เวิร์กโฟลว์ที่สอดคล้องกันโดยไม่คำนึงถึงความซับซ้อนของคลัสเตอร์

สถาปัตยกรรมและการตั้งค่า ArgoCD

ArgoCD เป็นเครื่องมือ GitOps ที่ได้รับการยอมรับอย่างกว้างขวางที่สุดสำหรับ Kubernetes มันมี UI เว็บที่มีประสิทธิภาพ CLI และ API สำหรับการจัดการการปรับใช้แอปพลิเคชันในคลัสเตอร์

เวิร์กโฟลว์ GitOpsผู้พัฒนาPush/PR Mergeที่เก็บ Gitสถานะที่ต้องการArgoCDนาฬิกา repoตรวจจับการดริฟท์คลัสเตอร์ K8sสถานะสดซิงค์อัตโนมัติย้อนกลับ = Git Revertเส้นทางการตรวจสอบ: ทุกการปรับใช้เป็นความมุ่งมั่นของ Git

ส่วนประกอบหลัก

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: true

ArgoCD 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 จ่ายเงินปันผลผ่านความน่าเชื่อถือที่ได้รับการปรับปรุง การตอบสนองต่อเหตุการณ์ที่เร็วขึ้น เส้นทางการตรวจสอบที่สมบูรณ์ และประสบการณ์ของนักพัฒนาที่ทำให้การปรับใช้งานทำได้ง่ายเพียงแค่รวมคำขอดึงเข้าด้วยกัน