🥇Cara pod Kubernetes mendapat alamat IP

Catatan. terjemah: Artikel ini, yang ditulis oleh jurutera SRE dari LinkedIn, menerangkan secara terperinci tentang keajaiban dalaman Kubernetes - lebih tepat lagi, interaksi CRI, CNI dan kube-apiserver - yang berlaku apabila pod seterusnya perlu diberikan alamat IP.

Salah satu keperluan asas Model rangkaian Kubernetes ialah setiap pod mesti mempunyai alamat IP sendiri dan mana-mana pod lain dalam kelompok mesti boleh menghubunginya di alamat tersebut. Terdapat banyak "penyedia" rangkaian (Flannel, Calico, Canal, dll.) yang membantu melaksanakan model rangkaian ini.

Apabila saya mula-mula mula bekerja dengan Kubernetes, ia tidak sepenuhnya jelas kepada saya bagaimana sebenarnya pod mendapatkan alamat IP mereka. Walaupun dengan pemahaman tentang bagaimana komponen individu berfungsi, sukar untuk membayangkan mereka bekerja bersama. Sebagai contoh, saya tahu untuk apa pemalam CNI, tetapi saya tidak tahu bagaimana sebenarnya ia dipanggil. Oleh itu, saya memutuskan untuk menulis artikel ini untuk berkongsi pengetahuan tentang pelbagai komponen rangkaian dan cara ia berfungsi bersama dalam kelompok Kubernetes, yang membolehkan setiap pod mendapatkan alamat IP uniknya sendiri.

Terdapat cara yang berbeza untuk mengatur rangkaian dalam Kubernetes, sama seperti terdapat pilihan masa jalan yang berbeza untuk bekas. Penerbitan ini akan menggunakan Flanel untuk mengatur rangkaian dalam kelompok, dan sebagai persekitaran boleh laku - bekas. Saya juga membuat andaian bahawa anda tahu cara rangkaian antara bekas berfungsi, jadi saya hanya akan menyentuhnya secara ringkas, hanya untuk konteks.

Beberapa konsep asas

Bekas dan Rangkaian: Gambaran Keseluruhan Ringkas

Terdapat banyak penerbitan yang sangat baik di Internet yang menerangkan cara kontena berkomunikasi antara satu sama lain melalui rangkaian. Oleh itu, saya hanya akan memberikan gambaran umum tentang konsep asas dan menghadkan diri saya kepada satu pendekatan, yang melibatkan penciptaan jambatan Linux dan pakej merangkum. Butiran diketepikan, kerana topik rangkaian kontena itu sendiri memerlukan artikel yang berasingan. Pautan ke beberapa penerbitan yang bernas dan berpendidikan akan disediakan di bawah.

Bekas pada satu hos

Satu cara untuk mengatur komunikasi melalui alamat IP antara bekas yang berjalan pada hos yang sama melibatkan mewujudkan jambatan Linux. Untuk tujuan ini, peranti maya dicipta dalam Kubernetes (dan Docker) veth (ethernet maya). Satu hujung peranti veth bersambung ke ruang nama rangkaian bekas, yang satu lagi ke Jambatan Linux pada rangkaian hos.

Semua bekas pada hos yang sama mempunyai satu hujung veth yang disambungkan ke jambatan yang melaluinya mereka boleh berkomunikasi antara satu sama lain melalui alamat IP. Jambatan Linux juga mempunyai alamat IP dan bertindak sebagai pintu masuk untuk trafik keluar dari pod yang ditujukan untuk nod lain.

Bekas pada hos yang berbeza

Enkapsulasi paket ialah satu kaedah yang membolehkan bekas pada nod berbeza berkomunikasi antara satu sama lain menggunakan alamat IP. Di Flanel, teknologi bertanggungjawab untuk peluang ini. vxlan, yang "membungkus" paket asal ke dalam paket UDP dan kemudian menghantarnya ke destinasinya.

Dalam gugusan Kubernetes, Flannel mencipta peranti vxlan dan mengemas kini jadual laluan pada setiap nod dengan sewajarnya. Setiap paket yang ditujukan untuk bekas pada hos yang berbeza melalui peranti vxlan dan dikapsulkan dalam paket UDP. Di destinasi, paket bersarang diekstrak dan dimajukan ke pod yang dikehendaki.

Nota: Ini hanyalah satu cara untuk mengatur komunikasi rangkaian antara bekas.

Apa itu CRI?

CRI (Antara Muka Masa Jalan Kontena) ialah pemalam yang membenarkan kubelet menggunakan persekitaran masa jalan kontena yang berbeza. API CRI dibina dalam pelbagai masa jalan, jadi pengguna boleh memilih masa jalan pilihan mereka.

Apakah CNI?

Projek CNI adalah a spesifikasi untuk mengatur penyelesaian rangkaian universal untuk bekas Linux. Di samping itu, ia termasuk pemalam, bertanggungjawab untuk pelbagai fungsi semasa menyediakan rangkaian pod. Pemalam CNI ialah fail boleh laku yang mematuhi spesifikasi (kami akan membincangkan beberapa pemalam di bawah).

Peruntukan subnet kepada nod untuk memberikan alamat IP kepada pod

Memandangkan setiap pod dalam kluster mesti mempunyai alamat IP, adalah penting untuk memastikan bahawa alamat ini unik. Ini dicapai dengan memberikan setiap nod subnet unik, dari mana pod pada nod itu kemudiannya diberikan alamat IP.

Pengawal IPAM Nod

Apabila nodeipam diluluskan sebagai parameter bendera --controllers pengurus-kube-controller, ia memperuntukkan subnet berasingan (podCIDR) kepada setiap nod daripada CIDR kluster (iaitu, julat alamat IP untuk rangkaian kluster). Oleh kerana podCIDR ini tidak bertindih, ia menjadi mungkin untuk setiap pod diperuntukkan alamat IP yang unik.

Nod Kubernetes diberikan podCIDR apabila ia pada mulanya didaftarkan dengan kluster. Untuk menukar podCIDR nod, anda perlu membatalkan pendaftarannya dan kemudian mendaftarkannya semula, membuat perubahan yang sesuai pada konfigurasi lapisan kawalan Kubernetes di antaranya. Anda boleh memaparkan podCIDR nod menggunakan arahan berikut:

$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24

Kubelet, masa jalan kontena dan pemalam CNI: cara semuanya berfungsi

Menjadualkan pod setiap nod melibatkan banyak langkah persediaan. Dalam bahagian ini, saya akan menumpukan hanya pada yang berkaitan secara langsung dengan menyediakan rangkaian pod.

Menjadualkan pod ke nod tertentu mencetuskan rangkaian peristiwa berikut:

Bantuan: Seni bina pemalam Containerd CRI.

Interaksi antara masa jalan kontena dan pemalam CNI

Setiap pembekal rangkaian mempunyai pemalam CNI sendiri. Masa jalan kontena menjalankannya untuk mengkonfigurasi rangkaian untuk pod semasa ia dimulakan. Dalam kes kontena, pemalam CNI dilancarkan oleh pemalam CRI kontena.

Lebih-lebih lagi, setiap pembekal mempunyai ejen sendiri. Ia dipasang pada semua nod Kubernetes dan bertanggungjawab untuk konfigurasi rangkaian pod. Ejen ini sama ada disertakan dengan konfigurasi CNI atau menciptanya secara bebas pada nod. Konfigurasi membantu pemalam CRI menetapkan pemalam CNI yang akan dipanggil.

Lokasi konfigurasi CNI boleh disesuaikan; secara lalai ia berada dalam /etc/cni/net.d/<config-file>. Pentadbir kluster juga bertanggungjawab untuk memasang pemalam CNI pada setiap nod kluster. Lokasi mereka juga boleh disesuaikan; direktori lalai - /opt/cni/bin.

Apabila menggunakan containerd, laluan untuk konfigurasi pemalam dan binari boleh ditetapkan dalam bahagian tersebut [plugins.«io.containerd.grpc.v1.cri».cni] в fail konfigurasi kontena.

Memandangkan kami menggunakan Flanel sebagai pembekal rangkaian kami, mari bercakap sedikit tentang menyediakannya:

Flanneld (daemon Flannel) biasanya dipasang dalam kelompok sebagai DaemonSet dengan install-cni sebagai bekas init.
Install-cni mencipta fail konfigurasi CNI (/etc/cni/net.d/10-flannel.conflist) pada setiap nod.
Flanneld mencipta peranti vxlan, mendapatkan semula metadata rangkaian daripada pelayan API dan memantau kemas kini pod. Semasa ia dicipta, ia mengedarkan laluan ke semua pod di seluruh kelompok.
Laluan ini membolehkan pod berkomunikasi antara satu sama lain melalui alamat IP.

Untuk maklumat lebih terperinci tentang kerja Flanel, saya syorkan anda menggunakan pautan di penghujung artikel.

Berikut ialah gambar rajah interaksi antara pemalam Containerd CRI dan pemalam CNI:

Seperti yang anda lihat di atas, kubelet memanggil pemalam Containerd CRI untuk mencipta pod, yang kemudiannya memanggil pemalam CNI untuk mengkonfigurasi rangkaian pod. Dengan berbuat demikian, pemalam CNI pembekal rangkaian memanggil pemalam CNI teras lain untuk mengkonfigurasi pelbagai aspek rangkaian.

Interaksi antara pemalam CNI

Terdapat pelbagai pemalam CNI yang tugasnya adalah untuk membantu menyediakan komunikasi rangkaian antara bekas pada hos. Artikel ini akan membincangkan tiga daripadanya.

pemalam CNI Flanel

Apabila menggunakan Flanel sebagai pembekal rangkaian, komponen Containerd CRI memanggil pemalam CNI Flanelmenggunakan fail konfigurasi CNI /etc/cni/net.d/10-flannel.conflist.

$ cat /etc/cni/net.d/10-flannel.conflist
{
  "name": "cni0",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
         "ipMasq": false,
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    }
  ]
}

Pemalam Flannel CNI berfungsi bersama dengan Flanneld. Semasa permulaan, Flanneld mendapatkan semula podCIDR dan butiran berkaitan rangkaian lain daripada pelayan API dan menyimpannya ke fail /run/flannel/subnet.env.

FLANNEL_NETWORK=10.244.0.0/16 
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450 
FLANNEL_IPMASQ=false

Pemalam Flannel CNI menggunakan data daripada /run/flannel/subnet.env untuk mengkonfigurasi dan memanggil pemalam jambatan CNI.

Pemalam CNI Bridge

Pemalam ini dipanggil dengan konfigurasi berikut:

{
  "name": "cni0",
  "type": "bridge",
  "mtu": 1450,
  "ipMasq": false,
  "isGateway": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24"
  }
}

Apabila dipanggil buat kali pertama, ia mencipta jambatan Linux dengan «name»: «cni0», yang ditunjukkan dalam konfigurasi. Kemudian pasangan veth dicipta untuk setiap pod. Satu hujungnya disambungkan ke ruang nama rangkaian kontena, yang satu lagi disertakan dalam jambatan Linux pada rangkaian hos. Pemalam CNI Bridge menghubungkan semua bekas hos ke jambatan Linux pada rangkaian hos.

Setelah selesai menyediakan pasangan veth, pemalam Bridge memanggil pemalam IPAM CNI hos tempatan. Jenis pemalam IPAM boleh dikonfigurasikan dalam konfigurasi CNI yang digunakan oleh pemalam CRI untuk memanggil pemalam Flannel CNI.

Pemalam IPAM CNI hos tempatan

Jambatan CNI panggilan pemalam IPAM hos tempatan CNI dengan konfigurasi berikut:

{
  "name": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/24",
    "dataDir": "/var/lib/cni/networks"
  }
}

Pemalam IPAM hos tempatan (IP Address Mpengurusan - pengurusan alamat IP) mengembalikan alamat IP untuk bekas dari subnet dan menyimpan IP yang diperuntukkan pada hos dalam direktori yang dinyatakan dalam bahagian dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Fail ini mengandungi ID bekas yang alamat IP ini diberikan.

Apabila memanggil pemalam IPAM hos tempatan, ia mengembalikan data berikut:

{
  "ip4": {
    "ip": "10.244.4.2",
    "gateway": "10.244.4.3"
  },
  "dns": {}
}

Ringkasan

Kube-controller-manager memberikan podCIDR kepada setiap nod. Setiap pod nod menerima alamat IP daripada ruang alamat dalam julat podCIDR yang diperuntukkan. Oleh kerana podCIDR nod tidak bertindih, semua pod menerima alamat IP unik.

Pentadbir kluster Kubernetes mengkonfigurasi dan memasang kubelet, masa jalan kontena, ejen pembekal rangkaian dan menyalin pemalam CNI ke setiap nod. Semasa permulaan, ejen pembekal rangkaian menjana konfigurasi CNI. Apabila pod dijadualkan ke nod, kubelet memanggil pemalam CRI untuk menciptanya. Seterusnya, jika containerd digunakan, pemalam Containerd CRI memanggil pemalam CNI yang dinyatakan dalam konfigurasi CNI untuk mengkonfigurasi rangkaian pod. Akibatnya, pod menerima alamat IP.

Saya mengambil sedikit masa untuk memahami semua kehalusan dan nuansa semua interaksi ini. Saya harap pengalaman ini akan membantu anda memahami dengan lebih baik cara Kubernetes berfungsi. Jika saya salah tentang apa-apa, sila hubungi saya di Twitter atau di alamat [e-mel dilindungi]. Jangan ragu untuk menghubungi jika anda ingin membincangkan aspek artikel ini atau perkara lain. Saya ingin bersembang dengan anda!

Bagaimanakah pod Kubernetes mendapat alamat IP?