გოგონა სკუტერზე. ილუსტრაცია FreepikNomad-ის ლოგო დან HashiCorp

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

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

Რა გინდა

ჩვენი გუნდი მხარს უჭერს უამრავ საერთო შესრულების მონიტორინგისა და ანალიზის სერვისებს: API ბოლო წერტილები Go-ში დაწერილი მეტრიკებისთვის, Prometheus-ის ექსპორტი, ჟურნალის ანალიზატორები, როგორიცაა Logstash და გოლუმი, ისევე როგორც მონაცემთა ბაზები, როგორიცაა InfluxDB ან Elasticsearch. თითოეული ეს სერვისი მუშაობს საკუთარ კონტეინერში. ჩვენ გვჭირდება მარტივი სისტემა, რომ ყველაფერი გამართული იყოს.

ჩვენ დავიწყეთ კონტეინერის ორკესტრირების მოთხოვნების ჩამონათვალით:

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

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

• მანქანების მარკირება მათი შესაძლებლობებიდან გამომდინარე (მაგალითად, მანქანების მარკირება სწრაფი დისკებით მძიმე I/O სერვისებისთვის).
• ორკესტრისგან დამოუკიდებლად სერვისების გაშვების შესაძლებლობა (მაგალითად, განვითარების დროს).
• საერთო ადგილი კონფიგურაციებისა და საიდუმლოებების გასაზიარებლად.
• საბოლოო წერტილი მეტრიკისა და ჟურნალებისთვის.

რატომ არ არის კუბერნეტესი ჩვენთვის სწორი?

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

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

გარდა ამისა, კუბერნეტესის ეკოსისტემა სწრაფად ვითარდება. დიდი დრო და ენერგია სჭირდება საუკეთესო პრაქტიკისა და უახლესი ინსტრუმენტების გაცნობას. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - სია გრძელდება და გრძელდება. ყველა ეს ხელსაწყო არ არის საჭირო, როცა იწყებ, მაგრამ არ იცი რა დაგჭირდება, ამიტომ ყველაფერი უნდა იცოდე. ამის გამო სწავლის მრუდი საკმაოდ ციცაბოა.

როდის გამოვიყენოთ Kubernetes

ჩვენს კომპანიაში ბევრი ადამიანი იყენებს Kubernetes-ს და საკმაოდ კმაყოფილია ამით. ამ შემთხვევებს მართავს Google ან Amazon, რომლებსაც აქვთ მათი მხარდაჭერის რესურსები.

Kubernetes მოყვება საოცარი თვისებები, რაც კონტეინერების ორკესტრირებას უფრო მართვადს ხდის:

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

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

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

ბატარეები არ მოყვება

Nomad არის ორკესტრის 20%, რომელიც უზრუნველყოფს საჭიროების 80%. ყველა ის აკეთებს არის განლაგების მართვა. Nomad ზრუნავს განლაგებაზე, შეცდომის შემთხვევაში გადატვირთავს კონტეინერებს... და ეგაა.

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

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

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

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

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

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

აქ წავიკითხეთ გასაღები service/geo-api/log-verbosity კონსულისგან და ექსპლუატაციის დროს გარემოს ცვლადზე გავლენის ქვეშ LOG_LEVEL. ჩვენ ასევე წარმოგიდგენთ გასაღებს secret/geo-api-key Vault-დან როგორც API_KEY. მარტივი, მაგრამ ძლიერი!

მისი სიმარტივის გამო, Nomad ადვილად გაფართოებულია სხვა სერვისებთან API-ის საშუალებით. მაგალითად, ამოცანების ტეგები მხარდაჭერილია. ჩვენ ყველა სერვისს აღვნიშნავთ მეტრიკის მიხედვით trv-metrics. ამ გზით პრომეთე ადვილად იპოვის ამ სერვისებს კონსულის მეშვეობით და პერიოდულად ამოწმებს საბოლოო წერტილს /metrics ახალი მონაცემებისთვის. იგივე შეიძლება გაკეთდეს, მაგალითად, ჟურნალებისთვის, გამოყენებით ლოკი.

გაფართოების მრავალი სხვა მაგალითია:

• შეასრულეთ ჯენკინსის სამუშაო კაკლის გამოყენებით და კონსული აკონტროლებს Nomad-ის სამუშაოს გადანაწილებას, როდესაც სერვისის კონფიგურაცია იცვლება.
• Ceph ამატებს განაწილებულ ფაილურ სისტემას Nomad-ს.
• fabio დატვირთვის დაბალანსებისთვის.

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

სამართლიანი გაფრთხილება

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

კუბერნეტებთან შედარებით, მომთაბარე საზოგადოება არც ისე დიდია. Kubernetes-ს უკვე ჰყავს დაახლოებით 75 commit და 000 კონტრიბუტორი, ხოლო Nomad-ს აქვს დაახლოებით 2000 commit და 14 contributor. Nomad-ს გაუჭირდება კუბერნეტესის სიჩქარის შენარჩუნება, მაგრამ შესაძლოა არც იყოს საჭირო! ეს უფრო სპეციალიზებული სისტემაა და უფრო მცირე საზოგადოება ასევე ნიშნავს, რომ თქვენი მოთხოვნის შემჩნევა და მიღება უფრო სავარაუდოა, ვიდრე Kubernetes.

რეზიუმე

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

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

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

თუ Kubernetes მანქანას შევადარებთ, Nomad იქნებოდა სკუტერი. ხან ერთი გჭირდება და ხან მეორე. ორივეს აქვს არსებობის უფლება.

წყარო: www.habr.com