Bagikan melalui

Pemecahan masalah Kubernetes

  • Artikel

Halaman ini membahas beberapa masalah umum dengan penyiapan, jaringan, dan penyebaran Kubernetes.

Tip

Sarankan item FAQ dengan menaikkan PR ke repositori dokumentasi kami.

Halaman ini dibagi menjadi kategori berikut:

  1. Pertanyaan Umum
  2. Kesalahan jaringan umum
  3. Kesalahan Windows umum
  4. Kesalahan master Kubernetes umum

Pertanyaan umum

Bagaimana cara mengetahui Kubernetes pada Windows berhasil diselesaikan?

Anda akan melihat kubelet, kube-proxy, dan (jika Anda memilih Flannel sebagai solusi jaringan Anda) proses agen host flanel yang berjalan pada simpul Anda. Selain itu, simpul Windows Anda harus terdaftar sebagai "Siap" di kluster Kubernetes Anda.

Dapatkah saya mengonfigurasi untuk menjalankan semua ini di latar belakang?

Dimulai dengan Kubernetes versi 1.11, kubelet & kube-proxy dapat dijalankan sebagai Layanan Windows asli. Anda juga dapat selalu menggunakan manajer layanan alternatif seperti nssm.exe untuk selalu menjalankan proses ini (flanel, kubelet & kube-proxy) di latar belakang untuk Anda.

Kesalahan jaringan umum

Load balancer di-plumbed secara tidak konsisten di seluruh node kluster

Pada Windows, kube-proxy membuat load balancer HNS untuk setiap layanan Kubernetes di kluster. Dalam konfigurasi kube-proxy (default), simpul dalam kluster yang berisi banyak penyeimbang beban (biasanya 100+) dapat kehabisan port TCP ephemeral yang tersedia (alias rentang port dinamis, yang secara default mencakup port 49152 hingga 65535). Hal ini disebabkan oleh tingginya jumlah port yang dicadangkan pada setiap simpul untuk setiap penyeimbang beban (non-DSR). Masalah ini dapat memanifestasikan dirinya melalui kesalahan dalam kube-proxy seperti:

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

Pengguna dapat mengidentifikasi masalah ini dengan menjalankan skrip CollectLogs.ps1 dan berkonsultasi dengan *portrange.txt file.

Juga CollectLogs.ps1 akan meniru logika alokasi HNS untuk menguji ketersediaan alokasi kumpulan port dalam rentang port TCP ephemeral, dan melaporkan keberhasilan/kegagalan di reservedports.txt. Skrip ini mencadangkan 10 rentang 64 port ephemeral TCP (untuk meniru perilaku HNS), menghitung keberhasilan & kegagalan reservasi, lalu merilis rentang port yang dialokasikan. Angka keberhasilan kurang dari 10 menunjukkan kumpulan ephemeral kehabisan ruang kosong. Ringkasan heuristik tentang berapa banyak reservasi port 64 blok yang kira-kira tersedia juga akan dihasilkan di reservedports.txt.

Untuk mengatasi masalah ini, beberapa langkah dapat dilakukan:

  1. Untuk solusi permanen, penyeimbangan beban kube-proxy harus diatur ke mode DSR. Mode DSR sepenuhnya diimplementasikan dan tersedia pada build Windows Server Insider yang lebih baru hanya 18945 (atau lebih tinggi).
  2. Sebagai solusinya, pengguna juga dapat meningkatkan konfigurasi Windows default port sementara yang tersedia menggunakan perintah seperti netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. PERINGATAN: Mengesampingkan rentang port dinamis default dapat memiliki konsekuensi pada proses/layanan lain pada host yang mengandalkan port TCP yang tersedia dari rentang non-sementara, sehingga rentang ini harus dipilih dengan hati-hati.
  3. Ada peningkatan skalabilitas untuk penyeimbang beban mode non-DSR menggunakan berbagi kumpulan port cerdas yang disertakan dalam KB4551853 pembaruan kumulatif (dan semua pembaruan kumulatif yang lebih baru).

Penerbitan HostPort tidak berfungsi

Untuk menggunakan fitur HostPort, pastikan plugin CNI Anda adalah rilis v0.8.6 atau lebih tinggi, dan bahwa file konfigurasi CNI memiliki portMappings kemampuan yang ditetapkan:

"capabilities": {
    "portMappings":  true
}

Saya melihat kesalahan seperti "hnsCall gagal di Win32: Diskette yang salah ada di drive."

Kesalahan ini dapat terjadi ketika membuat modifikasi kustom pada objek HNS atau menginstal Windows Update baru yang memperkenalkan perubahan pada HNS tanpa merobek objek HNS lama. Ini menunjukkan bahwa objek HNS yang sebelumnya dibuat sebelum pembaruan tidak kompatibel dengan versi HNS yang saat ini diinstal.

Pada Windows Server 2019 (dan yang lebih lama), pengguna dapat menghapus objek HNS dengan menghapus file HNS.data

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

Pengguna harus dapat langsung menghapus titik akhir atau jaringan HNS yang tidak kompatibel:

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Pengguna di Windows Server, versi 1903 dapat masuk ke lokasi registri berikut dan menghapus NIC apa pun yang dimulai dengan nama jaringan (misalnya vxlan0 atau cbr0):

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

Kontainer pada penyebaran host-gw Flanel saya di Azure tidak dapat menjangkau internet

Saat menyebarkan Flannel dalam mode host-gw di Azure, paket harus melalui host fisik Azure vSwitch. Pengguna harus memprogram rute jenis "appliance virtual" yang ditentukan pengguna untuk setiap subnet yang ditetapkan ke simpul. Ini dapat dilakukan melalui portal Azure (lihat contoh di sini) atau melalui az Azure CLI. Berikut adalah salah satu contoh UDR dengan nama "MyRoute" menggunakan perintah az untuk node dengan IP 10.0.0.4 dan subnet pod masing-masing 10.244.0.0/24:

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4 

Tip

Jika Anda menyebarkan Kubernetes di Azure atau IaaS VM dari penyedia cloud lain sendiri, Anda juga dapat menggunakannya overlay networking .

Pod Windows saya tidak dapat melakukan ping sumber daya eksternal

Pod Windows tidak memiliki aturan keluar yang diprogram untuk protokol ICMP hari ini. Namun, TCP/UDP didukung. Saat mencoba menunjukkan konektivitas ke sumber daya di luar kluster, silakan ganti ping <IP> dengan perintah yang curl <IP> sesuai.

Jika Anda masih menghadapi masalah, kemungkinan besar konfigurasi jaringan Anda di cni.conf layak mendapatkan perhatian ekstra. Anda selalu dapat mengedit file statis ini, konfigurasi akan diterapkan ke sumber daya Kubernetes yang baru dibuat.

Mengapa? Salah satu persyaratan jaringan Kubernetes (lihat model Kubernetes) adalah agar komunikasi kluster terjadi tanpa NAT secara internal. Untuk memenuhi persyaratan ini, kami memiliki ExceptionList untuk semua komunikasi di mana kami tidak ingin NAT keluar terjadi. Namun, ini juga berarti Bahwa Anda perlu mengecualikan IP eksternal yang anda coba kueri dari ExceptionList. Hanya dengan begitu lalu lintas yang berasal dari pod Windows Anda akan di-SNAT dengan benar untuk menerima respons dari dunia luar. Dalam hal ini, ExceptionList Anda di cni.conf akan terlihat sebagai berikut:

"ExceptionList": [
  "10.244.0.0/16",  # Cluster subnet
  "10.96.0.0/12",   # Service subnet
  "10.127.130.0/24" # Management (host) subnet
]

Simpul Windows saya tidak dapat mengakses layanan NodePort

Akses NodePort lokal dari simpul itu sendiri mungkin gagal. Ini adalah kesenjangan fitur yang diketahui yang ditangani dengan pembaruan kumulatif KB4571748 (atau yang lebih baru). Akses NodePort akan berfungsi dari simpul lain atau klien eksternal.

Simpul Windows saya berhenti merutekan Thourgh NodePorts setelah saya menurunkan skala pod saya

Karena keterbatasan desain, setidaknya perlu ada satu pod yang berjalan pada node Windows agar penerusan NodePort berfungsi.

Setelah beberapa waktu, titik akhir kontainer vNIC dan HNS sedang dihapus

Masalah ini dapat disebabkan ketika hostname-override parameter tidak diteruskan ke kube-proxy. Untuk mengatasinya, pengguna perlu meneruskan nama host ke kube-proxy sebagai berikut:

C:\k\kube-proxy.exe --hostname-override=$(hostname)

Pada mode Flannel (vxlan), pod saya mengalami masalah konektivitas setelah bergabung kembali dengan node

Setiap kali node yang dihapus sebelumnya sedang bergabung kembali ke kluster, flanelD akan mencoba menetapkan subnet pod baru ke simpul. Pengguna harus menghapus file konfigurasi subnet pod lama di jalur berikut:

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

Setelah meluncurkan Kubernetes, Flanneld terjebak dalam "Menunggu Jaringan dibuat"

Masalah ini harus diatasi dengan Flannel v0.12.0 (dan yang lebih tinggi). Jika Anda menggunakan versi Flanneld yang lebih lama, ada kondisi balapan yang diketahui yang dapat terjadi sia-sia sehingga IP manajemen jaringan flanel tidak diatur. Solusinya adalah dengan hanya melepaskan FlannelD secara manual.

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

Pod Windows saya tidak dapat diluncurkan karena hilangnya /run/flannel/subnet.env

Ini menunjukkan bahwa Flannel tidak diluncurkan dengan benar. Anda dapat mencoba untuk memulai ulang flanneld.exe atau Anda dapat menyalin file secara manual dari /run/flannel/subnet.env pada master Kubernetes ke C:\run\flannel\subnet.env pada simpul pekerja Windows dan memodifikasi FLANNEL_SUBNET baris ke subnet yang ditetapkan. Misalnya, jika subnet node 10.244.4.1/24 ditetapkan:

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

Lebih sering daripada tidak, ada masalah lain yang dapat menyebabkan kesalahan ini yang perlu diselidiki terlebih dahulu. Disarankan untuk membiarkan flanneld.exe membuat file ini untuk Anda.

Konektivitas pod-ke-pod antara host rusak pada kluster Kubernetes saya yang berjalan di vSphere

Karena vSphere dan Flannel mencadangkan port 4789 (port VXLAN default) untuk jaringan overlay, paket akhirnya dapat dicegat. Jika vSphere digunakan untuk jaringan overlay, vSphere harus dikonfigurasi untuk menggunakan port yang berbeda untuk membebaskan 4789.

Titik akhir/IP saya bocor

Ada 2 masalah yang saat ini diketahui yang dapat menyebabkan titik akhir bocor.

  1. Masalah pertama yang diketahui adalah masalah di Kubernetes versi 1.11. Hindari menggunakan Kubernetes versi 1.11.0 - 1.11.2.
  2. Masalah kedua yang diketahui yang dapat menyebabkan titik akhir bocor adalah masalah konkurensi dalam penyimpanan titik akhir. Untuk menerima perbaikan, Anda harus menggunakan Docker EE 18.09 atau lebih tinggi.

Pod saya tidak dapat diluncurkan karena kesalahan "jaringan: gagal mengalokasikan untuk rentang"

Ini menunjukkan bahwa ruang alamat IP pada simpul Anda habis. Untuk membersihkan titik akhir yang bocor, migrasikan sumber daya apa pun pada simpul yang terkena dampak & jalankan perintah berikut:

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

Simpul Windows saya tidak dapat mengakses layanan saya menggunakan IP layanan

Ini adalah batasan yang diketahui dari tumpukan jaringan saat ini pada Windows. Namun, Pod Windows dapat mengakses IP layanan.

Tidak ada adaptor jaringan yang ditemukan saat memulai Kubelet

Tumpukan jaringan Windows memerlukan adaptor virtual agar jaringan Kubernetes berfungsi. Jika perintah berikut tidak mengembalikan hasil (dalam shell admin), pembuatan jaringan HNS — prasyarat yang diperlukan agar Kubelet berfungsi — telah gagal:

Get-HnsNetwork | ? Name -ieq "cbr0"
Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

Seringkali ada baiknya untuk memodifikasi parameter InterfaceName dari skrip start.ps1, dalam kasus di mana adaptor jaringan host bukan "Ethernet". Jika tidak, lihat output start-kubelet.ps1 skrip untuk melihat apakah ada kesalahan selama pembuatan jaringan virtual.

Saya masih melihat masalah. Apa yang harus saya lakukan?

Mungkin ada batasan tambahan di jaringan Anda atau pada host yang mencegah jenis komunikasi tertentu antar simpul. Pastikan bahwa:

  • Anda telah mengonfigurasi topologi jaringan yang Anda pilih dengan benar (l2bridge atau overlay)
  • lalu lintas yang terlihat seperti berasal dari pod diizinkan
  • Lalu lintas HTTP diizinkan, jika Anda menyebarkan layanan web
  • Paket dari protokol yang berbeda (yaitu ICMP vs. TCP/UDP) tidak dihilangkan

Tip

Untuk sumber daya bantuan mandiri tambahan, ada juga panduan pemecahan masalah jaringan Kubernetes untuk Windows yang tersedia di sini.

Kesalahan Windows umum

Pod Kubernetes saya macet di "ContainerCreating"

Masalah ini dapat memiliki banyak penyebab, tetapi salah satu yang paling umum adalah bahwa gambar jeda salah dikonfigurasi. Ini adalah gejala tingkat tinggi dari masalah berikutnya.

Saat menyebarkan, kontainer Docker terus memulai ulang

Periksa apakah gambar jeda Anda kompatibel dengan versi OS Anda. Kubernetes mengasumsikan bahwa OS dan kontainer memiliki nomor versi OS yang cocok. Jika Anda menggunakan build Eksperimental Windows, seperti build Insider, Anda harus menyesuaikan gambar yang sesuai. Silakan lihat repositori Docker Microsoft untuk gambar.

Kesalahan master Kubernetes umum

Debugging master Kubernetes termasuk dalam tiga kategori utama (dalam urutan kemungkinan):

  • Ada yang salah dengan kontainer sistem Kubernetes.
  • Ada yang salah dengan cara kubelet menjalankan.
  • Ada yang salah dengan sistem.

Jalankan kubectl get pods -n kube-system untuk melihat pod yang dibuat oleh Kubernetes; ini dapat memberikan beberapa wawasan tentang pod tertentu yang mengalami crash atau tidak dimulai dengan benar. Kemudian, jalankan docker ps -a untuk melihat semua kontainer mentah yang mendukung pod-pod ini. Terakhir, jalankan docker logs [ID] pada kontainer yang diduga menyebabkan masalah untuk melihat output mentah proses.

Tidak dapat tersambung ke server API di https://[address]:[port]

Lebih sering daripada tidak, kesalahan ini menunjukkan masalah sertifikat. Pastikan Anda telah membuat file konfigurasi dengan benar, bahwa alamat IP di dalamnya cocok dengan host Anda, dan Anda telah menyalinnya ke direktori yang dipasang oleh server API.

Tempat yang bagus untuk menemukan file konfigurasi ini adalah:

  • ~/kube/kubelet/
  • $HOME/.kube/config
  • /etc/kubernetes/admin.conf

jika tidak, lihat file manifes server API untuk memeriksa titik pemasangan.