Bantu meningkatkan 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 GitHub tautan Edit halaman ini di 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 CD Argo

Kemampuan AKTIF tetapi aplikasi tidak disinkronkan

Jika kemampuan CD Argo 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 “Progressive”

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 CD Argo 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 membutuhkan codecommit:GitPull izin untuk repositori.

Untuk repositori Git pribadi:

Verifikasi kredenSIAL repositori dikonfigurasi dengan benar:

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

Pastikan rahasia berisi kredentif 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 penerapan

Jika aplikasi tidak menerapkan ke cluster jarak jauh, verifikasi pendaftaran 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 bidang berisi ARN cluster EKS, bukan URL API Kubernetes.

Verifikasi Entri Akses cluster target:

Pada cluster target, periksa apakah Argo CD Capability Role 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 cluster 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 disinkronkan tetapi membutuhkan 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 targetRevision: HEAD membatalkan cache manifes 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 disinkronkan atau tidak sinkron

Jika aplikasi Anda disinkronkan dan kemudian segera berjalanOutOfSync, atau jika tetap macet dalam loop sinkronisasi, penyebabnya biasanya menyimpang 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
         

Per argocd app diff intah adalah titik awal yang paling berguna. Ini menunjukkan kepada Anda 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 masalah ini, tambahkan ignoreDifferences untuk 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 yang dimulai lambat

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

Untuk mengatasinya, pertama-tama perbaiki penyimpangan yang mendasarinya (lihat skenario sertifikat). Jika penyimpangan 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 Aplikasi atau ApplicationSets mengelola sumber daya Kubernetes yang sama, CD Argo menunjukkan a. 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 finalis sumber daya

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

Untuk mengonfirmasi, daftarkan sumber daya yang memiliki cap 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:

Menggunakan daftar finalizer yang dicetak oleh perintah sebelumnya, atur daftar ke finalizer yang ingin Anda simpan dan tinggalkan hanya yang memblokir. Ganti finalizer-a dan finalizer-b dengan nama-nama itu:

kubectl patch resource-kind
            resource-name -n my-namespace \
  --type merge -p '{"metadata":{"finalizers":["finalizer-a","finalizer-b"]}}'

Jika finalizer pemblokiran adalah satu-satunya pada sumber daya, berikan daftar kosong:--type merge -p '{"metadata":{"finalizers":[]}}'.

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

Setelah sinkronisasi ke revisi tertentu gagal, Argo CD tidak akan mencoba ulang secara otomatis revisi yang sama. Hal ini biasanya terjadi karena cacat nyata 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 mengatasinya, perbaiki cacat manifes di repositori Git Anda dan dorong komit baru. Atau, picu sinkronisasi manual:

argocd app sync my-app
         

Monorepo commit churn memicu regenerasi yang luas

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

Untuk mencakup regenerasi hanya ke 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, sem targetRevision atkan ke nama cabang atau tag sebagai gantinyaHEAD.

Kubernetes yang default dan bermutasi webhook menyebabkan perbedaan hantu

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

Untuk mengatasi masalah ini untuk bidang yang dikelola oleh pengontrol lain (seperti /spec/replicas ketika 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 webhook default atau mutasi Kubernetes, Anda dapat mengaktifkan perbedaan 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 aplikasi dry-run 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 pengendali

Beberapa pengontrol menghasilkan sejumlah besar sumber daya berumur pendek atau sering diperbarui. Contohnya termasuk objek node Karpenter, identitas Cilium dan objek titik akhir, dan laporan kebijakan Kyverno. Jika sumber daya ini menghasilkan volume peristiwa 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 Dukungan untuk meminta pengecualian sumber daya atau pemfilteran peristiwa tontonan untuk jenis sumber daya ini.

Praktik terbaik

Kapan harus menghubungi AWS Dukungan

Buka kasus AWS Dukungan dalam situasi berikut:

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

Langkah selanjutnya