<p>يجب أن يجعل kubeadm الخيار --node-ip متاحًا</p>

أواجه حاليًا مشكلات في إعداد مجموعة Kubernetes في DigitalOcean بسبب هذا. بشكل افتراضي ، سيقوم kubelet بربط وكشف / بث IP الخاص بالبوابة الافتراضية ، والتي تكون في هذه الحالات عنوان IP العام الذي يواجه حركة مرور الإنترنت. ثم عند الوصول إلى نقطة إعداد وظيفة إضافية لشبكة pod (مثل Weave) ، فإن الجحيم كله ينهار لأن عنوان IP الخاص بإعلان السيد هو عنوان IP للشبكة الداخلية ولكن العقد العاملة تحاول الكشف عن العنوان العام: /

الحل هو تحديث ملف الوحدة الذي تم إسقاطه تحت /etc/systemd/system/kubelet.service.d/10-kubeadm.conf لإضافة --node-ip=<private_worker_ip> ، وإعادة تحميل الوحدات وإعادة تشغيل kubelet لجعلها تعمل.

إذا كان بإمكان kubeadm القيام بذلك بشكل افتراضي عن طريق تمرير الخيار مثل nkratzke الذي اقترح أن يكون ذلك رائعًا!

أردت فقط أن أؤكد أن إضافة الخيار --node-ip=<private-worker-ip> إلى الإعدادات في ملف /etc/systemd/system/kubelet.service.d/10-kubeadm.conf لن يصلح هذه المشكلة للإعداد الذي شرحته من قبل. على الرغم من أن العقد تستمع إلى هذه الواجهة ، تواصل Kubernetes استخدام البوابة الافتراضية للتواصل بين العقد ، والتي في هذه الحالة هي عنوان IP العام.

انا لدى نفس المشكله. لقد جربت طريقتك ولم تنجح معي أيضًا. هل تمكنت من جعلها تعمل؟

agsergi كنت أحاول إعداد مجموعة k8s في DigitalOcean مع تمكين خيار الشبكة الخاصة ، مما قادني إلى هذه المشكلة. لقد أدى تعطيل هذه الميزة إلى تحقيق ذلك بالنسبة لي ولكني لست متأكدًا مما إذا كنت على نفس القارب.

أعتقد أن هذه المشكلة ستظل موجودة إذا كان لديك أكثر من بطاقتي NIC متصلتين بالجهاز.

رفاق،
لدي واجهتان على جهاز VM ، أحدهما مخصص لـ NAT والثاني إذا كان لمحول hostonly. بشكل افتراضي ، كان kubeadmin يأخذ عنوان IP الافتراضي للواجهة (NAT في حالتي) إذا كنت تريد استخدام واجهة أخرى ، فاستخدم:
$ sudo kubeadm init --apiserver-advertise-address =

وعملت معي.

luxas لماذا يتم

@ evocage لا يوجد عنوان خادم - إعلان - خادم =

شكرا جزيلا.

واجهت نفس المشكلة على Scaleway.

عندما قمت بتهيئة المعلم ، مررت --apiserver-advertise-address=<private_net_IP> ولكن عندما أرغب في إضافة عقدة ( kubeadm join --toke=<token> <master_private_IP>:6443 ) لن يبدأ kube-proxy و weave-net pods (خطأ في المزامنة pod)

ولكن عندما أقوم بإرفاق عنوان IP عام بالعقدة الخاصة بي وأعد تشغيلها ، يسير كل شيء على ما يرام: التفكير:

اي فكرة؟

نفس المشكلة عند محاولة إعداد kubernetes على مضيف VM باستخدام IP واحد حيث يمكن إعادة توجيه بعض المنافذ فقط إلى أجهزة VM. أي حل بديل لجعله يعمل؟

أردت فقط إجراء 1+. أحاول تشغيل مجموعة من Digitalocean VMs مع عنوان IP خاص عليها جميعًا ، ومع ذلك يستمر عنوان الواجهة العامة في شق طريقه إلى المجموعة بطريقة ما.

تمكنت من الحصول على عناوين IP خاصة تعمل من خلال تشغيل هذا على master:

kubeadm init --apiserver-advertise-address=<private-master-ip> init

إضافة --node-ip=<private-node-ip> إلى /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ، إعادة تحميل البرنامج الخفي ، إعادة تشغيل kubelet ، ثم تشغيل:

kubeadm join --token <token> <private-master-ip>:6443 --discovery-token-ca-cert-hash sha256:<hash>

mongrelion ما نوع الاتصال بين العقدة <-> الرئيسية التي لا تزال تستخدم الواجهات العامة؟ لم أتمكن من تكرار هذا ، لذا سأكون مهتمًا بمعرفة ما إذا كان kubernetes يتصرف بشكل غير متوقع.

هذا فعلها! كان الجمع بين --apiserver-advertise-address لضمان أن يبدأ المعلم في المكان الصحيح ، و --node-ip في تكوين kubelet كان المزيج السحري.

بناءً على هذا الطلب ، فإن وجود هذا الخيار --node-ip مباشرة في kubeadm حتى تتم تهيئة ملفات التكوين بشكل صحيح سيكون مفيدًا للمبتدئين الجاهلين مثلي الذين يحاولون تدوير المجموعات :)

شكرا لك jamiehannaford على هذا الملخص. هل نعتقد أننا يجب أن نوثق هذا بشكل أكثر وضوحًا؟

luxas نعم أعتقد أن وجود حالة الاستخدام هذه موثقة بشكل صريح سيكون مفيدًا

jamiehannaford إذا كنت تريد إضافة هذا أيضًا إلى تعديل المستندات لـ v1.9 ، فالرجاء إرسال فقرة إليّ لإضافتها إلى https://github.com/kubernetes/website/pull/6103

تضمين التغريدة منجز

أهلا،

أود أن أقدم بعض الملاحظات أيضًا. أحاول استخدام kubeadm لبناء كتلة عقدة واحدة آمنة.
أرغب في ربط جميع خدمات kubernetes بالمضيف المحلي ولكن هذا لا يعمل.

أنا أستخدم هذا الأمر ويتم إنشاء الكتلة:
kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=127.0.0.1 \ --apiserver-cert-extra-sans=127.0.0.1,staging.my-server.net
ومع ذلك ، يحتوي /etc/kubernetes/admin.conf والأصدقاء على عنوان IP العام للسيد.
server: https://75.xx.yy.zz:6443

سأحاول اتباع نهج --node ، لكن سأكون ممتنًا إذا كان بإمكانك مساعدتي في إيجاد حل لذلك.

حالة الاستخدام الخاصة بي:

لدي آلة سمين أرغب في استخدامها كبيئة انطلاق وربما كبيئة إنتاج للمشاريع الصغيرة حيث لا أهتم بـ HA. يمكنني استخدام SSH واستخدام kubectl للتحكم في الكتلة.

شكرا،

لقد واجهت نفس المشكلة تمامًا مثل @ Mosho1 هنا ونزلت إلى أسفلها.

أنا أستخدم DO و CoreOS ولكن هذا في الحقيقة لا يرتبط بأي منهما ويمكن أن يحدث على المزودين والتوزيعات الأخرى. كما أنها غير مرتبطة بشبكات DO الخاصة التي يتم تمكينها أو تعطيلها: لقد أعادت إظهار المشكلة في كلتا الحالتين.

ما يحدث هو أن kubelet كما تم إعداده بواسطة kubeadm يبحث في الواجهات ويقرر إحضار شبكته الفرعية الخاصة إلى هذا المزيج ، بغض النظر عن عناوين IP المعينة أو الواجهات المتاحة ، ويريد القيام بذلك على نفس الشيء الذي يعتبره "رئيسي" (أول واحد؟ WAN واحد؟ أنا لا أعرف). هذا ليس مرئيًا عبر ifconfig ولكن بسهولة عبر ip addr ، ويتم إعداد مسار أيضًا ، ولكن ليس هناك أي احتمال أن يطير عبر شبكة DO التي تربط العقد eth0 .

تحرير: بفضل klausenbusk ، يبدو أن kubelet يختار عنوان IP المرساة على افتراض أنه قد يكون مفيدًا عندما لا يكون كذلك. انظر الى التفاصيل بالاسفل.

الحل في الواقع هو إخبار kubelet ما هو عنوان IP الذي يجب استخدامه. يمكن أن يكون العام أو الخاص إذا كنت تستخدم الشبكة الخاصة الاختيارية.

إليك كيفية استخدامي لـ --node-ip . احترس ، هذا يفترض أن KUBELET_EXTRA_ARGS لم يتم تعيينه بالفعل في ملف الوحدة.

$ DROPLET_IP_ADDRESS=$(ip addr show dev eth0 | awk 'match($0,/inet (([0-9]|\.)+).* scope global eth0$/,a) { print a[1]; exit }')
$ echo $DROPLET_IP_ADDRESS  # check this, jus tin case
$ echo "Environment=\"KUBELET_EXTRA_ARGS=--node-ip=$DROPLET_IP_ADDRESS\"" >> /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
$ systemctl daemon-reload
$ systemctl restart kubelet

lloeki شكرا على الكتابة. هل تمانع في تحديث المستندات ، ربما هنا: https://github.com/kubernetes/website/blob/master/docs/setup/independent/troubleshooting-kubeadm.md

لذلك يختار WAN one (eth0) ، ويرى (أو يتجاهل) عنوان IP عام ، ويقرر إضافة شبكة فرعية خاصة ثانية (مثل 10.19.0.0/255 في حالتي) ، ربما تحت الاعتقاد بأن جميع العقد eth0 هي على نفس الرابط.

هل انت متاكد من ذلك؟ يمكن أن يكون مجرد عنوان IP (قارن بـ curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address )

klausenbusk أنت --node-ip .

لذلك يبدو أن kubelet يختار هذا الشخص على افتراض أنه يمكن أن يكون مفيدًا عندما لا يكون كذلك؟

$ curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
10.19.0.39
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet yyy.yyy.yyy.yyy/20 brd yyy.yyy.yyy.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.19.0.39/16 brd 10.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever

هل تمانع في تحديث المستندات

jamiehannaford يبدو أنني أستطيع فعل ذلك :)

/ تعيين liztio

لقد ألقيت نظرة على هذا وأعتقد أن الإجماع حتى إذا طلب المستخدمون إضافة الوسيطة --node-ip إلى kubeadm ، هو أن تعديل تكوين kubelet واستخدام المعلمات مثل jamiehannaford المقترح هنا هو النهج الموصى به:
https://github.com/kubernetes/kubeadm/issues/203#issuecomment -335416377

(أو ربما يتم إلحاقه بـ $ KUBELET_EXTRA_ARGS قبل إعادة تشغيل kublet).

نظرًا لقرار الابتعاد عن إضافة حجج cmd إضافية إلى kubeadm ، أعتقد أنه قد يكون من الآمن إغلاق هذه المشكلة ... ما لم تكن هناك خطط لتمكين ذلك باستخدام خيارات kubeadm MasterConfig (بطريقة ما ؟؟ ... لأننا نعتمد على يقوم المستخدم بتحرير تكوين kubelet ويستريح يدويًا على التغييرات).

تحرير: أو ربما باستخدام تكوين kubelet الديناميكي إذا كان ذلك ممكنًا؟

يبدو أن جميع الاقتراحات الخاصة بتغييرات الوثائق أعلاه قد تم دمجها.

تضمين التغريدة

أنا بخير مع إغلاق هذا.

فقط لاحظ أنه في Kubernetes 1.11 إعداد KUBELET_EXTRA_ARGS في /etc/systemd/system/kubelet.service.d/20-custom.conf لم يعد يعمل: يجب ضبطه في / etc / sysconfig / kubelet (بناء جملة مختلف قليلاً من هذه الملفات).

stepin لقد قمت للتو بإعداد مجموعة 1.11 باستخدام kubeadm وحصلت على هذا بعد ذلك cat: /etc/sysconfig/kubelet: No such file or directory

/etc/systemd/system/kubelet.service.d/20-custom.conf أيضًا غير موجود لذا لست متأكدًا مما كنت تفعله هناك.

إذا كان ما قلته صحيحًا ، فيبدو أن لعبة config hot potato مستمرة.

تمكنت من العثور على موقع آخر لتكوين kubelet هنا: /etc/default/kubelet

بالنسبة للمسافرين المستقبليين (للأسبوع القادم على الأقل) ، يبدو أن هذا يعمل:

PRIVATE_IP=10.99.0.0
echo "KUBELET_EXTRA_ARGS=--node-ip=$PRIVATE_IP" > /etc/default/kubelet
systemctl daemon-reload
systemctl restart kubelet

من الواضح أنك ستحتاج إلى تغيير عنوان IP إلى ما هو ملكك على تلك العقدة المعينة.

إخلاء المسؤولية: أنا فقط أتحقق من Kubernetes لذلك لا أضمن أن هذا لا يفعل شيئًا فظيعًا. على الرغم من أن /etc/systemd/system/kubelet.service.d/10-kubeadm.conf يشير إلى /etc/default/kubelet ، لذلك أعتقد أن هذا هو الشيء الصحيح الذي يجب فعله.

jazoom - شكرًا لتعليقك ، لقد قادني أخيرًا إلى قراءة ملف وحدة systemd عن كثب. ظننت أنني كنت مجنونًا لأنني استطعت إحضار نفس التكوين في 1.10 ، وعمل كل شيء ... قم بإحضار التكوين في 1.11 ولم يكن الإعداد المخصص --node-ip كنت أقوم به ينطبق على الإطلاق. أدى التبديل إلى إضافة الوسائط الإضافية في /etc/default/kubelet إصلاح المشكلة بالنسبة لي.

geerlingguy على الرحب والسعة.

على الأقل لم تكن حالة "أنها تعمل في كل ثانية أحضر فيها مجموعة 1.11". ستجعلك تلك المشكلات التي لا يمكن إعادة إنتاجها تشعر بالجنون.

ركضت للتو في هذا في "Kubeadm 1.13". تم إصلاحه باستخدام ما يلي:

1) أضف "--node-ip" إلى "/var/lib/kubelet/kubeadm-flags.env":

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

2) أعد تشغيل Kubelet:

systemctl daemon-reload && systemctl restart kubelet

^ إذا كان أي شخص على علم بكيفية جعل ذلك يعمل مع عناوين IP العائمة التي لا تظهر على NIC ، فيرجى إبلاغي بذلك. ناجح على خلاف ذلك.

أهلا،

يرجى تجربة هذا https://wiki.hetzner.de/index.php/Cloud_floating_IP_persistent/en .
إنه يعمل مع Hetzner لكنني أعتقد أنه عام.
يوجين

عمل هذا على أكمل وجه. شكرا لك.

واجهت للتو هذه المشكلة في "Kubeadm 1.13". تم إصلاح المشكلة بالطرق التالية:

1. أضف "--node-ip" في "/var/lib/kubelet/kubeadm-flags.env":

[root@Node-18121 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS=--cgroup-driver=systemd --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.1 --node-ip=10.10.10.1

1. أعد تشغيل Kubelet:

systemctl daemon-reload && systemctl restart kubelet

شكرا جزيلا ، تتحرك