/ tetapkan @liztio

Lihat # 598. Jelas bug, bukan permintaan fitur, berdasarkan keluaran logging oleh kubeadm.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirim masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

/ remove-lifecycle basi

/ tetapkan @rdodev

dapatkah Anda memverifikasi bahwa ini masih ada untuk 1,12 dan menetapkan pencapaian 1,13 jika Anda dapat melakukan repro mengingat semua pengocokan kami

/ jenis bug

598 memiliki langkah repro yang mudah

Akhirnya menyiasati ini.

/ siklus hidup aktif

@timothysc tidak dapat mereplikasi di 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.

Jalankan 'kubectl get node' pada master untuk melihat node ini bergabung dengan cluster.

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 Saya memperbanyaknya minggu lalu pada 1,12. Menurut Anda, mengapa kubeadm sebenarnya terhubung ke 10.0.0.106:6000 ?

Aturan firewall

@tokopedia
``
root @ ip-10-0-0-43 : ~ # kubeadm gabung 10.0.0.106:6443 --token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256: d993ceed705830e8a10fcf2cb29d7c2030217039c6ebafcf45ed88
[preflight] menjalankan pemeriksaan pra-penerbangan
[penemuan] Mencoba untuk terhubung ke Server API "10.0.0.106:6443"
[penemuan] Membuat klien penemuan info cluster, meminta info dari " https://10.0.0.106 : 6443"
[penemuan] Gagal meminta info cluster, akan mencoba lagi: [Dapatkan https://10.0.0.106 : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info: dial tcp 10.0.0.106:6443: connect : koneksi ditolak]
[penemuan] Gagal meminta info cluster, akan mencoba lagi: [Dapatkan https://10.0.0.106 : 6443 / api / v1 / namespaces / kube-public / configmaps / cluster-info: dial tcp 10.0.0.106:6443: connect : koneksi ditolak]
^ C
root @ ip-10-0-0-43 : ~ # kubeadm join 10.0.0.106:6000 --token nwoa2x.cqar2ndxrtnw9arc --discovery-token-ca-cert-hash sha256: d993ceed705830e8a10fcf2cb29d7c2030217039c6ebafcf45ed88
[preflight] menjalankan pemeriksaan pra-penerbangan
[penemuan] Mencoba untuk terhubung ke API Server "10.0.0.106:6000"
[penemuan] Membuat klien penemuan info cluster, meminta info dari " https://10.0.0.106 : 6000"
[penemuan] Meminta info dari " https://10.0.0.106 : 6000" lagi untuk memvalidasi TLS terhadap kunci publik yang disematkan
[Penemuan] Tanda tangan info cluster dan isinya valid dan sertifikat TLS divalidasi terhadap root yang disematkan, akan menggunakan API Server "10.0.0.106:6000"
[penemuan] Berhasil membuat koneksi dengan API Server "10.0.0.106:6000"
[kubelet] Mendownload konfigurasi untuk kubelet dari ConfigMap "kubelet-config-1.12" di namespace sistem kube
[kubelet] Menulis konfigurasi kubelet ke file "/var/lib/kubelet/config.yaml"
[kubelet] Menulis file lingkungan kubelet dengan flag ke file "/var/lib/kubelet/kubeadm-flags.env"
[preflight] Mengaktifkan layanan kubelet
[tlsbootstrap] Menunggu kubelet untuk melakukan TLS Bootstrap ...
[patchnode] Mengunggah informasi Soket CRI "/var/run/dockershim.sock" ke objek API Node "ip-10-0-0-43" sebagai penjelasan

Node ini telah bergabung dengan cluster: ``

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

Di master:

$ 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 tidak tahu harus memberi tahu Anda apa. Ini adalah instalasi segar mint di infra segar.

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 sepertinya telah dimodifikasi dari default. Menggunakannya tidak akan mereproduksi masalah. Apa perintah 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

Jadi Anda memulainya dengan port 6000. Itu tidak akan berhasil untuk mereproduksi masalah ini. Masalah ini adalah tentang tidak dapat bergabung dengan master di alamat / port yang berbeda dari konfigurasi awal master.

@jethrogb apa kasus penggunaannya, silakan. Mengapa Anda ingin bergabung dengan bidang kendali di alamat / port yang berbeda dari tempat bidang kendali dibawa online?

Ini beberapa ...

1. Master mengubah alamat IP.
2. Dulunya memiliki master tunggal, tetapi sekarang berubah master menjadi HA. Penggabung selanjutnya akan ingin menggunakan alamat IP LB.
3. Master berada di belakang NAT, tidak semua node menggunakan IP yang sama untuk terhubung ke master.

Masalah utamanya adalah Anda memberi tahu kubeadm join IP / port apa yang akan digunakan, dikatakan akan menggunakan alamat itu, tetapi tidak !

@tokopedia

Dalam kasus 1) Anda perlu menerbitkan kembali sertifikat tidak dengan cara lain. Sertifikat dibuat untuk nama host dan alamat ip dari bidang kontrol setelah init. Dapat dikurangi dengan menerbitkan sertifikat ke nama DNS di init.

Dalam kasus 2) proses berpindah dari bidang kendali tunggal ke HA mengharuskan Anda untuk menerbitkan kembali semua sertifikat yang relevan (khususnya untuk menambahkan nama LB dns)

Saya tidak yakin 3) adalah konfigurasi yang didukung saat ini.

Saya tidak yakin apa hubungannya semua ini dengan sertifikat.

@jethrogb terlebih dahulu, meskipun Anda dapat terhubung (entah bagaimana), itu akan gagal pada ketidakcocokan sertifikat seperti yang dijelaskan di atas.

Kedua, ini bukan bug karena ini bukan kasus penggunaan yang didukung. AFICT bukan karena dulu berfungsi dan sekarang tidak. Itu hanya bukan fitur yang ada dan rusak.

@timothysc Saya tidak berpikir item ini dan # 598 sama / menipu. Yang ini (# 664) kami tahu ini berfungsi karena itulah cara kami menguji HA di 1.11 dan 1.12

598 layak dilihat sebagai permintaan fitur.

@timothysc ^^

@tallclair haha Saya tahu ini pasti akan terjadi E_TOO_MANY_TIMS_IN_K8S

@jethrogb terlebih dahulu, meskipun Anda dapat terhubung (entah bagaimana), itu akan gagal pada ketidakcocokan sertifikat seperti yang dijelaskan di atas.

Ini tidak ada hubungannya dengan sertifikat. Meskipun sertifikat yang disajikan oleh server API di alamat yang ditentukan pengguna di kubeadm join keluar, kubeadm join kemudian (bertentangan dengan klaimnya di terminal) akan terhubung ke alamat yang sama sekali berbeda untuk langkah terakhir dari prosedur bergabung.

Kedua, ini bukan bug karena ini bukan kasus penggunaan yang didukung. AFICT bukan karena dulu berfungsi dan sekarang tidak. Itu hanya bukan fitur yang ada dan rusak.

Saya tidak yakin saya mengerti apa yang Anda katakan. Apakah Anda mengatakan bahwa alat yang mengirim pesan kepada pengguna bahwa alat tersebut akan melakukan satu hal saat melakukan hal lain bukanlah bug?

Ini tidak ada hubungannya dengan sertifikat. Meskipun sertifikat yang disajikan oleh server API di alamat yang ditentukan pengguna di kubeadm join keluar, kubeadm join kemudian (bertentangan dengan klaimnya di terminal) akan terhubung ke alamat yang sama sekali berbeda untuk langkah terakhir dari prosedur bergabung.

Untuk menjelaskan mengapa sertifikat penting, mari kita lihat jika ip bidang kontrol berubah, ini terjadi:

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]

Hal yang sama berlaku untuk kasus 2) jika Anda pergi dari bidang kendali tunggal ke HA. Hanya mencoba untuk menunjukkan kasus penggunaan yang Anda sebutkan di atas tidak didukung oleh kubeadm tanpa menghasilkan / swizzling sertifikat di node bidang kontrol. Jadi cakupannya di sini hanya ke port forwarding.

Saya tidak yakin saya mengerti apa yang Anda katakan. Apakah Anda mengatakan bahwa alat yang mengirim pesan kepada pengguna bahwa alat tersebut akan melakukan satu hal saat melakukan hal lain bukanlah bug?

Saya pikir kita harus membuka kembali diskusi tentang masalah awal Anda karena tidak ada hubungannya dengan masalah khusus ini. Mari kita tunggu masukan @timothysc untuk melanjutkan.

@jethrogb Jadi jika saya membaca ini dengan benar Anda mengubah ip: port setelah init awal, tetapi join tidak menggunakan penggantian baris perintah, itu menggunakan apa yang disimpan di conf kubeadm yang disimpan di cluster.

Ini kasus penggunaan yang aneh, tetapi argumen baris cmd tampaknya tidak menimpa @rdodev dalam kasus penggunaan ini. Tampaknya memeriksa 80-90% jalan, kemudian gunakan konfigurasi untuk koneksi.

Ya itu akurat

Teman-teman, interpretasi argumen baris perintah titik akhir server API selama penggabungan menyesatkan. Sebenarnya, ini hanya digunakan selama bootstrap dan tidak untuk yang lain. Dan meski begitu, ini hanya digunakan selama penemuan berbasis token. Ini akan diabaikan (bahkan tanpa satu peringatan) dengan penemuan berbasis kubeconfig.

Jadi sebenarnya ada beberapa masalah di sini:

• Titik akhir server API penemuan berbasis token bootstrap mengalami UX yang menyesatkan. Taruhan terbaik saya adalah menghentikan cara argumen mandiri untuk menyediakan ini dan memperkenalkan saklar baris perintah deskriptif untuk ini (sesuatu seperti --discovery-token-apiserver ). Nilai yang diberikan kemudian menjadi joinCfg.Discovery.BootstrapToken.APIServerEndpoint .

• Jika seseorang ingin menimpa Server API yang sebenarnya pada basis per node, kita mungkin harus mengubah konfigurasi (mungkin menambahkan bidang di NodeRegistrationOptions dan / atau mungkin saklar baris perintah?).
  Tidak bertahan, ini berpotensi merusak sesuatu pada operasi kubeadm berikutnya (seperti pada peningkatan) jadi kami mungkin perlu menyimpannya sebagai anotasi juga.

• Titik akhir server API penemuan berbasis token bootstrap mengalami UX yang menyesatkan. Taruhan terbaik saya adalah menghentikan cara argumen mandiri untuk menyediakan ini dan memperkenalkan saklar baris perintah deskriptif untuk ini (sesuatu seperti --discovery-token-apiserver ). Nilai yang diberikan kemudian menjadi joinCfg.Discovery.BootstrapToken.APIServerEndpoint .

+1

• Jika seseorang ingin menimpa Server API yang sebenarnya pada basis per node, kita mungkin harus mengubah konfigurasi (mungkin menambahkan bidang di NodeRegistrationOptions dan / atau mungkin saklar baris perintah?).
  Tidak bertahan, ini berpotensi merusak sesuatu pada operasi kubeadm berikutnya (seperti pada peningkatan) jadi kami mungkin perlu menyimpannya sebagai anotasi juga.

IMO kita tidak boleh menimpa ini saat bergabung, mungkin kita dapat memiliki perintah untuk memperbarui Titik Akhir Server Api di cluster-info configmap

Saya sebenarnya tidak jelas. Dengan "memodifikasi konfigurasi" saya bermaksud untuk benar-benar menambahkan bidang baru di suatu tempat dalam format konfigurasi berikutnya (mungkin v1beta2 ) dan mungkin menyimpannya di suatu tempat di cluster (anotasi node?).
Ini membutuhkan beberapa diskusi dan mungkin tidak akan terjadi dalam siklus saat ini (terutama jika kita mengikuti cara "menambahkan opsi konfigurasi").

Apa yang pasti bisa kita lakukan dalam siklus ini adalah menambahkan saklar baris perintah untuk server API penemuan token bootstrap dan menghentikan penyediaannya sebagai argumen anonim.

@ neolit123 @fabriziopandini WDYT?

Apa yang pasti bisa kita lakukan dalam siklus ini adalah menambahkan saklar baris perintah untuk server API penemuan token bootstrap dan menghentikan penyediaannya sebagai argumen anonim.

Tim dan Fabrizio agak tidak setuju.
tapi saya semua +1 karena menjalankan kebijakan penghentian GA terkait argumen itu.

itu hanyalah masalah.

@ neolit123 meskipun kita tidak pergi ke jalur peralihan baris perintah, kita sebenarnya dapat melakukan pekerjaan yang lebih baik dalam mendokumentasikan arg, baik dalam bantuan alat sebaris ( kubeadm join --help ) dan dalam dokumen situs web.
Saya berasumsi, bahwa dokumen yang lebih baik dapat (semacam) "memperbaiki" masalah juga dan ini dapat dilakukan sebagai bagian dari penulisan dokumen fase bergabung.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirim masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

membaca melalui keseluruhan tiket ada beberapa masalah yang merupakan kesalahpahaman, dibahas di tempat lain atau tidak didokumentasikan.

masalah asli:

masalah aslinya berbicara tentang:

tetapi kubelet config dan kube-proxy config mungkin juga master0 ip atau master1 ip, perilaku ini tidak diharapkan di HA.

saya tidak mengerti masalah ini, jadi jika Anda merasa ini masih layak untuk 1,13 (1,12 tidak didukung lagi) silakan masuk ke tiket baru dengan detail lengkap dan contoh.
tiket ini banyak menyimpang.

argumen gabungan anonim yang menyesatkan:

ini dilacak di sini:
https://github.com/kubernetes/kubeadm/issues/1375

kami berencana untuk beralih ke argumen bernama untuk penemuan misalnya --discovery-endpoint tetapi memilih keluar dari ide ini dan Anda harus terus menggunakan kubeadm join addr:ip

transisi dari bidang kontrol tunggal ke HA:

dilacak di sini:
https://github.com/kubernetes/kubeadm/issues/1664

PR untuk topik ini baru saja digabungkan di dokumen kami:
https://github.com/kubernetes/website/pull/15524

TL; DR adalah jika Anda mengubah alamat server-api pada node bidang kontrol setelah cluster dibuat, Anda perlu membuat ulang sertifikat dan menambal objek cluster. untuk transisi yang lebih baik ke HA menggunakan nama DNS.

jika ada hal lain yang sedang dimainkan, harap buat tiket bersih dengan detail lengkap sehingga pengelola dapat memahami masalahnya.

@ neolit123 # 598 digabung menjadi ini tetapi tidak jelas bagi saya apakah itu diselesaikan.

@tokopedia

598 digabung menjadi ini

jika masalah Anda dari # 598 masih dapat dijalankan, buka kembali masalah tersebut tetapi harap diingat bahwa masalah tersebut harus dapat direkonstruksi dengan 1.13+, karena versi lama berada di luar dukungan condong dan tidak didukung oleh tim kubeadm.

@ neolit123 Saya memiliki node bidang kontrol Kubernetes yang berjalan di dalam container Docker melalui https://github.com/kubernetes-sigs/kind. Server api diekspos pada host Docker melalui penerusan port. Saya perlu menambahkan node pekerja di jaringan host Docker ke cluster.

Jelas alamat IP dan nama host dari container yang menjalankan kubelet dan host Docker di mana API diekspos melalui penerusan port berbeda, jadi kami mengalami masalah yang dijelaskan dalam masalah ini. Untuk satu hal, ketika seseorang mencapai API node master melalui port yang diteruskan pada host Docker, alamat IP tidak cocok dengan sertifikat. Ini mudah diperbaiki: kita cukup menambahkan IP host Docker ke certificateSANs saat menggunakan kubeadm untuk menerapkan cluster.

Masalah lainnya (yang lebih sulit untuk dipecahkan) adalah ketika kita mencoba untuk menggabungkan node pekerja ke cluster, kita perlu secara konsisten mengganti titik akhir API yang digunakan untuk mencapai node master (yaitu harus menggunakan IP host Docker di mana saja, dan bukan alamat IP internal container Docker, yang tidak dapat diaksesnya).

Sejauh yang saya mengerti masih belum ada cara untuk melakukan ini, atau setidaknya saya tidak dapat melihatnya dari melihat bendera untuk kubeadm join , dan membuatArgumen posisi untuk tujuan ini adalah apa yang diminta oleh masalah ini (memang saya tidak sepenuhnya memahami argumen tandingan terhadap ini). Apakah saya melewatkan sesuatu?

Masalah lainnya (yang lebih sulit untuk dipecahkan) adalah ketika kita mencoba untuk menggabungkan node pekerja ke cluster, kita perlu secara konsisten mengganti titik akhir API yang digunakan untuk mencapai node master (yaitu harus menggunakan IP host Docker di mana saja, dan bukan alamat IP internal container Docker, yang tidak dapat diaksesnya).

Ini sepertinya skenario yang tidak didukung menurut jenisnya.
apakah Anda mendapatkan umpan balik dari pengelola yang baik (atau #kind pada k8s slack)?

Sejauh yang saya mengerti masih tidak ada cara untuk melakukan ini, atau setidaknya saya tidak dapat melihatnya dari melihat tanda untuk bergabung kubeadm, dan membuat host: argumen posisi

OP masalah ini membingungkan dan saya rasa itu tidak terkait dengan masalah Anda.

@ neolit123 Pertanyaan penting adalah apakah itu skenario yang didukung oleh kubeadm; jenis hanya membungkus kubeadm dan runtime kontainer. Saya dapat memikirkan sejumlah skenario lain yang tidak melibatkan jenis di mana port API node pesawat kontrol kubernetes diteruskan ke tempat lain, dan node pekerja harus terdaftar di jaringan di mana alamat bidang kontrol asli tidak dapat diakses. Misalnya menggunakan terowongan SSH, atau proxy balik TCP.

kubeadm join membutuhkan titik akhir kube-apiserver untuk melakukan penemuan dan bootstrap Node.
bahwa kube-apiserver bisa berada di mana saja - jaringan yang sama atau jaringan lain dan kubeadm mendukung kasus tersebut.
titik akhir juga dapat menjadi titik akhir penyeimbang beban.

endpoint itu kemudian ditulis pada file kubelet.conf node pekerja yang digunakan untuk berkomunikasi ke server API

Anda dapat menghilangkan argumen posisi sepenuhnya dari kubeadm join dan menggunakan bidang Penemuan JoinConfiguration .

Masalah lainnya (yang lebih sulit untuk dipecahkan) adalah ketika kita mencoba untuk menggabungkan node pekerja ke cluster, kita perlu secara konsisten mengganti titik akhir API yang digunakan untuk mencapai node master (yaitu harus menggunakan IP host Docker di mana saja, dan bukan alamat IP internal container Docker, yang tidak dapat diaksesnya).

ini sepertinya masalah perangkat lunak tingkat tinggi yang menggunakan kubeadm (misalnya jenis).
perangkat lunak tingkat tinggi tidak menjalankan kubeadm join dengan titik akhir yang Anda inginkan.

Pertanyaan penting adalah apakah itu skenario yang didukung oleh kubeadm; jenis hanya membungkus kubeadm dan runtime kontainer. Saya dapat memikirkan sejumlah skenario lain yang tidak melibatkan jenis di mana port API node pesawat kontrol kubernetes diteruskan ke tempat lain, dan node pekerja harus terdaftar di jaringan di mana alamat bidang kontrol asli tidak dapat diakses. Misalnya menggunakan terowongan SSH, atau proxy balik TCP.

jika kube-apiserver tidak dapat diakses, kubeadm tidak dapat menggabungkan Node baru ini ke cluster. Titik.
kubeadm join membutuhkan titik akhir yang valid yang dapat dihubungkan dengan klien k8s untuk melakukan penemuan dan validasi, yang kemudian akan mengarah ke bootstrap TLS dan pembuatan objek Node baru.

jadi ya, kubeadm join memang membutuhkan titik akhir server API yang valid / dapat dijangkau.

perangkat lunak tingkat tinggi tidak menjalankan kubeadm bergabung dengan titik akhir yang Anda inginkan.

Bukan kind yang mengeksekusi kubeadm join , ini aku. Saya menjalankan kubeadm join secara manual, memberikan alamat host Docker tempat API diekspos melalui penerusan port (perhatikan bahwa ini tidak cocok dengan --control-plane-endpoint yang digunakan untuk memulai node bidang kontrol itu sendiri; alamat itu tidak dapat diakses oleh node pekerja).

Masalahnya adalah bahwa alamat yang saya berikan ke kubeadm join tidak digunakan secara konsisten selama proses bergabung: ini hanya digunakan pada tahap awal, setelah itu prosesnya gagal karena pada titik tertentu node pekerja mengunduh konfigurasi dari control plane API, lalu mulai menggunakan alamat asli yang tidak dapat diakses sesuai dengan argumen --control-plane-endpoint yang digunakan untuk memulai node bidang kontrol.

jika kube-apiserver tidak dapat diakses, kubeadm tidak dapat menggabungkan Node baru ini ke cluster. Titik.

Kube-apiserver dapat diakses melalui port forwarding . Tidak dapat diakses di alamat asli yang ditentukan menggunakan --advertise-addr atau --control-plane-endpoint ketika kubeadm init digunakan, karena alamat tersebut adalah fungsi dari jaringan di mana node bidang kontrol itu sendiri sedang berjalan, dan tidak harus dari jaringan tempat pekerja yang bergabung sedang berjalan.

harap catat masalah terpisah dan berikan alamat IP serta contoh konkret penyiapan Anda.

@ neolit123 tidak jelas bagi saya mengapa masalah lain diperlukan. Masalah ini telah dilaporkan beberapa kali selama beberapa tahun terakhir dan selalu menjadi masalah yang sama: Anda menjalankan kubeadm join ADDRESS dan pada titik tertentu ADDRESS (yang berfungsi) ditukar dengan yang lain ( yang tidak).

mari kita mulai dengan masalah baru untuk melihat:

• langkah-langkah reproduksi minimal yang tepat.
• versi kubeadm yang terpengaruh.

versi kubeadm yang terpengaruh.

sebenarnya, saya akan sangat penasaran tentang hal di atas karena melihat logika kami untuk 1,17 dan 1,18 di bawah:
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

titik akhir yang Anda masukkan sebagai argumen posisi atau melalui JoinConfiguration berakhir di bootstrap-kubelet.conf tervalidasi yang tertulis pada disk.