**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 **catatan** Kemampuan EKS sepenuhnya dikelola dan dijalankan di luar cluster Anda. Anda tidak memiliki akses langsung ke ruang nama pengontrol. Anda dapat mengonfigurasi pengiriman log pengontrol untuk visibilitas ke perilaku pengontrol. Lihat [Akses log pengontrol Kemampuan EKS](capabilities-controller-logs.md). Pemecahan masalah berfokus pada kesehatan kemampuan, status aplikasi, dan konfigurasi. ## 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**: 1. Buka konsol Amazon EKS di https://console.aws.amazon.com/eks/home \#/cluster. 1. Pilih nama cluster Anda. 1. Pilih ** tab ** Observability. 1. Pilih ** Monitor cluster**. 1. Pilih ** tab ** Kemampuan untuk melihat kesehatan dan status untuk semua kemampuan. ** 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**: + **Repositori tidak dikonfigurasi**: Repositori Git tidak ditambahkan ke CD Argo + **Otentikasi gagal**: kunci SSH, token, atau CodeCommit kredenSIAL tidak valid + **Aplikasi tidak dibuat**: Tidak ada sumber daya aplikasi yang ada di cluster + **Kebijakan sinkronisasi**: Sinkronisasi manual diperlukan (sinkronisasi otomatis tidak diaktifkan) + **Izin IAM**: Izin hilang untuk CodeCommit atau Manajer Rahasia **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 mencapai`Healthy`, 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**: + **Penerapan belum siap**: Pod gagal memulai atau pemeriksaan kesiapan gagal + **Ketergantungan sumber daya**: Sumber daya menunggu sumber daya lain siap + **Kesalahan penarikan gambar**: Gambar kontainer tidak dapat diakses + **Sumber daya tidak mencukupi**: Cluster tidak memiliki CPU atau memori untuk pod **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, lihat[Daftarkan kluster target](argocd-register-clusters.md). ## 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 + **Tidak ada konfigurasi webhook**: Tanpa webhook, Argo CD mensurvei repositori pada interval default 6 menit. Ini menunda deteksi commit baru. + **TargetRevision disetel ke ** HEAD: Setiap komit ke repositori membatalkan cache manifes. Argo CD kemudian meregenerasi manifes pada setiap rekonsiliasi. + **Repositori Git besar atau kompleks**: Monorepos atau grafik Helm yang kompleks menyebabkan pembuatan manifes yang lambat karena volume file dan templat untuk diproses. + **Jumlah sumber daya Kubernetes yang tinggi dalam satu aplikasi**: Aplikasi yang mengelola banyak sumber daya menyebabkan sinkronisasi cache cluster lambat karena CD Argo harus melacak status setiap sumber daya. ### Mitigasi + **Konfigurasikan webhook Git**: Webhook segera memberi tahu Argo CD ketika perubahan didorong, melewati interval polling default. Untuk langkah-langkah konfigurasi, lihat[Pertimbangan CD Argo](argocd-considerations.md). + **Gunakan nama cabang tertentu atau komit SHA**: Setel `targetRevision` ke nama cabang atau komit SHA alih-alih `HEAD` untuk mempertahankan cache manifes di antara sinkronisasi. + **Pisahkan monorepos besar**: Bagilah repositori besar menjadi repositori yang lebih kecil dan terfokus untuk mengurangi waktu pembuatan manifes. + **Kurangi sumber daya per aplikasi**: Pisahkan aplikasi dengan banyak sumber daya Kubernetes menjadi beberapa aplikasi yang lebih kecil untuk mengurangi waktu sinkronisasi cache cluster. + **Aktifkan pengiriman log pengontrol**: Log pengontrol memberikan visibilitas ke perilaku rekonsiliasi dan pemrosesan antrian. Untuk langkah-langkah konfigurasi, lihat[Akses log pengontrol Kemampuan EKS](capabilities-controller-logs.md). ## Aplikasi berulang kali disinkronkan atau tidak sinkron Jika aplikasi Anda disinkronkan dan kemudian segera berjalan`OutOfSync`, 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: + Aplikasi sinkronisasi, lalu segera ditampilkan `OutOfSync` + Diff menunjukkan perubahan pada bidang webhook atau `caBundle` bidang Rahasia TLS `data` 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 ``` **catatan** Self-heal waktu backoff adalah pengaturan pengontrol tingkat instance. Jika Anda perlu menyesuaikan waktu penyembuhan diri daripada menonaktifkannya, buka kasus AWS Dukungan. ### 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: + Jadikan sumber daya yang diperebutkan unik per pemilik. Tambahkan lingkungan atau akhiran cluster ke nama sumber daya. + Saat mengganti nama ApplicationSet, atur terlebih `preserveResourcesOnDeletion: true` dahulu untuk menghindari penghancuran sumber daya yang ada secara destruktif: ``` 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: + Pastikan pengontrol yang memiliki finalizer pemblokiran sehat dan berjalan. + Jika pengontrol yang memiliki sehat tetapi finalizer tidak diproses, hapus finalizer pemblokiran dari sumber daya yang macet. 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":[]}}'`. **Awas** Atur daftar finalizer secara eksplisit daripada menghapus entri berdasarkan posisi. Sumber daya dapat membawa finalizer dari lebih dari satu pengontrol. Finalizer tidak dalam urutan yang dijamin. Menghapus entri pertama dapat menghapus finalizer yang salah, yang membuat pemblokiran tetap di tempatnya dan sumber daya masih macet. Menghapus finalizer juga melewatkan pembersihan apa pun yang akan dilakukan pengontrol pemilik, yang dapat meninggalkan AWS sumber daya tanpa catatannya di cluster Anda. Lakukan ini hanya setelah Anda mengonfirmasi bahwa pengontrol yang memiliki tidak dapat memproses finalizer. ### 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: ``` 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 gantinya`HEAD`. ### 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 (seperti`terminationGracePeriodSeconds`,`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 + **Gunakan perbedaan aplikasi terlebih dahulu**: Jalan `argocd app diff` kan sebagai langkah diagnostik pertama untuk masalah sinkronisasi berulang. Ini menunjukkan kepada Anda penyebab pasti penyimpangan. + **Lebih suka ignoreDifferences yang sempit**: Targetkan bidang tertentu pada jenis sumber daya tertentu. Hindari aturan abaikan luas yang dapat menutupi penyimpangan konfigurasi nyata. + **Pasangkan ignoreDifferences dengan RespectIgnoreDifferences**: Selalu tambahkan opsi `RespectIgnoreDifferences=true` sinkronisasi. Tanpa itu, sinkronisasi masih mengganti bidang yang diabaikan. + **Jaga agar nama sumber daya tetap unik**: Lingkup nama sumber daya per lingkungan dan cluster untuk menghindari tabrakan kepemilikan antara Aplikasi atau ApplicationSets. + **Berhati-hatilah dengan prune dan selfHe ** al: Jangan aktifkan keduanya pada beban kerja yang membutuhkan waktu lama untuk memulai. Penyembuhan diri dapat merobohkan sumber daya sebelum menjadi sehat. + **Sematkan jalur manifes TargetRevision dan cakupan**: Untuk aplikasi di repositori bersama yang besar, gunakan cabang atau tag alih-alih `HEAD` dan tambahkan anotasi`manifest-generate-paths`. ### Kapan harus menghubungi AWS Dukungan Buka kasus AWS Dukungan dalam situasi berikut: + Instance-level penyetelan pengontrol tampaknya diperlukan (jumlah prosesor, waktu penyembuhan diri, atau pengecualian sumber daya). + Repo-server atau kapasitas pengontrol tampaknya tidak cukup untuk jumlah aplikasi Anda. + Konfigurasi beban kerja, drift, kepemilikan, atau finalisasi tidak menjelaskan perilaku tersebut. Sertakan output dari `argocd app get` dan `argocd app diff` untuk aplikasi yang terpengaruh dalam kasus dukungan Anda. ## Langkah selanjutnya + [Pertimbangan CD Argo](argocd-considerations.md)- Pertimbangan Argo CD dan praktik terbaik + [Bekerja dengan Argo CD](working-with-argocd.md)- Membuat dan mengelola Aplikasi CD Argo + [Daftarkan kluster target](argocd-register-clusters.md)- Konfigurasikan penerapan multi-cluster + [Pemecahan Masalah Kemampuan EKS](capabilities-troubleshooting.md)- Panduan pemecahan masalah kemampuan umum