ბიბლიოთეკა
00/07 · ~38 წთ
GUIDEDECK · კონტეინერები, რომლებიც არ ვარდება

Kubernetes
& თვითგანკურნებადი
კლასტერის ხელოვნება.

38-წუთიანი სამუშაო სესია იმაზე, როგორ გადახვიდეთ ლეპტოპზე გაშვებული ერთი კონტეინერიდან მთელ ფლოტამდე, რომელიც თავად ანაწილებს, მასშტაბირებს და ირჩენს თავს — Pod-ები, Deployment-ები, Service-ები, კონფიგურაცია & საცავი, ავტომასშტაბირება და ის ინსტრუმენტები, რომლებიც ამ ყველაფერს ერთად კრავს.

~38 წთდამწყები → საშუალოპრაქტიკული ცნებები
გადაახვიეთ
01 · რატომ Kubernetes 4 წთ

ერთი კონტეინერი მარტივია.
ასი, ბევრ მანქანაზე გაფანტული — აღარ.

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

Kubernetes (ხშირად წერენ როგორც K8s — „K“, რვა ასო, „s“) — ღია კოდის სისტემა, რომელიც თქვენს კონტეინერებს მანქანების ჯგუფზე უშვებს და მუშა მდგომარეობაში ინახავს. თქვენ ეუბნებით, რა გინდათ („ამ აპლიკაციის ხუთი ასლი, ყოველთვის ჩართული“); ის კი თავად წყვეტს, სად განათავსოს ისინი, აკვირდება მათ და ასწორებს, როცა რეალობა თქვენს სურვილს დაშორდება.
ორკესტრირება — ბევრი კონტეინერის განთავსების, ქსელის, მასშტაბირებისა და აღდგენის ავტომატიზაცია. წარმოიდგინეთ საპორტო ტერმინალი: თითოეულ კონტეინერს ხელით არ ეზიდებით — ამწეების სისტემა წყვეტს, რომელ გემზე და რომელ სლოტში მოხვდება, და ხელახლა დგამს ყველაფერს, რაც ჩამოვარდება. Kubernetes სწორედ ეს ამწეების სისტემაა პროგრამებისთვის.

ერთი იდეა, რომელზეც ყველაფერი დგას: კონტროლის ციკლი

  • თქვენ YAML ფაილში ჩაწერთ სასურველ მდგომარეობას („v2-ის 3 რეპლიკა“) და გადასცემთ კლასტერს.
  • Kubernetes მუდმივად ადარებს კლასტერის სასურველ და ფაქტიურ მდგომარეობას.
  • როცა ისინი განსხვავდება — pod ჩავარდა, ნოუდი გაქრა — ის ათანხმებს მათ: უშვებს, აჩერებს ან გადააქვს, სანამ რეალობა თქვენს სურვილს არ დაემთხვევა.
  • ეს დეკლარაციული მიდგომაა: აღწერთ დანიშნულების წერტილს და არა ნაბიჯ-ნაბიჯ მარშრუტს.

სასურველი და ფაქტიური, სამუდამოდ. სწორედ ამ სხვაობის დახურვას უთმობს Kubernetes მთელ სიცოცხლეს.

რას გაძლევთ ეს

⟳

თვითგანკურნება. ჩავარდნილი კონტეინერი ან მკვდარი მანქანა? ავტომატურად ჩანაცვლდება.

⇅

მასშტაბირება. ღამით 3 ასლი, პიკზე 30 — ხელით ან ავტომატურად.

↻

განახლება მოცდენის გარეშე. ახალი ვერსია თანდათან გამოდის; თუ ცუდად იქცევა, უკან დააბრუნებთ.

⇄

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

02 · ძირითადი ობიექტები 7 წთ

Pod-ები, ReplicaSet-ები
და მათ თავზე Deployment.

თითქმის ყველაფერი, რასაც უშვებთ, ობიექტების მცირე ნაკრებით აღიწერება, რომლებიც ერთმანეთზე ეწყობა. დროის 90%-ს სამ მათგანთან გაატარებთ: Pod (რა მუშაობს), ReplicaSet (რამდენი) და Deployment (როგორ იცვლება ის დროთა განმავლობაში).

Pod — ყველაზე მცირე რამ, რასაც Kubernetes უშვებს: ერთი ან რამდენიმე კონტეინერი, რომლებიც ერთ IP მისამართსა და საცავს იზიარებენ. ჩვეულებრივ ეს მხოლოდ ერთი აპლიკაციის კონტეინერია; ზოგჯერ გვერდით პატარა დამხმარეც მიჰყვება („sidecar“). pod-ები ერთჯერადია — ავადმყოფ pod-ს არ არჩენთ, უბრალოდ ცვლით.
Pod · 10.1.4.7
საერთო ქსელი + საცავი
აპის კონტეინერი
api:8080
sidecar (არჩ.)
log-shipper
ვოლუმი

ერთი pod-ის კონტეინერები ერთ IP-ს იზიარებენ და localhost-ით ესაუბრებიან ერთმანეთს. pod არის განთავსების ერთეული.

რატომ pod და არა უბრალოდ კონტეინერი?

  • ზოგი კონტეინერი ერთსა და იმავე მანქანაზე უნდა იყოს ერთად — აპლიკაცია და მისი ლოგების გამგზავნი, რომლებიც ფაილებსა და ქსელის სივრცეს იზიარებენ.
  • pod არის ერთეული, რომელსაც Kubernetes ანაწილებს და კურნავს. ის ერთ ნოუდზე ჯდება, მთლიანად ცოცხლობს და მთლიანად კვდება.
  • თითოეულ pod-ს თავისი IP აქვს — მაგრამ ეს IP დროებითია (შემდეგი სექცია სწორედ ამას აგვარებს).
ReplicaSet — მუშა მდგომარეობაში ინახავს იდენტური pod-ების ფიქსირებულ რაოდენობას. ითხოვთ 3-ს; თუ ერთი მოკვდება, ის მეოთხეს უშვებს — უკაცრავად, ჩამნაცვლებელ მესამეს. პირდაპირ მას იშვიათად ქმნით. Deployment — თქვენ მაგივრად მართავს ReplicaSet-ებს და ვერსიების ცვლილებას უვლის (rolling განახლებები, როლბექები, ისტორია). სწორედ ეს ობიექტია, რომელსაც რეალურად წერთ.

თქვენ წერთ Deployment-ს; ის ქმნის ReplicaSet-ს; ReplicaSet კი pod-ებს იმ რაოდენობაზე ინახავს, რაც მოითხოვეთ.

Deployment YAML-ში

apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 # სასურველი რაოდენობა selector: matchLabels: { app: api } template: # pod-ის ნიმუში metadata: labels: { app: api } spec: containers: - name: api image: ghcr.io/acme/api:v2 ports: [{ containerPort: 8080 }]

replicas: 3 სურვილია; template კი ის pod-ია, რომელიც სამჯერ იბეჭდება. გაუშვით apply და დანარჩენს ციკლი გააკეთებს.

ლეიბლები & სელექტორები — გასაღები/მნიშვნელობის იარლიყები ობიექტებზე და შეკითხვები, რომლებიც მათ პოულობენ. ეს Kubernetes-ის წებოა: ReplicaSet ფლობს „pod-ებს ლეიბლით app=api“, ხოლო Service მოგვიანებით სწორედ იმავე ლეიბლზე აგზავნის ტრაფიკს. არაფერია მიბმული ჩაშენებულ იდენტიფიკატორებზე — ყველაფერი ლეიბლებით თანხვდება.
03 · სერვისები და ქსელი 6 წთ

Pod-ები მოდიან და მიდიან.
Service მათ ფიქსირებულ შესასვლელს აძლევს.

თითოეულ pod-ს თავისი IP აქვს, მაგრამ pod-ები მუდმივად იცვლება — ანუ ეს IP მოძრავი სამიზნეა. მას კოდში ვერ ჩააწერთ. Service გაძლევთ სტაბილურ სახელსა და მისამართს, რომელიც ყოველთვის მის უკან მდგარ ჯანმრთელ pod-ებზე მიუთითებს, რამდენჯერაც არ უნდა შეიცვალონ ისინი.

Service — სტაბილური სახელი, IP და დატვირთვის ბალანსერი pod-ების იმ ნაკრებისთვის, რომელიც ლეიბლით არის შერჩეული. სხვა აპლიკაციები http://api-ს (სერვისის სახელს) მიმართავენ და არასოდეს ფიქრობენ იმაზე, რომელი pod ან რომელი ნოუდი პასუხობს. Service მოთხოვნებს იმ pod-ებზე ანაწილებს, რომლებიც ამჟამად ჯანმრთელია.

Service ლეიბლით ირჩევს pod-ებს და დატვირთვას ჯანმრთელებზე ანაწილებს — pod-ები შეიძლება შეიცვალოს ისე, რომ გამომძახებლებმა ვერც შენიშნონ.

Service YAML-ში

apiVersion: v1 kind: Service metadata: name: api spec: selector: app: api # ემთხვევა Deployment-ის pod-ებს ports: - port: 80 # სერვისის პორტი targetPort: 8080 # კონტეინერის პორტი

იგივე app: api ლეიბლი, რაც Deployment-ს აქვს — სხვა კავშირი საჭირო არ არის.

Service-ის სამი ტიპი — სადამდე აღწევს ტრაფიკი

ClusterIP

მხოლოდ შიგნით

ნაგულისხმევი. ვირტუალური IP, რომელიც მხოლოდ კლასტერის შიგნით არის ხელმისაწვდომი. იდეალურია, როცა ერთი აპლიკაცია მეორეს იძახებს (frontend → api → db).

NodePort

პორტი ყველა ნოუდზე

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

LoadBalancer

ნამდვილი გარე IP

თქვენს ღრუბელს სთხოვს გარე დატვირთვის ბალანსერს საჯარო IP-ით. ეს ჩვეულებრივი გზაა, ერთი TCP სერვისი ინტერნეტში გამოაჩინოთ.

Ingress — HTTP/HTTPS როუტერი, რომელიც გარე ტრაფიკს ჰოსტისა და გზის მიხედვით სწორ Service-ს გადასცემს. თითო აპლიკაციაზე თითო ღრუბლოვანი ბალანსერის ნაცვლად უშვებთ ერთ ingress-კონტროლერს და წერთ წესებს: shop.acme.com → web, shop.acme.com/api → api. ის ასევე ერთ ადგილას ამთავრებს TLS-ს (HTTPS).

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

Service და Ingress — როდის რომელი

  • Service კლასტერის შიდა სამშენებლო ბლოკია: სტაბილური მისამართი + დატვირთვის ბალანსირება pod-ებისთვის. ის ყველა აპლიკაციას სჭირდება.
  • Ingress წინ დგას HTTP(S)-ისთვის — ჰოსტისა და გზის მიხედვით მარშრუტიზაცია და TLS ბევრი აპლიკაციისთვის ერთი მისამართის უკან.
  • მარტივი წესი: Service აპლიკაციიდან აპლიკაციამდე, Ingress ბრაუზერიდან კლასტერამდე. არა-HTTP ტრაფიკი (მაგალითად, სუფთა TCP-ზე მომუშავე ბაზა) სამაგიეროდ LoadBalancer ტიპის Service-ს იყენებს.
04 · კონფიგი და საცავი 5 წთ

კონფიგი და მონაცემები იმიჯის გარეთ დატოვეთ.

კონტეინერის იმიჯი ყველა გარემოში ერთი და იგივე უნდა იყოს — მხოლოდ მისი პარამეტრები იცვლება. Kubernetes ამას გამოყოფს: ConfigMap-ები და Secret-ები ინახავს პარამეტრებს; Volume-ები და PVC-ები კი იმ მონაცემებს, რომლებმაც ცალკეულ pod-ზე დიდხანს უნდა იცოცხლოს.

ConfigMap

არასაიდუმლო პარამეტრები

გასაღები/მნიშვნელობის კონფიგი — ლოგირების დონე, ფუნქციონალის ფლაგები, სერვისის URL — pod-ში შედის როგორც გარემოს ცვლადები ან მიმაგრდება როგორც ფაილები. კონფიგს ცვლით იმიჯის ხელახლა აგების გარეშე.

Secret

საიდუმლო მონაცემები

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

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

როგორ მიმართავთ მათ pod-ში

containers: - name: api image: acme/api:v2 envFrom: - configMapRef: { name: api-config } env: - name: DB_PASS valueFrom: secretKeyRef: name: api-secrets key: db-password

კონფიგი მითითებით შემოდის — არასოდეს იწვება იმიჯში და არასოდეს კომიტდება ღია ტექსტად.

Volume — pod-ზე მიმაგრებული საცავი. pod-ის საკუთარი ფაილური სისტემა გადატვირთვისას იშლება, ამიტომ ყველაფერი, რამაც უნდა გადარჩეს, ვოლუმზე ხვდება. მდგრადი საცავისთვის ორ დაწყვილებულ ობიექტს იყენებთ: PersistentVolume (PV) — კლასტერში არსებული ნამდვილი საცავი — და PersistentVolumeClaim (PVC) — pod-ის მოთხოვნა გარკვეული ზომისა და ტიპის საცავზე. pod ითხოვს PVC-ით; კლასტერი კი მას PV-ს აბამს.

pod ითხოვს საცავს ზომისა და ტიპის მიხედვით; კლასტერი ამ მოთხოვნას რეალურ დისკს აბამს და pod-ის გადაადგილებისას ხელახლა მიამაგრებს.

Stateless თუ stateful

  • ვებაპლიკაციების უმეტესობა stateless-ია — მონაცემები ბაზაში ინახება და ნებისმიერ მოთხოვნას ნებისმიერი pod პასუხობს. ეს მარტივი შემთხვევაა.
  • ის, რაც მონაცემებს ლოკალურად ინახავს (ბაზები, რიგები), stateful-ია — მას სტაბილური საცავი და იდენტობა სჭირდება, რასაც StatefulSet + PVC-ები უზრუნველყოფს.
  • დამწყების წესი: მდგომარეობა მართულ მონაცემთა ბაზებში გაიტანეთ, სადაც შეგიძლიათ, და თქვენი pod-ები stateless დატოვეთ.
05 · მასშტაბირება და განკურნება 6 წთ

იყავით ხელმისაწვდომი, იყავით სწრაფი
და განაახლეთ მოცდენის გარეშე.

სწორედ აქ ამართლებს კონტროლის ციკლი თავის თავს. პრობები ეუბნება Kubernetes-ს, ჯანმრთელია თუ არა pod, ავტოსკეილერი რეპლიკების რაოდენობას დატვირთვას უსადაგებს, rolling განახლებები კი ვერსიებს რამდენიმე pod-ის ბიჯით ცვლის.

livenessProbe

ცოცხალია?

პერიოდული შემოწმება (HTTP, TCP ან ბრძანება). თუ ის რამდენჯერმე ჩავარდება, Kubernetes კონტეინერს გადატვირთავს — ეს არის წამალი ჩამოკიდებული ან ჩაკეტილი პროცესისთვის.

readinessProbe

მზადაა ტრაფიკისთვის?

ამოწმებს, შეუძლია თუ არა pod-ს ახლავე მომსახურება. სანამ ის ჩავარდნილია, pod Service-იდან ამოდის — მოთხოვნები აღარ ეგზავნება — მაგრამ არ გადაიტვირთება. შესანიშნავია გახურებისა და დროებითი გადატვირთვისთვის.

startupProbe

ჩაიტვირთა?

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

პრობები & რესურსები YAML-ში

readinessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 5 livenessProbe: httpGet: { path: /healthz, port: 8080 } periodSeconds: 10 resources: requests: { cpu: "100m", memory: "128Mi" } limits: { cpu: "500m", memory: "256Mi" }

requests ეუბნება scheduler-ს, რამდენი ადგილი დაჯავშნოს; limits კი ზღუდავს, რამდენის გამოყენება შეუძლია pod-ს. ავტოსკეილერიც სწორედ ამათ მიმართ ზომავს დატვირთვას.

ავტომასშტაბირება — HPA

Horizontal Pod Autoscaler (HPA) — ამატებს ან აკლებს pod-ების რეპლიკებს, რომ მეტრიკა სამიზნესთან ახლოს დარჩეს (მაგალითად, საშუალო CPU 60%-ზე). ტრაფიკის ნახტომი → მეტი pod; მშვიდი ღამე → ნაკლები. ის ცვლის იმას, რამდენი pod მუშაობს და არა თითოეულის ზომას.
kind: HorizontalPodAutoscaler spec: scaleTargetRef: { kind: Deployment, name: api } minReplicas: 3 maxReplicas: 20 metrics: [{ type: Resource, resource: { name: cpu, target: { averageUtilization: 60 } } }]

ახალი pod-ები ჯერ ეშვება და მზადყოფნის შემოწმებას გადის, მხოლოდ ამის შემდეგ ითიშება ძველები — ასე სიმძლავრე არასოდეს ეცემა და ცუდი ვერსია უკან დაბრუნებადია.

Rolling განახლებები & თვითგანკურნება

  • შეცვალეთ იმიჯი Deployment-ში და Kubernetes ახალ pod-ებს თანდათან უშვებს: ყოველ ჯერზე ელოდება მზადყოფნის შემოწმებას და მხოლოდ შემდეგ შლის ძველს.
  • kubectl rollout undo წინა ReplicaSet-ზე გაბრუნებთ, თუ ახალი ვერსია ცუდად იქცევა.
  • თვითგანკურნება ყველგან ერთი და იგივე ციკლია: ჩავარდნილი pod გადაიტვირთება, მკვდარი ნოუდის pod-ები სხვაგან გადანაწილდება, რაოდენობა კი ყოველთვის სასურველს უბრუნდება.
06 · ინსტრუმენტების ლანდშაფტი 6 წთ

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

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

მანიფესტების გაშვება და შაბლონიზაცია

kubectl

კლასტერის CLI

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

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

პაკეტების მენეჯერი

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

  • დადებითი: მზა ჩარტების უზარმაზარი ეკოსისტემა; მარტივია გარემოს მიხედვით მნიშვნელობების მიცემა.
  • უარყოფითი: YAML-ში ჩაწერილი Go-შაბლონების ლოგიკა ძნელი წასაკითხი და გასამართია.
Kustomize

უშაბლონო ოვერლეები

ჩაშენებულია kubectl-ში. ინახავთ მარტივ ბაზას და შემდეგ თითოეული გარემოსთვის ოვერლეებით აპაჩავთ — შაბლონების ენის გარეშე.

  • დადებითი: სუფთა YAML, ახალი სინტაქსის გარეშე; სუფთა diff-ები dev/stage/prod-ს შორის.
  • უარყოფითი: არ აქვს შეფუთვისა და გაზიარების ისეთი მოდელი, როგორიც Helm-ის ჩარტებს.
# გაშვება / დათვალიერება / გამართვა kubectl apply -f deploy.yaml kubectl get pods -w kubectl describe pod api-7c9 kubectl logs -f api-7c9 kubectl rollout undo deploy/api

როგორ აირჩიოთ: დაიწყეთ kubectl + Kustomize-ით — ახალი ენები საერთოდ არ გჭირდებათ და გუნდების უმეტესობას ეს სრულად ჰყოფნის. Helm-ს მაშინ მიმართეთ, როცა აპლიკაციის შეფუთვა და გაზიარება გჭირდებათ ან მესამე მხარის პროგრამის დაყენება. ბევრი გუნდი ორივეს იყენებს: Helm-ს გარე დამოკიდებულებებისთვის, Kustomize-ს კი საკუთარი აპლიკაციებისთვის.

საიდან მოდის თავად კლასტერი

control plane-ის (ტვინის) თავად მართვა რთულია და იშვიათად ღირს. მართული სერვისები მას თქვენ მაგივრად უშვებენ; თქვენ მხოლოდ თქვენს დატვირთვებს მოიტანთ.

EKS · AWS

Amazon

  • დადებითი: ყველაზე ღრმა ინტეგრაცია AWS-თან და ყველაზე დიდი მოცვა.
  • უარყოფითი: ყველაზე მეტი ხელით აწყობა სჭირდება.
GKE · GCP

Google

  • დადებითი: ფართოდ ითვლება ყველაზე გამართულად; ძლიერი autopilot რეჟიმი.
  • უარყოფითი: Google Cloud-ზე გაბამთ.
AKS · Azure

Microsoft

  • დადებითი: ბუნებრივი არჩევანი Azure-ისა და კორპორაციული გუნდებისთვის.
  • უარყოფითი: ყველაზე მჭიდროდაა Azure-ის ეკოსისტემაზე მიბმული.
თვითმართული

თქვენ უშვებთ

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

როგორ აირჩიოთ: გამოიყენეთ იმ ღრუბლის მართული სერვისი, სადაც უკვე ხართ — უმეტესობისთვის სწორედ ეს არის სწორი პასუხი. თავად მართეთ მხოლოდ მაშინ, თუ on-prem გჭირდებათ, მკაცრი რეგულაციები გაქვთ ან სპეციალური აპარატურა. სასწავლად ლოკალური კლასტერი (kind, k3d ან minikube) უფასო და მყისიერია.

Git როგორც ჭეშმარიტების წყარო

GitOps — Git-რეპოზიტორია ინახავს სასურველ მდგომარეობას, კლასტერში მჯდომი აგენტი კი განუწყვეტლივ ათანხმებს მასთან კლასტერს. kubectl apply-ს ხელით აღარ უშვებთ; სამაგიეროდ, pull request-ს მერჯავთ და აგენტი მას სინქრონიზაციაში მოიყვანს.
Argo CD

GitOps ინტერფეისით

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

  • დადებითი: შესანიშნავი ხილვადობა; ადვილად ასათვისებელი.
  • უარყოფითი: კიდევ ერთი დიდი სისტემა, რომელიც უნდა უშვათ და დაიცვათ.
Flux

მსუბუქი GitOps

მცირე კონტროლერების ნაკრები, Git-ზე და CLI-ზე აგებული, რომელიც კარგად ეწყობა Helm-სა და Kustomize-თან.

  • დადებითი: მინიმალური, მოდულური, სუფთად ინტეგრირდება.
  • უარყოფითი: Argo CD-ზე ნაკლები ჩაშენებული ინტერფეისი აქვს.

როგორ აირჩიოთ: გინდათ დაშბორდი და რბილი შესვლა? Argo CD. გინდათ მინიმალური, აწყობადი, CLI-ზე ორიენტირებული სისტემა? Flux. ორივე შემთხვევაში მოგება ერთია: Git ხდება თქვენი აუდიტის ლოგიც და როლბექის ღილაკიც.

07 · სამუშაო დეპლოი და შეჯამება 4 წთ

apply-დან ცოცხალ გაშვებამდე, ხუთი ბრძანებით.

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

# 1 · აღწერეთ სასურველი მდგომარეობა (Deployment + Service) kubectl apply -f k8s/ # 2 · უყურეთ, როგორ იწყება pod-ები და გადის მზადყოფნას kubectl get pods -w # 3 · გამოიტანეთ გარეთ Ingress-ით (უკვე k8s/-შია) kubectl get ingress # 4 · გაუმკლავდით ტრაფიკის ნახტომს kubectl scale deploy/api --replicas=10 # 5 · გაუშვით ახალი ვერსია — rolling განახლება, ნულოვანი მოცდენა kubectl set image deploy/api api=acme/api:v3

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

ხუთი წესი, რომელიც თან უნდა წაიღოთ

1აღწერეთ და ნუ ბრძანებთ. თქვით, სად გინდათ მისვლა; შეთანხმების ციკლი სხვაობას სამუდამოდ ხურავს.
2Deployment → ReplicaSet → Pod-ები. თქვენ წერთ Deployment-ს; ის თქვენ მაგივრად უვლის რაოდენობასა და rollout-ებს.
3დააკავშირეთ ლეიბლით, მიწვდით Service-ით. pod-ები ერთჯერადია; Service სტაბილური შესასვლელია, Ingress კი — HTTP-როუტერი.
4კონფიგი და მონაცემები გარეთ ცხოვრობს. ConfigMap-ები და Secret-ები პარამეტრებისთვის; PVC-ები ყველაფრისთვის, რამაც pod-ს უნდა გადაურჩეს.
5პრობები + ავტოსკეილერი = ხელმისაწვდომობა. ჯანმრთელობის შემოწმებები კურნავს, HPA მასშტაბირებს, rolling განახლებები კი მოცდენის გარეშე უშვებს ახალ ვერსიას.
ცოდნის შემოწმება

დაგამახსოვრდათ?

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

შეაფასეთ ეს დასტა
იყავით პირველი

ნავიგაცია ← → ღილაკებით ან სქროლით · ნაწილი 2: გაღრმავებული Kubernetes → · უკან ბიბლიოთეკაში