Not. tercüme: LinkedIn'den bir SRE mühendisi tarafından yazılan bu makale, Kubernetes'in bir sonraki bölmeye bir IP adresi atanması gerektiğinde meydana gelen iç büyüsü, daha doğrusu CRI, CNI ve kube-apserver etkileşimi hakkında ayrıntılara giriyor.
Temel gereksinimlerden biri her bölmenin kendi IP adresine sahip olması ve kümedeki diğer bölmelerin bu adresten onunla iletişim kurabilmesi gerekir. Bu ağ modelinin uygulanmasına yardımcı olan birçok ağ “sağlayıcısı” (Flannel, Calico, Canal, vb.) vardır.
Kubernetes ile ilk çalışmaya başladığımda, bölmelerin IP adreslerini tam olarak nasıl aldıkları benim için tam olarak açık değildi. Bireysel bileşenlerin nasıl çalıştığını anlasak bile, bunların birlikte çalıştığını hayal etmek zordu. Örneğin, CNI eklentilerinin ne işe yaradığını biliyordum ama tam olarak nasıl çağrıldıkları hakkında hiçbir fikrim yoktu. Bu nedenle, çeşitli ağ bileşenleri ve bunların her bir bölmenin kendi benzersiz IP adresini almasına olanak tanıyan bir Kubernetes kümesinde birlikte nasıl çalıştıkları hakkındaki bilgileri paylaşmak için bu makaleyi yazmaya karar verdim.
Tıpkı konteynerler için farklı çalışma zamanı seçeneklerinin olduğu gibi, Kubernetes'te ağ iletişimini düzenlemenin de farklı yolları vardır. Bu yayında kullanılacak ağı bir kümede ve yürütülebilir bir ortam olarak düzenlemek için - . Ayrıca konteynerler arasında ağ oluşturmanın nasıl çalıştığını bildiğinizi varsayıyorum, bu yüzden sadece bağlam için buna kısaca değineceğim.
Bazı temel kavramlar
Konteynerler ve Ağ: Kısa Bir Genel Bakış
İnternette konteynerlerin ağ üzerinden birbirleriyle nasıl iletişim kurduğunu açıklayan çok sayıda mükemmel yayın bulunmaktadır. Bu nedenle, yalnızca temel kavramlara genel bir bakış sunacağım ve kendimi bir Linux köprüsü oluşturmayı ve paketleri kapsüllemeyi içeren tek bir yaklaşımla sınırlayacağım. Konteyner ağı konusu ayrı bir makaleyi hak ettiğinden ayrıntılar atlanmıştır. Özellikle aydınlatıcı ve eğitici yayınlardan bazılarına bağlantılar aşağıda verilecektir.
Bir ana bilgisayardaki kapsayıcılar
Aynı ana bilgisayarda çalışan konteynerler arasındaki IP adresleri aracılığıyla iletişimi organize etmenin bir yolu, bir Linux köprüsü oluşturmaktır. Bu amaçla Kubernetes'te (ve Docker'da) sanal cihazlar oluşturulur. . Veth cihazının bir ucu konteynerin ağ ad alanına, diğer ucu ise konteynerin ağ ad alanına bağlanır. ana bilgisayar ağında.
Aynı ana bilgisayardaki tüm konteynerlerin, IP adresleri aracılığıyla birbirleriyle iletişim kurabilecekleri bir köprüye bağlı bir ucu vardır. Linux köprüsünün ayrıca bir IP adresi vardır ve diğer düğümlere yönelik bölmelerden gelen çıkış trafiği için bir ağ geçidi görevi görür.
Farklı ana bilgisayarlardaki kapsayıcılar
Paket kapsülleme, farklı düğümlerdeki kapların IP adreslerini kullanarak birbirleriyle iletişim kurmasına olanak tanıyan bir yöntemdir. Flannel'da bu fırsattan teknoloji sorumludur. Orijinal paketi bir UDP paketine "paketleyen" ve ardından hedefine gönderen.
Flannel, bir Kubernetes kümesinde bir vxlan cihazı oluşturur ve her düğümdeki rota tablosunu buna göre günceller. Farklı bir ana bilgisayardaki bir konteynere gönderilen her paket, vxlan cihazından geçer ve bir UDP paketinde kapsüllenir. Hedefte iç içe geçmiş paket çıkarılır ve istenen bölmeye iletilir.
Not: Bu, kapsayıcılar arasındaki ağ iletişimini düzenlemenin yalnızca bir yoludur.
CRI nedir?
kubelet'in farklı konteyner çalışma zamanı ortamlarını kullanmasına olanak tanıyan bir eklentidir. CRI API çeşitli çalışma zamanlarında yerleşiktir, böylece kullanıcılar istedikleri çalışma zamanını seçebilirler.
CNI nedir?
kendilerini temsil et Linux kapsayıcıları için evrensel bir ağ çözümü düzenlemek. Ayrıca şunları içerir: , bir pod ağı kurarken çeşitli işlevlerden sorumludur. CNI eklentisi spesifikasyona uygun yürütülebilir bir dosyadır (bazı eklentileri aşağıda tartışacağız).
Bölmelere IP adresleri atamak için alt ağların düğümlere tahsisi
Bir kümedeki her bölmenin bir IP adresine sahip olması gerektiğinden bu adresin benzersiz olmasını sağlamak önemlidir. Bu, her düğüme benzersiz bir alt ağ atanarak elde edilir ve bu alt ağdan o düğümdeki bölmelere daha sonra IP adresleri atanır.
Düğüm IPAM Denetleyicisi
Ne zaman nodeipam bayrak parametresi olarak geçti --controllers CIDR kümesindeki her düğüme ayrı bir alt ağ (podCIDR) tahsis eder (yani küme ağı için IP adresleri aralığı). Bu podCIDR'ler çakışmadığı için her bir pod'a benzersiz bir IP adresi tahsis edilmesi mümkün hale gelir.
Bir Kubernetes düğümüne, kümeye ilk kez kaydedildiğinde bir podCIDR atanır. Düğümlerin podCIDR'sini değiştirmek için, bunların kaydını silmeniz ve ardından yeniden kaydetmeniz ve arada Kubernetes kontrol katmanı yapılandırmasında uygun değişiklikleri yapmanız gerekir. Aşağıdaki komutu kullanarak bir düğümün podCIDR'sini görüntüleyebilirsiniz:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, konteyner çalışma zamanı ve CNI eklentileri: her şey nasıl çalışır?
Düğüm başına bir kapsül planlamak birçok hazırlık adımını içerir. Bu bölümde sadece pod ağı kurulumuyla doğrudan ilgili olanlara odaklanacağım.
Belirli bir düğüme bir bölmenin planlanması aşağıdaki olaylar zincirini tetikler:
SSS: .
Konteyner çalışma zamanı ile CNI eklentileri arasındaki etkileşim
Her ağ sağlayıcısının kendi CNI eklentisi vardır. Kapsayıcının çalışma zamanı, başlatılırken bölmenin ağını yapılandırmak için onu çalıştırır. Containerd durumunda, CNI eklentisi eklenti tarafından başlatılır .
Üstelik her sağlayıcının kendi acentesi vardır. Tüm Kubernetes düğümlerine kurulur ve bölmelerin ağ yapılandırmasından sorumludur. Bu aracı ya CNI yapılandırmasına dahildir ya da onu düğümde bağımsız olarak oluşturur. Yapılandırma, CRI eklentisinin hangi CNI eklentisinin çağrılacağını belirlemesine yardımcı olur.
CNI yapılandırmasının konumu özelleştirilebilir; varsayılan olarak şuradadır /etc/cni/net.d/<config-file>. Küme yöneticileri ayrıca her küme düğümüne CNI eklentilerinin yüklenmesinden de sorumludur. Konumları da özelleştirilebilir; varsayılan dizin - /opt/cni/bin.
Containerd kullanırken, eklenti yapılandırması ve ikili dosyalar için yollar bölümde ayarlanabilir. [plugins.«io.containerd.grpc.v1.cri».cni] в .
Ağ sağlayıcımız olarak Flannel'ı kullandığımız için, kurulumundan biraz bahsedelim:
- Flanneld (Flannel'ın arka plan programı) genellikle bir kümeye DaemonSet olarak kurulur.
install-cnigibi . Install-cniyaratır (/etc/cni/net.d/10-flannel.conflist) her düğümde.- Flanneld bir vxlan cihazı oluşturur, API sunucusundan ağ meta verilerini alır ve pod güncellemelerini izler. Oluşturuldukça rotaları kümedeki tüm bölmelere dağıtır.
- Bu yollar, bölmelerin IP adresleri aracılığıyla birbirleriyle iletişim kurmasına olanak tanır.
Flannel'in çalışmaları hakkında daha detaylı bilgi için yazının sonundaki linkleri kullanmanızı tavsiye ederim.
Aşağıda Containerd CRI eklentisi ile CNI eklentileri arasındaki etkileşimin bir diyagramı verilmiştir:
Yukarıda görebileceğiniz gibi kubelet, pod'u oluşturmak için Containerd CRI eklentisini çağırır ve daha sonra pod'un ağını yapılandırmak için CNI eklentisini çağırır. Bunu yaparken ağ sağlayıcının CNI eklentisi, ağın çeşitli yönlerini yapılandırmak için diğer temel CNI eklentilerini çağırır.
CNI eklentileri arasındaki etkileşim
Görevi ana bilgisayardaki konteynerler arasında ağ iletişimi kurmaya yardımcı olmak olan çeşitli CNI eklentileri vardır. Bu makale bunlardan üçünü tartışacak.
CNI eklentisi Flanel
Flannel'ı ağ sağlayıcısı olarak kullanırken, Containerd CRI bileşeni çağrılar CNI yapılandırma dosyasını kullanma /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
}
}
]
}
Flannel CNI eklentisi Flanneld ile birlikte çalışır. Flanneld, başlatma sırasında podCIDR'yi ve ağla ilgili diğer ayrıntıları API sunucusundan alır ve bunları bir dosyaya kaydeder. /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Flannel CNI eklentisi aşağıdaki verileri kullanır: /run/flannel/subnet.env CNI köprü eklentisini yapılandırmak ve çağırmak için.
CNI eklentisi Köprüsü
Bu eklenti aşağıdaki konfigürasyonla çağrılır:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
İlk kez çağrıldığında bir Linux köprüsü oluşturur. «name»: «cni0», yapılandırmada belirtilir. Daha sonra her bölme için bir veth çifti oluşturulur. Bir ucu konteynerin ağ ad alanına bağlanır, diğer ucu ise ana bilgisayar ağındaki Linux köprüsüne dahil edilir. tüm ana bilgisayar kapsayıcılarını ana bilgisayar ağındaki bir Linux köprüsüne bağlar.
Veth çiftinin kurulumunu tamamladıktan sonra Bridge eklentisi, ana bilgisayar-yerel IPAM CNI eklentisini çağırır. IPAM eklenti türü, CRI eklentisinin Flannel CNI eklentisini çağırmak için kullandığı CNI yapılandırmasında yapılandırılabilir.
Yerel ana IPAM CNI eklentileri
CNI çağrılarını köprüle aşağıdaki konfigürasyonla:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Ana makine-yerel IPAM eklentisi (IP Adres Myönetimi - IP adresi yönetimi) alt ağdan konteynerin IP adresini döndürür ve tahsis edilen IP'yi ana bilgisayarda bölümde belirtilen dizinde saklar dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Bu dosya, bu IP adresinin atandığı konteynerin kimliğini içerir.
Ana makine-yerel IPAM eklentisini çağırırken aşağıdaki verileri döndürür:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Özet
Kube denetleyici yöneticisi her düğüme bir podCIDR atar. Her düğümün bölmeleri, tahsis edilen podCIDR aralığındaki adres alanından IP adresleri alır. Düğümlerin podCIDR'leri çakışmadığından tüm bölmeler benzersiz IP adresleri alır.
Kubernetes kümesi yöneticisi kubelet'i, konteyner çalışma zamanını, ağ sağlayıcı aracısını yapılandırıp yükler ve CNI eklentilerini her düğüme kopyalar. Başlangıç sırasında ağ sağlayıcı aracısı bir CNI yapılandırması oluşturur. Bir düğüme bir kapsül planlandığında kubelet, onu oluşturmak için CRI eklentisini çağırır. Daha sonra, konteynerd kullanılırsa Containerd CRI eklentisi, bölmenin ağını yapılandırmak için CNI yapılandırmasında belirtilen CNI eklentisini çağırır. Sonuç olarak bölme bir IP adresi alır.
Tüm bu etkileşimlerin tüm inceliklerini ve nüanslarını anlamam biraz zaman aldı. Bu deneyimin Kubernetes'in nasıl çalıştığını daha iyi anlamanıza yardımcı olacağını umuyorum. Herhangi bir konuda yanılıyorsam lütfen benimle iletişime geçin veya adreste . Bu makalenin bazı yönlerini veya başka herhangi bir konuyu tartışmak isterseniz bize ulaşmaktan çekinmeyin. Seninle sohbet etmeyi çok isterim!
referanslar
Konteynerler ve ağ
Flanel nasıl çalışır?
CRI ve CNI
çevirmenden PS
Blogumuzda da okuyun:
- «";
- "Kubernetes'te Ağ Oluşturmaya Yönelik Resimli Bir Kılavuz": , ;
- «'.
Kaynak: habr.com