Kejuruteraan Lepasan DevOps dan Pagar CI/CD: Memastikan Pengewisan yang Boleh Dipercayai pada Kubernetes

Senario

Sebuah platform e-dagang menggunakan GitLab CI + ArgoCD untuk pengewisan berterusan tetapi kerap mengalami ketidaktersediaan perkhidmatan selepas pengewisan. Pasukan kekurangan pagar automatik, menyebabkan campur tangan manual dan purata masa pemulihan 45 minit.

Gejala

• Status pengewisan menunjukkan berjaya tetapi Pod memasuki CrashLoopBackOff
• Permulaan aplikasi lambat akibat pemeriksaan kesihatan yang hilang atau salah konfigurasi
• OOMKill akibat had sumber yang tidak mencukupi
• Rollback memerlukan kubectl rollout undo manual tanpa langkah pengesahan

Diagnosis

1. Tiada Prob Liveness: Deployment kekurangan livenessProbe, jadi Kubernetes tidak boleh memulakan semula Pod yang tidak sihat secara automatik.
2. Kekurangan Kuota Sumber: Kontena tiada requests atau limits, menyebabkan pertikaian sumber.
3. Rollback Automatik Dimatikan: ArgoCD tidak mempunyai selfHeal atau autoSync yang dikonfigurasi dengan betul.

Arahan Utama

Menambah Prob Liveness (coretan Deployment)

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

Menetapkan Had Sumber

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "500m"

Mengaktifkan Rollback Auto ArgoCD

Dalam spesifikasi Application:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
  syncOptions:
    - Validate=false
  rollback: {} # Rollback disokong secara lalai

Kawalan Risiko

• Pemeriksaan Pra-Pengewisan: Gunakan OPA/Gatekeeper untuk polisi-sebagai-kod, menguatkuasakan pemeriksaan kesihatan dan had sumber.
• Pengewisan Canary: Gunakan ArgoCD Rollouts untuk pengewisan berperingkat dengan jeda automatik atau rollback.
• Tetingkap Pengewisan: Benarkan pengewisan automatik hanya semasa waktu luar puncak.

Langkah Rollback

1. Jalankan kubectl rollout undo deployment/<name> -n <namespace>
2. Gunakan CLI ArgoCD: argocd app rollback <app-name> --prune
3. Sahkan status Pod dan respons aplikasi selepas rollback.

Pengesahan

• Pantau metrik: kiraan restart Pod, kependaman permintaan, kadar ralat
• Periksa log melalui kubectl logs atau log berpusat (EFK/Loki)
• Suntik kegagalan: Bunuh Pod untuk menguji penyembuhan sendiri.

Bila Menghantar Tiket OpsGlobal

• Pasukan SRE dalaman kekurangan kapasiti untuk merekabentuk pagar menyeluruh.
• Insiden pengeluaran melibatkan rollback kompleks atau isu konsistensi data.
• Anda memerlukan penyelesaian masalah pakar untuk kelemahan keselamatan saluran CI/CD.
• Anda mempunyai soalan tentang mengoptimumkan peraturan pemantauan dan penggera.

OpsGlobal menyediakan sokongan SRE jauh 24/7 untuk melaksanakan dan mengekalkan pagar ini, memastikan pengewisan anda selamat dan pantas.