როგორ იღებს Kubernetes pod IP მისამართს?

Შენიშვნა. თარგმნა: ეს სტატია, რომელიც დაწერილია LinkedIn-ის SRE ინჟინრის მიერ, დეტალურად განიხილავს Kubernetes-ის შინაგან მაგიას - უფრო ზუსტად, CRI-ს, CNI-სა და kube-apiserver-ის ურთიერთქმედებას - ეს ხდება მაშინ, როდესაც მომდევნო პოდს სჭირდება IP მისამართის მინიჭება.

ერთ-ერთი ძირითადი მოთხოვნა Kubernetes ქსელის მოდელი არის ის, რომ თითოეულ პოდს უნდა ჰქონდეს თავისი IP მისამართი და ნებისმიერ სხვა პოდს კლასტერში უნდა შეეძლოს მასთან დაკავშირება ამ მისამართზე. არსებობს მრავალი ქსელის „პროვაიდერი“ (Flannel, Calico, Canal და ა.შ.), რომლებიც ეხმარება ამ ქსელის მოდელის განხორციელებას.

როდესაც პირველად დავიწყე Kubernetes-თან მუშაობა, ჩემთვის სრულიად გაუგებარი იყო, როგორ იღებენ პოდებს თავიანთი IP მისამართები. იმის გაგებაც კი, თუ როგორ ფუნქციონირებს ცალკეული კომპონენტები, ძნელი წარმოსადგენია მათი ერთობლივი მუშაობა. მაგალითად, ვიცოდი, რისთვის იყო CNI დანამატები, მაგრამ წარმოდგენა არ მქონდა ზუსტად როგორ ერქვა მათ. ამიტომ, გადავწყვიტე დამეწერა ეს სტატია, რათა გამეზიარებინა ცოდნა სხვადასხვა ქსელის კომპონენტების შესახებ და როგორ მუშაობენ ისინი ერთად Kubernetes კლასტერში, რაც საშუალებას აძლევს თითოეულ პოდს მიიღოს საკუთარი უნიკალური IP მისამართი.

Kubernetes-ში ქსელის ორგანიზების სხვადასხვა გზა არსებობს, ისევე როგორც არსებობს კონტეინერების მუშაობის სხვადასხვა ვარიანტი. ეს პუბლიკაცია გამოიყენებს ფლანელი ქსელის ორგანიზება კლასტერში და როგორც შესრულებადი გარემო - კონტეინერი. მე ასევე ვარაუდობ, რომ თქვენ იცით, როგორ მუშაობს კონტეინერებს შორის ქსელი, ამიტომ მოკლედ შევეხები მას, მხოლოდ კონტექსტისთვის.

რამდენიმე ძირითადი კონცეფცია

კონტეინერები და ქსელი: მოკლე მიმოხილვა

ინტერნეტში არის უამრავი შესანიშნავი პუბლიკაცია, რომელიც ხსნის, თუ როგორ ურთიერთობენ კონტეინერები ერთმანეთთან ქსელის საშუალებით. ამიტომ, მე მხოლოდ ზოგად მიმოხილვას მივცემ ძირითად ცნებებს და შემოვიფარგლები ერთი მიდგომით, რომელიც გულისხმობს Linux ხიდის შექმნას და პაკეტების ინკაფსულაციას. დეტალები გამოტოვებულია, რადგან თავად კონტეინერის ქსელის თემა ცალკე სტატიას იმსახურებს. ზოგიერთი განსაკუთრებით გამჭრიახი და საგანმანათლებლო პუბლიკაციების ბმულები მოცემულია ქვემოთ.

კონტეინერები ერთ მასპინძელზე

ერთი და იგივე ჰოსტზე გაშვებულ კონტეინერებს შორის IP მისამართების საშუალებით კომუნიკაციის ორგანიზების ერთ-ერთი გზაა Linux ხიდის შექმნა. ამ მიზნით, ვირტუალური მოწყობილობები იქმნება Kubernetes-ში (და Docker-ში) veth (ვირტუალური ეთერნეტი). Veth მოწყობილობის ერთი ბოლო უერთდება კონტეინერის ქსელის სახელთა სივრცეს, მეორე კი - Linux ხიდი მასპინძელ ქსელში.

ყველა კონტეინერს ერთი და იგივე ჰოსტზე აქვს ვეტის ერთი ბოლო, რომელიც დაკავშირებულია ხიდთან, რომლის მეშვეობითაც მათ შეუძლიათ ერთმანეთთან კომუნიკაცია IP მისამართების საშუალებით. Linux-ის ხიდს ასევე აქვს IP მისამართი და მოქმედებს როგორც კარიბჭე სხვა კვანძებისთვის განკუთვნილი პოდებიდან გასასვლელი ტრაფიკისთვის.

კონტეინერები სხვადასხვა მასპინძლებზე

პაკეტის encapsulation არის ერთ-ერთი მეთოდი, რომელიც საშუალებას აძლევს კონტეინერებს სხვადასხვა კვანძზე დაუკავშირდნენ ერთმანეთს IP მისამართების გამოყენებით. Flannel-ში ტექნოლოგია პასუხისმგებელია ამ შესაძლებლობაზე. vxlan, რომელიც „აფუთებს“ თავდაპირველ პაკეტს UDP პაკეტში და შემდეგ აგზავნის დანიშნულების ადგილზე.

Kubernetes კლასტერში, Flannel ქმნის vxlan მოწყობილობას და შესაბამისად აახლებს მარშრუტების ცხრილს თითოეულ კვანძზე. თითოეული პაკეტი, რომელიც განკუთვნილია კონტეინერისთვის სხვადასხვა ჰოსტზე, გადის vxlan მოწყობილობაში და ჩასმულია UDP პაკეტში. დანიშნულების ადგილას, ჩადგმული პაკეტი ამოღებულია და გადაგზავნილია სასურველ პოდში.

შენიშვნა: ეს არის მხოლოდ ერთი გზა კონტეინერებს შორის ქსელური კომუნიკაციის ორგანიზებისთვის.

რა არის CRI?

CRI (კონტეინერის გაშვების ინტერფეისი) არის დანამატი, რომელიც კუბელეტს საშუალებას აძლევს გამოიყენოს კონტეინერის მუშაობის სხვადასხვა გარემო. CRI API ჩაშენებულია სხვადასხვა გაშვების დროში, ასე რომ მომხმარებლებს შეუძლიათ აირჩიონ მუშაობის დრო.

რა არის CNI?

პროექტი CNI არის სპეციფიკაცია Linux კონტეინერებისთვის უნივერსალური ქსელის გადაწყვეტის ორგანიზება. გარდა ამისა, იგი მოიცავს დანამატები, პასუხისმგებელია სხვადასხვა ფუნქციებზე პოდ ქსელის დაყენებისას. CNI მოდული არის შესრულებადი ფაილი, რომელიც შეესაბამება სპეციფიკაციას (ქვემოთ განვიხილავთ ზოგიერთ დანამატს).

ქვექსელების განაწილება კვანძებზე IP მისამართების მინიჭებისთვის

ვინაიდან კლასტერში თითოეულ პოდს უნდა ჰქონდეს IP მისამართი, მნიშვნელოვანია იმის უზრუნველყოფა, რომ ეს მისამართი უნიკალურია. ეს მიიღწევა თითოეული კვანძის უნიკალური ქვექსელის მინიჭებით, საიდანაც ამ კვანძის პოდებს ენიჭებათ IP მისამართები.

Node IPAM კონტროლერი

როდესაც nodeipam გავიდა დროშის პარამეტრად --controllers kube-კონტროლერი-მენეჯერი, ის გამოყოფს ცალკეულ ქვექსელს (podCIDR) თითოეულ კვანძს კლასტერიდან CIDR (ანუ IP მისამართების დიაპაზონი კლასტერული ქსელისთვის). ვინაიდან ეს podCIDR-ები არ ემთხვევა ერთმანეთს, შესაძლებელი ხდება თითოეულ პოდს გამოეყოს უნიკალური IP მისამართი.

Kubernetes კვანძს ენიჭება podCIDR, როდესაც ის თავდაპირველად რეგისტრირებულია კლასტერში. კვანძების podCIDR-ის შესაცვლელად, თქვენ უნდა გააუქმოთ ისინი და შემდეგ ხელახლა დაარეგისტრიროთ ისინი, შესაბამისი ცვლილებების შეტანით Kubernetes საკონტროლო ფენის კონფიგურაციაში. შეგიძლიათ აჩვენოთ კვანძის podCIDR შემდეგი ბრძანების გამოყენებით:

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

Kubelet, კონტეინერის გაშვების დრო და CNI დანამატები: როგორ მუშაობს ეს ყველაფერი

კვანძის დანიშვნა თითო კვანძზე მოიცავს უამრავ მოსამზადებელ ნაბიჯს. ამ განყოფილებაში ყურადღებას გავამახვილებ მხოლოდ მათზე, რომლებიც პირდაპირ კავშირშია პოდ ქსელის დაყენებასთან.

პოდის დანიშვნა გარკვეულ კვანძზე იწვევს მოვლენების შემდეგ ჯაჭვს:

კითხვა: Containerd CRI დანამატების არქიტექტურა.

ურთიერთქმედება კონტეინერის გაშვებასა და CNI დანამატებს შორის

თითოეულ ქსელის პროვაიდერს აქვს საკუთარი CNI მოდული. კონტეინერის გაშვების დრო აწარმოებს მას პოდისთვის ქსელის კონფიგურაციისთვის, როდესაც ის ამუშავებს. კონტეინერის შემთხვევაში, CNI მოდული გაშვებულია დანამატის მიერ კონტეინერი CRI.

უფრო მეტიც, თითოეულ პროვაიდერს ჰყავს საკუთარი აგენტი. ის დამონტაჟებულია Kubernetes-ის ყველა კვანძზე და პასუხისმგებელია პოდების ქსელის კონფიგურაციაზე. ეს აგენტი ან შედის CNI კონფიგურაციაში ან დამოუკიდებლად ქმნის მას კვანძზე. კონფიგურაცია ეხმარება CRI დანამატს დააყენოს რომელ CNI დანამატს დაურეკოს.

CNI კონფიგურაციის ადგილმდებარეობის მორგება შესაძლებელია; ნაგულისხმევად არის /etc/cni/net.d/<config-file>. კლასტერების ადმინისტრატორები ასევე პასუხისმგებელნი არიან CNI დანამატების დაყენებაზე თითოეულ კლასტერულ კვანძზე. მათი მდებარეობა ასევე მორგებულია; ნაგულისხმევი დირექტორია - /opt/cni/bin.

კონტეინერის გამოყენებისას, დანამატის კონფიგურაციისა და ბინარების ბილიკები შეიძლება დაყენდეს განყოფილებაში [plugins.«io.containerd.grpc.v1.cri».cni] в კონტეინერის კონფიგურაციის ფაილი.

ვინაიდან ჩვენ ვიყენებთ Flannel-ს, როგორც ჩვენი ქსელის პროვაიდერს, მოდით ვისაუბროთ ცოტა მის დაყენებაზე:

• Flanneld (Flannel's daemon) ჩვეულებრივ დაინსტალირებულია კლასტერში, როგორც DaemonSet install-cni როგორც საწყისი კონტეინერი.
• Install-cni ქმნის CNI კონფიგურაციის ფაილი (/etc/cni/net.d/10-flannel.conflist) თითოეულ კვანძზე.
• Flanneld ქმნის vxlan მოწყობილობას, ამოიღებს ქსელის მეტამონაცემებს API სერვერიდან და აკონტროლებს pod განახლებებს. როგორც კი ისინი იქმნება, ის ანაწილებს მარშრუტებს კლასტერში ყველა პოდში.
• ეს მარშრუტები საშუალებას აძლევს პოდებს დაუკავშირდნენ ერთმანეთს IP მისამართების საშუალებით.

ფლანელის მუშაობის შესახებ უფრო დეტალური ინფორმაციისთვის გირჩევთ გამოიყენოთ სტატიის ბოლოს მოცემული ბმულები.

აქ მოცემულია Containerd CRI მოდულისა და CNI დანამატების ურთიერთქმედების დიაგრამა:

როგორც ზემოთ ხედავთ, kubelet უწოდებს Containerd CRI დანამატს პოდის შესაქმნელად, რომელიც შემდეგ უწოდებს CNI დანამატს პოდის ქსელის კონფიგურაციისთვის. ამით, ქსელის პროვაიდერის CNI მოდული მოუწოდებს სხვა ძირითად CNI დანამატებს ქსელის სხვადასხვა ასპექტების კონფიგურაციისთვის.

ურთიერთქმედება CNI დანამატებს შორის

არსებობს სხვადასხვა CNI დანამატები, რომელთა ამოცანაა დაეხმაროს მასპინძელზე კონტეინერებს შორის ქსელური კომუნიკაციის დაყენებაში. ამ სტატიაში განვიხილავთ სამ მათგანს.

CNI მოდული Flannel

ქსელის პროვაიდერად Flannel-ის გამოყენებისას, Containerd CRI კომპონენტი იძახებს CNI მოდული FlannelCNI კონფიგურაციის ფაილის გამოყენებით /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 მოდული მუშაობს Flanneld-თან ერთად. გაშვების დროს, Flanneld ამოიღებს podCIDR და ქსელთან დაკავშირებულ სხვა დეტალებს API სერვერიდან და ინახავს მათ ფაილში /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 მოდული იყენებს მონაცემებს /run/flannel/subnet.env CNI bridge მოდულის კონფიგურაციისთვის და გამოძახებისთვის.

CNI მოდულის ხიდი

ამ დანამატს ეწოდება შემდეგი კონფიგურაციით:

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

პირველად გამოძახებისას ის ქმნის Linux-ის ხიდს «name»: «cni0», რომელიც მითითებულია კონფიგურაციაში. შემდეგ იქმნება ვეთების წყვილი თითოეული ჯიშისთვის. მისი ერთი ბოლო უკავშირდება კონტეინერის ქსელის სახელთა სივრცეს, მეორე შედის Linux ხიდის მასპინძელ ქსელში. CNI მოდულის ხიდი აკავშირებს ყველა ჰოსტის კონტეინერს Linux-ის ხიდთან მასპინძელ ქსელში.

Veth წყვილის დაყენების დასრულების შემდეგ, Bridge მოდული უწოდებს ჰოსტ-ლოკალურ IPAM CNI დანამატს. IPAM მოდულის ტიპის კონფიგურაცია შესაძლებელია CNI კონფიგურაციაში, რომელსაც CRI მოდული იყენებს Flannel CNI მოდულის გამოსაძახებლად.

ჰოსტ-ლოკალური IPAM CNI დანამატები

Bridge CNI ზარები ჰოსტ-ლოკალური IPAM მოდული CNI შემდეგი კონფიგურაციით:

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

ჰოსტ-ლოკალური IPAM მოდული (IP Address Mმენეჯმენტი - IP მისამართის მართვა) აბრუნებს კონტეინერის IP მისამართს ქვექსელიდან და ინახავს გამოყოფილ IP-ს ჰოსტზე განყოფილებაში მითითებულ დირექტორიაში. dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. ეს ფაილი შეიცავს კონტეინერის ID-ს, რომელსაც ეს IP მისამართი აქვს მინიჭებული.

მასპინძლის ლოკალური IPAM მოდულის გამოძახებისას ის აბრუნებს შემდეგ მონაცემებს:

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

რეზიუმე

Kube-კონტროლერი-მენეჯერი თითოეულ კვანძს ანიჭებს podCIDR-ს. თითოეული კვანძის პოდი იღებს IP მისამართებს მისამართების სივრციდან გამოყოფილი podCIDR დიაპაზონში. ვინაიდან კვანძების podCIDR-ები ერთმანეთს არ ემთხვევა, ყველა პოდი იღებს უნიკალურ IP მისამართებს.

Kubernetes კლასტერის ადმინისტრატორი აკონფიგურირებს და აყენებს kubelet-ს, კონტეინერის გაშვების დროს, ქსელის პროვაიდერის აგენტს და აკოპირებს CNI დანამატებს თითოეულ კვანძში. გაშვების დროს, ქსელის პროვაიდერის აგენტი ქმნის CNI კონფიგურაციას. როდესაც pod არის დაგეგმილი კვანძში, kubelet მოუწოდებს CRI დანამატს მის შესაქმნელად. შემდეგი, თუ კონტეინერი გამოიყენება, Containerd CRI მოდული მოუწოდებს CNI მოდულს, რომელიც მითითებულია CNI კონფიგურაციაში, რათა დააკონფიგურიროთ პოდის ქსელი. შედეგად, pod იღებს IP მისამართს.

გარკვეული დრო დამჭირდა ყველა ამ ურთიერთქმედების ყველა დახვეწილობისა და ნიუანსის გასაგებად. იმედი მაქვს, რომ ეს გამოცდილება დაგეხმარებათ უკეთ გაიგოთ, თუ როგორ მუშაობს Kubernetes. თუ რამეში ვცდები, გთხოვთ დამიკავშირდეთ ნომერზე Twitter ან მისამართზე [ელ.ფოსტით დაცულია]. თავისუფლად დაუკავშირდით, თუ გსურთ ამ სტატიის ან სხვა რაიმე ასპექტების განხილვა. მე სიამოვნებით ვისაუბრებ შენთან!

ლიტერატურა

კონტეინერები და ქსელი

• კონტეინერის ქსელის მიმოხილვა
• კონტეინერების ქსელის დემისტიფიკაცია

როგორ მუშაობს ფლანელი?

• Flannel Networking Demystify
• Kubernetes With Flannel - ქსელის გაგება

CRI და CNI

• CRI Plugin Architecture
• CNI სპეც
• CNI დანამატები

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «Calico კუბერნეტში ქსელისთვის: შესავალი და მცირე გამოცდილება";
• "ილუსტრირებული გზამკვლევი ქსელში Kubernetes-ში": ნაწილები 1 და 2 (ქსელის მოდელი, გადაფარვის ქსელები), ნაწილი 3 (მომსახურება და ტრაფიკის დამუშავება);
• «Container Networking Interface (CNI) - ქსელის ინტერფეისი და სტანდარტი Linux კონტეინერებისთვის".

წყარო: www.habr.com