კუბერნეტის ტოპ 10 ხრიკი და რჩევა

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

უმარტივესი ბრძანება Kubernetes-თან მუშაობისთვის

დასაწყისისთვის, ალბათ ყველაზე მარტივი და სასარგებლო მოქმედება Kubernetes-თან მუშაობისას. შემდეგი ბრძანება იძლევა ბრძანების დასრულებას kubectl bash shell-ში:

echo "source <(kubectl completion bash)" >> ~/.bashrc

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

ნაგულისხმევი მეხსიერება და CPU ლიმიტები სახელთა სივრცეში

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

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

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

შექმენით ასეთი იამლი და მიმართეთ ნებისმიერ სახელთა სივრცეს. მაგალითად, სახელთა სივრცეში limit-example. ახლა ამ სახელთა სივრცეში განლაგებულ ნებისმიერ კონტეინერს ექნება 512 Mi ლიმიტი, თუ ამ კონტეინერისთვის დამატებით არ არის დაყენებული სხვა ინდივიდუალური ლიმიტი.

ნაგვის შეგროვება Kubernetes-ის ძველ ვერსიებში

Kubelet ნაგულისხმევად იწყებს ნაგვის შეგროვებას, როდესაც var/lib/docker იკავებს ხელმისაწვდომი დისკის სივრცის 90%. ეს შესანიშნავია, თუმცა, სანამ Kubernetes 1.7 არ იყო ნაგულისხმევი ლიმიტი გამოყენებული ინოდების რაოდენობაზე, რაც შეესაბამება ფაილების სისტემაში ფაილების რაოდენობას.

პოტენციურად თქვენი კონტეინერი var/lib/docker შეიძლება გამოიყენოს დისკის სივრცის მხოლოდ 50%, მაგრამ შეიძლება ამოიწუროს ინოდები, რაც პრობლემებს შეუქმნის მუშებს.

Kubelet-ის ძველ ვერსიებში 1.4-დან 1.6-მდე მოგიწევთ დაამატოთ ეს დროშა:

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

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

მინიკუბე... პატარა, მაგრამ ძლიერი ადგილობრივი კუბერნეტები

Minikube არის უმარტივესი გზა ადგილობრივი Kubernetes კლასტერის გასაშვებად. იგი გაშვებულია მარტივი ბრძანებით:

minikube start

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

ილუსტრაციის წყარო

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

იმისათვის, რომ Docker აიძულოთ სურათი გადაიტანოს ადგილობრივ Kubernetes კლასტერში, დოკერ მანქანას ეძლევა შემდეგი ბრძანება:

eval $(minikube docker-env)

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

არ მისცეთ kubectl-ს წვდომა ყველას

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

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

პოდ ბიუჯეტის მართვა

როგორ უზრუნველვყოთ კუბერნეტის კლასტერში აპლიკაციის შეფერხების დრო? PodDisruptionBudget და ისევ PodDisruptionBudget.

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

შენიშვნა: PDB ბიუჯეტი მხედველობაში მიიღება მხოლოდ მაშინ, როდესაც ბიუჯეტის დარღვევა შექცევადია (ნებაყოფლობითი შეფერხება). ისეთ სიტუაციებში, როგორიცაა ტექნიკის გაუმართაობა, PDB არ იმუშავებს.

მაგალითი PDB:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: app-a-pdb
spec:
  minAvailable: 2
  selector:
      matchLabels:
        app: app-a

ორი ძირითადი პარამეტრია matchLabels и minAvailable. პირველი პარამეტრი განსაზღვრავს, რომელ აპლიკაციებზე ვრცელდება ბიუჯეტი. მაგალითად, თუ მე მაქვს განლაგება ეტიკეტებით app: app-a и app: app-b, მაშინ ეს PDB ვრცელდება მხოლოდ პირველზე.

პარამეტრის minAvailable გათვალისწინებულია კვანძის დაცლის (გაწმენდისას). მაგალითად, ჩვენს მაგალითში, დაცლის დროს, ყველა ინსტანცია გამოსახლებულია app: app-a, გარდა ორი.

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

განაცხადის ჯანმრთელობის მონიტორინგი

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

პირველი ზონდი (მზადყოფნა) განსაზღვრავს კონტეინერის მზადყოფნას ტრაფიკის მისაღებად.

მეორე (სიცოცხლე) გვიჩვენებს, არის თუ არა კონტეინერი ჯანსაღი ან საჭიროებს ხელახლა დაწყებას.

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

ტეგები ყველგანაა

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

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

ვთქვათ, იყენებთ იმავე კლასტერს dev и qa. ეს ნიშნავს, რომ თქვენ შეგიძლიათ გქონდეთ აპლიკაცია app-a, ერთდროულად მუშაობს ორივე გარემოში qa и dev. ამ შემთხვევაში, ჩვენ შეგვიძლია ცალკე წვდომა აპლიკაციის ინსტანციაზე კონკრეტულ გარემოში შესაბამისი პარამეტრის მითითებით environment. მაგალითად, app: app-a и environment: dev ერთი გარემოსთვის და app: app-a и environment: qa მეორესთვის.

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

მოწესრიგდი საგნები

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

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

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

გაიცანი Go

მთავარი რჩევა ბოლოს შევინახეთ. ისწავლეთ Go პროგრამირების ენა.

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

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

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

თარგმნილია Mail.ru Cloud Solutions-ის მხარდაჭერით

სხვა რა წაიკითხო:

1. ავტოსკალირების სამი დონე Kubernetes-ში და როგორ გამოვიყენოთ ისინი ეფექტურად.
2. Kubernetes მუშა კვანძები: ბევრი პატარა ან რამდენიმე დიდი?
3. 25 სასარგებლო ინსტრუმენტი Kubernetes-ის განლაგებისა და მართვისთვის.

წყარო: www.habr.com