/ تعيين liztio

انظر # 598. من الواضح وجود خطأ ، وليس طلب ميزة ، بناءً على تسجيل الإخراج بواسطة kubeadm.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة التي لا معنى لها

/ تعيين rdodev

هل يمكنك التحقق من أن هذا لا يزال موجودًا لـ 1.12 وتعيين 1.13 معلمًا إذا كان بإمكانك إعادة عرضه نظرًا لجميع عمليات الخلط

/ نوع الخطأ

598 لديه خطوات repro سهلة

الالتفاف حول هذا أخيرا.

/ دورة الحياة نشطة

timothysc لم يكن قادرًا على التكرار في 1.12

root@ip-10-0-0-43:~#  kubeadm join 10.0.0.106:6000 --token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256:d993ceed705830e8a10fcf2cb29d7c2030217039c6ebafcfb2766dceb45ed885
[preflight] running pre-flight checks
    [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_rr ip_vs_wrr ip_vs_sh ip_vs] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.0.0.106:6000"
[discovery] Created cluster-info discovery client, requesting info from "https://10.0.0.106:6000"
[discovery] Requesting info from "https://10.0.0.106:6000" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.0.0.106:6000"
[discovery] Successfully established connection with API Server "10.0.0.106:6000"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "ip-10-0-0-43" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

قم بتشغيل 'kubectl get nodes' على المفتاح الرئيسي لرؤية هذه العقدة تنضم إلى الكتلة.

root@ip-10-0-0-106:~# kubectl get nodes
NAME            STATUS     ROLES    AGE 
ip-10-0-0-106   NotReady   master   3m37s 
ip-10-0-0-43    NotReady   <none>   86s

rdodev لقد 10.0.0.106:6000 ؟

jethrogb قواعد جدار الحماية. في خطوات repro التي ربطتها ، يتم فرضهم عبر iptables.

تضمين التغريدة
""
root @ ip-10-0-0-43 : ~ # kubeadm انضم 10.0.0.106:6443 - Token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256: d993ceed705830e8a10fcf2cb29d7c2030217039c6ebcefcfcf
[الاختبار المبدئي] إجراء فحوصات ما قبل الرحلة
[اكتشاف] محاولة الاتصال بخادم API "10.0.0.106:6443"
[اكتشاف] تم إنشاء عميل اكتشاف معلومات الكتلة ، لطلب معلومات من " https://10.0.0.106 : 6443"
[اكتشاف] فشل في طلب معلومات المجموعة ، ستحاول مرة أخرى: [احصل على https://10.0.0.106 : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info: dial tcp 10.0.0.106:6443: connect : الاتصال مرفوض]
[اكتشاف] فشل في طلب معلومات المجموعة ، ستحاول مرة أخرى: [احصل على https://10.0.0.106 : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info: dial tcp 10.0.0.106:6443: connect : الاتصال مرفوض]
^ ج
root @ ip-10-0-0-43 : ~ # kubeadm انضم 10.0.0.106:6000 - Token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256: d993ceed705830e8a10fcf2cb29d7c2030217039c6ebafcefb2788
[الاختبار المبدئي] إجراء فحوصات ما قبل الرحلة
[اكتشاف] محاولة الاتصال بخادم API "10.0.0.106:6000"
[اكتشاف] تم إنشاء عميل اكتشاف معلومات الكتلة ، لطلب معلومات من " https://10.0.0.106 : 6000"
[اكتشاف] طلب معلومات من " https://10.0.0.106 : 6000" مرة أخرى للتحقق من صحة TLS مقابل المفتاح العام المثبت
[اكتشاف] توقيع معلومات الكتلة ومحتوياتها صالحة ويتم التحقق من صحة شهادة TLS مقابل الجذور المثبتة ، وستستخدم خادم API "10.0.0.106:6000"
[اكتشاف] الاتصال بنجاح بخادم API "10.0.0.106:6000"
[kubelet] تنزيل تكوين kubelet من ConfigMap "kubelet-config-1.12" في مساحة اسم نظام kube
[kubelet] كتابة تكوين kubelet في ملف "/var/lib/kubelet/config.yaml"
[kubelet] كتابة ملف بيئة kubelet مع إشارات إلى الملف "/var/lib/kubelet/kubeadm-flags.env"
[الاختبار المبدئي] تفعيل خدمة kubelet
[tlsbootstrap] في انتظار kubelet لأداء TLS Bootstrap ...
[patchnode] تحميل معلومات CRI Socket "/var/run/dockershim.sock" إلى كائن Node API "ip-10-0-0-43" كتعليق توضيحي

انضمت هذه العقدة إلى الكتلة: ""

testuser<strong i="5">@ali0</strong>:~$ sudo kubeadm join 10.198.0.221:6443 --token cykhjx.3kabrvhgdkwohqz5 --discovery-token-ca-cert-hash sha256:c2a5e209423b6dd23fe865d0de7a62e42a3638ae40b243885545e4b5152564db --ignore-preflight-errors=SystemVerification
[preflight] running pre-flight checks
    [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{} ip_vs:{} ip_vs_rr:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.198.0.221:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.198.0.221:6443"
[discovery] Failed to request cluster info, will try again: [Get https://10.198.0.221:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.198.0.221:6443: connect: connection refused]
^C
testuser<strong i="6">@ali0</strong>:~$ sudo kubeadm join 10.198.0.221:6000 --token cykhjx.3kabrvhgdkwohqz5 --discovery-token-ca-cert-hash sha256:c2a5e209423b6dd23fe865d0de7a62e42a3638ae40b243885545e4b5152564db --ignore-preflight-errors=SystemVerification
[preflight] running pre-flight checks
    [WARNING RequiredIPVSKernelModulesAvailable]: the IPVS proxier will not be used, because the following required kernel modules are not loaded: [ip_vs_sh ip_vs_rr ip_vs_wrr] or no builtin kernel ipvs support: map[ip_vs:{} ip_vs_rr:{} ip_vs_wrr:{} ip_vs_sh:{} nf_conntrack_ipv4:{}]
you can solve this problem with following methods:
 1. Run 'modprobe -- ' to load missing kernel modules;
2. Provide the missing builtin kernel ipvs support

[discovery] Trying to connect to API Server "10.198.0.221:6000"
[discovery] Created cluster-info discovery client, requesting info from "https://10.198.0.221:6000"
[discovery] Requesting info from "https://10.198.0.221:6000" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.198.0.221:6000"
[discovery] Successfully established connection with API Server "10.198.0.221:6000"
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.12" ConfigMap in the kube-system namespace
Get https://10.198.0.221:6443/api/v1/namespaces/kube-system/configmaps/kubelet-config-1.12: dial tcp 10.198.0.221:6443: connect: connection refused

على السيد:

$ sudo KUBECONFIG=/etc/kubernetes/admin.conf kubectl get cm -n kube-public cluster-info -oyaml
apiVersion: v1
data:
  jws-kubeconfig-cykhjx: eyJhbGciOiJIUzI1NiIsImtpZCI6ImN5a2hqeCJ9..BiYLnM2uq2lehUOez8n0tBuMqkErikP0ULsGzyAf_go
  kubeconfig: |
    apiVersion: v1
    clusters:
    - cluster:
        certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRFNE1UQXhOakl6TVRNME5sb1hEVEk0TVRBeE16SXpNVE0wTmxvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTXNPCkN3OVpVazZJSTVBTjJSUVVyNmRlM1dpMmhOM2hUVSt5aEhCZVMrU0ttQUFPVkp0SmxSTHMwa0c0eXBSb3pENXIKQUphOVRaSi9XOFhLTWdIOUR3ckdHWC9OUzRVRzNoNXdyME5xMlBxeVVqMGZETUNBR2d2MGc3NlNGaTlCWGcrcwoyaEFmOEl5UFlOZ2F1WXFvMUttdjdleXVHUmp2Z2JnU1J2WVIwZWVWYkhxWTIvdlA3T2RBeXRBcytKcGFTS28zCmpVZTR3dGtEcTYralo4ZnlnUS9EbkkwY0pRK1pMaUVIS0d0T2JscnRNWlRxS0RsTXVQd0Y4TE4yQ1kyZUh1WUgKaTM3cUgxMHp1SmlQZXBmOXdVdzc1QkR3eUNlVTVTbUJWUFo0b2xJT3c3ZW5JdDhoNGVpWTlOSklDbHdPNUhDWApaWG0xYmp6L0FKdEhoejg5QXFVQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFBSzlGRkg5eDB0RXhaTGREWjkzQm4walYzTnEKRWl5VzBmUTVpOHBBdlBVV3dMUVd1dkpuM1BLSUtTcjlpZGdwSUthUk1FKzMyRGRXQzVvZDIyakdBQ1REdjBjdAoxbFBSM3RBSTAwQnY2bS9BM09NQVRqY1JKd1hhL0ZHMDdRMU1sbkxibGhXMTlqaVMxQU9ycjRGZ2l1Z3VJQy9uCmd0UWZ3ZHJqTEhZSDY1KzJPRGtnWldNVjBqbjdpZlNMdnlpamJjRUttVXpSZm44T0hmYldWNXRMd2dRN295dHYKRE5tWHdkRkc3WFh3MVZVZjJKQkhDVGJHNndVU1diVFRPbzB1NnJLazJQakZoKzU5QVl4R2I1Ynp4N2thTW8xZwpYZktrUVVWSVcxaGZhelpSUHYzbWEzTmNsSis0R3VIMGc2OThvaEpHZGFkVHpXNmx2WnhoUW9NKzgycz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
        server: https://10.198.0.221:6443
      name: ""
    contexts: []
    current-context: ""
    kind: Config
    preferences: {}
    users: []
kind: ConfigMap
metadata:
  creationTimestamp: 2018-10-16T23:14:15Z
  name: cluster-info
  namespace: kube-public
  resourceVersion: "288"
  selfLink: /api/v1/namespaces/kube-public/configmaps/cluster-info
  uid: 3318106a-d199-11e8-b21c-54e1ad024614

jethrogb لا أعرف ماذا أقول لك. هذا هو تثبيت النعناع الطازج على الأشعة تحت الحمراء الطازجة.

root@ip-10-0-0-106:~# KUBECONFIG=/etc/kubernetes/admin.conf kubectl get cm -n kube-public cluster-info -oyaml apiVersion: v1 data: jws-kubeconfig-nwoa2x: eyJhbGciOiJIUzI1NiIsImtpZCI6Im53b2EyeCJ9..Be2U7ch__XzQ7em8vLEw8WAX6dQZeeLXaKVjh_a7YYA kubeconfig: | apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRFNE1UQXhOakl5TXpNME4xb1hEVEk0TVRBeE16SXlNek0wTjFvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBS2cxCjREbzhNbGtBSVZJM29xem9XK2trbUtmYjIyOGFLd1FzaXJsSTNMN2F1QnlrWC9JaEk0Tm9UYkZmMFpXbEdkRTYKUlVJNFdUZml1L2RqWXJqZG9YM2pZcGtxRERmTm5KNWxteGkzUStwbmVmM3hTWGtEbTNEOXFadWV0R0JXRTZzRwppNHIycUZxSmRnS21MMCswdnlXNmhkRUNUY1VwdFFTSzkzQmUxTzBMQnFRa1BLd0I0QjQ3Z3d6bGtSOFpaeTAyCm1zN1IvaE9lK0h5NEl2c0FQTmFQbHBpVFhQRyt5d2lLMkoxcXJBb0hzUDhNelNhdzN3OHB4bkJmc2V2NmErYWsKZm42b1p3QVJibi9yTDRNbHJaSlNpWC8vVEdvWTN5YlZYZ2lDWWVzMHNZQWR6T1Q3Sjl2VDBzYkRHK0Z2STFTYQpha05WUDJwdVNkdlhvcmtoc1JFQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFEbHJ5eklBRExwbUVEaURxdXhIdURPb2hmS0sKbVhMeVc4SkllYXFzT0k0cGd0aDJITDRJcG4vbm14VWF3bVh4SVB4YWc3N2I1cXZHcm5YTXN6SHd4WUp2SnJ0cgpJU2VyOVdvSmpuY0xVUnhkeTVBb3ZMWFZYZ3Y2S1dHVlFnMkt2dXpmNGMyL1ZVN09jNnpQMlRhNVJJaHgrcVU2CnBSeWN5Q2RJOUdaMUFpN0JSSTd1M3VtUjRiT3BhckpMaVRvZ2hsMGNDTlBDRDBhZ2dlNHBGemxSd0VLbEpINmMKMmgzcGFxZ0dQUU5YY1ZzcGdtbTgvQ2JvbFVta1d1RjZRTm1KemxuK2tUdlhkRTJiY3NkSUxyeU5Nb0J0L2paUQpoaVZxTnhBVWVuV1hEVk8wVnd5ZXRxY3crL2ZGb05jZndUL1FERXduQXpJd29SM3FHdUZXVk1aQllVZz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= server: https://10.0.0.106:6000 name: "" contexts: [] current-context: "" kind: Config preferences: {} users: [] kind: ConfigMap metadata: creationTimestamp: 2018-10-16T22:34:14Z name: cluster-info namespace: kube-public resourceVersion: "314" selfLink: /api/v1/namespaces/kube-public/configmaps/cluster-info uid: 9c0579c2-d193-11e8-b95c-026da1fc2270

rdodev أن cluster-info يبدو أنه تم تعديله من الإعداد الافتراضي. لن يؤدي استخدامه إلى إعادة إنتاج المشكلة. ما هو الأمر kubeadm init الخاص بك؟

kubeadm init --config kudeadm.yaml

root@ip-10-0-0-106:~# cat kudeadm.yaml
apiVersion: kubeadm.k8s.io/v1alpha3
kind: InitConfiguration
apiEndpoint:
  advertiseAddress: "10.0.0.106"
  bindPort: 6000

لذا فأنت تقوم بتهيئته باستخدام المنفذ 6000. لن يعمل ذلك لإعادة إظهار هذه المشكلة. تتعلق هذه المشكلة بعدم القدرة على الانضمام إلى مدير في عنوان / منفذ مختلف عما تم تكوينه في الأصل.

jethrogb ما هي حالة الاستخدام ، من فضلك. لماذا قد ترغب في الانضمام إلى طائرة تحكم على عنوان / منفذ مختلف عن الذي تم إحضار طائرة التحكم به عبر الإنترنت؟

هنا زوجان ...

1. تم تغيير عنوان IP الرئيسي.
2. اعتاد أن يكون سيدًا واحدًا ، ولكن تم تغييره الآن ليصبح HA. سوف ترغب الصلات المستقبلية في استخدام عنوان LB IP.
3. Master وراء NAT ، لا تستخدم جميع العقد نفس عنوان IP للاتصال بالسيد.

المشكلة الرئيسية هي أنك تخبر kubeadm join ما هو IP / المنفذ الذي يجب استخدامه ، وتقول إنها ستستخدم هذا العنوان ، لكنها لا تفعل ذلك!

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

في الحالة 1) تحتاج إلى إعادة إصدار الشهادات بأي طريقة أخرى للتغلب عليها. يتم إنشاء الشهادات لاسم المضيف وعنوان IP لمستوى التحكم عند التهيئة. يمكن التخفيف عن طريق إصدار شهادات لاسم DNS في init.

في الحالة 2) تتطلب عملية الانتقال من مستوى التحكم الفردي إلى HA إعادة إصدار جميع الشهادات ذات الصلة (خاصة لإضافة اسم LB dns)

لست متأكدًا من أن 3) تكوين مدعوم في الوقت الحالي.

لست متأكدًا من علاقة أي من هذا بالشهادات.

jethrogb أولاً ، حتى لو تمكنت من الاتصال (بطريقة ما) ، فسوف يفشل في عدم تطابق الشهادة كما هو موضح أعلاه.

ثانيًا ، إنه ليس خطأ حقًا لأن هذه ليست حالة استخدام مدعومة. AFICT ليس الأمر أنه كان يعمل مرة واحدة والآن ليس كذلك. إنها ليست ميزة موجودة ومعطلة.

timothysc لا أعتقد أن هذا العنصر و # 598 هما نفس / مغفلين. هذا (# 664) نعلم أنه يعمل لأن هذه هي الطريقة التي اختبرنا بها HA في 1.11 و 1.12

598 يستحق نظرة كطلب ميزة.

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

tallclair هاها كنت أعرف أن هذا سيحدث بالتأكيد E_TOO_MANY_TIMS_IN_K8S

jethrogb أولاً ، حتى لو تمكنت من الاتصال (بطريقة ما) ، فسوف يفشل في عدم تطابق الشهادة كما هو موضح أعلاه.

هذا لا علاقة له بالشهادات. حتى إذا كانت الشهادة التي قدمها خادم واجهة برمجة التطبيقات على العنوان الذي حدده المستخدم في kubeadm join ، فإن kubeadm join سيتصل بعد ذلك (على عكس مطالباته على الجهاز) بعنوان مختلف تمامًا لـ الخطوة الأخيرة في إجراء الانضمام.

ثانيًا ، إنه ليس خطأ حقًا لأن هذه ليست حالة استخدام مدعومة. AFICT ليس الأمر أنه كان يعمل مرة واحدة والآن ليس كذلك. إنها ليست ميزة موجودة ومعطلة.

لست متأكدًا من أنني أفهم ما تقوله. هل تقول أن الأداة التي ترسل رسائل إلى المستخدم بأنها ستفعل شيئًا ما بينما تفعل شيئًا آخر ليست خطأ؟

هذا لا علاقة له بالشهادات. حتى إذا كانت الشهادة التي قدمها خادم واجهة برمجة التطبيقات على العنوان الذي حدده المستخدم في kubeadm join ، فإن kubeadm join سيتصل بعد ذلك (على عكس مطالباته على الجهاز) بعنوان مختلف تمامًا لـ الخطوة الأخيرة في إجراء الانضمام.

لشرح سبب أهمية الشهادات ، دعنا نرى في حالة تغير IP لمستوى التحكم ، يحدث هذا:

root@ip-10-0-0-43:~# kubeadm join 34.220.204.xxx:6000 --token nwoa2x.cqar2ndxrtnw9arc 
[preflight] running pre-flight checks
[discovery] Trying to connect to API Server "34.220.204.xxx:6000"
[discovery] Created cluster-info discovery client, requesting info from "https://34.220.204.xxx:6000"
[discovery] Requesting info from "https://34.220.204.xxx:6000" again to validate TLS against the pinned public key
[discovery] Failed to request cluster info, will try again: [Get https://34.220.204.xxx:6000/api/v1/namespaces/kube-public/configmaps/cluster-info: x509: certificate is valid for 10.96.0.1, 10.0.0.106, not 34.220.204.xxx]

ينطبق الشيء نفسه على الحالة 2) إذا كنت تنتقل من مستوى تحكم واحد إلى HA. مجرد محاولة الإشارة إلى حالات الاستخدام التي ذكرتها أعلاه غير مدعومة من قبل kubeadm بدون شهادات إعادة إنشاء / swizzling في عقد مستوى التحكم. لذا فإن النطاق هنا هو فقط إعادة توجيه المنفذ.

لست متأكدًا من أنني أفهم ما تقوله. هل تقول أن الأداة التي ترسل رسائل إلى المستخدم بأنها ستفعل شيئًا ما بينما تفعل شيئًا آخر ليست خطأ؟

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

jethrogb لذا إذا قرأت هذا بشكل صحيح ، فقد قمت بتغيير ip: port بعد البادئ الأولي ، لكن الصلة لا تستخدم تجاوز سطر الأوامر ، إنها تستخدم ما تم تخزينه في kubeadm conf المخزن في الكتلة.

إنها حالة استخدام غريبة ، ولكن يبدو أن أحرف سطر cmd لا تتجاوز

نعم هذا دقيق

أيها الناس ، تفسير وسيطة سطر أوامر نقطة نهاية خادم واجهة برمجة التطبيقات أثناء الانضمام مضلل. في الحقيقة ، يتم استخدام هذا فقط أثناء التمهيد وليس لأي شيء آخر. ومع ذلك ، يتم استخدامه فقط أثناء الاكتشاف المستند إلى الرمز المميز. سيتم تجاهله (بدون تحذير واحد) مع الاكتشاف القائم على kubeconfig.

إذن هناك بالفعل مشكلتان هنا:

• نقطة نهاية خادم واجهة برمجة التطبيقات (API) للاكتشاف المستند إلى رمز التمهيد المميز لها تجربة مستخدم مضللة. أفضل رهان هو إهمال طريقة الوسيطة المستقلة لتوفير هذا وإدخال تبديل سطر أوامر وصفي لهذا (شيء مثل --discovery-token-apiserver ). تنتقل القيمة المقدمة بعد ذلك إلى joinCfg.Discovery.BootstrapToken.APIServerEndpoint .

• إذا رغب شخص ما في الكتابة فوق خادم API الفعلي على أساس كل عقدة ، فقد نضطر إلى تعديل التكوين (ربما نضيف حقلاً في NodeRegistrationOptions و / أو ربما تبديل سطر الأوامر؟).
  عدم الإصرار على ذلك لديه القدرة على كسر شيء ما في عمليات تشغيل kubeadm اللاحقة (مثل الترقية) لذلك قد نحتاج إلى تخزينه كتعليق توضيحي أيضًا.

• نقطة نهاية خادم واجهة برمجة التطبيقات (API) للاكتشاف المستند إلى رمز التمهيد المميز لها تجربة مستخدم مضللة. أفضل رهان هو إهمال طريقة الوسيطة المستقلة لتوفير هذا وإدخال تبديل سطر أوامر وصفي لهذا (شيء مثل --discovery-token-apiserver ). تنتقل القيمة المقدمة بعد ذلك إلى joinCfg.Discovery.BootstrapToken.APIServerEndpoint .

+1

• إذا رغب شخص ما في الكتابة فوق خادم API الفعلي على أساس كل عقدة ، فقد نضطر إلى تعديل التكوين (ربما نضيف حقلاً في NodeRegistrationOptions و / أو ربما تبديل سطر الأوامر؟).
  عدم الإصرار على ذلك لديه القدرة على كسر شيء ما في عمليات تشغيل kubeadm اللاحقة (مثل الترقية) لذلك قد نحتاج إلى تخزينه كتعليق توضيحي أيضًا.

IMO لا ينبغي لنا الكتابة فوق هذا في وقت الانضمام ، ربما يمكننا الحصول على أمر لتحديث نقطة نهاية خادم Api على cluster-info configmap

لم أكن واضحًا في الواقع. من خلال "تعديل التكوين" قصدت بالفعل إضافة حقل جديد في مكان ما بتنسيق التكوين التالي (ربما v1beta2 ) وربما يستمر في مكان ما في المجموعة (تعليق توضيحي للعقدة؟).
هذا يحتاج إلى بعض المناقشة ، وربما لن يحدث في الدورة الحالية (خاصة إذا واصلنا طريقة "إضافة خيار التكوين").

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

MustafaHosny اللهم امين

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

اختلف تيم وفابريزيو نوعًا ما.
ولكن أنا جميعًا +1 لتشغيل سياسة إيقاف GA بناءً على ذلك.

لا شيء سوى المتاعب.

@ neolit123 حتى لو لم ننتقل إلى مسار تبديل سطر الأوامر ، يمكننا فعلاً القيام بعمل أفضل في توثيق الوسيطة ، سواء في مساعدة الأداة المضمنة ( kubeadm join --help ) وفي مستندات موقع الويب.
أفترض أن المستندات الأفضل يمكنها (نوعًا ما) "إصلاح" المشكلة أيضًا وأنه يمكن القيام بذلك كجزء من مراحل الانضمام إلى كتابة المستندات.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

عند قراءة البطاقة بأكملها ، هناك العديد من المشكلات التي تكون إما سوء فهم ، أو مغطاة في مكان آخر أو غير موثقة.

الإصدار الأصلي:

يتحدث العدد الأصلي عن:

لكن تكوين kubelet و kube-proxy config قد يكونان أيضًا master0 ip أو master1 ip ، وهذا السلوك غير متوقع في HA.

لا أفهم هذه المشكلة ، لذا إذا كنت تشعر أن هذا لا يزال قابلاً للتطبيق حتى 1.13 (لم يعد 1.12 مدعومًا) ، فيرجى تسجيل بطاقة جديدة مع التفاصيل الكاملة والأمثلة.
هذه التذكرة انحرفت كثيرا.

حجة الانضمام المجهولة المضللة:

تم تعقب هذا هنا:
https://github.com/kubernetes/kubeadm/issues/1375

كنا نخطط للتبديل إلى وسيطة محددة للاكتشاف ، على سبيل المثال ، --discovery-endpoint ولكن تم إلغاء الاشتراك في هذه الفكرة وسيتعين عليك الاستمرار في استخدام kubeadm join addr:ip

الانتقال من مستوى تحكم واحد إلى HA:

تم تعقبه هنا:
https://github.com/kubernetes/kubeadm/issues/1664

العلاقات العامة لهذا الموضوع الذي تم دمجه للتو في مستنداتنا:
https://github.com/kubernetes/website/pull/15524

TL ؛ DR هو أنه إذا قمت بتعديل عنوان خادم api على عقدة مستوى التحكم بعد إنشاء الكتلة ، فأنت بحاجة إلى إعادة إنشاء الشهادات وتصحيح كائنات الكتلة. للانتقال بشكل أفضل إلى HA ، استخدم أسماء DNS.

إذا كان هناك شيء آخر قيد التشغيل ، فيرجى إنشاء تذاكر نظيفة مع التفاصيل الكاملة حتى يتمكن القائمون على الصيانة من استيعاب المشكلة.

تم دمج @ neolit123 # 598 في هذا ولكن ليس من الواضح بالنسبة لي ما إذا كان قد تم حلها.

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

تم دمج 598 في هذا

إذا كانت مشكلتك من # 598 لا تزال قابلة للتطبيق ، فالرجاء إعادة فتح المشكلة ولكن يرجى مراعاة أنه يجب إعادة إنتاجها باستخدام 1.13+ ، لأن الإصدارات القديمة خارج انحراف الدعم ولا يدعمها فريق kubeadm.

@ neolit123 لدي عقدة طائرة تحكم Kubernetes تعمل داخل حاوية Docker عبر https://github.com/kubernetes-sigs/kind. يتم عرض خادم api على مضيف Docker عبر إعادة توجيه المنفذ. أحتاج إلى إضافة عقدة عاملة في شبكة مضيف Docker إلى المجموعة.

من الواضح أن عنوان IP واسم المضيف للحاوية التي تقوم بتشغيل kubelet و Docker host حيث يتم الكشف عن واجهة برمجة التطبيقات عبر إعادة توجيه المنفذ يختلفان ، لذلك نواجه المشاكل الموضحة في هذه المشكلة. لسبب واحد ، عندما يصل شخص ما إلى واجهة برمجة تطبيقات العقدة الرئيسية عبر المنفذ المُعاد توجيهه على مضيف Docker ، فإن عنوان IP لا يتطابق مع الشهادة. هذا سهل الإصلاح: يمكننا فقط إضافة عنوان IP الخاص بمضيف Docker إلى شبكات SSAN عند استخدام kubeadm لنشر المجموعة.

المشكلة الأخرى (التي يصعب حلها) هي أنه عندما نحاول ضم العقدة العاملة إلى الكتلة ، نحتاج إلى تجاوز نقطة نهاية API المستخدمة للوصول إلى العقدة الرئيسية (أي يجب أن تستخدم IP الخاص بمضيف Docker في كل مكان ، و ليس عنوان IP الداخلي لحاوية Docker ، التي لا يمكن الوصول إليها).

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

المشكلة الأخرى (التي يصعب حلها) هي أنه عندما نحاول ضم العقدة العاملة إلى الكتلة ، نحتاج إلى تجاوز نقطة نهاية API المستخدمة للوصول إلى العقدة الرئيسية (أي يجب أن تستخدم IP الخاص بمضيف Docker في كل مكان ، و ليس عنوان IP الداخلي لحاوية Docker ، التي لا يمكن الوصول إليها).

هذا يبدو وكأنه سيناريو غير مدعوم حسب النوع.
هل حصلت على تعليقات من المشرفين اللطفاء (أو #kind على k8s slack)؟

بقدر ما أفهم أنه لا توجد طريقة للقيام بذلك ، أو على الأقل لا يمكنني رؤية واحدة من النظر إلى أعلام انضمام kubeadm ، وجعل المضيف: وسيطة موضع

كان OP الخاص بهذه المشكلة محيرًا ولا أعتقد أنه مرتبط بمشكلتك.

@ neolit123 السؤال المهم هو ما إذا كان سيناريو مدعوم من kubeadm ؛ النوع فقط يلتف kubeadm ووقت تشغيل الحاوية. يمكنني التفكير في عدد من السيناريوهات الأخرى التي لا تتضمن نوعًا حيث يتم إعادة توجيه منفذ واجهة برمجة تطبيقات عقدة مستوى التحكم kubernetes في مكان آخر ، ويجب تسجيل العقدة العاملة بها في شبكة حيث لا يمكن الوصول إلى عنوان مستوى التحكم الأصلي. على سبيل المثال ، باستخدام نفق SSH ، أو وكيل عكسي لـ TCP.

يحتاج kubeadm join إلى نقطة نهاية kube-apiserver لإجراء الاكتشاف وتمهيد Node.
يمكن أن يكون kube-apiserver في أي مكان - نفس الشبكة أو شبكة أخرى و kubeadm يدعم هذه الحالات.
يمكن أن تكون نقطة النهاية نقطة نهاية موازن التحميل أيضًا.

يتم بعد ذلك كتابة نقطة النهاية هذه على ملف kubelet.conf الخاص بالعقدة العاملة والذي يتم استخدامه للاتصال بخادم API

يمكنك حذف الوسيطة الموضعية تمامًا من kubeadm join واستخدام حقل JoinConfiguration 's Discovery.

المشكلة الأخرى (التي يصعب حلها) هي أنه عندما نحاول ضم العقدة العاملة إلى الكتلة ، نحتاج إلى تجاوز نقطة نهاية API المستخدمة للوصول إلى العقدة الرئيسية (أي يجب أن تستخدم IP الخاص بمضيف Docker في كل مكان ، و ليس عنوان IP الداخلي لحاوية Docker ، التي لا يمكن الوصول إليها).

يبدو أن هذه مشكلة في البرامج عالية المستوى التي تستخدم kubeadm (مثل النوع).
البرنامج عالي المستوى لا ينفذ kubeadm join مع نقطة النهاية التي تريدها.

السؤال المهم هو ما إذا كان سيناريو مدعوم من kubeadm ؛ النوع فقط يلتف kubeadm ووقت تشغيل الحاوية. يمكنني التفكير في عدد من السيناريوهات الأخرى التي لا تتضمن نوعًا حيث يتم إعادة توجيه منفذ واجهة برمجة تطبيقات عقدة مستوى التحكم kubernetes في مكان آخر ، ويجب تسجيل العقدة العاملة بها في شبكة حيث لا يمكن الوصول إلى عنوان مستوى التحكم الأصلي. على سبيل المثال ، باستخدام نفق SSH ، أو وكيل عكسي لـ TCP.

إذا لم يكن الوصول إلى خادم kube-apiserver متاحًا ، فلن يتمكن kubeadm من الانضمام إلى هذه العقدة الجديدة في الكتلة. فترة.
يحتاج kubeadm join إلى نقطة نهاية صالحة يمكن لعميل k8s الاتصال بها لإجراء الاكتشاف والتحقق من الصحة ، والذي سيؤدي بعد ذلك إلى TLS bootstrap وإنشاء كائن عقدة جديد.

لذا نعم ، يحتاج kubeadm join إلى نقطة نهاية خادم API صالحة / قابلة للوصول.

البرنامج عالي المستوى لا ينفذ kubeadm انضم مع نقطة النهاية التي تريدها.

ليس kind هو الذي ينفذ kubeadm join ، إنه أنا. أقوم بتنفيذ kubeadm join يدويًا ، مع توفير عنوان مضيف Docker حيث يتم عرض واجهة برمجة التطبيقات عبر إعادة توجيه المنفذ (لاحظ أن هذا لا يتطابق مع --control-plane-endpoint الذي تم استخدامه لبدء عقدة مستوى التحكم نفسها ؛ هذا العنوان لا يمكن الوصول إليه من قبل العقدة العاملة).

تكمن المشكلة في أن العنوان الذي قدمته لـ kubeadm join لا يتم استخدامه بشكل ثابت طوال عملية الانضمام: يتم استخدامه فقط في المراحل الأولية ، وبعد ذلك تفشل العملية لأنه في مرحلة ما تقوم العقدة العاملة بتنزيل التكوين من واجهة برمجة تطبيقات مستوى التحكم ، ثم تبدأ في استخدام العنوان الأصلي الذي يتعذر الوصول إليه المقابل لوسيطة --control-plane-endpoint التي تم استخدامها لبدء عقدة مستوى التحكم.

إذا لم يكن الوصول إلى خادم kube-apiserver متاحًا ، فلن يتمكن kubeadm من الانضمام إلى هذه العقدة الجديدة في الكتلة. فترة.

يمكن الوصول إلى kube-apiserver عبر إعادة توجيه المنفذ . لا يمكن الوصول إليه من العنوان الأصلي الذي تم تحديده باستخدام --advertise-addr أو --control-plane-endpoint عندما تم استخدام kubeadm init ، لأن هذا العنوان هو إحدى وظائف الشبكة التي بها عقدة مستوى التحكم نفسها تعمل ، وليس بالضرورة الشبكة التي يعمل فيها العامل المنضم.

الرجاء تسجيل مشكلة منفصلة وتقديم عناوين IP وأمثلة ملموسة لإعدادك.

@ neolit123 ليس من الواضح بالنسبة لي سبب الحاجة إلى مشكلة أخرى. تم الإبلاغ عن هذه المشكلة بالفعل عدة مرات على مدار السنوات العديدة الماضية وهي نفس المشكلة في كل مرة: تقوم بتشغيل kubeadm join ADDRESS وفي وقت ما يتم استبدال ADDRESS (والذي يعمل) بشيء آخر ( الذي لا).

لنبدأ في إصدار جديد لنرى:

• خطوات التكاثر الدقيقة.
• إصدارات kubeadm المتأثرة.

إصدارات kubeadm المتأثرة.

في الواقع ، سأكون فضوليًا حقًا بشأن ما سبق لأن النظر إلى منطقنا 1.17 و 1.18 تحت:
https://github.com/kubernetes/kubernetes/tree/release-1.17/cmd/kubeadm/app/discovery
https://github.com/kubernetes/kubernetes/tree/release-1.18/cmd/kubeadm/app/discovery

تنتهي نقطة النهاية التي تغذيها كوسيطة موضعية أو عبر JoinConfiguration في bootstrap-kubelet.conf الذي تم التحقق منه والمكتوب على القرص.