10 გავრცელებული შეცდომა Kubernetes-ის გამოყენებისას

Შენიშვნა. თარგმნა: ამ სტატიის ავტორები არიან ინჟინრები პატარა ჩეხური კომპანიის, pipetail-დან. მათ მოახერხეს შეაგროვეს მშვენიერი სია [ზოგჯერ ბანალური, მაგრამ მაინც] ძალიან აქტუალური პრობლემებისა და მცდარი წარმოდგენების შესახებ, რომლებიც დაკავშირებულია Kubernetes კლასტერებთან.

Kubernetes-ის გამოყენების წლების განმავლობაში, ჩვენ ვიმუშავეთ დიდი რაოდენობით კლასტერებთან (როგორც მართული, ასევე უმართავი - GCP-ზე, AWS-ზე და Azure-ზე). დროთა განმავლობაში დავიწყეთ იმის შემჩნევა, რომ გარკვეული შეცდომები მუდმივად მეორდებოდა. თუმცა, ამაში სირცხვილი არ არის: უმეტესობა ჩვენ თვითონ გავაკეთეთ!

სტატიაში მოცემულია ყველაზე გავრცელებული შეცდომები და ასევე მითითებულია მათი გამოსწორების გზები.

1. რესურსები: მოთხოვნები და ლიმიტები

ეს ნივთი ნამდვილად იმსახურებს ყველაზე დიდ ყურადღებას და პირველ ადგილს სიაში.

CPU მოთხოვნა ჩვეულებრივ ან საერთოდ არ არის მითითებული, ან აქვს ძალიან დაბალი ღირებულება (თითოეულ კვანძზე რაც შეიძლება მეტი ჯიშის მოთავსება). ამრიგად, კვანძები გადატვირთულია. მაღალი დატვირთვის დროს, კვანძის გადამამუშავებელი ძალა სრულად გამოიყენება და კონკრეტული დატვირთვა იღებს მხოლოდ იმას, რასაც "ითხოვს" CPU throttling. ეს იწვევს განაცხადის შეყოვნების გაზრდას, ვადის ამოწურვას და სხვა უსიამოვნო შედეგებს. (დაწვრილებით ამის შესახებ ჩვენს სხვა ბოლო თარგმანში: ”CPU-ს შეზღუდვები და აგრესიული throttling in Kubernetes" - დაახლ. თარგმანი.)

Საუკეთესო ძალა ( უკიდურესად არარის რეკომენდებულია):

resources: {}

უკიდურესად დაბალი CPU მოთხოვნა (უკიდურესად არარის რეკომენდებულია):

   resources:
      Requests:
        cpu: "1m"

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

გადაჭარბებული შერჩევა (გადაჭარბება) მეხსიერების პრობლემებმა შეიძლება გამოიწვიოს უფრო დიდი პრობლემები. CPU-ს ლიმიტის მიღწევა გულისხმობს საათის ციკლების გამოტოვებას, ხოლო მეხსიერების ლიმიტის მიღწევა გულისხმობს პოდის მოკვლას. ოდესმე თუ დაკვირვებია OOMkill? დიახ, სწორედ ამაზე ვსაუბრობთ.

გსურთ მინიმუმამდე დაიყვანოთ ამის ალბათობა? ნუ გადაანაწილებთ მეხსიერებას და გამოიყენეთ გარანტირებული QoS (მომსახურების ხარისხი) მეხსიერების მოთხოვნის ლიმიტზე დაყენებით (როგორც ქვემოთ მოცემულ მაგალითში). წაიკითხეთ მეტი ამის შესახებ ჰენინგ ჯეიკობსის პრეზენტაციები (წამყვანი ინჟინერი ზალანდო).

ადიდებული (OOM-ის მოკვლის უფრო მაღალი შანსი):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

გარანტირებული:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

რა დაგეხმარებათ რესურსების შექმნისას?

ერთად მეტრიკა-სერვერი შეგიძლიათ იხილოთ CPU რესურსის მიმდინარე მოხმარება და მეხსიერების გამოყენება pods (და მათ შიგნით კონტეინერები). სავარაუდოდ, თქვენ უკვე იყენებთ მას. უბრალოდ გაუშვით შემდეგი ბრძანებები:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

თუმცა, ისინი აჩვენებენ მხოლოდ მიმდინარე გამოყენებას. მას შეუძლია მოგცეთ უხეში წარმოდგენა სიდიდის რიგის შესახებ, მაგრამ საბოლოოდ დაგჭირდებათ დროთა განმავლობაში მეტრიკის ცვლილებების ისტორია (პასუხი კითხვებზე, როგორიცაა: „რა იყო CPU-ის მაქსიმალური დატვირთვა?“, „რა იყო დატვირთული გუშინ დილით?“ და ა.შ.). ამისთვის შეგიძლიათ გამოიყენოთ პრომეთე, მონაცემთა ძაღლი და სხვა იარაღები. ისინი უბრალოდ იღებენ მეტრებს metrics-server-დან და ინახავენ მათ, ხოლო მომხმარებელს შეუძლია გამოიკითხოს ისინი და შესაბამისად შეადგინოს ისინი.

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

გამოთვლითი ენერგიის ეფექტურად გამოყენება არ არის ადვილი ამოცანა. ეს თითქოს ტეტრისს ყოველთვის თამაშობ. თუ ძალიან ბევრს იხდით გამოთვლით სიმძლავრეზე დაბალი საშუალო მოხმარებით (ვთქვათ ~10%), გირჩევთ ნახოთ პროდუქტები AWS Fargate-ზე ან Virtual Kubelet-ზე. ისინი აგებულია სერვერის გარეშე/გადახდის თითო გამოყენებაზე ბილინგის მოდელზე, რომელიც შეიძლება უფრო იაფი აღმოჩნდეს ასეთ პირობებში.

2. სიცოცხლისუნარიანობისა და მზადყოფნის ზონდები

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

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

ეს ტესტები ხშირად ერთმანეთში აირია:

• სიცოცხლე — „გადარჩენის“ შემოწმება, რომელიც გადატვირთავს პოდს, თუ ის ვერ მოხერხდება;
• მზადყოფნა — მზადყოფნის შემოწმება, თუ ის ვერ ხერხდება, ის წყვეტს პოდს Kubernetes სერვისიდან (ამის შემოწმება შესაძლებელია გამოყენებით kubectl get endpoints) და ტრაფიკი არ მიდის მასზე, სანამ შემდეგი შემოწმება წარმატებით არ დასრულდება.

ორივე ეს შემოწმება შესრულებული POD-ის მთელი სასიცოცხლო ციკლის განმავლობაში. Ეს ძალიან მნიშვნელოვანია.

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

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

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

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

3. LoadBalancer თითოეული HTTP სერვისისთვის

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

თუ სერვისს გახსნით როგორც type: LoadBalancer, მისი კონტროლერი (დამოკიდებულია სერვისის პროვაიდერზე) უზრუნველყოფს გარე LoadBalancer-ს (აუცილებლად არ მუშაობს L7-ზე, არამედ L4-ზეც კი) და ამან შეიძლება გავლენა მოახდინოს ღირებულებაზე (გარე სტატიკური IPv4 მისამართი, გამოთვლითი სიმძლავრე, ბილინგი წამში. ) ასეთი რესურსების დიდი რაოდენობის შექმნის აუცილებლობის გამო.

ამ შემთხვევაში, ბევრად უფრო ლოგიკურია ერთი გარე დატვირთვის ბალანსერის გამოყენება, სერვისების გახსნა როგორც type: NodePort. ან კიდევ უკეთესი, გააფართოვეთ მსგავსი რამ nginx-ingress-კონტროლერი (ან ტრეფიკი), ვინ იქნება ერთადერთი NodePort საბოლოო წერტილი დაკავშირებულია დატვირთვის გარე ბალანსერთან და მარშრუტებს ტრაფიკს კლასტერში გამოყენებით ingress-კუბერნეტის რესურსები.

სხვა შიდა კლასტერულ (მიკრო) სერვისებს, რომლებიც ურთიერთობენ ერთმანეთთან, შეუძლიათ „კომუნიკაცია“ ისეთი სერვისების გამოყენებით, როგორიცაა ClusterIP და ჩაშენებული სერვისის აღმოჩენის მექანიზმი DNS-ის საშუალებით. უბრალოდ არ გამოიყენოთ მათი საჯარო DNS/IP, რადგან ამან შეიძლება გავლენა მოახდინოს შეყოვნებაზე და გაზარდოს ღრუბლოვანი სერვისების ღირებულება.

4. კლასტერის ავტომატური მასშტაბირება მისი მახასიათებლების გათვალისწინების გარეშე

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

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

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

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

5. IAM/RBAC შესაძლებლობების უგულებელყოფა

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

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

დაივიწყეთ kube2iam და გადადით პირდაპირ IAM-ის როლებზე სერვისის ანგარიშებისთვის (როგორც აღწერილია ამავე სახელწოდების შენიშვნა შტეპან ვრანი):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ერთი ანოტაცია. არც ისე რთულია, არა?

ასევე, არ მიანიჭოთ სერვისის ანგარიშებს და მაგალითების პროფილებს პრივილეგიები admin и cluster-adminთუ მათ ეს არ სჭირდებათ. ამის განხორციელება ცოტა უფრო რთულია, განსაკუთრებით RBAC K8-ებში, მაგრამ ნამდვილად ღირს ძალისხმევა.

6. ნუ დაეყრდნობით ავტომატურ ანტი-აფინურობას წიპწების მიმართ

წარმოიდგინეთ, რომ თქვენ გაქვთ კვანძზე რაიმე განლაგების სამი ასლი. კვანძი ეცემა და მასთან ერთად ყველა რეპლიკა. არასასიამოვნო სიტუაციაა, არა? მაგრამ რატომ იყო ყველა რეპლიკა ერთსა და იმავე კვანძზე? კუბერნეტესმა არ უნდა უზრუნველყოს მაღალი ხელმისაწვდომობა (HA)?!

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

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

Სულ ეს არის. ახლა pods დაიგეგმება სხვადასხვა კვანძებში (ეს მდგომარეობა მოწმდება მხოლოდ დაგეგმვისას, მაგრამ არა მათი მუშაობისას - შესაბამისად requiredDuringSchedulingIgnoredDuringExecution).

აქ საუბარია podAntiAffinity სხვადასხვა კვანძებზე: topologyKey: "kubernetes.io/hostname", - და არა სხვადასხვა ხელმისაწვდომობის ზონების შესახებ. სრულფასოვანი HA-ს განსახორციელებლად, თქვენ მოგიწევთ უფრო ღრმად ჩასწვდეთ ამ თემას.

7. PodDisruptionBudgets-ის იგნორირება

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

PDB საშუალებას გაძლევთ თავიდან აიცილოთ სერვისის შეფერხებები, რომლებიც გამოწვეულია კვანძების ნაკლებობით:

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

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

ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ აქ.

8. მრავალი მომხმარებელი ან გარემო საერთო კლასტერში

Kubernetes სახელების სივრცეები (სახელთა სივრცეები) არ იძლევა ძლიერ იზოლაციას.

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

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

9. გარე ტრაფიკის პოლიტიკა: კლასტერი

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

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

მეორეს მხრივ, თუ კუბერნეტის გარკვეულ სერვისს აქვს პოლიტიკის ნაკრები externalTrafficPolicy: Local, მაშინ NodePort იხსნება მხოლოდ იმ კვანძებზე, სადაც რეალურად გაშვებულია საჭირო პოდები. გარე დატვირთვის ბალანსერის გამოყენებისას, რომელიც ამოწმებს მდგომარეობას (ჯანმრთელობის შემოწმება) საბოლოო წერტილები (როგორ აკეთებს AWS ELB), ის გაგზავნის ტრაფიკს მხოლოდ საჭირო კვანძებში, რაც ხელსაყრელ გავლენას მოახდენს შეფერხებებზე, გამოთვლის საჭიროებებზე, გასვლის გადასახადებზე (და საღი აზრიც იგივეს გვკარნახობს).

დიდი შანსია, რომ თქვენ უკვე იყენებთ მსგავს რამეს ტრეფიკი ან nginx-ingress-კონტროლერი როგორც NodePort-ის ბოლო წერტილი (ან LoadBalancer, რომელიც ასევე იყენებს NodePort-ს) HTTP შემოსული ტრაფიკის მარშრუტისთვის და ამ პარამეტრის დაყენებამ შეიძლება მნიშვნელოვნად შეამციროს ასეთი მოთხოვნების შეყოვნება.

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

10. არ შეხვიდეთ მტევნებზე და ნუ ბოროტად გამოიყენებთ საკონტროლო სიბრტყეს

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

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

არაფერია გასართობი მტევნის შინაურ ცხოველებად გადაქცევაში, ამიტომ გირჩევთ ვარჯიშის დროს პერიოდულად ამოიღოთ ისინი კატასტროფის აღდგენა (ეს დაეხმარება ქაოსის ინჟინერია - დაახლ. თარგმანი.). გარდა ამისა, საკონტროლო ფენაზე მუშაობა არ დააზარალებს (საკონტროლო თვითმფრინავი). მისი შეხების შიში არ არის კარგი ნიშანი. და ა.შ. მკვდარი? ბიჭებო, თქვენ ნამდვილად გაგიჭირდათ!

მეორეს მხრივ, თქვენ არ უნდა გაიტაცოთ მისი მანიპულირებით. დროთა განმავლობაში საკონტროლო ფენა შეიძლება გახდეს ნელი. სავარაუდოდ, ეს გამოწვეულია ობიექტების დიდი რაოდენობის შექმნით მათი ბრუნვის გარეშე (ჩვეულებრივი სიტუაცია, როდესაც იყენებთ Helm-ს ნაგულისხმევი პარამეტრებით, რის გამოც მისი მდგომარეობა კონფიგურაციებში/საიდუმლოებში არ განახლდება - შედეგად, ათასობით ობიექტი გროვდება საკონტროლო ფენა) ან kube-api ობიექტების მუდმივი რედაქტირებით (ავტომატური სკალირებისთვის, CI/CD-სთვის, მონიტორინგისთვის, მოვლენების ჟურნალები, კონტროლერები და ა.შ.).

გარდა ამისა, ჩვენ გირჩევთ შეამოწმოთ SLA/SLO ხელშეკრულებები მართულ Kubernetes-ის პროვაიდერთან და ყურადღება მიაქციოთ გარანტიებს. გამყიდველს შეუძლია გარანტია საკონტროლო ფენის ხელმისაწვდომობა (ან მისი ქვეკომპონენტები), მაგრამ არა თქვენ მიერ გაგზავნილი მოთხოვნების p99 დაგვიანებით. სხვა სიტყვებით რომ ვთქვათ, შეგიძლიათ შეხვიდეთ kubectl get nodes, და მიიღეთ პასუხი მხოლოდ 10 წუთის შემდეგ და ეს არ იქნება მომსახურების ხელშეკრულების პირობების დარღვევა.

11. ბონუსი: უახლესი ტეგის გამოყენებით

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

ECR ინარჩუნებს სურათის ტეგების უცვლელობას; ჩვენ გირჩევთ გაეცნოთ ამ შესანიშნავი თვისებას.

რეზიუმე

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

შეგიძლიათ გაეცნოთ სხვადასხვა გუნდის წარუმატებელ გამოცდილებას მოთხრობების ეს კრებული ჰენინგ ჯეიკობსის მიერ.

ამ სტატიაში მოცემული შეცდომების სიაში დამატება მსურველებს შეუძლიათ დაგვიკავშირდნენ Twitter-ზე (@MarekBartik, @MstrsObserver).

PS მთარგმნელისგან

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

• «Kubernetes კლასტერების დიზაინი: რამდენი უნდა იყოს?";
• «უსაფრთხოების ABC Kubernetes-ში: ავთენტიფიკაცია, ავტორიზაცია, აუდიტი";
• «ავტომატური მასშტაბირება და რესურსების მართვა Kubernetes-ში„(მიმოხილვა და ვიდეო რეპორტაჟი);
• «ConfigMaps Kubernetes-ში: ნიუანსები, რომელთა ცოდნაც ღირს".

წყარო: www.habr.com