Kubernetes 1.17: ახალი ამბების ხაზგასმა

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

ამ მასალის მომზადებისთვის გამოყენებული ინფორმაცია აღებულია ოფიციალური განცხადებიდან, Kubernetes-ის გაფართოებების თვალთვალის ცხრილები, CHANGELOG-1.17 და დაკავშირებული საკითხები, pull-ის მოთხოვნები და Kubernetes Enhancement Proposals (KEP). Რა არის ახალი?..

ტოპოლოგიის მცოდნე მარშრუტიზაცია

კუბერნეტის საზოგადოება დიდი ხანია ელოდება ამ ფუნქციას - ტოპოლოგიის მცოდნე სერვისის მარშრუტიზაცია. თუ CAP ის სათავეს იღებს 2018 წლის ოქტომბერში და ოფიციალური გაფართოება — 2 წლის წინ, ჩვეულებრივი საკითხები (როგორც ამ) - და კიდევ რამდენიმე წლით უფროსი...

ზოგადი იდეა მდგომარეობს იმაში, რომ უზრუნველყოს "ლოკალური" მარშრუტიზაციის შესაძლებლობა Kubernetes-ში მცხოვრები სერვისებისთვის. „ლოკალურობა“ ამ შემთხვევაში ნიშნავს „იგივე ტოპოლოგიურ დონეს“ (ტოპოლოგიის დონე), რომელიც შეიძლება იყოს:

• სერვისებისთვის იდენტური კვანძი,
• იგივე სერვერის თარო,
• იგივე რეგიონი
• იგივე ღრუბლოვანი პროვაიდერი,
• ...

ამ ფუნქციის გამოყენების მაგალითები:

• დაზოგვა ტრაფიკზე ღრუბლოვან ინსტალაციაში მრავალი ხელმისაწვდომობის ზონით (multi-AZ) - იხ. ახალი ილუსტრაცია AWS-ში ერთი და იმავე რეგიონის, მაგრამ სხვადასხვა AZ-ების ტრაფიკის მაგალითის გამოყენებით;
• დაბალი შესრულების შეყოვნება / უკეთესი გამტარუნარიანობა;
• გახეხილი სერვისი, რომელსაც აქვს ადგილობრივი ინფორმაცია კვანძის შესახებ თითოეულ ფრაგმენტში;
• fluentd-ის (ან ანალოგების) განთავსება იმავე კვანძზე იმ აპლიკაციებთან, რომელთა ჟურნალები შეგროვებულია;
• ...

ასეთ მარშრუტიზაციას, რომელმაც "იცის" ტოპოლოგიის შესახებ, ასევე უწოდებენ ქსელის აფინურობას - ანალოგიით. კვანძის მიახლოება, pod affinity/anti-affinity ან გამოჩნდა არც ისე დიდი ხნის წინ ტოპოლოგია-ცნობილი მოცულობის განრიგი (და მოცულობის უზრუნველყოფა). განხორციელების ამჟამინდელი დონე ServiceTopology Kubernetes-ში - ალფა ვერსია.

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

IPv4/IPv6 ორმაგი სტეკის მხარდაჭერა

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

• კუბე-პროქსიში განხორციელდა ორივე რეჟიმში (IPv4 და IPv6) ერთდროული მუშაობის შესაძლებლობა;
• в Pod.Status.PodIPs გამოჩნდა დაღმავალი API-ს მხარდაჭერა (ამავე დროს, როგორც შიგნით /etc/hosts ახლა ისინი მოითხოვენ მასპინძელს IPv6 მისამართის დამატებას);
• ორმაგი სტეკის მხარდაჭერა ᲙᲔᲗᲘᲚᲘ (Kubernetes IN Docker) და kubeadm;
• განახლებული e2e ტესტები.

ილუსტრაცია ორმაგი სტეკის IPV4/IPv6 გამოყენებით KIND-ში

პროგრესი CSI-ში

სტაბილურად გამოცხადდა ტოპოლოგიის მხარდაჭერა CSI-ზე დაფუძნებული შენახვისთვის, პირველად შემოღებული K8s 1.12.

ინიციატივა მოცულობის დანამატების მიგრაცია CSI-ში - CSI მიგრაცია - მიღწეული ბეტა ვერსია. ეს ფუნქცია გადამწყვეტია არსებული საცავის დანამატების თარგმნისთვის (ხეში) თანამედროვე ინტერფეისისთვის (CSI, ხის გარეთ) უხილავი Kubernetes-ის საბოლოო მომხმარებლებისთვის. კლასტერების ადმინისტრატორებს მხოლოდ CSI Migration-ის ჩართვა დასჭირდებათ, რის შემდეგაც არსებული სახელმწიფო რესურსები და სამუშაო დატვირთვები გააგრძელებენ „უბრალოდ მუშაობას“... მაგრამ იყენებენ უახლესი CSI დრაივერების ნაცვლად Kubernetes-ის ბირთვში შემავალი მოძველებული დრაივერების ნაცვლად.

ამ დროისთვის, AWS EBS დრაივერების მიგრაცია მზად არის ბეტა ვერსიაში (kubernetes.io/aws-ebs) და GCE PD (kubernetes.io/gce-pd). სხვა საცავის პროგნოზები შემდეგია:

ჩვენ ვისაუბრეთ იმაზე, თუ როგორ მოვიდა "ტრადიციული" შენახვის მხარდაჭერა K8-ებში CSI-ში ეს მუხლი. და CSI მიგრაციის ბეტა სტატუსზე გადასვლას ეძღვნება ცალკე გამოცემა პროექტის ბლოგზე.

გარდა ამისა, კიდევ ერთი მნიშვნელოვანი ფუნქციონალობა CSI-ს კონტექსტში, რომელიც წარმოიშვა (ალფა განხორციელება) K1.17s 8-ში, მიაღწია ბეტა სტატუსს (ანუ ნაგულისხმევად ჩართულია) Kubernetes 1.12 გამოშვებაში - სნეფშოტების შექმნა და მათგან აღდგენა. Kubernetes Volume Snapshot-ში განხორციელებულ ცვლილებებს შორის ბეტა გამოშვების გზაზე:

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

1.17 გამოშვების დროს ფუნქციას მხარს უჭერს სამი CSI დრაივერი: GCE Persistent Disk CSI Driver, Portworx CSI Driver და NetApp Trident CSI Driver. დამატებითი დეტალები მისი განხორციელებისა და გამოყენების შესახებ შეგიძლიათ იხილოთ აქ ეს პუბლიკაცია ბლოგზე.

Cloud Provider Labels

ეტიკეტები, რომლებიც ავტომატურად ენიჭება შექმნილ კვანძებსა და ტომებს, გამოყენებული ღრუბლოვანი პროვაიდერის მიხედვით, ხელმისაწვდომია Kubernetes-ში, როგორც ბეტა ვერსია ძალიან დიდი ხნის განმავლობაში - K8s 1.2-ის გამოსვლის შემდეგ. (2016 წლის აპრილი!). ამდენი ხნის განმავლობაში მათი ფართო გამოყენების გათვალისწინებით, დეველოპერები გადავწყვიტე, რომ დროა გამოვაცხადოთ ფუნქცია სტაბილურად (GA).

ამიტომ, მათ ყველა დაარქვეს შესაბამისად (ტოპოლოგიის მიხედვით):

• beta.kubernetes.io/instance-type → node.kubernetes.io/instance-type
• failure-domain.beta.kubernetes.io/zone → topology.kubernetes.io/zone
• failure-domain.beta.kubernetes.io/region → topology.kubernetes.io/region

... მაგრამ კვლავ ხელმისაწვდომია მათი ძველი სახელებით (უკანა თავსებადობისთვის). თუმცა, ყველა ადმინისტრატორს რეკომენდირებულია გადაერთოს მიმდინარე ლეიბლებზე. დაკავშირებული დოკუმენტაცია K8s განახლებულია.

kubeadm-ის სტრუქტურირებული გამომავალი

პირველად წარმოდგენილია ალფა ვერსიაში სტრუქტურირებული გამომავალი kubeadm უტილიტასთვის. მხარდაჭერილი ფორმატები: JSON, YAML, Go შაბლონი.

ამ ფუნქციის განხორციელების მოტივაცია (შესაბამისად CAP) არის:

მიუხედავად იმისა, რომ Kubernetes შეიძლება განლაგდეს ხელით, ამ ოპერაციის დე ფაქტო (თუ არა დე იურე) სტანდარტია kubeadm-ის გამოყენება. სისტემების მართვის პოპულარული ინსტრუმენტები, როგორიცაა Terraform, ეყრდნობა kubeadm-ს Kubernetes-ის განლაგებისთვის. Cluster API-ში დაგეგმილი გაუმჯობესებები მოიცავს Kubernetes-ის ჩატვირთვის პაკეტს kubeadm-ით და cloud-init-ით.

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

ჩვენი უშუალო გეგმები მოიცავს მხარდაჭერას (სტრუქტურირებული გამომავალი სახით) შემდეგი kubeadm ბრძანებებისთვის:

• alpha certs
• config images list
• init
• token create
• token list
• upgrade plan
• version

JSON პასუხის ილუსტრაცია ბრძანებაზე kubeadm init -o json:

{
  "node0": "192.168.20.51:443",
  "caCrt": "sha256:1f40ff4bd1b854fb4a5cf5d2f38267a5ce5f89e34d34b0f62bf335d74eef91a3",
  "token": {
    "id":          "5ndzuu.ngie1sxkgielfpb1",
    "ttl":         "23h",
    "expires":     "2019-05-08T18:58:07Z",
    "usages":      [
      "authentication",
      "signing"
    ],
    "description": "The default bootstrap token generated by 'kubeadm init'.",
    "extraGroups": [
      "system:bootstrappers:kubeadm:default-node-token"
    ]
  },
  "raw": "Rm9yIHRoZSBhY3R1YWwgb3V0cHV0IG9mIHRoZSAia3ViZWFkbSBpbml0IiBjb21tYW5kLCBwbGVhc2Ugc2VlIGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2FrdXR6LzdhNjg2ZGU1N2JmNDMzZjkyZjcxYjZmYjc3ZDRkOWJhI2ZpbGUta3ViZWFkbS1pbml0LW91dHB1dC1sb2c="
}

სხვა ინოვაციების სტაბილიზაცია

ზოგადად, Kubernetes 1.17-ის გამოშვება მოხდა დევიზით ”სტაბილურობა" ამას ხელი შეუწყო იმან, რომ მასში ბევრი მახასიათებელია (მათი საერთო რაოდენობაა 14) მიიღო GA სტატუსი. Მათ შორის:

• კვანძების „მონიშვნა“ გარკვეული პირობების მიხედვით (TaintNodesByCondition), გამოჩნდა K8s 1.8;
• უყურეთ სანიშნეებს - ახალი ტიპის ღონისძიებები, რომლებსაც აქვთ ეტიკეტი, რომ ყველა ობიექტი შეესაბამება გარკვეულ ვერსიას (resourceVersion) უკვე დამუშავებულია საათით;
• ნაგულისხმევი მნიშვნელობები (ნაგულისხმევი) მორგებული რესურსებისთვის;
• გაზიარებული კონტეინერებს შორის pod პროცესის სახელთა სივრცეებში;
• ScheduleDaemonSetPods - დისპლეის დაგეგმვა DaemonSet-ში kube-scheduler-ის გამოყენებით (DaemonSet კონტროლერის ნაცვლად);
• დინამიური საზღვრები კვანძის ტიპის მიხედვით მოცულობების რაოდენობაზე;
• გარემოს ცვლადის მხარდაჭერა დირექტორია სახელებისთვის, რომლებიც დამონტაჟებულია როგორც subPath;
• კუბელეტის გულისცემის გადაცემა სპეციალიზებულ Lease API-ს;
• "ფინალიზატორის დაცვა" (ფინალიზატორის დაცვა) დატვირთვის ბალანსერებისთვის (შესაბამისი სერვისის რესურსების შემოწმება LoadBalancer რესურსების წაშლამდე);
• kube-apiserver ოპტიმიზაცია მრავალჯერადი საათებით მუშაობისას, ობიექტების იდენტური ნაკრების მონიტორინგისას - მიიღწევა თითოეული დამკვირვებლისთვის ერთი და იგივე ობიექტების განმეორებითი სერიალიზაციის თავიდან აცილებით.

სხვა ცვლილებები

ინოვაციების სრული სია Kubernetes 1.17-ში, რა თქმა უნდა, არ შემოიფარგლება ზემოთ ჩამოთვლილით. აქ არის რამდენიმე სხვა (და უფრო სრული სიისთვის იხ შეცვლა):

• ბოლო გამოშვებაში წარმოდგენილი ფუნქცია მიაღწია ბეტა ვერსიას RunAsUserName ფანჯრებისთვის;
• მსგავსი ცვლილება დაემართა EndpointSlice API (ასევე K8s 1.16-დან), თუმცა ამ დროისთვის ეს გამოსავალი Endpoint API-ის მუშაობის/მაშტაბურობის გასაუმჯობესებლად ნაგულისხმევად არ არის ჩართული;
• ღეროები ახლა გადამწყვეტია კასეტური მუშაობისთვის შეიძლება შეიქმნას არა მხოლოდ სახელთა სივრცეებში kube-system (დეტალებისთვის იხილეთ დოკუმენტაცია პრიორიტეტული კლასის მოხმარების შეზღუდვა);
• ახალი ვარიანტი კუბელეტისთვის - --reserved-cpus — საშუალებას გაძლევთ ცალსახად განსაზღვროთ სისტემისთვის რეზერვირებული CPU-ების სია;
• ამისთვის kubectl logs წარმოდგენილია ახალი დროშა --prefix, ჩანაწერის თითოეულ სტრიქონზე pod და წყაროს კონტეინერის სახელის დამატება;
• в label.Selector დაემატა RequiresExactMatch;
• ყველა კონტეინერი kube-dns-ში ახლა გარბიან ნაკლები პრივილეგიებით;
• ჰიპერკუბი გამოყოფილია ცალკე GitHub საცავში და აღარ იქნება ჩართული Kubernetes-ის გამოშვებებში;
• ბევრი გაუმჯობესებული შესრულება kube-პროქსი არა UDP პორტებისთვის.

დამოკიდებულების ცვლილებები:

• kubeadm-ში ჩართული CoreDNS ვერსია არის 1.6.5;
• crictl ვერსია განახლებულია v1.16.1-ზე;
• CSI 1.2.0;
• და ა.შ. 3.4.3;
• უახლესი ტესტირება Docker ვერსია განახლებულია 19.03-მდე;
• მინიმალური Go ვერსია, რომელიც საჭიროა Kubernetes 1.17-ის შესაქმნელად არის 1.13.4.

PS

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

• «Kubernetes 1.16: ახალი ამბების ხაზგასმა";
• «Kubernetes 1.15: ახალი ამბების ხაზგასმა";
• «Kubernetes 1.14: ახალი ამბების ხაზგასმა";
• «Kubernetes 1.13: ახალი ამბების ხაზგასმა".

წყარო: www.habr.com