Secrets ו-ConfigMaps

כלל ה-namespace

kubectl get secret -A | grep <SECRET>                  # which namespaces hold it
kubectl -n <NS> get secret <SECRET>                    # does THIS namespace hold it

איך מוודאים: לכל סביבה (trident-dev, trident-staging, trident-prod) יש את שלושת ה-Secrets. השם זהה, אבל התוכן יכול להיות שונה (למשל trident-tls — תעודה לכל host).

generic: סיסמה כקובץ

kubectl -n <NS> create secret generic <SECRET> --from-file=postgres_password=<FILE>
# TRIDENT: kubectl -n trident-dev create secret generic trident-postgres --from-file=postgres_password=$HOME/.local/share/trident/credentials/postgres/dev/password

--from-file=<KEY>=<FILE>: שם המפתח ב-Secret (postgres_password) הוא מה שיהפוך לשם הקובץ במאונט. בלי KEY=, שם הקובץ המקורי הופך למפתח.
הקובץ חייב להיות ללא newline בסוף (כתוב אותו עם printf %s, או read -rs). echo ו-here-string מוסיפים \n ל-Secret. כתיבה בטוחה: bash/snippets.

איך מוודאים: kubectl -n <NS> get secret <SECRET> -o jsonpath='{.data}' | jq 'keys' מציג ["postgres_password"].

docker-registry: למשיכת images

kubectl -n <NS> create secret docker-registry <SECRET> \
  --docker-server=<REGISTRY> \
  --docker-username=<USER> \
  --docker-password="$(cat <TOKEN_FILE>)"
# TRIDENT: --docker-server=registry.gitlab.com  (never https://..., and not the web host name)

--docker-server הוא ה-registry (registry.gitlab.com), לא gitlab.com. ה-Secret מקבל type kubernetes.io/dockerconfigjson. ה-Pod משתמש בו דרך extraImagePullSecrets ב-values (values). איזה token מתאים: gitlab/registry.

איך מוודאים: kubectl -n <NS> get secret <SECRET> -o jsonpath='{.type}' מדפיס kubernetes.io/dockerconfigjson. אם Pod נתקע ב-ImagePullBackOff, describe pod מראה אם ה-Secret חסר, השרת שגוי או ה-token בלי scope.

tls: תעודה ומפתח

kubectl -n <NS> create secret tls <SECRET> --cert=<FILE>.crt --key=<FILE>.key
# TRIDENT: kubectl -n trident-dev create secret tls trident-tls --cert=tls/dev.trident.test.crt --key=tls/dev.trident.test.key

איך מוודאים: get secret <SECRET> -o jsonpath='{.type}' מדפיס kubernetes.io/tls; ו-openssl x509 -in <FILE>.crt -noout -subject -dates מראה ל-host הנכון. שם ה-Secret חייב להיות זה שב-extraTls.secretName של ה-Ingress (networking).

יצירה אידמפוטנטית: create | apply

create נכשל אם האובייקט קיים. כדי שאפשר יהיה להריץ שוב ושוב:

kubectl -n <NS> create secret generic <SECRET> --from-file=postgres_password=<FILE> \
  --dry-run=client -o yaml | kubectl apply --server-side --force-conflicts -f -

--dry-run=client -o yaml מייצר את ה-YAML בלי לשלוח, ו-apply יוצר או מעדכן. עם --server-side ערך ה-Secret לא נשמר ב-annotation last-applied-configuration (ב-apply רגיל הוא נשמר שם; פירוט). את ה-namespace עצמו: kubectl create namespace <NS> --dry-run=client -o yaml | kubectl apply -f -. פונקציה מוכנה עם בדיקות קלט: bash/snippets, וה-script המלא: bash/templates.

מאונט כקובץ, לא כ-env

Secret כ-קובץ מוגן בהרשאות; משתנה סביבה דולף ל-child processes, ל-kubectl describe וללוגים. לכן POSTGRES_PASSWORD_FILE=/run/secrets/<APP_DIR>/postgres_password (TRIDENT: <APP_DIR> = trident) ולא ערך. ב-Compose, secrets: מתורגם ל-Secret volume, לא ל-envFrom secretRef. מיפוי: architecture/compose-to-k8s.

kubectl -n <NS> exec deploy/<SERVICE> -- ls -l /run/secrets/<APP_DIR>

איך מוודאים: הקובץ קיים, בגודל > 0. אם התיקייה ריקה — secretName שגוי ב-values, או Secret חסר ב-namespace.

ConfigMaps

ConfigMap מכיל הגדרות לא-רגישות. ב-TRIDENT הוא נוצר מה-values (configMaps.<name>.data), לא ידנית. לבדיקה:

kubectl -n <NS> get cm
kubectl -n <NS> get cm trident-queue -o jsonpath='{.data}' | jq    # a ConfigMap name from get cm
kubectl -n <NS> exec deploy/<SERVICE> -- env | grep -E 'REDIS_HOST|POSTGRES_HOST'

איך מוודאים: הערכים תואמים לשמות ה-Services (fullnameOverride). ConfigMap כ-envFrom נקרא בזמן הפעלת ה-Pod: אחרי שינוי, ה-Pod מוחלף על ידי Argo, או rollout restart.