תפעול Argo CD — repo Secrets, סטטוסים, kubectl

repo Secrets

Argo צריך credential לכל repo פרטי: Secret ב-namespace argocd עם label מיוחד. שני repos = שני Secrets, גם אם ה-credential משותף; ה-url לא.

apiVersion: v1
kind: Secret
metadata:
  name: <SECRET>
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
type: Opaque
stringData:
  type: git
  url: https://<GITLAB_HOST>/<GROUP>/<REPO>.git
  username: <USER>
  password: <TOKEN_FILE>   # the file's contents, not its path

הערה: ה-password נקרא מקובץ ה-token (ראה register-repository.sh ב-TRIDENT, או bash/templates). ה-token לא נכנס ל-Git.

url חייב להיות זהה ל-repoURL בייט-לבייט

kubectl -n argocd get secret <SECRET> -o jsonpath='{.data.url}' | base64 -d; echo
kubectl -n argocd get secret -l argocd.argoproj.io/secret-type=repository

איך מוודאים: הכתובת המודפסת זהה לתו לתו ל-repoURL; הרשימה השנייה מציגה Secret לכל repo.

לבדוק שה-credential באמת עובד

ה-flag --verify של register-repository.sh בודק רק את צורת ה-Secret (שדות, label), לא ש-GitLab מקבל אותו.

git ls-remote https://<USER>:$(cat <TOKEN_FILE>)@<GITLAB_HOST>/<GROUP>/<REPO>.git HEAD

איך מוודאים: רשימת refs (HEAD, refs/heads/main, tags). שגיאת Access denied = הבעיה בצד GitLab.

ב-UI: Settings → Repositories, עמודת Connection Status (Successful / Failed).

קריאת הסטטוסים

kubectl -n argocd get applications
kubectl -n argocd get application <APP> -o jsonpath='{.status.sync.status}/{.status.health.status}{"\n"}'

SYNC	HEALTH	משמעות	מה עושים
`Synced`	`Healthy`	המצב החי = Git, והמשאבים בריאים	עדיין לא הוכחה שהאפליקציה עובדת: `curl` ל-`/info`
`Synced`	`Progressing`	rollout באמצע	המתן, בדוק `kubectl get pods`
`Synced`	`Degraded`	הוחל, אבל Pod לא תקין	`describe`/`logs` ב-`<NS>` (בעיה בצד Pods, לא Argo)
`OutOfSync`	`Healthy`/`Progressing`	Git שונה מהחי; sync יתחיל (או ממתין אם ידני)	בדוק `syncPolicy`; חכה לפולינג או refresh
`OutOfSync`	`Missing`	משאבים לא קיימים (למשל namespace חסר)	`kubectl get ns`, הרץ את script ההכנה
`Unknown`	`Healthy`	Argo לא הצליח לרנדר: אין משאבים, ולכן "Healthy" ריק	קרא `.status.conditions`

אל תבדוק מצבים זמניים (OutOfSync בזמן self-heal, Progressing באמצע rollout) כ"כישלון".

ComparisonError: קוראים מלמטה למעלה

kubectl -n argocd get application <APP> -o jsonpath='{.status.conditions}{"\n"}'

ההודעה היא בצל: כל שכבה עוטפת את זו שמתחתיה, והסיבה האמיתית היא השורה האחרונה.

פירוק מלא של הודעה כזאת, שכבה אחר שכבה: debugging/overview. בקיצור: ComparisonError, אחר כך איזה source, אחר כך helm template שנכשל, ובשורה האחרונה הסיבה.

חפש בטקסט denied/403/unauthorized. אם אין, אל תוסיף סיבות שהטקסט לא תומך בהן.

סיבות נפוצות ל-Unknown/ComparisonError: credential ל-repo, path שגוי, $values בלי ref: values, YAML פגום ב-values, תיקיית chart חסרה ב-templates.

פעולות עם kubectl בלבד

# all apps: sync, health, last operation phase
kubectl -n argocd get applications -o custom-columns=NAME:.metadata.name,SYNC:.status.sync.status,HEALTH:.status.health.status,OP:.status.operationState.phase
# last operation: phase + when it finished + message
kubectl -n argocd get application <APP> -o jsonpath='{.status.operationState.phase}{"  "}{.status.operationState.finishedAt}{"\n"}{.status.operationState.message}{"\n"}'
date -u
# sync history (revisions applied)
kubectl -n argocd get application <APP> -o jsonpath='{.status.history}{"\n"}'

רענון מיידי (קריאה מחדש של Git, בלי לחכות לפולינג):

kubectl -n argocd annotate application <APP> argocd.argoproj.io/refresh=hard --overwrite

hard גם מנקה cache של manifests, ו-Argo מסיר את ה-annotation לבד. איך מוודאים: .status.sync.revision מתעדכן ל-commit האחרון. חשוב: refresh לא מתניע מחדש sync שנכשל.

Argo ויתר: sync ידני

אפשרות 1: ב-UI, כפתור Sync באפליקציה. אפשרות 2: kubectl patch של השדה operation (הצורה מהתיעוד הרשמי, Sync Applications with Kubectl):

kubectl -n argocd patch application <APP> --type merge --dry-run=server -p '{"operation":{"initiatedBy":{"username":"admin"},"sync":{"syncStrategy":{"hook":{}}}}}'
kubectl -n argocd patch application <APP> --type merge -p '{"operation":{"initiatedBy":{"username":"admin"},"sync":{"syncStrategy":{"hook":{}}}}}'

הפקודה הראשונה היא בדיקה בלבד (--dry-run=server). איך מוודאים: OP ב-get applications עובר ל-Running ואז Succeeded, וה-App Synced/Healthy. Argo מסיר את .operation בסיום.

רצוי למנוע את זה מראש: syncPolicy.retry מאפשר לקבוע limit אחר (-1 = ללא הגבלה) ו-backoff (duration, factor, maxDuration). השדות קיימים ב-CRD של ה-cluster (kubectl explain application.spec.syncPolicy.retry).

spec:
  syncPolicy:
    automated: {prune: true, selfHeal: true}
    retry:
      limit: -1        # -1 = unlimited; omitted = default 5
      backoff: {duration: 5s, factor: 2, maxDuration: 3m}

kubectl -n argocd delete application <APP>

בדיקת self-heal ו-prune

selfHeal: שינוי חי מוחזר.

kubectl -n <NS> scale deployment <SERVICE> --replicas=0
kubectl -n <NS> get deployment <SERVICE> -w

איך מוודאים: תוך פולינג/שניות ה-READY חוזר ל-1/1 בלי שנגעת ב-Git. (אם לא: selfHeal חסר, בדוק syncPolicy.)

prune: מחיקה ב-Git מוחקת בקלאסטר. הסר משאב מהרינדור (למשל Deployment מה-values, או קובץ מה-path), commit + push, וחכה.

kubectl -n <NS> get deployment <SERVICE>

איך מוודאים: NotFound אחרי ה-sync. בלי prune: true המשאב נשאר ו-Application נשאר OutOfSync.

לעולם לא מתקנים live: מתקנים ב-Git

prod לא צריך syncPolicy אחר

שני gates שונים: CI שולט במה שנכנס ל-Git (job ה-promote של prod הוא when: manual), ו-Argo תמיד אוטומטי. אז prod.yaml זהה ל-dev.yaml ב-syncPolicy. ה-promote עדיין מריץ promote.sh, והלחיצה היא על ה-job ב-CI. ראה ci/patterns.