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

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

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

დავიწყოთ მნიშვნელოვანი შესავალი SIG კლასტერ-სიცოცხლის ციკლიდან: დინამიური ჩავარდნის კლასტერები Kubernetes (ან უფრო ზუსტად რომ ვთქვათ, თვითმმართველობის HA განლაგება) არის ახლა შეიძლება შეიქმნას ნაცნობი (ერთი კვანძის კლასტერების კონტექსტში) ბრძანებების გამოყენებით kubeadm (init и join). მოკლედ ამისთვის:

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

Kubeadm-ით შექმნილი Kubernetes HA კლასტერის არქიტექტურა

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

API

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

განხორციელების შესახებ დეტალები მოცემულია CAP. ამჟამინდელი მზადყოფნა არის ალფა (ბეტაზე დაწინაურება იგეგმება Kubernetes-ის შემდეგი გამოშვებისთვის).

ხელმისაწვდომია ალფა ვერსიაში შესაძლებლობა OpenAPI v3 სქემის გამოყენებით OpenAPI დოკუმენტაციის შექმნა და გამოქვეყნება CustomResources-ისთვის (CR) გამოიყენება (სერვერის მხრიდან) K8s მომხმარებლის მიერ განსაზღვრული რესურსების დასადასტურებლად (CustomResourceDefinition, CRD). CRD-ისთვის OpenAPI-ის გამოქვეყნება საშუალებას აძლევს კლიენტებს (მაგ. kubectl) შეასრულეთ ვალიდაცია თქვენს მხარეს (შიგ kubectl create и kubectl apply) და გასცემს დოკუმენტაციას სქემის მიხედვით (kubectl explain). დეტალები - in CAP.

წინასწარ არსებული ჟურნალები ახლა იხსნება დროშით O_APPEND (მაგრამ არა O_TRUNC) მორების დაკარგვის თავიდან აცილების მიზნით ზოგიერთ სიტუაციაში და მორების შეკვეცის მოხერხებულობისთვის გარე კომუნალური საშუალებებით ბრუნვისთვის.

ასევე Kubernetes API-ის კონტექსტში, შეიძლება აღინიშნოს, რომ ქ PodSandbox и PodSandboxStatus დაემატა სფეროში runtime_handler შესახებ ინფორმაციის ჩასაწერად RuntimeClass პოდში (დაწვრილებით ამის შესახებ წაიკითხეთ ტექსტში Kubernetes 1.12 გამოშვება, სადაც ეს კლასი გამოჩნდა როგორც ალფა ვერსია) და Admission Webhooks-ში განხორციელდა ვერსიების განსაზღვრის უნარი AdmissionReview მხარს უჭერენ. დაბოლოს, დაშვების Webhooks წესები ახლა არის შეიძლება შეიზღუდოს მათი გამოყენების მასშტაბი სახელთა სივრცისა და კლასტერული ჩარჩოების მიხედვით.

შენახვა

PersistentLocalVolumes, რომელსაც ჰქონდა ბეტა სტატუსი გამოშვების შემდეგ K8s 1.10, გამოაცხადა სტაბილური (GA): ეს ფუნქციების კარი აღარ არის გამორთული და წაიშლება Kubernetes 1.17-ში.

შესაძლებლობა გარემოს ცვლადების გამოყენებით ე.წ Downward API (მაგალითად, პოდის სახელი) დაყენებული დირექტორიების სახელებისთვის subPath, განვითარდა - ახალი დარგის სახით subPathExpr, რომელიც ახლა გამოიყენება სასურველი დირექტორია სახელის დასადგენად. ფუნქცია თავდაპირველად გამოჩნდა Kubernetes 1.11-ში, მაგრამ 1.14-ისთვის ის დარჩა ალფა ვერსიის სტატუსში.

როგორც Kubernetes-ის წინა გამოშვებაში, ბევრი მნიშვნელოვანი ცვლილებაა დანერგილი აქტიურად განვითარებადი CSI (კონტეინერის შენახვის ინტერფეისი):

CSI

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

CSI-ის კიდევ ერთი ფუნქცია ალფა ვერსიაში - შესაძლებლობა მიმართეთ პირდაპირ (ე.ი. PV/PVC გამოყენების გარეშე) CSI ტომებს pod სპეციფიკაციის ფარგლებში. ეს ხსნის CSI-ის, როგორც ექსკლუზიურად დისტანციური მონაცემთა შენახვის შეზღუდვას, გააღო კარი მათთვის სამყაროში ადგილობრივი ეფემერული მოცულობები. Გამოყენებისთვის (მაგალითი დოკუმენტაციიდან) უნდა იყოს ჩართული CSIInlineVolume მხატვრული კარიბჭე.

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

ამ ყველაფერმა განაპირობა ის, რომ ალფა ვერსიამ მიაღწია მიგრაციის პროცესი შიდა მოდულის კოდი, დანერგილი როგორც ხეში, CSI დანამატებში, რის წყალობითაც დეველოპერების საზრუნავი შემცირდება მათი დანამატების ერთი ვერსიის მხარდაჭერამდე, ხოლო ძველ API-ებთან თავსებადობა დარჩება და ისინი შეიძლება გამოცხადდეს მოძველებულად ჩვეულ სცენარში. მოსალოდნელია, რომ Kubernetes-ის (1.15) შემდეგი გამოშვებისთვის მოხდება ღრუბლოვანი პროვაიდერის ყველა დანამატის მიგრაცია, იმპლემენტაცია მიიღებს ბეტა სტატუსს და სტანდარტულად გააქტიურდება K8s ინსტალაციაში. დეტალებისთვის იხ დიზაინის წინადადება. ამ მიგრაციამაც გამოიწვია უარყოფა ღრუბლის კონკრეტული პროვაიდერების მიერ განსაზღვრული მოცულობის ლიმიტებიდან (AWS, Azure, GCE, Cinder).

გარდა ამისა, ბლოკის მოწყობილობების მხარდაჭერა CSI-ით (CSIBlockVolume) გადატანილი ბეტა ვერსიამდე.

კვანძები / Kubelet

წარმოდგენილია ალფა ვერსია ახალი საბოლოო წერტილი კუბელეთში, განკუთვნილია დაბრუნების მეტრიკა ძირითად რესურსებზე. ზოგადად რომ ვთქვათ, თუ ადრე Kubelet იღებდა სტატისტიკას კონტეინერის გამოყენების შესახებ cAdvisor-ისგან, ახლა ეს მონაცემები მოდის კონტეინერის გაშვების გარემოდან CRI-ის (Container Runtime Interface) მეშვეობით, მაგრამ Docker-ის ძველ ვერსიებთან მუშაობის თავსებადობა ასევე შენარჩუნებულია. ადრე Kubelet-ში შეგროვებული სტატისტიკა იგზავნებოდა REST API-ით, მაგრამ ახლა ბოლო წერტილი მდებარეობს /metrics/resource/v1alpha1. დეველოპერების გრძელვადიანი სტრატეგია შედგება არის Kubelet-ის მიერ მოწოდებული მეტრიკის ნაკრების მინიმუმამდე შემცირება. სხვათა შორის, თავად ეს მეტრიკა ახლა დარეკავენ არა „ძირითადი მეტრიკა“, არამედ „რესურსების მეტრიკა“ და აღწერილია როგორც „პირველი კლასის რესურსები, როგორიცაა პროცესორი და მეხსიერება“.

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

„gRPC არ არის თავსებადი ძირითადი მონიტორინგის მილსადენებთან. ბოლო წერტილი გამოდგება მხოლოდ Metrics სერვერზე მეტრიკის მიწოდებისთვის ან კომპონენტების მონიტორინგისთვის, რომლებიც უშუალოდ ინტეგრირდება მასთან. Prometheus ტექსტის ფორმატის შესრულება Metrics Server-ში ქეშირების გამოყენებისას საკმარისად კარგი ჩვენთვის უპირატესობა მიანიჭეთ პრომეთეს, ვიდრე gRPC, საზოგადოებაში პრომეთეს ფართოდ გავრცელების გათვალისწინებით. მას შემდეგ, რაც OpenMetrics ფორმატი გახდება უფრო სტაბილური, ჩვენ შევძლებთ მივუდგეთ gRPC შესრულებას პროტოზე დაფუძნებული ფორმატით."

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

სხვა ცვლილებებს შორის:

• Kubelet ახლა (ერთხელ) შეჩერებას ცდილობს კონტეინერები უცნობ მდგომარეობაში ოპერაციების გადატვირთვამდე და წაშლამდე.
• გამოყენებისას PodPresets ახლა საწყისი კონტეინერი დაამატა იგივე ინფორმაცია, რაც ჩვეულებრივი კონტეინერისთვის.
• კუბელეტი დაიწყო გამოყენება usageNanoCores CRI სტატისტიკის პროვაიდერისგან და Windows-ის კვანძებისა და კონტეინერებისთვის დაემატა ქსელის სტატისტიკა.
• ოპერაციული სისტემისა და არქიტექტურის ინფორმაცია ახლა ჩაწერილია ეტიკეტებში kubernetes.io/os и kubernetes.io/arch კვანძის ობიექტები (გადატანილია ბეტადან GA-ზე).
• პოდში კონტეინერებისთვის კონკრეტული სისტემის მომხმარებელთა ჯგუფის მითითების შესაძლებლობა (RunAsGroup, გამოჩნდა K8s 1.11) მოწინავე ბეტამდე (ჩართულია ნაგულისხმევად).
• du და იპოვეთ გამოყენებული cAdvisor-ში, შეცვალა on Go განხორციელება.

CLI

cli-runtime-ში და kubectl-ში დაემატა -k დროშა ინტეგრაციისთვის მორგება (სხვათა შორის, მისი განვითარება ახლა ცალკე საცავში ხორციელდება), ე.ი. დამატებითი YAML ფაილების დასამუშავებლად სპეციალური კუსტომიზაციის დირექტორიებიდან (მათი გამოყენების შესახებ დეტალებისთვის იხ CAP):

მარტივი ფაილის გამოყენების მაგალითი მორგება (კუსტომიზების უფრო რთული გამოყენება შესაძლებელია შიგნით ზედნადები)

გარდა ამისა:

• დამატებულია ახალი გუნდი kubectl create cronjob, რომლის სახელიც თავისთავად საუბრობს.
• В kubectl logs ახლა შენ შეგიძლია კომბინირება დროშები -f (--follow ნაკადის ჟურნალებისთვის) და -l (--selector ეტიკეტის მოთხოვნისთვის).
• კუბექტლი ასწავლიდა wild card-ით შერჩეული ფაილების კოპირება.
• გუნდში kubectl wait დაემატა დროშა --all ყველა რესურსის შესარჩევად მითითებული რესურსის ტიპის სახელთა სივრცეში.

სხვა

შემდეგმა შესაძლებლობებმა მიიღეს სტაბილური (GA) სტატუსი:

• ReadinessGate, გამოიყენება პოდის სპეციფიკაციაში, რათა განისაზღვროს დამატებითი პირობები, რომლებიც მხედველობაში მიიღება პოდის მზადყოფნაში;
• დიდი გვერდების მხარდაჭერა (მოწოდების კარიბჭე HugePages);
• CustomPodDNS;
• PriorityClass API Pod Priority & Preemption.

Kubernetes 1.14-ში შემოღებული სხვა ცვლილებები:

• ნაგულისხმევი RBAC პოლიტიკა აღარ იძლევა API წვდომას discovery и access-review მომხმარებლები ავთენტიფიკაციის გარეშე (არაავთენტიფიცირებული).
• ოფიციალური CoreDNS მხარდაჭერა უზრუნველყოფილი მხოლოდ Linux, ასე რომ, როდესაც იყენებთ kubeadm-ს მის (CoreDNS) კლასტერში განსათავსებლად, კვანძები უნდა მუშაობდეს მხოლოდ Linux-ზე (nodeSelectors გამოიყენება ამ შეზღუდვისთვის).
• ნაგულისხმევი CoreDNS კონფიგურაცია ახლა არის იყენებს წინსვლის მოდული პროქსის ნაცვლად. ასევე, CoreDNS-ში დაემატა ReadinessProbe, რომელიც ხელს უშლის დატვირთვის დაბალანსებას შესაბამის (მომსახურებისთვის არ არის მზად) პოდებზე.
• კუბეადმში, ფაზებზე init ან upload-certs, შესაძლებელი გახდა ჩატვირთეთ ახალი საკონტროლო სიბრტყის დასაკავშირებლად საჭირო სერთიფიკატები kubeadm-certs საიდუმლოებასთან (გამოიყენეთ დროშა --experimental-upload-certs).
• Windows-ის ინსტალაციისთვის გამოჩნდა ალფა ვერსია მხარდაჭერა gMSA (Group Managed Service Account) - სპეციალური ანგარიშები Active Directory-ში, რომლებიც ასევე შეიძლება გამოყენებულ იქნას კონტეინერებში.
• იყიდება G.C.E. გააქტიურებული mTLS დაშიფვრა etcd-სა და kube-apiserver-ს შორის.
• მეორადი/დამოკიდებული პროგრამული უზრუნველყოფის განახლებები: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, Docker 18.09 მხარდაჭერა kubeadm-ში და მინიმალური მხარდაჭერილი Docker API ვერსია ახლა არის 1.26.

PS

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

• «Kubernetes 1.13: ახალი ამბების ხაზგასმა";
• «Kubernetes 1.12: ახალი ამბების ხაზგასმა";
• «Kubernetes 1.11: ახალი ამბების ხაზგასმა";
• «Kubernetes 1.10: ახალი ამბების ხაზგასმა".

წყარო: www.habr.com