Kubeadm: لا يمكن ترقية kube-apiserver من التسجيل الخاص.

تم إنشاؤها على ٢ أكتوبر ٢٠١٧  ·  4تعليقات  ·  مصدر: kubernetes/kubeadm

لقد راجعت هذه المشكلة ، رقم 71 ، يبدو أنه لا يمكنني إضافة بيانات اعتماد إذا لم يكن kube-apiserver قيد التشغيل ، ولكن بعد سحب الصورة الخاصة يدويًا ، وإعادة تشغيل kubelet ، ما زلت أتلقى الخطأ.

PullImage "docker.kesci.com:5000/kube-apiserver:latest" from image service failed: rpc error: code = Unknown desc = Error response from daemon: Get https://**my.private.image.registry**/v2/kube-apiserver/manifests/latest: no basic auth credentials

إصدارات

إصدار kubeadm (استخدم kubeadm version ):

البيئة :

  • إصدار Kubernetes (استخدم kubectl version ):
    Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.5", GitCommit:"17d7182a7ccbb167074be7a87f0a68bd00d58d97", GitTreeState:"clean", BuildDate:"2017-08-31T09:14:02Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
  • مزود السحابة أو تكوين الأجهزة :
    Aws
  • نظام التشغيل (على سبيل المثال من / etc / os-release):
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
  • Kernel (على سبيل المثال uname -a ):
    Linux ip-172-31-28-254 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
  • آخرون :

ماذا حدث؟

استبدل صورة تكوين /etc/kubernetes/manifests/kube-apiserver.yaml يدويًا ، وتلقى kubelet خطأ container start failed: ErrImagePull: rpc error: code = Unknown desc = Error response from daemon: Get https://my.private.image.registry/v2/kube-apiserver/manifests/latest: no basic auth credentials , يبدو أنه لم يتم تكوين بيانات الاعتماد ، لذلك أقوم يدويًا بسحب الصورة
docker pull my.private.image.registry/kube-apiserver:latest و run service kubelet restart ، لا يزال يظهر هذا الخطأ.

ماذا توقعت أن يحدث؟

يدعم kubelet تكوين بيانات الاعتماد يدويًا أو يمكنه التعرف على الصور المحلية التي تم سحبها.

كيف يمكن إعادة إنتاجها (بأقل قدر ممكن من الدقة والدقة)؟

استبدل صورة /etc/kubernetes/manifests/kube-apiserver.yaml بصورة تسجيل خاصة.

kinsupport

التعليق الأكثر فائدة

ggaaooppeenngg يجب أن تجرب هذا:

  1. قبل سحب الصور مع عامل سحب الرصيف
  2. استخدم kubeadm init --config yourconfigfile ، مع الحرص على تعيين الخيار imageRepository في ملف التكوين

يرجى ملاحظة ما يلي:

  • يجب عليك سحب الصور مسبقًا ، لأنه لا توجد طريقة لإنشاء أسرار imagePullSecrets قبل وجود المجموعة 😄
  • الإجراء أعلاه يعمل في kubeadm v1.8 ؛ لا أتذكر ما إذا كان هذا مدعومًا أيضًا في الإصدارات السابقة: confused:
  • يقوم هذا الإجراء بتعيين الريبو الخاص بك في ملفات yaml دون الحاجة إلى تغييرات يدوية 👍 ؛ ومع ذلك ، من المتوقع أن تتبع جميع الصور المحلية اصطلاح تسمية قياسيًا (على سبيل المثال ، بنية اسم المكون: الإصدار)

لمزيد من المعلومات يمكنك إلقاء نظرة على https://kubernetes.io/docs/admin/kubeadm/

ال 4 كومينتر

الحل الخاص بي: عامل الإرساء يسحب الصورة ويضبط imagePullPolicy على "أبدًا" ، ثم أعد تشغيل kubelet.

كيف تتوقع أن يتصرف kubeadm في هذه الحالة؟ نحن نستخدم الصور الرسمية ولا ندعم عمليات إعادة الشراء المخصصة. ما هي حالة استخدامك لاستخدام صورة مخصصة؟

ggaaooppeenngg يجب أن تجرب هذا:

  1. قبل سحب الصور مع عامل سحب الرصيف
  2. استخدم kubeadm init --config yourconfigfile ، مع الحرص على تعيين الخيار imageRepository في ملف التكوين

يرجى ملاحظة ما يلي:

  • يجب عليك سحب الصور مسبقًا ، لأنه لا توجد طريقة لإنشاء أسرار imagePullSecrets قبل وجود المجموعة 😄
  • الإجراء أعلاه يعمل في kubeadm v1.8 ؛ لا أتذكر ما إذا كان هذا مدعومًا أيضًا في الإصدارات السابقة: confused:
  • يقوم هذا الإجراء بتعيين الريبو الخاص بك في ملفات yaml دون الحاجة إلى تغييرات يدوية 👍 ؛ ومع ذلك ، من المتوقع أن تتبع جميع الصور المحلية اصطلاح تسمية قياسيًا (على سبيل المثال ، بنية اسم المكون: الإصدار)

لمزيد من المعلومات يمكنك إلقاء نظرة على https://kubernetes.io/docs/admin/kubeadm/

jamiehannaford أريد أن أحفر بعض مشكلات الأداء ، وأضيف بعض سجلات التتبع ، حتى أتمكن من إجراء فحص.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات