ხვრელების დაფიქსირება კუბერნეტის კლასტერში. მოხსენება და ტრანსკრიპტი DevOpsConf-დან

პაველ სელივანოვმა, Southbridge-ის გადაწყვეტილებების არქიტექტორმა და Slurm მასწავლებელმა, წარმოადგინა პრეზენტაცია DevOpsConf 2019-ზე. ეს მოხსენება არის Kubernetes-ის სიღრმისეული კურსის ერთ-ერთი თემის ნაწილი „Slurm Mega“.

Slurm Basic: შესავალი Kubernetes-ში 18-20 ნოემბერს მოსკოვში გაიმართება.
Slurm Mega: იყურება Kubernetes-ის კაპოტის ქვეშ - მოსკოვი, 22-24 ნოემბერი.
Slurm Online: Kubernetes-ის ორივე კურსი ყოველთვის ხელმისაწვდომი.

ჭრილის ქვემოთ მოცემულია მოხსენების ტრანსკრიპტი.

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

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

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

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

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

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

მაგალითებით გეტყვით, როგორ გავაკეთე ეს და როგორ დავიცვა თავი ამისგან.

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

გარდა ჩვენი ძირითადი საქმიანობისა, ჩვენ ახლახან დავიწყეთ პროექტები სახელწოდებით Slurms. ჩვენ ვცდილობთ Kubernetes-თან მუშაობის ჩვენი უნარი ცოტათი მივაწოდოთ მასებს, ვასწავლოთ სხვა ადამიანებს ასევე მუშაობა K8-ებთან.

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

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

ფაქტიურად სამი პუნქტია, რომელზეც დღეს ვისაუბრებ:

1. მომხმარებლის უფლებები pod უფლებების წინააღმდეგ. მომხმარებლის უფლებები და პოდის უფლებები არ არის იგივე.
2. ინფორმაციის შეგროვება კლასტერის შესახებ. მე გაჩვენებთ, რომ თქვენ შეგიძლიათ შეაგროვოთ ყველა საჭირო ინფორმაცია კლასტერიდან ამ კლასტერზე სპეციალური უფლებების გარეშე.
3. DoS შეტევა კლასტერზე. თუ ინფორმაციის შეგროვება ვერ მოვახერხეთ, ნებისმიერ შემთხვევაში შევძლებთ კლასტერის მოთავსებას. მე ვისაუბრებ DoS შეტევებზე კასეტური კონტროლის ელემენტებზე.

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

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

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

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

kubectl apply -f pod.yaml

ეს პოდი მივა კუბერნეტის კლასტერის ერთ-ერთ ოსტატთან. და ამის შემდეგ კლასტერი სიხარულით დაგვიბრუნებს ფაილს სახელად admin.conf. Cube-ში ეს ფაილი ინახავს ადმინისტრატორის ყველა სერთიფიკატს და ამავდროულად აკონფიგურირებს კლასტერის API-ს. ასე ადვილია ადმინისტრატორის წვდომა, ვფიქრობ, Kubernetes კლასტერების 98%.

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

ახლა კი სპეციალურად მომზადებული ლულის შესახებ. ჩვენ ვაწარმოებთ მას ნებისმიერ სურათზე. მაგალითისთვის ავიღოთ debian:jessie.

ჩვენ გვაქვს ეს ნივთი:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

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

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

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

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

hostNetwork: true 
hostPID: true 

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

მაშინ საქმე წვრილმანებზეა. აიღე etcd და წაიკითხე რაც გინდა.

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

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

და მისი არსი იმაში მდგომარეობს, რომ ჩვენ შეგვიძლია ვთქვათ პოდში, რომ ჩვენ გავუშვით, თუნდაც ამ კლასტერზე უფლებების გარეშე, რომ ჩვენ გვინდა შევქმნათ ტომი ტიპის hostPath. ეს ნიშნავს, რომ მივიღოთ ის გზა ჰოსტიდან, რომელზედაც ჩვენ გავუშვით - და მივიღოთ როგორც მოცულობა. შემდეგ კი მას ვუწოდებთ სახელს: მასპინძელი. ჩვენ ვამაგრებთ მთელ მასპინძელს პოდში. ამ მაგალითში, / host დირექტორიაში.

კიდევ გავიმეორებ. ჩვენ ვუთხარით პოდს, რომ მივიდეს მასტერთან, იქ მიიღოს hostNetwork და hostPID - და დაამონტაჟოს მასტერის მთელი ფესვი ამ პოდში.

თქვენ გესმით, რომ Debian-ში ჩვენ გვაქვს bash run, და ეს bash გადის root ქვეშ. ანუ, ჩვენ უბრალოდ მივიღეთ root მასტერზე, Kubernetes კლასტერში რაიმე უფლებების გარეშე.

შემდეგ მთელი ამოცანაა გადახვიდეთ ქვე დირექტორიაში /host /etc/kubernetes/pki, თუ არ ვცდები, აიღოთ იქ კლასტერის ყველა მთავარი სერთიფიკატი და, შესაბამისად, გახდეთ კლასტერის ადმინისტრატორი.

თუ ამას ასე შეხედავთ, ეს არის ზოგიერთი ყველაზე საშიში უფლებები პოდებში - მიუხედავად იმისა, თუ რა უფლებები აქვს მომხმარებელს:

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

ჩემი ფავორიტი არის Root მომხმარებელი. და Kubernetes-ს აქვს ეს Run As Non-Root ვარიანტი. ეს არის ჰაკერისგან დაცვის ტიპი. იცით, რა არის "მოლდოვური ვირუსი"? თუ მოულოდნელად გახდებით ჰაკერი და მოხვედით ჩემს Kubernetes კლასტერში, მაშინ ჩვენ, ღარიბი ადმინისტრატორები, გკითხავთ: „გთხოვთ, მიუთითოთ თქვენს პოდებში, რომლითაც გატეხავთ ჩემს კლასტერს, გაუშვით როგორც არა-root. წინააღმდეგ შემთხვევაში, ისე მოხდება, რომ თქვენ აწარმოებთ პროცესს თქვენს პოდში root ქვეშ და ძალიან გაგიადვილდებათ ჩემი გატეხვა. გთხოვთ დაიცვათ თავი საკუთარი თავისგან."

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

მაგრამ რა უნდა გააკეთოს ამ ყველაფერთან?

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

ეს არის yaml ობიექტი - ჩვენ შეგვიძლია შევქმნათ იგი Kubernetes კლასტერში - რომელიც აკონტროლებს უსაფრთხოების ასპექტებს კონკრეტულად პოდების აღწერაში. ეს არის, ფაქტობრივად, ის აკონტროლებს უფლებებს გამოიყენოს ნებისმიერი hostNetwork, hostPID, გარკვეული მოცულობის ტიპები, რომლებიც ჩატვირთვისას არის პოდებში. Pod Security Policy-ის დახმარებით ამ ყველაფრის აღწერა შესაძლებელია.

Pod Security Policy-ში ყველაზე საინტერესო ის არის, რომ Kubernetes კლასტერში, ყველა PSP ინსტალერი არანაირად არ არის აღწერილი, ისინი უბრალოდ გამორთულია ნაგულისხმევად. პოდის უსაფრთხოების პოლიტიკა ჩართულია დაშვების მოდულის გამოყენებით.

კარგი, მოდით განვათავსოთ Pod Security Policy კლასტერში, ვთქვათ, რომ გვაქვს რამდენიმე სერვისის პოდი სახელთა სივრცეში, რომლებზეც წვდომა მხოლოდ ადმინისტრატორებს აქვთ. ვთქვათ, ყველა დანარჩენ შემთხვევაში, პოდებს აქვთ შეზღუდული უფლებები. რადგან, სავარაუდოდ, დეველოპერებს არ სჭირდებათ თქვენს კლასტერში პრივილეგირებული პოდების გაშვება.

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

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

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

ალბათ ყველა კითხულობს ერთსა და იმავე სტატიებს Habré-ზე და მონიტორინგი მდებარეობს მონიტორინგის სახელთა სივრცეში. ჩაფხუტის დიაგრამა ყველას ერთნაირად უწოდებენ. ვვარაუდობ, რომ თუ თქვენ დააინსტალირებთ სტაბილურს/პრომეთეუსს, თქვენ მიიღებთ დაახლოებით იგივე სახელებს. და, სავარაუდოდ, არც კი მომიწევს DNS სახელის გამოცნობა თქვენს კლასტერში. იმიტომ რომ სტანდარტულია.

შემდეგ ჩვენ გვაქვს გარკვეული dev ns, რომელშიც შეგიძლიათ გაუშვათ გარკვეული pod. და შემდეგ ამ პოდიდან ძალიან ადვილია ამის გაკეთება:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics არის პრომეთეუსის ერთ-ერთი ექსპორტიორი, რომელიც აგროვებს მეტრებს თავად Kubernetes API-დან. იქ ბევრი მონაცემია, რა მუშაობს თქვენს კლასტერში, რა არის, რა პრობლემები გაქვთ მასთან.

როგორც მარტივი მაგალითი:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

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

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

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

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

არის ასეთი რამ - ქსელის პოლიტიკა.

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

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

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

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

რა უნდა გავაკეთოთ?

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

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

როდესაც ახალ კლასტერს აყენებთ, ამავე დროს ფლანელის ნაცვლად ჩადეთ Calico.

რა უნდა გააკეთოთ, თუ თქვენი სერთიფიკატები გაიცემა ასი წლის განმავლობაში და არ აპირებთ კლასტერის გადანაწილებას? არსებობს ისეთი რამ, როგორიცაა Kube-RBAC-Proxy. ეს არის ძალიან მაგარი განვითარება, ის საშუალებას გაძლევთ ჩასვათ საკუთარი თავი, როგორც გვერდითი კონტეინერი Kubernetes კლასტერში ნებისმიერ პოდში. და ის რეალურად ამატებს ავტორიზაციას ამ პოდზე თავად Kubernetes-ის RBAC-ის მეშვეობით.

ერთი პრობლემაა. ადრე, ეს Kube-RBAC-Proxy გადაწყვეტა ჩაშენებული იყო ოპერატორის Prometheus-ში. მაგრამ შემდეგ ის წავიდა. ახლა თანამედროვე ვერსიები ეყრდნობა იმ ფაქტს, რომ თქვენ გაქვთ ქსელის პოლიტიკა და დახურეთ იგი მათი გამოყენებით. და ამიტომ მოგვიწევს სქემის ოდნავ გადაწერა. ფაქტობრივად, თუ წახვალ ეს საცავი, არის მაგალითები იმისა, თუ როგორ გამოვიყენოთ ეს, როგორც გვერდითი კარები, და სქემები მინიმალურად უნდა გადაიწეროს.

არის კიდევ ერთი პატარა პრობლემა. პრომეთე არ არის ერთადერთი, ვინც საკუთარ მეტრებს ვინმეს აწვდის. ჩვენი Kubernetes კლასტერის ყველა კომპონენტს ასევე შეუძლია დააბრუნოს საკუთარი მეტრიკა.

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

ასე რომ, მე სწრაფად გაჩვენებთ ორ გზას, თუ როგორ შეიძლება კუბერნეტის კლასტერის დანგრევა.

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

მეთოდი პირველი. რესურსების ამოწურვა.

მოდით გავუშვათ კიდევ ერთი სპეციალური პოდი. მას ექნება ასეთი განყოფილება.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

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

თუ მე გავუშვებ ასეთ პოდს, მაშინ გავუშვებ ბრძანებას:

$ kubectl scale special-pod --replicas=...

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

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

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

და აქედან მოდის მეთოდი ნომერი ორი. ჩვენ ვიწყებთ 11 პოდს. ეს არის თერთმეტი მილიარდი. ეს იმიტომ კი არა, რომ ასეთი რიცხვი მოვიფიქრე, არამედ იმიტომ, რომ მე თვითონ ვნახე.

რეალური ამბავი. გვიან საღამოს ვაპირებდი ოფისიდან გასვლას. მე ვხედავ დეველოპერების ჯგუფს, რომლებიც კუთხეში ზის და გაბრაზებული აკეთებენ რაღაცას ლეპტოპებით. მე მივდივარ ბიჭებთან და ვეკითხები: "რა დაგემართათ?"

ცოტა ადრე, საღამოს ცხრა საათზე, ერთ-ერთი დეველოპერი სახლში წასასვლელად ემზადებოდა. და მე გადავწყვიტე: "ახლა ჩემს განაცხადს ერთზე შევამცირებ." ერთი დავაჭირე, მაგრამ ინტერნეტი ცოტათი შენელდა. მან კიდევ ერთხელ დააჭირა ერთს, დააჭირა ერთს და დააჭირა Enter-ს. ყველაფერზე ვწუწუნებდი, რაც შემეძლო. შემდეგ ინტერნეტი გაცოცხლდა - და ყველაფერი დაიწყო ამ რიცხვამდე შემცირება.

მართალია, ეს ამბავი კუბერნეტესზე არ მომხდარა, იმ დროს ეს იყო მომთაბარე. დამთავრდა იმით, რომ ერთი საათის შემდეგ ჩვენი მცდელობის შემდეგ, შეგვეჩერებინა Nomad მასშტაბის დაჟინებული მცდელობისგან, ნომადმა უპასუხა, რომ ის არ შეწყვეტს მასშტაბებს და სხვას არაფერს გააკეთებს. "დავიღალე, მივდივარ." და დაიხარა.

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

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

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

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

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

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

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

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

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

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

რესურსის კვოტა + ლიმიტის დიაპაზონი + RBAC
• სახელთა სივრცის შექმნა
• შექმენით ლიმიტის დიაპაზონი შიგნით
• შექმენით რესურსების შიდა ქვოტა
• შექმენით სერვისის ანგარიში CI-სთვის
• შექმენით rolebinding CI და მომხმარებლებისთვის
• სურვილისამებრ გაუშვით საჭირო სერვისის პოდები

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

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

პატარა ამარტივებს მთელ ამ რთულ პროცესს.

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

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

LimitRange/ResourceQuota - დროა მისი გამოყენება. ამის გამოყენება დიდი ხნის წინ დავიწყეთ და დიდი ხნის განმავლობაში დარწმუნებული ვიყავი, რომ ყველა იყენებდა. აღმოჩნდა, რომ ეს იშვიათია.

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

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

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

მადლობა ყველას.

წყარო: www.habr.com