عمليات شراء الحساب السحابي من Google: تقدم Pods تقارير متكررة إلى ImagePullBackOff / ErrImagePull مجموعة كاملة من دليل التحقيق وتجنب الحفر
في إطلاق عمليات حفظ السلام اليومية لـ Google Kubernetes Engine (GKE) وإصدار CI/CD ، فإن الشيء الأكثر إزعاجًا هو الخط المبهر في شريط حالة Pod
ErrImagePull
أو
ImagePullBackOff
.
ببساطة ،
ErrImagePull
إنه خطأ محدد تم طرحه عندما فشلت محاولة Kubelet الأولى في سحب صورة معكوسة ؛ و
ImagePullBackOff
إنها آلية الحماية الذاتية لـ K8s-عندما تجد أن الصورة المرآة لا يمكن سحبها ، فإنها ستدخل حالة "التراجع وإعادة المحاولة" (فترة إعادة الاختبار الممتدة الأسية).
إذا واجهت هذه المشكلة ، لا داعي للذعر. فيما يلي مجموعة من الضغط
استبعاد الأولويات من الأعلى إلى المنخفض
يساعدك برنامج التحقيق القتالي الفعلي على ضرب الآفة مباشرة.
الخطوة الأولى: التشخيص في الموقع الأول ، والتقاط سجل الأخطاء بدقة
التخمين الأعمى للسلطة أو الشبكة مضيعة للوقت. احصل أولاً على معلومات الخطأ المباشرة المسجلة بواسطة Kubernetes من خلال سطر الأوامر.
1. عرض أحداث Pod (Events)
قم بتشغيل الأمر التالي ، اسحب إلى آخر عرض
Events
كتلة:
باش
Kubectl describe pod <pod-name> -n <name>
انتبه
Failed
عادة ما يتم الكشف عن الإخراج المحدد للحدث مباشرة:
لا يوجد أحد أو لا يوجد مكان: مسار المرآة/علامة مكتوبة بشكل خاطئ ، أو لا يوجد شيء في المستودع.
PermissionDenied أو Unauthorized: أذونات IAM غير كافية ، والعقد لا تصل إلى المستودع.
لا يوجد اتصال أو i/o timeout: لا توجد شبكة (شائعة في المجموعات الخاصة أو اعتراض جدار الحماية).
الخطوة الثانية: خمسة أسباب أساسية للتحقيق والحلول
وفقًا لتجربة بيئة الإنتاج ، فإن أكثر من 90 ٪ من فشل سحب صورة مرآة GKE ناتج عن الأسباب الخمسة التالية:
1. خطأ إملائي في مسار المرآة أو Tag (الخطأ الأقل شيوعًا)
بعد أن تحولت خدمة المرايا من Google Cloud بالكامل إلى السجل الفني (GAR) ، كان تنسيق المسار صارمًا للغاية:
Plaintext
[REGION]-docker.pkg.de v/[PROJECT-ID]/[REPOSITORY]/[IMAGE]:[TAG]
# على سبيل المثال: asia-east1-docker.pkg.dev/my-gcp-project/my-repo/my-app:v1.0.0
استكشاف وإصلاح:
التدقيق الإملائي: تحقق
ما إذا كانت بادئة المنطقة (مثل asia-east1) ، ومعرف المشروع ، واتصال المستودع ، واتصال المرآة بها أخطاء إملائية.
تحقق مما إذا كان Tag موجودًا: قم بتشغيل gcloud في المحطة الطرفية للتحقق مما إذا كان الإصدار المتطابق موجودًا بالفعل في السحابة: Bashgcloud artifacts docker الصور asia-east1-docker.pkg.dev/my-project/my-repo
انتبه إلى تباين Tag: إذا كان المستودع الخاص بك يعمل على "Tag Immutability" ، فسوف يفشل دفع Tag الذي يحمل نفس الاسم ، مما يؤدي إلى فشل المجموعة في الحصول على أحدث صورة مرآة.
2. حقوق GCP IAM غير كافية (حساب الخدمة غير مصرح به)
تعتمد عقدة GKE (Node) على طلب الحصول على صورة مرآة من سجل Artifact
حساب خدمة GCP المرتبط بتجمع العقدة (حساب خدمة Node)
بدلاً من حسابك الشخصي أو Workload Identity لـ Pod.
إذا كنت تستخدم حساب الخدمة الافتراضي عند إنشاء تجمع عقدة GKE ، أو كنت تستخدم حساب خدمة مخصص ، ولكنك لم تمنح إذن القراءة لـ Artifact Registry ، فأبلغ عن ذلك
PermissionDenied
.
التفتيش والإصلاح:
الحصول على حساب الخدمة الذي تستخدمه مجموعة عقدة الكتلة: Bashgcloud container node-pools describe <node-pool-name> \-cluster <cluster-name> \-zone <zone> \-format = "value(config.service Account)"
امنح حق قراءة التسجيل الحرفي لحساب الخدمة (قارئ التسجيل الحرفي/الإرسالي/التسجيل الحرفي. reader):Bashgcloud projects add-iam-policy-binding <PROJECT-ID> \-member = "مكتب المحاسبة:<NODE-SERVICE-ACCOUNT-EMAIL>" \-role = "دليل".
* (ملاحظة: إذا كانت مجموعة GKE الخاصة بك في المشروع A ، مستودع المرآة في المشروع B ، يرجى التأكد من أن يكون في المشروع B (مستودع
المشروع) *
قم بمنح سلطة Reader Registry Artifact إلى حساب خدمة العقدة للمشروع A!)
3. Private GKE Networking Issue (Private GKE Networking Issue)
إذا كنت تستخدم
مجموعة GKE الخاصة (Private Cluster)
، العقدة ليس لديها عنوان IP العام. إذا لم يتم تكوين المجموعة مع مخرج الشبكة الخارجية ولم يتم فتح الوصول إلى Google الخاص ، فلن تتمكن العقدة من الاتصال
*. Pkg.de v
تحميل مرآة.
التفتيش والإصلاح:
إذا كنت تقوم بسحب صورة Google الداخلية: تحتاج إلى فتح Private Google Access (وصول Google الخاص) على الشبكة الفرعية ، بحيث يمكن الوصول إلى حركة المرور مباشرة إلى GAR من خلال شبكة Google الداخلية دون المرور عبر الشبكة العامة. Bashgcloud compute subnetworks update <SUBNET-NAME> \-region <REGION> \-enable-private-google-الوصول
إذا تم سحب صورة مرآة خارجية (مثل Docker Hub و GitHub Packages): يجب أن تستخدم العقدة الخاصة Cloud NAT للوصول إلى الشبكة الخارجية. تأكد من تكوين بوابة Cloud NAT الصحيحة في VPC و Region حيث توجد المجموعة.
4. سحب مستودعات الطرف الثالث الخاصة المفقودة imagePullSecrets
إذا تم تخزين صورة المرآة الخاصة بك في مستودع خاص تابع لجهة خارجية (مثل Harbor الذي تم بناؤه ذاتيًا ، و Docker Hub الخاص ، و GitLab Registry ، وما إلى ذلك) ، فلا يمكن لعقدة GKE استخدام المصادقة المضمنة في GCP.
التفتيش والإصلاح:
قم بإنشاء مفتاح Docker المقابل في K8s: bashkubectl create docker-registry-key \-docker-server =<YOUR-PRIVATE-REGISTRY> \-docker-username =<USERNAME> \-docker-password = <PASSWD-OR-TOKEN> \-Edocker <email =
اقتباس صريح في Deployment / Pod YAML secret:YAMLspec: imagePullSecr
Ets:-name: my-registry-key containers: - name: my-app image: your-registry.com/team/app:v1
5. مشكلة تجاوز الموارد أو حصة المشروع (تم تعليق الخدمة بسبب متأخرات الحساب)
في بعض الأحيان لا تكمن المشكلة في تكوين K8s نفسه ، ولكن في قاعدة البنية التحتية. إذا واجه مشروع GCP قيود حصص الموارد ، أو قفل الحصص ، أو الأكثر شيوعًا-
شحن حساب جوجل كلاود
سيؤدي الفشل في إكمال الرسوم في الوقت المناسب إلى متأخرات ، وستعلق GCP مؤقتًا بعض خدمات API أو تقيد (بما في ذلك عرض النطاق الترددي للتنزيل أو إمكانية الوصول إلى التخزين في سجل Artifact).
التفتيش والإصلاح:
انتقل إلى GCP Console لعرض صفحة Billing (التسوية) للتأكد من أن حساب التسوية في حالة طبيعية.
تأكد من إلغاء حظر قنوات إعادة شحن الحساب السحابي للشركة من Google ، وتجنب تخفيض تصنيف الخدمة الآلية بسبب انتهاء صلاحية بطاقة الائتمان أو حدود الميزانية ، مما يؤدي إلى سحب مرآة عبر الإنترنت للعمل الإضافي أو رفض الاتصال.
الخطوة الثالثة: التحقق السريع مع توصيات الوقاية
بعد الانتهاء من الإصلاح ، يمكنك إجبار Kubernetes على إعادة سحب التحقق من المرآة من خلال الأمر التالي:
باش
# السيناريو A: احذف قرد الخطأ واسمح لـ Deployment بإعادة البناء تلقائيًا
Kubectl delete pod <pod-name> -n <name>
# البرنامج B: إعادة التشغيل المباشر
Kubectl rollout restart deployment <deployment-name> -n <namespace>
توصيات أفضل الممارسات:
تجنب استخدام: علامة latest: استخدم رقم الإصدار الثابت أو Git Commit SHA كعلامة لمنع Kubelet من سحب الإصدار غير المتوقع بسبب آلية ذاكرة التخزين المؤقت.
قم بتشغيل ذاكرة التخزين المؤقت المرآة أو تدفق الصورة في بيئة الإنتاج: بالنسبة للمرايا الكبيرة ، يمكنك تمكين وظيفة Image Streaming على GKE ، مما يقلل بشكل كبير من وقت بدء تشغيل Pod وفترة انتظار تنزيل المرآة.
آلية CI/CD السليمة: قبل تحديث Manifest على خط التجميع ، قم أولاً بإضافة التحقق من وجود المرآة لتجنب نشر Image PullBackOff بسبب عدم دفع المرآة بنجاح من المصدر.
اتبع المنطق أعلاه للتحقيق خطوة بخطوة ، ويمكن تحديد موقع معظم أخطاء سحب مرآة GKE وحلها في غضون دقائق قليلة.
