ჩვენი ხელები მოწყენილობისთვის არ არის: K8-ებში Rook კასეტურის აღდგენა

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

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

"ყველაფერი დაკარგულია!"

წარმოიდგინეთ, რომ ერთხელ უკვე დააკონფიგურირეთ და გაუშვით Rook თქვენს K8s კლასტერში და ის იდეალურად მუშაობდა, მაგრამ რაღაც „მშვენიერ“ მომენტში შემდეგი ხდება:

• ახალ პოდებს არ შეუძლიათ Ceph-დან RBD სურათების დამონტაჟება.
• გუნდები, როგორიცაა lsblk и df ისინი არ მუშაობენ Kubernetes-ის კვანძებზე. ეს ავტომატურად ნიშნავს, რომ კვანძებზე დამონტაჟებულ RBD სურათებთან დაკავშირებით რაღაც პრობლემაა. მათი წაკითხვა შეუძლებელია, რაც მიუთითებს, რომ მონიტორები მიუწვდომელია...
• დიახ, კლასტერში არ არის მომუშავე მონიტორები. უფრო მეტიც, არც OSD პოდები და არც MGR პოდია.

როდესაც პოდი დაიწყო rook-ceph-operator? არც ისე დიდი ხნის წინ განლაგდა. რატომ? Rook ოპერატორმა გადაწყვიტა ახალი კლასტერის შექმნა... როგორ შეგვიძლია ახლა კლასტერის და მისი მონაცემების აღდგენა?

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

პატარა პრაქტიკა, თუ გრძელი გზა

ჩვენ დავათვალიერებთ ირგვლივ არსებულ ვითარებას და აღვადგენთ თქვენს მონიტორებს.

მოდით, გადავხედოთ ConfigMaps-ის სიას: არის ის, რაც საჭიროა სარეზერვო ასლის შესაქმნელად. rook-ceph-config и rook-config-overrideისინი ჩნდებიან, როდესაც კლასტერი წარმატებით განლაგდება.

NB: ახალ ვერსიებში, დამტკიცების შემდეგ ეს PRConfigMaps აღარ წარმოადგენს კლასტერის განლაგების წარმატების ინდიკატორს.

შემდგომი მოქმედებების შესასრულებლად, საჭიროა ყველა სერვერის მყარი გადატვირთვა, რომელზეც დამონტაჟებულია RBD სურათები (ls /dev/rbd*). ეს უნდა გაკეთდეს sysrq-ის მეშვეობით (ან „ფეხით“ მონაცემთა ცენტრში). ეს მოთხოვნა აუცილებელია დამონტაჟებული RBD-ების მოსახსნელად, რომელთათვისაც სტანდარტული გადატვირთვა არ იმუშავებს (ის წარუმატებლად შეეცდება მათ ჩვეულებრივ დემონტაჟს).

კინოთეატრი იწყება პალტოების საკიდით, ხოლო Ceph-ის კლასტერი - მონიტორებით. მოდით, განვიხილოთ ისინი.

რუკი მონიტორის პოდში შემდეგ ობიექტებს ამაგრებს:

Volumes:
 rook-ceph-config:
   Type:      ConfigMap (a volume populated by a ConfigMap)
   Name:      rook-ceph-config
 rook-ceph-mons-keyring:
   Type:        Secret (a volume populated by a Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Type:          HostPath (bare host directory volume)
   Path:          /var/lib/rook/mon-a/data
Mounts:
  /etc/ceph from rook-ceph-config (ro)
  /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw)
  /var/log/ceph from rook-ceph-log (rw)

ვნახოთ, რა არის საიდუმლო rook-ceph-mons-keyring:

kind: Secret
data:
 keyring: LongBase64EncodedString=

ჩვენ ვშიფრავთ და ვიღებთ ჩვეულებრივ საკვანძო რგოლს ადმინისტრატორისა და მონიტორების უფლებებით:

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

გავიხსენოთ. ახლა კი საიდუმლოდ გადავხედოთ გასაღების საკიდს. rook-ceph-admin-keyring:

kind: Secret
data:
 keyring: anotherBase64EncodedString=

რა არის მასში?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

აქაც იგივეა. კიდევ ერთხელ ვნახოთ... აი, მაგალითად, საიდუმლო. rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

საბოლოოდ ConfigMap-ში კიდევ რამდენიმე საიდუმლოს ვპოულობთ. rook-ceph-mon:

kind: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

და ეს არის ორიგინალური სია გასაღების რგოლებით, საიდანაც მოდის ზემოთ აღწერილი ყველა საიდუმლო.

როგორც ცნობილია (იხ. dataDirHostPath в დოკუმენტაცია), რუკი ამ მონაცემებს ორ ადგილას ინახავს. მოდით, გადავიდეთ კვანძებზე, რათა ვნახოთ ბრელოკები, რომლებიც შენახულია მონიტორებითა და OSD-ებით პოდებში დამონტაჟებულ დირექტორიებში. ამისათვის კვანძებზე ვიპოვით [ბრელოკებს]. /var/lib/rook/mon-a/data/keyring და ჩვენ ვნახავთ:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

უეცრად აქ საიდუმლო განსხვავებული აღმოჩნდა - არა ConfigMaps-ის მსგავსად.

რაც შეეხება ადმინისტრატორის გასაღებს? ისიც გვაქვს:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

პრობლემა სწორედ ეს არის. იყო რაღაც ხარვეზი: კლასტერი ხელახლა შეიქმნა... სინამდვილეში კი ასე არ მოხდა.

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

• მონიტორის გასაღების რგოლს ფაილიდან ვიღებთ /var/lib/rook/mon-a/data/keyring (ან სარეზერვო ასლიდან);
• ფარულად შეცვალეთ გასაღების სამაგრი rook-ceph-mons-keyring;
• დაარეგისტრირეთ გასაღების რგოლი ადმინისტრატორიდან და მონიტორიდან ConfigMap-ში rook-ceph-mon;
• ჩვენ ვხსნით პოდ კონტროლერებს მონიტორებთან ერთად.

სასწაული მალე მოხდება: მონიტორები გამოჩნდება და დაიწყებენ მუშაობას. ჰურა, ყველაფერი დაიწყო!

ჩვენ აღვადგენთ OSD-ს

მოდი, პოდში წავიდეთ rook-operator: გამოწვევა ceph mon dump აჩვენებს, რომ ყველა მონიტორი ადგილზეა და ceph -s - რომ ისინი კვორუმში არიან. თუმცა, თუ OSD ხეს დააკვირდებით (ceph osd tree), უცნაურ რამეს დავინახავთ: OSD-ები გამოჩნდა, მაგრამ ისინი ცარიელია. აღმოჩნდა, რომ მათი აღდგენაც როგორმე საჭიროა. მაგრამ როგორ?

ამასობაში, ConfigMaps-მა შეიძინა ის ფუნქციები, რომლებიც ასე სასოწარკვეთილად გვჭირდებოდა. rook-ceph-config и rook-config-override, ასევე მრავალი სხვა ConfigMap სახელწოდებით, როგორიცაა rook-ceph-osd-$nodename-configმოდით შევხედოთ მათ:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

ყველაფერი არასწორია, ყველაფერი აერია!

მოდით, ოპერატორის პოდი ნულამდე დავიყვანოთ, წავშალოთ გენერირებული პოდის განლაგებები OSD-ის მეშვეობით და გამოვასწოროთ ეს ConfigMaps. მაგრამ საიდან ვიშოვოთ ისინი? სწორი OSD რუკა კვანძების მიხედვით?

• მოდით, კიდევ ერთხელ ვცადოთ დირექტორიების დათვალიერება. /mnt/osd[1-2] კვანძებზე - იმ იმედით, რომ იქ რაღაცას მივხვდებით.
• კატალოგში /mnt/osd1 არსებობს 2 ქვედირექტორია: osd0 и osd16ეს უკანასკნელი ზუსტად ConfigMap-ში (16) მითითებული ID-ია?
• მოდით, შევამოწმოთ ზომები და ვნახოთ, რომ osd0 ბევრად მეტი osd16.

ჩვენ იმ დასკვნამდე მივდივართ, რომ osd0 - ეს არის საჭირო OSD, რომელიც მითითებული იყო, როგორც /mnt/osd1 ConfigMap-ში (რადგან ჩვენ ვიყენებთ დირექტორიაზე დაფუძნებული OSD.)

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

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

მოდით, ისევ Rook ოპერატორების პოდში შევიდეთ და კლასტერის მდგომარეობა შევამოწმოთ... დიახ, ზოგიერთ კვანძზე OSD სახელები ცოტათი შევაფერხეთ! პრობლემა არ არის: ხელახლა შევცვალეთ ConfigMaps, ახალი OSD-ებიდან ზედმეტი დირექტორიები წავშალეთ და დიდი ხნის ნანატრ მდგომარეობას მივაღწიეთ. HEALTH_OK!

მოდით, გადავხედოთ აუზში გადაღებულ სურათებს:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

ყველაფერი თავის ადგილზეა - კლასტერი შენახულია!

ძალიან მეზარება სარეზერვო ასლების გაკეთება, ან სწრაფი გზა

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

1. ჩვენ Rook ოპერატორის განლაგებას ნულამდე ვახდენთ;
2. ჩვენ ვშლით ყველა განლაგებას, გარდა Rook ოპერატორისა;
3. ჩვენ აღვადგენთ ყველა საიდუმლოებას და ConfigMaps-ს სარეზერვო ასლიდან;
4. დირექტორიის შინაარსის აღდგენა /var/lib/rook/mon-* კვანძებზე;
5. ჩვენ აღვადგენთ (თუ მოულოდნელად დავკარგეთ) CRD-ს CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Rook ოპერატორის განლაგებას ისევ 1-მდე ვამცირებთ.

სასარგებლო რჩევები

შექმენით სარეზერვო ასლები!

და იმ სიტუაციების თავიდან ასაცილებლად, როდესაც მათგან აღდგენაა საჭირო:

1. სერვერების გადატვირთვასთან დაკავშირებული მასშტაბური კლასტერული სამუშაოს შესრულებამდე, Rook ოპერატორი ნულამდე დააყენეთ, რათა მან ზედმეტი არაფერი გააკეთოს.
2. მონიტორებზე წინასწარ nodeAffinity-ის დამატება.
3. ყურადღება მიაქციეთ წინასწარ ტაიმ-აუტების დაყენება ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

იმის ნაცვლად, რომ დასკვნა

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

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

PS

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

• «რუკს თუ არა რუკს - ეს არის კითხვა";
• «Rook - "თვითმომსახურების" მონაცემთა საწყობი Kubernetes-ისთვის";
• «Longhorn, Rancher-ის K8-ებისთვის განაწილებული საცავი, CNCF-ს წარედგინა.".
• «მუდმივი მეხსიერების შექმნა Kubernetes-ში მიწოდებით Ceph-ის საფუძველზე".

წყარო: www.habr.com