Bantu tingkatkan halaman ini

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memecahkan masalah dengan kemampuan Argo CD

Kemampuan aktif tetapi aplikasi tidak disinkronkan

Jika kemampuan Argo CD Anda menunjukkan ACTIVE status tetapi aplikasi tidak disinkronkan, periksa kesehatan kemampuan dan status aplikasi.

Periksa kesehatan kemampuan:

Anda dapat melihat masalah kesehatan dan status kemampuan di konsol EKS atau menggunakan AWS CLI.

Konsol:

AWS CLI:

# View capability status and health
aws eks describe-capability \
  --region region-code \
  --cluster-name my-cluster \
  --capability-name my-argocd

# Look for issues in the health section

Penyebab umum:

Periksa status aplikasi:

# List applications
kubectl get application -n argocd

# View sync status
kubectl get application my-app -n argocd -o jsonpath='{.status.sync.status}'

# View application health
kubectl get application my-app -n argocd -o jsonpath='{.status.health}'

Periksa kondisi aplikasi:

# Describe application to see detailed status
kubectl describe application my-app -n argocd

# View application health
kubectl get application my-app -n argocd -o jsonpath='{.status.health}'

Aplikasi terjebak dalam status “Kemajuan”

Jika aplikasi ditampilkan Progressing tetapi tidak pernah mencapaiHealthy, periksa status sumber daya aplikasi dan peristiwa.

Periksa kesehatan sumber daya:

# View application resources
kubectl get application my-app -n argocd -o jsonpath='{.status.resources}'

# Check for unhealthy resources
kubectl describe application my-app -n argocd | grep -A 10 "Health Status"

Penyebab umum:

Verifikasi konfigurasi cluster target (untuk pengaturan multi-cluster):

# List registered clusters
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=cluster

# View cluster secret details
kubectl get secret cluster-secret-name -n argocd -o yaml

Kegagalan otentikasi repositori

Jika Argo CD tidak dapat mengakses repositori Git Anda, verifikasi konfigurasi otentikasi.

Untuk CodeCommit repositori:

Verifikasi Peran Kemampuan IAM memiliki CodeCommit izin:

# View IAM policies
aws iam list-attached-role-policies --role-name my-argocd-capability-role
aws iam list-role-policies --role-name my-argocd-capability-role

# Get specific policy details
aws iam get-role-policy --role-name my-argocd-capability-role --policy-name policy-name
      

Peran tersebut membutuhkan codecommit:GitPull izin untuk repositori.

Untuk repositori Git pribadi:

Verifikasi kredenal repositori dikonfigurasi dengan benar:

# Check repository secret exists
kubectl get secret -n argocd repo-secret-name -o yaml

Pastikan rahasia berisi kredensyal otentikasi yang benar (kunci SSH, token, atau). username/password

Untuk repositori menggunakan Secrets Manager:

# Verify IAM Capability Role has Secrets Manager permissions
aws iam list-attached-role-policies --role-name my-argocd-capability-role

# Test secret retrieval
aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:region-code:111122223333:secret:my-secret
      

Multi-cluster masalah penyebaran

Jika aplikasi tidak menyebarkan ke cluster jarak jauh, verifikasi registrasi cluster dan konfigurasi akses.

Periksa pendaftaran cluster:

# List registered clusters
kubectl get secret -n argocd -l argocd.argoproj.io/secret-type=cluster

# Verify cluster secret format
kubectl get secret CLUSTER_SECRET_NAME -n argocd -o yaml

Pastikan server field tersebut berisi ARN klaster EKS, bukan URL API Kubernetes.

Verifikasi Entri Akses kluster target:

Pada cluster target, periksa apakah Peran Kemampuan CD Argo memiliki Entri Akses:

# List access entries (run on target cluster or use AWS CLI)
aws eks list-access-entries --cluster-name target-cluster

# Describe specific access entry
aws eks describe-access-entry \
  --cluster-name target-cluster \
  --principal-arn arn:aws:iam::111122223333:role/my-argocd-capability-role
      

Periksa izin IAM untuk lintas akun:

Untuk penerapan lintas akun, verifikasi Peran Kemampuan CD Argo memiliki Entri Akses pada kluster target. Kemampuan terkelola menggunakan Entri Akses EKS untuk akses lintas akun, bukan asumsi peran IAM.

Untuk informasi lebih lanjut tentang konfigurasi multi-cluster, lihatDaftarkan kluster target.

Peningkatan waktu sinkronisasi aplikasi

Jika aplikasi Anda menyinkronkan tetapi memakan waktu lebih lama dari yang diharapkan, gunakan langkah-langkah diagnostik berikut untuk mengidentifikasi penyebabnya.

Periksa waktu sinkronisasi terakhir

Konfirmasikan penundaan dengan meninjau kapan aplikasi terakhir disinkronkan:

# View last sync time for all applications
kubectl get application -n argocd -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.operationState.finishedAt}{"\n"}{end}'

# View last sync time for a specific application
kubectl get application my-app -n argocd -o jsonpath='{.status.operationState.finishedAt}'

Periksa kondisi aplikasi

Tinjau kondisi aplikasi untuk penundaan antrian rekonsiliasi:

# Check conditions on an application
kubectl get application my-app -n argocd -o jsonpath='{.status.conditions}'

Periksa konfigurasi TargetRevision

Aplikasi yang menggunakan cache manifes targetRevision: HEAD tidak valid pada setiap komit ke repositori, yang memperlambat waktu sinkronisasi:

# List applications using HEAD as targetRevision
kubectl get application -n argocd -o jsonpath='{range .items[?(@.spec.source.targetRevision=="HEAD")]}{.metadata.name}{"\n"}{end}'

Penyebab umum

Mitigasi

Aplikasi berulang kali menyinkronkan atau tidak sinkron

Jika aplikasi Anda menyinkronkan dan kemudian segera berjalanOutOfSync, atau jika tetap macet dalam loop sinkronisasi, penyebabnya biasanya penyimpangan antara apa yang didefinisikan Git dan apa yang ada di cluster. Mulailah dengan diagnostik dasar.

Kumpulkan informasi diagnostik

# View current sync and health status
argocd app get my-app

# Show exact fields that differ between Git and live state
argocd app diff my-app

# Check whether the app has ever reached a stable state
argocd app history my-app
         

argocd app diffPerintah adalah titik awal yang paling berguna. Ini menunjukkan dengan tepat bidang mana yang menyebabkan aplikasi tampak tidak sinkron.

Self-managed sertifikat menyebabkan penyimpangan

Pengontrol seperti cert-manager, OPA Gatekeeper, dan KEDA menghasilkan sertifikat saat runtime. Nilai runtime ini tidak ada di Git, jadi Argo CD mendeteksi penyimpangan pada setiap rekonsiliasi.

Gejalanya adalah:

Untuk mengatasi hal ini, tambahkan ignoreDifferences bidang yang terpengaruh dan aktifkan RespectIgnoreDifferences di opsi sinkronisasi Anda:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  ignoreDifferences:
    - group: admissionregistration.k8s.io
      kind: ValidatingWebhookConfiguration
      jsonPointers:
        - /webhooks/0/clientConfig/caBundle
    - group: ""
      kind: Secret
      jsonPointers:
        - /data/tls.crt
        - /data/tls.key
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true

Self-heal mengganggu beban kerja awal yang lambat

Ketika selfHeal diaktifkan, Argo CD menyinkronkan ulang aplikasi ketika mendeteksi drift. Jika beban kerja Anda membutuhkan waktu 30-60 detik untuk memulai, penyembuhan diri akan terpicu sebelum beban kerja menjadi. Healthy Dengan prune diaktifkan, ini mungkin meruntuhkan sumber daya yang dimulai sebagian.

Untuk mengatasi ini, pertama-tama perbaiki penyimpangan yang mendasarinya (lihat skenario sertifikat). Jika drift bukan penyebabnya, pertimbangkan untuk menonaktifkan self-heal untuk beban kerja yang Anda kelola secara eksklusif melalui Git:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  syncPolicy:
    automated:
      selfHeal: false
      prune: false

ApplicationSet atau tabrakan kepemilikan sumber daya

Jika dua Applications atau ApplicationSets mengelola resource Kubernetes yang sama, Argo CD menampilkan file. SharedResourceWarning Sumber daya tidak pernah mencapai keadaan stabil. Ini biasanya terjadi ketika nama sumber daya bersama tidak dicakup per lingkungan atau cluster.

Untuk mengatasi ini:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-appset
spec:
  syncPolicy:
    preserveResourcesOnDeletion: true

Penghapusan macet dari finalizer sumber daya

Jika aplikasi macet dalam Terminating status atau menunjukkan “N objek tersisa untuk dihapus”, resources-finalizer.argocd.argoproj.io finalizer memblokir penghapusan hingga semua sumber daya terkelola dihapus. Sumber daya yang dikelola dengan finalizer sendiri yang tidak dapat diproses memblokir penghapusan tanpa batas waktu.

Untuk mengonfirmasi, daftarkan sumber daya yang memiliki stempel waktu penghapusan tetapi belum dihapus:

kubectl get all -n my-namespace -o json | \
  jq '.items[] | select(.metadata.deletionTimestamp != null) | {name: .metadata.name, kind: .kind, finalizers: .metadata.finalizers}'

Untuk mengatasi ini:

kubectl patch resource-kind
            resource-name -n my-namespace \
  --type json -p '[{"op": "remove", "path": "/metadata/finalizers/0"}]'

Sinkronisasi yang gagal tidak mencoba ulang secara otomatis ke revisi yang sama

Setelah sinkronisasi ke revisi tertentu gagal, Argo CD tidak mencoba ulang revisi yang sama secara otomatis. Ini biasanya terjadi karena cacat manifes seperti ComparisonError dari kunci variabel lingkungan duplikat.

Konfirmasikan dengan memeriksa status aplikasi:

argocd app get my-app
# Look for: Operation: Sync  Phase: Failed  Revision: <sha>

Untuk mengatasi hal ini, perbaiki cacat manifes di repositori Git Anda dan dorong komit baru. Atau, memicu sinkronisasi manual:

argocd app sync my-app
         

Monorepo commit churn memicu regenerasi luas

Jika banyak aplikasi melacak HEAD pada repositori yang sama, setiap komit ke repositori itu berubah HEAD untuk semua aplikasi. Ini memicu regenerasi nyata untuk setiap aplikasi, bahkan mereka yang file-nya tidak berubah. Untuk informasi selengkapnya tentang targetRevision dan caching, lihat bagian “Peningkatan waktu sinkronisasi aplikasi” di halaman ini.

Untuk membuat cakupan regenerasi ke hanya file yang digunakan setiap aplikasi, tambahkan manifest-generate-paths anotasi:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  annotations:
    argocd.argoproj.io/manifest-generate-paths: /apps/my-app
spec:
  source:
    repoURL: https://github.com/my-org/my-monorepo.git
    targetRevision: HEAD
    path: apps/my-app

Dengan anotasi ini, Argo CD hanya meregenerasi manifes ketika file di bawah jalur yang ditentukan berubah. Untuk pustaka bersama yang digunakan di seluruh aplikasi, Anda dapat menentukan beberapa jalur yang dipisahkan oleh titik koma (). ;

Jika memungkinkan, pin targetRevision ke nama cabang atau tag, bukanHEAD.

Kubernetes yang default dan bermutasi pada webhook menyebabkan phantom diffs

Jika aplikasi Anda muncul OutOfSync segera setelah sinkronisasi, periksa diff untuk bidang yang tidak pernah Anda tetapkan (sepertiterminationGracePeriodSeconds,dnsPolicy, atau/spec/replicas). Server API Kubernetes atau webhook yang bermutasi menambahkan bidang-bidang tersebut pada waktu penerapan.

Untuk mengatasi hal ini untuk bidang yang dikelola oleh pengontrol lain (seperti /spec/replicas saat HPA mengelola penskalaan), tambahkan: ignoreDifferences

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  ignoreDifferences:
    - group: apps
      kind: Deployment
      jsonPointers:
        - /spec/replicas
  syncPolicy:
    syncOptions:
      - RespectIgnoreDifferences=true

Untuk bidang yang ditambahkan oleh Kubernetes yang default atau bermutasi webhook, Anda dapat mengaktifkan diff sisi server pada aplikasi:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  annotations:
    argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true

Server-side diff melakukan dry-run apply per resource, yang meningkatkan beban pada server API Kubernetes. Uji ini pada sejumlah kecil aplikasi sebelum Anda mengaktifkannya secara luas.

High-churn sumber daya milik pengontrol

Beberapa pengontrol menghasilkan sejumlah besar sumber daya berumur pendek atau sering diperbarui. Contohnya termasuk objek simpul Karpenter, identitas Cilium dan objek titik akhir, dan laporan kebijakan Kyverno. Jika sumber daya ini menghasilkan volume acara tontonan yang tinggi dan menyebabkan churn sinkronisasi, Anda dapat mengurangi beban dengan mengecualikan jenis sumber daya tersebut atau memfilter acara tontonan. Perubahan ini memerlukan konfigurasi pengontrol tingkat instance.

Pada kemampuan terkelola, buka kasus AWS Support untuk meminta pengecualian sumber daya atau pemfilteran acara tontonan untuk jenis sumber daya ini.

Praktik terbaik

Kapan harus menghubungi AWS Support

Buka kasus AWS Support dalam situasi berikut:

Sertakan output dari argocd app get dan argocd app diff untuk aplikasi yang terpengaruh dalam kasus dukungan Anda.

Langkah selanjutnya