Workstation Logo
ผลิตภัณฑ์
AI LabsOpenAI AgentsClaude AgentsGrok BotWorkstation CRM (WSL CRM)การตลาดผลิตภัณฑ์ทั้งหมด
โซลูชัน AI
เวิร์กสเตชัน AIAI SME PackagesAI ส่วนตัวคลัสเตอร์ GPUEdge AIแล็บ AI องค์กรAI ตามอุตสาหกรรม
บริการ
Platform ModernisationDigital EngineeringData Foundations & AIAutonomous Operationsที่ปรึกษา AIระบบอัตโนมัติ DevOpsความมั่นคงปลอดภัยไซเบอร์การพัฒนาซอฟต์แวร์การสร้างเอเจนต์การตั้งค่า MLOps
เกี่ยวกับเรา
พาร์ทเนอร์เรื่องราวลูกค้า
บทความ
เอกสาร
WSL ProxyRing PromoterWSL VaultJobshoutSysOps 24/7
บล็อก
ติดต่อเราLogin
Workstation

เวิร์กสเตชัน AI ซอฟต์แวร์มัลติเอเจนต์ AI โครงสร้างพื้นฐาน GPU และโซลูชันเอเจนต์อัจฉริยะสำหรับธุรกิจยุคใหม่

ติดต่อเรา

โซลูชัน AI

เวิร์กสเตชัน AIAI SME PackagesAI ส่วนตัวคลัสเตอร์ GPUEdge AIแล็บ AI องค์กรAI ตามอุตสาหกรรม

ผลิตภัณฑ์

ผลิตภัณฑ์ทั้งหมดWSL CRM และ ERPการตลาดOpenAI AgentsWSL ProxyRing PromoterWSL VaultJobshoutSysOps 24/7

บริษัท

เกี่ยวกับเราทำไมต้อง Workstationพาร์ทเนอร์เรื่องราวลูกค้าราคาติดต่อ

แหล่งข้อมูล

บทความเอกสารประกอบบล็อกค้นหาแผนผังเว็บไซต์
สำนักงานสหราชอาณาจักร
77-79 Marlowes, Hemel Hempstead HP1 1LFเส้นทาง - ออกทางแยกที่ 20 จาก M25 Outer Londonเลขทะเบียนบริษัท: 11641870จ. - ศ.: 9:00 - 18:00 น. GMT
+44 7515 356 146
สำนักงานเบลเยียม
Workstation SRL, Rue Vanderkindere 34, 1180 Uccle, BrusselsBE 0751.518.683จ. - ศ.: 9:00 - 18:00 น. CET
+32 492 45 67 46
สำนักงานอินเดีย
#159 Sector 9, Pocket 1, DDA Flats, 110077 Dwarka, New Delhi
+91 98881 98841

© 2026 Workstation AI สงวนลิขสิทธิ์

ความเป็นส่วนตัวคุกกี้ข้อกำหนดการให้บริการแผนผังเว็บไซต์

Loading blog...

Home / Blog
DevOpsKubernetesRke2

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

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

Balinder Walia27 พฤษภาคม 25684 min read

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