إصدار kubeadm : 1.10.2
البيئة :
منذ شهرين ، أنشأت مجموعة kubernetes 1.9.3 HA باستخدام kubeadm 1.9.3
، باتباع التوثيق "الرسمي" https://kubernetes.io/docs/setup/independent/high-availability/ ، إعداد تستضيف كتلة HA etcd
على العقد الرئيسية باستخدام القرون الثابتة
أردت ترقية مجموعتي إلى k8s 1.10.2
باستخدام أحدث kubeadm
؛ بعد تحديث kubeadm
، عند تشغيل kubeadm upgrade plan
، حصلت على الخطأ التالي:
[root@shared-cob-01 tmp]# kubeadm upgrade plan
[preflight] Running pre-flight checks.
[upgrade] Making sure the cluster is healthy:
[upgrade/config] Making sure the configuration is correct:
[upgrade/config] Reading configuration from the cluster...
[upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[upgrade/plan] computing upgrade possibilities
[upgrade] Fetching available versions to upgrade to
[upgrade/versions] Cluster version: v1.9.3
[upgrade/versions] kubeadm version: v1.10.2
[upgrade/versions] Latest stable version: v1.10.2
[upgrade/versions] FATAL: context deadline exceeded
لقد حققت في المشكلة ووجدت السببين الأساسيين:
kubeadm
لا يحدد مجموعة etcd
أنها تمكين TLSيرشد الدليل إلى استخدام الأمر التالي في الكبسولة الثابتة etcd
- etcd --name <name> \
- --data-dir /var/lib/etcd \
- --listen-client-urls http://localhost:2379 \
- --advertise-client-urls http://localhost:2379 \
- --listen-peer-urls http://localhost:2380 \
- --initial-advertise-peer-urls http://localhost:2380 \
- --cert-file=/certs/server.pem \
- --key-file=/certs/server-key.pem \
- --client-cert-auth \
- --trusted-ca-file=/certs/ca.pem \
- --peer-cert-file=/certs/peer.pem \
- --peer-key-file=/certs/peer-key.pem \
- --peer-client-cert-auth \
- --peer-trusted-ca-file=/certs/ca.pem \
- --initial-cluster etcd0=https://<etcd0-ip-address>:2380,etcd1=https://<etcd1-ip-address>:2380,etcd2=https://<etcd2-ip-address>:2380 \
- --initial-cluster-token my-etcd-token \
- --initial-cluster-state new
شيكات kubeadm >= 1.10
(هنا: https://github.com/kubernetes/kubernetes/blob/release-1.10/cmd/kubeadm/app/util/etcd/etcd.go#L56) إذا كان etcd
قام
"--cert-file=",
"--key-file=",
"--trusted-ca-file=",
"--client-cert-auth=",
"--peer-cert-file=",
"--peer-key-file=",
"--peer-trusted-ca-file=",
"--peer-client-cert-auth=",
ولكن كما أعلام --client-cert-auth
و --peer-client-cert-auth
تستخدم في التعليمات دون أي معلمة (وهي القيم المنطقية) kubeadm
لم تعترف etcd
الكتلة لديك TLS ممكن.
الإصلاح الشخصي:
لقد قمت بتحديث الأمر الخاص بي etcd
ثابت pod لاستخدام - --client-cert-auth=true
و - --peer-client-cert-auth=true
إصلاح عام:
قم بتحديث التعليمات لاستخدام --client-cert-auth=true
و --peer-client-cert-auth=true
وتخفيف الشيكات kubeadm باستخدام "--peer-cert-file"
و "--peer-key-file"
(بدون تساوي)
kubeadm
الشهادات الصحيحةبعد تحديد النقطة 1 ، استمرت المشكلة لأن kubeadm
لم يكن يستخدم الشهادات الصحيحة.
باتباع دليل kubeadm HA ، في الواقع ، الشهادات التي تم إنشاؤها هي ca.pem
ca-key.pem
peer.pem
peer-key.pem
client.pem
client-key.pem
لكن أحدث kubeadm
يتوقع ca.crt
ca.key``peer.crt
peer.key``healthcheck-client.crt
healthcheck-client.key
بدلاً من ذلك.
Yhe kubeadm-config
MasterConfiguration يتم تجاهل مفاتيح etcd.caFile
و etcd.certFile
و etcd.keyFile
.
الإصلاح الشخصي:
تمت إعادة تسمية الشهادة .pem
لمكافئها .crt
و .key
وتم تحديث تكوين البود الثابت etcd
لاستخدامها.
إصلاح عام:
استخدم قيم kubeadm-config
data.caFile
، data.certFile
و data.keyFile
، استنتج الشهادات الصحيحة من تعريف pod ثابت etcd (مسار pod + مجلدات hostPath) و / أو أنشئ شهادة عميل مؤقتة جديدة لاستخدامها أثناء الترقية.
يجب أن يتم تنفيذ خطة الترقية بشكل صحيح
أنشئ مجموعة k8s ha باستخدام kubeadm 1.9.3
باتباع https://kubernetes.io/docs/setup/independent/high-availability/ وحاول تحديثها إلى k8s >= 1.10
باستخدام أحدث kubeadm
يبدو أن هذه المشكلة قد تم إصلاحها في kubeadm 1.10.3
، على الرغم من أنها لن تقوم تلقائيًا بتحديث الكبسولة الثابتة etcd
لأنها تتعرف عليها على أنها "خارجية"
أنا أستخدم kubeadm 1.10.3
ولدي نفس المشكلات. مجموعتي هي 1.10.2 مع خارجي آمن وما إلى ذلك
brokenmass هل قيم
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/etcd/healthcheck-client.crt
keyFile: /etc/kubernetes/pki/etcd/healthcheck-client.key
detiber هل يمكنك المساعدة من فضلك؟
تضمين التغريدة
في حالتي ، تبدو القيم كما يلي:
caFile: /etc/kubernetes/pki/etcd/ca.pem
certFile: /etc/kubernetes/pki/etcd/client.pem
keyFile: /etc/kubernetes/pki/etcd/client-key.pem
1.10.3 يعمل بشكل صحيح
brokenmass لذا مع kubeadm 1.10.3 يعمل كل شيء دون الحاجة إلى إصلاحات شخصية. في هذه الحالة أنا مرتبك قليلاً. لدي kubeadm 1.10.3 ولكن نفس رسالة الخطأ التي ذكرتها في تقرير الخطأ هذا. سوف أتحقق مرة أخرى من التكوين الخاص بي ، فقد أرتكب بعض الأخطاء في مكان آخر
أضف هنا (أو انضم إلى kubernetes slack وأرسل لي رسالة مباشرة) kubeadm-config ، وما إلى ذلك البودات الثابتة yml والإخراج الكامل kubeadm upgrade plan
اعتذاري ، أنا الآن أرى هذا للتو. قامchuckha بالعمل الأصلي لمستندات HA وغير ذلك من المستندات الثابتة ، وسأعمل معه خلال اليومين المقبلين لمعرفة ما إذا كان بإمكاننا المساعدة في تقويم ترقيات HA.
detiber شكرا لك. تعمل خطة الترقية أخيرًا. لكني أواجه بعض مشكلات ظروف السباق عند محاولة ترقية الكتلة. في بعض الأحيان تعمل في بعض الأحيان لدي نفس الخطأ مثل kubernetes / kubeadm / قضايا / 850 تشغيل kubeadm في حالة السباق عند محاولة إعادة تشغيل جراب على عقدة واحدة.
واجهت بعض الصعوبات في الحصول على إعداد اختبار البيئة لهذا اليوم وينفد الوقت قبل أن تبدأ عطلة نهاية الأسبوع. سأنتقل مرة أخرى هذا في وقت مبكر من الأسبوع المقبل.
/ إسنادchuckhadetiber
chuckhadetiberstealthybox أي تحديث على ذلك؟
لذا لم تكن ترقية 1.9-> 1.10 HA مسارًا مدعومًا أو تم فحصه.
نحن نعمل حاليًا على تحديث مستندات الصيانة الخاصة بنا لـ 1.11-> 1.12 والتي نخطط للاستمرار في المضي قدمًا بها.