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

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

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

კვანძები

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

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

kubectl debug -c debug-shell --image=debian target-pod -- bash

დეტალები ეფემერული კონტეინერების შესახებ (და მათი გამოყენების მაგალითები) შეგიძლიათ იხილოთ აქ შესაბამისი KEP. მიმდინარე იმპლემენტაცია (K8s 1.16-ში) არის ალფა ვერსია და მისი ბეტა ვერსიაზე გადატანის კრიტერიუმებს შორის არის „Ephemeral Containers API-ის ტესტირება [Kubernetes]-ის მინიმუმ 2 გამოშვებისთვის“.

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

კიდევ ერთი ინოვაცია - PodOverhead - შექმნილია უზრუნველსაყოფად ბუდებისთვის ზედნადები ხარჯების გაანგარიშების მექანიზმი, რომელიც შეიძლება მნიშვნელოვნად განსხვავდებოდეს გამოყენებული მუშაობის დროის მიხედვით. მაგალითად, ავტორები ეს KEP შედეგად მიიღება Kata Containers, რომელიც მოითხოვს სტუმრის ბირთვის, კატა აგენტის, init სისტემის და ა.შ. როდესაც ზედნადები იმდენად დიდი ხდება, არ შეიძლება მისი იგნორირება, რაც იმას ნიშნავს, რომ საჭიროა მისი გათვალისწინება შემდგომი კვოტების, დაგეგმვისა და ა.შ. მის განსახორციელებლად PodSpec დამატებულია ველი Overhead *ResourceList (შედარებულია მონაცემებთან RuntimeClassთუ ერთი გამოიყენება).

კიდევ ერთი მნიშვნელოვანი ინოვაციაა კვანძის ტოპოლოგიის მენეჯერი (კვანძის ტოპოლოგიის მენეჯერი), შექმნილია Kubernetes-ში სხვადასხვა კომპონენტისთვის ტექნიკის რესურსების განაწილების დაზუსტების მიდგომის გაერთიანებისთვის. ეს ინიციატივა გამოწვეულია სხვადასხვა თანამედროვე სისტემების მზარდი საჭიროებით (ტელეკომუნიკაციების სფეროდან, მანქანათმცოდნეობის სფეროდან, ფინანსური სერვისებიდან და ა. ტექნიკის აჩქარების შესაძლებლობები. Kubernetes-ში ასეთი ოპტიმიზაცია აქამდე მიღწეულია განსხვავებული კომპონენტების წყალობით (CPU მენეჯერი, Device Manager, CNI), ახლა კი მათ დაემატება ერთი შიდა ინტერფეისი, რომელიც აერთიანებს მიდგომას და ამარტივებს ახალი მსგავსი - ე.წ. ტოპოლოგია- კავშირს. იცის - კომპონენტები Kubelet მხარეს. დეტალები - in შესაბამისი KEP.

ტოპოლოგიის მენეჯერის კომპონენტის დიაგრამა

შემდეგი ფუნქცია - კონტეინერების შემოწმება, როდესაც ისინი მუშაობენ (გაშვების ზონდი). მოგეხსენებათ, კონტეინერებს, რომელთა გაშვებას დიდი დრო სჭირდება, ძნელია განახლებული სტატუსის მიღება: ისინი ან „მოკლან“ სანამ რეალურად დაიწყებენ ფუნქციონირებას, ან ჩიხში აღმოჩნდებიან დიდი ხნით. ახალი შემოწმება (ჩართულია გამოძახებული ფუნქციების კარიბჭის მეშვეობით StartupProbeEnabled) გააუქმებს - უფრო სწორად, აყოვნებს - ნებისმიერი სხვა შემოწმების ეფექტს იმ მომენტამდე, სანამ pod არ დაასრულებს მუშაობას. ამ მიზეზით, ფუნქცია თავდაპირველად ეწოდა pod-startup liveness-probe holdoff. პოდებისთვის, რომელთა დაწყებას დიდი დრო სჭირდება, შეგიძლიათ გამოკითხოთ შტატი შედარებით მოკლე დროში.

გარდა ამისა, RuntimeClass-ის გაუმჯობესება დაუყოვნებლივ ხელმისაწვდომია ბეტა სტატუსში და ამატებს მხარდაჭერას „ჰეტეროგენული კლასტერებისთვის“. C RuntimeClass დაგეგმვა ახლა სულაც არ არის აუცილებელი, რომ თითოეულ კვანძს ჰქონდეს მხარდაჭერა თითოეული RuntimeClass-ისთვის: პოდებისთვის შეგიძლიათ აირჩიოთ RuntimeClass კლასტერის ტოპოლოგიაზე ფიქრის გარეშე. ადრე, ამის მისაღწევად - ისე, რომ კვანძები დასრულდეს კვანძებზე ყველაფრის მხარდაჭერით, რაც მათ სჭირდებათ - საჭირო იყო შესაბამისი წესების მინიჭება NodeSelector-ისთვის და ტოლერანტებისთვის. IN CAP საუბარია გამოყენების მაგალითებზე და, რა თქმა უნდა, განხორციელების დეტალებზე.

ქსელი

ორი მნიშვნელოვანი ქსელის ფუნქცია, რომლებიც პირველად გამოჩნდა (ალფა ვერსიაში) Kubernetes 1.16-ში არის:

• მხარდაჭერა ორმაგი ქსელის დასტა - IPv4/IPv6 - და მისი შესაბამისი „გაგება“ რგოლების, კვანძების, სერვისების დონეზე. იგი მოიცავს IPv4-to-IPv4 და IPv6-to-IPv6 თავსებადობას პოდებს შორის, პოდებიდან გარე სერვისებამდე, საცნობარო იმპლემენტაციებს (Bridge CNI, PTP CNI და Host-Local IPAM დანამატებში), ასევე უკუთავსებადია Kubernetes კლასტერებთან, რომლებიც მუშაობენ. მხოლოდ IPv4 ან IPv6. განხორციელების დეტალები მოცემულია CAP.

  პოდების სიაში ორი ტიპის (IPv4 და IPv6) IP მისამართების ჩვენების მაგალითი:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• ახალი API ბოლო წერტილისთვის - EndpointSlice API. ის წყვეტს არსებული Endpoint API-ის მუშაობის/მაშტაბურობის საკითხებს, რომლებიც გავლენას ახდენენ საკონტროლო სიბრტყის სხვადასხვა კომპონენტებზე (apiserver, etcd, endpoints-controller, kube-proxy). ახალი API დაემატება Discovery API ჯგუფს და შეძლებს მოემსახუროს ათიათასობით უკანა ბოლო წერტილს თითოეულ სერვისზე ათასობით კვანძისგან შემდგარ კლასტერში. ამისათვის, თითოეული სერვისი აისახება N ობიექტზე EndpointSlice, რომელთაგან თითოეულს ნაგულისხმევად აქვს არაუმეტეს 100 საბოლოო წერტილი (მნიშვნელობის კონფიგურირებადია). EndpointSlice API ასევე უზრუნველყოფს მისი მომავალი განვითარების შესაძლებლობებს: მრავალჯერადი IP მისამართის მხარდაჭერა თითოეული პოდისთვის, ახალი მდგომარეობები ბოლო წერტილებისთვის (არა მხოლოდ Ready и NotReady), დინამიური ქვეპარამეტრები ბოლო წერტილებისთვის.

ბოლო გამოშვებაში წარმოდგენილმა მიაღწია ბეტა ვერსიას ფინალისტიდაასახელა service.kubernetes.io/load-balancer-cleanup და ერთვის თითოეულ სერვისს ტიპის მიხედვით LoadBalancer. ასეთი სერვისის წაშლის დროს ის ხელს უშლის რესურსის რეალურ წაშლას, სანამ არ დასრულდება ყველა შესაბამისი ბალანსირებული რესურსის „გასუფთავება“.

API მანქანები

ნამდვილი "სტაბილიზაციის ეტაპი" არის Kubernetes API სერვერის არეალში და მასთან ურთიერთქმედებაში. ეს დიდწილად იმის წყალობით მოხდა სტაბილურ სტატუსში გადაყვანა მათ, ვისაც სპეციალური შესავალი არ სჭირდება CustomResourceDefinitions (CRD), რომლებსაც აქვთ ბეტა სტატუსი Kubernetes 1.7-ის შორეული დღეებიდან (და ეს არის 2017 წლის ივნისი!). იგივე სტაბილიზაცია მოვიდა დაკავშირებულ მახასიათებლებზე:

• "ქვე რესურსები" ერთად /status и /scale CustomResources-ისთვის;
• ტრანსფორმაცია ვერსიები CRD-ისთვის, დაფუძნებული გარე webhook-ზე;
• ცოტა ხნის წინ წარმოდგენილი (K8s 1.15-ში) ნაგულისხმევი მნიშვნელობები (ნაგულისხმევი) და ველის ავტომატური მოცილება (გასხვლა) CustomResources-ისთვის;
• შესაძლებლობა OpenAPI v3 სქემის გამოყენებით OpenAPI დოკუმენტაციის შესაქმნელად და გამოქვეყნებისთვის, რომელიც გამოიყენება სერვერის მხარეს CRD რესურსების დასადასტურებლად.

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

ორმა სხვა ფუნქციამ მიაღწია ბეტას: სერვერის მხარეს ვრცელდება и სანიშნეების ყურება.

და ერთადერთი მნიშვნელოვანი სიახლე ალფა ვერსიაში იყო უარყოფა საწყისი SelfLink - სპეციალური URI, რომელიც წარმოადგენს მითითებულ ობიექტს და არის მისი ნაწილი ObjectMeta и ListMeta (ანუ ნებისმიერი ობიექტის ნაწილი Kubernetes-ში). რატომ ტოვებენ მას? მოტივაცია მარტივი გზით ხმები როგორც ამ სფეროს ჯერ კიდევ არსებობის რეალური (აბსოლუტური) მიზეზების არარსებობა. უფრო ფორმალური მიზეზებია შესრულების ოპტიმიზაცია (არასაჭირო ველის მოხსნით) და ზოგადი აპისერვერის მუშაობის გამარტივება, რომელიც იძულებულია აწარმოოს ასეთი ველი სპეციალური გზით (ეს არის ერთადერთი ველი, რომელიც დაყენებულია ობიექტის წინ. არის სერიული). ნამდვილი მოძველება (ბეტას ფარგლებში) SelfLink მოხდება Kubernetes 1.20 ვერსიით, ხოლო საბოლოო - 1.21.

Მონაცემთა საცავი

ძირითადი სამუშაოები შენახვის ზონაში, როგორც წინა გამოშვებებში, შეინიშნება ტერიტორიაზე CSI მხარდაჭერა. აქ ძირითადი ცვლილებები იყო:

• პირველად (ალფა ვერსიაში) გამოჩნდა CSI მოდულის მხარდაჭერა Windows მუშა კვანძებისთვის: საცავთან მუშაობის ამჟამინდელი მეთოდი ასევე ჩაანაცვლებს ხის შიდა დანამატებს Kubernetes core და FlexVolume დანამატებს Microsoft-ისგან Powershell-ზე დაფუძნებული;

  
  Windows-ისთვის Kubernetes-ში CSI დანამატების დანერგვის სქემა

• შესაძლებლობა CSI ტომების ზომის შეცვლაK8s 1.12-ში შემოღებული, გადაიზარდა ბეტა ვერსიამდე;
• მსგავსი "პრომოცია" (ალფადან ბეტამდე) მიღწეული იქნა CSI-ის გამოყენების შესაძლებლობით ადგილობრივი ეფემერული ტომების შესაქმნელად (CSI Inline Volume მხარდაჭერა).

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

განრიგი

ორი შესამჩნევი ცვლილება განრიგში (ორივე ალფაში):

• EvenPodsSpreading - შესაძლებლობა დატვირთვის „სამართლიანი განაწილებისთვის“ ლოგიკური აპლიკაციის ერთეულების ნაცვლად გამოიყენეთ პოდნები (როგორც Deployment და ReplicaSet) და ამ განაწილების რეგულირება (როგორც მძიმე მოთხოვნა ან როგორც რბილი მდგომარეობა, ანუ პრიორიტეტი). ფუნქცია გააფართოვებს დაგეგმილი პოდების განაწილების არსებულ შესაძლებლობებს, რომლებიც ამჟამად შეზღუდულია პარამეტრებით PodAffinity и PodAntiAffinity, ადმინისტრატორებს ამ საკითხზე უფრო დახვეწილ კონტროლს აძლევს, რაც ნიშნავს უკეთეს მაღალ ხელმისაწვდომობას და რესურსების ოპტიმიზებულ მოხმარებას. დეტალები - in CAP.
• გამოიყენეთ BestFit პოლიტიკა в RequestedToCapacityRatio პრიორიტეტული ფუნქცია პოდ დაგეგმვის დროს, რაც საშუალებას მისცემს ვრცელდება ურნის შეფუთვა („კონტეინერებში შეფუთვა“) როგორც ძირითადი რესურსებისთვის (პროცესორი, მეხსიერება) და გაფართოებული (როგორიცაა GPU). დაწვრილებით იხ CAP.

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

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

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

ასევე Kubernetes 1.16 გამოშვებაში შეიძლება აღინიშნოს ინიციატივისთვის შემოტანა ხელმისაწვდომი მეტრიკა სრული თანმიმდევრობით, უფრო ზუსტად, შესაბამისად ოფიციალური რეგულაციები K8-ის ინსტრუმენტაციამდე. ისინი დიდწილად ეყრდნობიან შესაბამისს პრომეთეს დოკუმენტაცია. შეუსაბამობები წარმოიშვა სხვადასხვა მიზეზის გამო (მაგალითად, ზოგიერთი მეტრიკა უბრალოდ შეიქმნა ამჟამინდელი ინსტრუქციების გამოჩენამდე) და დეველოპერებმა გადაწყვიტეს, რომ დროა ყველაფერი ერთიან სტანდარტამდე მიიყვანონ, "პრომეთეს დანარჩენი ეკოსისტემის შესაბამისად". ამ ინიციატივის ამჟამინდელი განხორციელება ალფა სტატუსშია, რომელიც თანდათან დაწინაურდება Kubernetes-ის შემდგომ ვერსიებში ბეტაზე (1.17) და სტაბილურზე (1.18).

გარდა ამისა, შეიძლება აღინიშნოს შემდეგი ცვლილებები:

• Windows-ის განვითარების მხარდაჭერა с გარეგნობა Kubeadm უტილიტები ამ OS-სთვის (ალფა ვერსია), შესაძლებლობა RunAsUserName Windows კონტეინერებისთვის (ალფა ვერსია), გაუმჯობესება ჯგუფის მართული სერვისის ანგარიშის (gMSA) მხარდაჭერა ბეტა ვერსიამდე, მხარდაჭერა დამაგრება/მიმაგრება vSphere ტომებისთვის.
• გადამუშავებული მონაცემთა შეკუმშვის მექანიზმი API პასუხებში. ადრე ამ მიზნებისთვის გამოიყენებოდა HTTP ფილტრი, რომელიც აწესებდა უამრავ შეზღუდვას, რაც ხელს უშლიდა მის ნაგულისხმევ ჩართვას. "გამჭვირვალე მოთხოვნის შეკუმშვა" ახლა მუშაობს: კლიენტების გაგზავნა Accept-Encoding: gzip სათაურში ისინი იღებენ GZIP შეკუმშულ პასუხს, თუ მისი ზომა აღემატება 128 კბ-ს. Go კლიენტები ავტომატურად უჭერენ მხარს შეკუმშვას (საჭირო სათაურის გაგზავნას), ასე რომ ისინი დაუყოვნებლივ შეამჩნევენ ტრაფიკის შემცირებას. (სხვა ენებისთვის შეიძლება საჭირო გახდეს მცირე ცვლილებები.)
• შესაძლებელი გახდა HPA-ს სკალირება გარე მეტრიკის საფუძველზე. თუ მასშტაბირებას ახორციელებთ ობიექტების/გარე მეტრიკის საფუძველზე, მაშინ, როდესაც სამუშაო დატვირთვა უმოქმედოა, შეგიძლიათ ავტომატურად გაზარდოთ 0-მდე რეპლიკა რესურსების დაზოგვის მიზნით. ეს ფუნქცია განსაკუთრებით სასარგებლო უნდა იყოს იმ შემთხვევებში, როდესაც მუშები ითხოვენ GPU რესურსებს და სხვადასხვა ტიპის უმოქმედო მუშაკების რაოდენობა აღემატება ხელმისაწვდომი GPU-ების რაოდენობას.
• ახალი კლიენტი - k8s.io/client-go/metadata.Client - ობიექტებზე "განზოგადებული" წვდომისთვის. იგი შექმნილია მეტამონაცემების ადვილად მოსაპოვებლად (ანუ ქვეგანყოფილება metadata) კლასტერული რესურსებიდან და მათთან ერთად განახორციელოს ნაგვის შეგროვებისა და კვოტირების ოპერაციები.
• ააშენეთ კუბერნეტები ახლა შენ შეგიძლია მემკვიდრეობითი ("ჩაშენებული" ხის შიგნით) ღრუბლოვანი პროვაიდერების გარეშე (ალფა ვერსია).
• kubeadm უტილიტაში დაემატა ოპერაციების დროს მორგებული პატჩების გამოყენების ექსპერიმენტული (ალფა ვერსია). init, join и upgrade. შეიტყვეთ მეტი დროშის გამოყენების შესახებ --experimental-kustomize, იხილეთ CAP.
• ახალი საბოლოო წერტილი აპისერვერისთვის - readyz, - გაძლევთ საშუალებას ექსპორტის ინფორმაცია მისი მზადყოფნის შესახებ. API სერვერსაც ახლა აქვს დროშა --maximum-startup-sequence-duration, რომელიც საშუალებას გაძლევთ დაარეგულიროთ მისი გადატვირთვა.
• ორ თვისებები Azure-სთვის გამოცხადდა სტაბილურად: მხარდაჭერა ხელმისაწვდომობის ზონები (ხელმისაწვდომობის ზონები) და ჯვარედინი რესურსების ჯგუფი (RG). გარდა ამისა, Azure-მა დაამატა:
  • ავტორიზაციის მხარდაჭერა AAD და ADFS;
  • აბსტრაქტი service.beta.kubernetes.io/azure-pip-name დატვირთვის ბალანსერის საჯარო IP-ის მითითება;
  • შესაძლებლობა პარამეტრები LoadBalancerName и LoadBalancerResourceGroup.
• AWS-ს ახლა აქვს მხარს ვუჭერთ EBS-სთვის ვინდოუსზე და ოპტიმიზირებულია EC2 API ზარები DescribeInstances.
• Kubeadm ახლა დამოუკიდებელია მიგრირებს CoreDNS კონფიგურაცია CoreDNS ვერსიის განახლებისას.
• ორობითი ა.შ.შ დოკერის შესაბამის სურათში გააკეთეს world-executable, რომელიც საშუალებას გაძლევთ გაუშვათ ეს სურათი root უფლებების საჭიროების გარეშე. ასევე, etcd მიგრაციის სურათი შეწყვიტა etcd2 ვერსიის მხარდაჭერა.
• В Cluster Autoscaler 1.16.0 გადაერთო დისტროლესზე, როგორც საბაზისო გამოსახულება, გაუმჯობესდა შესრულება, დაემატა ახალი ღრუბლოვანი პროვაიდერები (DigitalOcean, Magnum, Packet).
• მეორადი/დამოკიდებული პროგრამული უზრუნველყოფის განახლებები: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2.

PS

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

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

წყარო: www.habr.com