CKAD_Prep

Commands cheatsheet for CKAD(Certified Kubernetes Application Developer) Exam - Georgian Language

CKAD Exam Preparation - Do or Die

👋 The Main Commands Usage From the Topic With Explanation(In georgian)

First Chapter First Lab - PODS

k = Kubectl

1. k get pods - პოდების დალისტვა დეფოლთ ნეიმსფეისში
2. k get pods -a - ყველა პოდის დალისტვა რაც სისტემაშია
3. k get pods -a —namespace dbs-back-test - ყველა პოდის დალისტვა დბს-ნეიმსფეისში
4. k run nginx - პოდის დასტარტვა რომლის სახელიც იქნება nginx
5. k run nginx —image=nginx - პოდის დასტარტვა რომელის სახელი და იმიჯი იქნება nginx
6. k describe pod nginx - ეს ბრძანება მიაჯდება nginx პოდს და აღწერს მის მდგომარეობას უფრო სიღრმისეულად
7. k get pods -o wide - ეს ბრძანება დალისტავს პოდებს ოღონდ უფრო მეტი მონაცემით, ნოუდებით, აიპებით და ა.შ
8. k delete pod nginx - ეს ბრძანება წაშლის უკვე არსებულ პოდს.
9. k run nginx —image=nginx —dry-run=client -o yaml > nginx.yaml - იმ შემთხვევაში თუ ჩვენ გვსურს, შევქმნათ პოდის იამლ ვერსია მისი პირდაპირი გაშვების გარეშე, ვუშვებთ —dry-run=client კლიენტს, მშრალ გაშვებას და წარმოვადგენთ მას ჩვენთვის -o yaml -ანუ იამლის ფორმატში. უშალოდ > ბრძანება ნიშნავს, რომ მიღებული yaml ფაილი ჩაიწეროს კონკრეტულ ფაილში, რომელიც ბრძანებასთან ერთად შეიქმნება.
10. k create -f nginx.yaml - ამ ბრძანებით იქმნება ლოკალზე არსებული იამლი პოდად.
11. k apply -f redis.yaml - უკვე არსებულ პოდში, თუ ლოკალიდან შევიტანთ იამლში ცვლილებას, უნდა გამოვიყენოთ apply.
12. k top node or k top pod - დაგვილისტავს რესურსებს ყველზე მეტს რომელიც იყენებს იმას
13. k run nginx —image=nginx —rm -it — bin/sh - ეს გააჩენს დროებით პოდს, რომელსაც მივაჯდებით და ინტერაქტიულად ბაშში და გავუშვებთ რამე ქომანდს

First Chapter Second Lab - ReplicaSets

1. k get replicasets or rs - ლისტავს რეპლიკასეტების რაოდენობას.

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

2. kind = ReplicaSet | apiVersion = app/v1 - სხვა შემთხვევაში, რეპლიკასეტი არ ამოიწევა. ასევე თუ არ გვახსოვს ზეპირად, უნდა გავუშვათ k explain replicaset, სადაც პირველივე იქნება kind და apiversion რა არის ამ ინსტანსისთვის

3. k edit rs replicaset-name - ედიტ კომანდიდ შეგვიძლია შევცვალოთ რაღაც მნიშვნელობა უშუალოდ პოდში ან რეპლიკასეტში.

4. k scale rs replicaset-name —replicas=5 - ეს ქომანდი დაასქეილებს რეპლიკასეტს 5 პოდამდე, შეგვიძლია დავაედიტოთ და მივაჯდეთ პირდაპირ, ან შეგვიძლია ამ ქომანდით პირდაპირ გავზარდოთ პოდების რაოდენობა ან შევამციროთ

First Chapter Third Lab - Deployments

1. k create deployment deployment-name —image=httpd:2.4-apine —replicas=3 - ეს ქომანდი შექმნის დიფლოიმენთს, რომლის სახელი იქნება deployment-name , მისი იმიჯი იქნება httpd:2.4-alpine ხოლო რეპლიკების(პოდების რაოდენობა) იქნება 3

First Chapter Forth Lab - Namespaces

1. k get namespaces or ns - ლისტავს ნეიმსფეისების რაოდენობას
2. k get pods —namespace=research - დალისტავს ყველა პოდს რისერჩ ნეიმსფეისში
3. k get pods —all-namespaces - ეს დალისტავს ყველა პოდს ყველა ნეიმსფეიში და გავიგებთ რომელი პოდი რომელ ნეიმსფეისს ეკუთვნის. - k get pods -A იგივეა
4. k get svc or services - ეს დაგვილისტავს სერვისებს ნეიმსფეისში, შეიძლება გვქონდეს db-service სერვისი, და გვჭირდებოდეს გავიგოთ როგორ ეკომუნიცირება ჩვენი პოდი მას. თუ პოდი და სერვისი ერთ ნეიმსფეისის ქვეშ არის, პოდს მხოლოდ სერვისის სახელი სჭირდება, თუ არა და სხვა ნეიმსფეისშია მაშინ სერვისის სრული მისამართი ჭირდება + db-service.dev.svc.cluster.local
5. k config set-context —current —namespace=ckad - ეს შეცვლის ნეიმსფეისს, ამ ნეიმსფეისს მიაჯდება.

First Chapter Fifth Lab - Imperative Commands

1. kubectl run nginx-pod —image=nxing:alpine - ქმნი პოდს nginx-pod რომლის იმიჯია nginx:alpine
2. k run redis —image=redis:alpine —labels=”tier=db” - ქმნი პოდს რედის, რომლის იმიჯია რედის ალფაინი და აქვს ლეიბლი tier=db შეგვიძლია მამენტ ფრჩხილიც მოვაშოროთ
3. k expose pod redis —port=6379 —name=redis-service - ამ ქომანდით, ვაექსფოუსებთ სერვისს რომელსაც ქვია რედის-სერვისი პორტზე 6379 პოდი რედისისთვის.
4. k create deployment webapp —image=tbcbank/webapp-color —replicas=3 - ეს იპერატიული ბრძანება შექმნის დიფლოიმენთს ვებაპს, რომლის იმიჯი იქნება თბსბანკივებაპი და რეპლიკებს გამოუშვებს 3 ზე.
5. k run custom-nginx —image=nginx —port=8080 - ასეთ შემთხვევაში იქმენბა პოდი custom-nginx იმიჯით nginx და ეგრევე ექსფოუსდება პორტზე 8080.
6. k create deployment redis-deploy —image=redis —replicas=2 —namespace=dev-ns - ეს ქომანდი შექმის დიფლოიმენთს redis-deploy - ს რომლის იმიჯი იქნება რედისი, იქნება 2 რეპლიკაზე და გაკეთდება ნეიმსფეისში dev-ns
7. k run httpd —image=httpd:alpine —port=80 —expose=true - ასეთ დროს, როცა ჩვენ გვჭირდება შევქმნათ პოდი რაღაც იმიჯით და შემდეგ ის დავაექსფოუსოდ კლასტერაიპით, ჩვენ უბრალოდ შეგვიძლია გამოვიყენოთ —expose=true და ასეთ დროს ის ავტომატურად კლასტერაიპით დაექსფოუსდება —პორტ80 რო ვუთითებთ პოდს, სერვისისვის ის ავტომატურად დესთინეიშენი იქნება.

Second Chapter First Lab - Commands & Args

1. command [ “sleep” , “5000” ] ან command [ “sleep 5000”] ან command [ “sleep”] argument [ “5000” ] - ნებისმიერი ამ კომანდ არგუმენტის თავსებადობიდან შეგვიძლია გამოვიყენოთ, რომ პოდს აგდავცეთ ბრძანება და არგუმენტი რასაც გაუშვებს პოდის დასტარტვისას
2. k replace —force -f /tmp/kubectl-edit-randomnumbers.yaml - ჩვენ როცა ვიყენებთ ქომანდს edit - ამ დროს პოდში ვაედიტებთ რაღაც ინფორმაციას და შემდეგ k replace - თი ვანახლებთ, თუმცა, როდესაც ცვლილება არის უმნიშვნელო, მაგალითად არგუმენტში შეგვაქვს რაიმე ცვლილება, ამ დროს გვჭირდება —force ქომანდის გამოყენება
3. k run webapp-green —image=randomimage — —color=green - მსგავსი ფორმატით გადავცემთ არგუმენტს რომ ფერი არის მწვანე

Second Chapter Second Lab - ConfigMaps

1. k get configmaps or cm - ეს დაგვილისტავს ყველა კონგიმაპს

2. k create configmap webapp-config-map —from-literal=app_color=darkblue - ეს ქომანდი შექმნის კონფიგმაპს, რასაც გადაცემს დეითას რომ აპპ-ქოლორ არის დარქბლუ

3. როდესაც ConfigMap - ს ვამატებთ, ეს გვჭირდება იმისთვის, რომ ის environmental variable - რაც გვაქვს, არ ვწეროთ ყოველ ჯერზე თავიდან პოდში, და გვქონდეს უკვე მზა რეფერენსი, რასაც გავუტარებთ თითოეულ პოდს. თუ აქამდე გვქონდა ასე პოდში.

   `containers:

   • env:
     • name: APP_COLOR value: green`

   სადაც გადავცემდით ცვლადს APP_COLOR და ვეუბნებოდით რომ მისი მნიშვნელობა უნდა ყოფილიყო green - ამის ნაცვლად კონფიგმაპს ავსახავთ შემდეგნაირად.

   `containers:

   • env:
     • name: APP_COLOR valueFrom: #ამით ვანიშნებთ, რომ აქედან მოგვაქვს ინფორმაცია configMapKeyRef: #ეს არის კონფიგმეპის რეფერენსი, გადავცემთ რომ ვიყენებთ cs name: webapp-config-map # ეს არის სახელი კონფიგმაპის key: APP_COLOR # ეს არის ის ქი რასაც გადავცემთ მაგალით appcolor=green`

   Second Chapter Third Lab - Secrets

   1. kubectl create secret generic db-secret --from-literal=DB_Host=sql01 --from-literal=DB_User=root --from-literal=DB_Password=password123 - ეს შექმნის სეკრეტს და ჩაწერს შესაბამის სამ მნიშვნელობას მასში
   2. აქ ვუთითებთ პოდში სექრეთრეფს, ანუ ვანიჭებთ რომ ეს სეკრეტი გამოიყენოს

   spec:
     containers:
     - image: kodekloud/simple-webapp-mysql
       imagePullPolicy: Always
       name: webapp
       envFrom:
       - secretRef:
           name: db-secret

   Second Chapter Fourth Lab - Security Context

   1. whoami - გაძლევს თუ რა კონკრეტული იუზერით იძახებ მაგ მომენტში ქომანდს.
   2. k exec ubuntu-sleeper — whoami - ეს ქომანდი მიაჯდება პოდს ubuntu-sleeper და ამის შემდეგ განახორციელებს ბრძანებას whoami
   3. პოდში ეს ცვლილება გვეტყვის, რომ ქომანდები დაისტარტოს პოდში 1010 იუზერით

   securityContext:
   	runAsUser: 1010

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

     securityContext:
       capabilities:
   			add: [ "SYS_TIME" , " NET_ADMIN" ]

   Second Chapter Fourth Lab - Service Accounts

   1. k create serviceaccount or sa dashboard-sa - შექმნის სერვის ექაუნთს სახელად dasbhoard-sa
   2. k create token dasbhboard-sa შექმნის ტოკენს სერვის ექაუნთისთვის
   3. იმისთვის, რომ სერვისექაუნთი დავამაუნთოთ დიფლოიმენთში, ამისთვის საჭიროა, spec - ის ქვეშ, იქ სადაც კონტეინერია, გავწეროთ ცვლადი serviceAccountName და გადავცეთ სერვისექაუნთის მნიშვნელობა

   Second Chapter Fifth Lab - Taints and Tolerations

   1. k describe node node1 - ამით ნოუდის სიღრმისეულ ინფორმაციას ვგებულობთ
   2. k taint node node1 spray=mortein:NoSchedule - ეს ნიშნავს, რომ ვადებთ თეინთს ჩვენს ნოუდს, აქედან ფორმულა არის ასეთი - Key=Value:Effect - როცა ეს თეინთი დაიდება, იმ შემთხვევაში, თუ spray იქნება mortein დიფლოიმენთის დროს, ეს დიფლოიმენთი ჩავარდება ამ ნოუდში, თუ თეინთი არ იყო ეს, ჩვენ მივიღებთ ეფექტს NoSchedule ანუ ეს ნოდი არ მიიღებს ამ დიფლოიმენთს
   3. k get pods —watch - ამით ჩვენ შეგვიძლია პოდის ამოწევის პროცესს ვუყუროთ
   4. k taint node node1 mortein- ამ შემთხვევაში, იგივე ქომანდი ოღონდ თეინთს ბოლოში მინუსი ნიშნავს, რომ ჩვენ ვშლით კონკრეტული ნოუდიდან კონკრეტულ ტეინტს.
   5. Taint - არის ყოველთვის ნოუდი - Tolerations - ყოველთვის პოდი
   • NoSchedule - თუ თოლერეიშენი არ აკმაყოფილებს თეინთს, მაშინ პოდი არ მოხვდება კონკრეტულ ნოუდზე
   • PreferNoSchedule - თუ პოდი არ აკმაყოფილებს თეინთს, მაშინ სისტემა მაქსიმალურად ეცდება რომ არ მოხვდეს ამ ნოუდზე, მაგრამ ნონ გარანტ
   • NoExecute - ამ შემთხვევაში, პოდი თუ არ აკმაყოფილებს ნოუდის თეინთს, ის არ მოხვდება ამ ნოუდზე, და თუ თეინთის დადებამდე ნოუდზე ამ პოდის წინა ვერსიები იყო, ისინიც წაიშლება.
   1. k describe node node1 | grep Taint - ასე შეგვიძლია ნოუდში შევიხედოთ, და ძებნა რომ არ დავიწყოთ, პირდაპირ მოვგრეფოთ თეინთი

   Second Chapter Sixth Lab - Node Affinity

   1. k label node node1 color=blue - ეს ქომანდი დაადებს ლეიბლს ნოუდ1-ს
   2. მაგალითი, როგორ ვამატებთ node affinity - ს დიფლოიმენთში, ეს ხდება კონტეინერის Spec - ის ქვეშ.

   affinity:
     nodeAffinity:
   		requiredDuringSchedulingIgnoreDuringExecution:
   			nodeSelectorTerms:
   			- matchExpressions:
   			  - key: color 
   					operator: In
   					values:
   					- blue

   Third Chapter First Lab - Multi Container Pods

   1. k -n elastick-stack exec -it app — cat /log/app.log - აქ მივაჯდებით პოდს და შიგნით პოდში გავუშვებთ ბრძანებას რომ დაგვილისტოს აპპ.ლოგ ფაილი
   2. k logs app -n elastick-stack - ეს არის პირველის მსგავსი, ოღონდ ნაკლები წვალებით
   3. საიდ ქარის დამაუნთების მაგალითი.

   containers:
   - image: busybox
   	name: sidecar
   	volumeMounts:
   	- mountPath: /var/log/event/
   		name: log-volume

   Third Chapter Second Lab - Liveness&Readiness

   1. Readiness probe ინიციალირდება spec სექციაში, კონტეინერის ქვეშ

   readinessProbe:
   	httpGet:
   		path: /ready
   		port: 8080

   💡 რედინეს პრობები გვჭირდება მაშინ, როცა გვაქვს შემდეგი სიტუაცია, თუ გვაქვს ორ პოდზე დასქეილებული დიფლოიმენთი, ხოლო ბალანსერი ამ ორ პოდზე ანაწილებს ტრაფიკს, ბალანსერმა უნდა იცოდეს, თუ როდის არის ეს პოდი ტრაფიკის მისაღებად მზად, თუ მან ეს არ იცის, როგორც კი კონტეინერი დადგება მაშინვე დაიწყებს რექვესთების გაგზავნას, რამაც შეიძლება მომხმარებლების გარკვეული ნაწილი 500 - ზე გაიყვანოს. ამისთვის საჭიროა დავამატოთ რედინეს პრობი, ბალანსერი პერიოდულად ამოწმებს პოდის სიცოცხლისუნარიანობას /ready - ზე, იმ შემთხვევაში თუ უბრუნდება დადებითი პასუხი, იწყებს ბალანსერი ამ პოდის გამოყენებასაც, თუ ეს პოდი დაეცა, ბალანსერი ამას ხედავს და მთლიან ტრაფიკს ამისამართებს პირველ პოდში. ზოგადად რედინეს პრობის მუშაობის ლოგიკა არის ესეთი, პოდის დადგომის შემდეგ აქტიურდება initialDelaySeconds ამდენი წამის განმავლობაში ის ელოდება პოდს დადგომიდან, რათა პოდში ყველა საჭირო შიდა ამბები დასრულდეს, შემდეგ ანხორციელებს რედის ჩეკს.
   1. Liveness Probe ასევე ინიციალდება სპეცში, კონტეინერის ქვეშ

   livenessProbe:
     httpGet:
       path: /live
       port: 8080
   	periodSeconds: 1
   	initialDelaySeconds: 80

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

   Fourth Chapter First Lab - Labels&Selectors

   1. k get pods —selector env=dev ეს დალისტავს ყველა პოდს, რომლის ენვაირონმენთი არის დევ.
   2. k get pods —selector bu=finance —no-headers | wc -l - ეს დალისტავს ყველა პოდს, რომელიც გაფილტრულია სელექტორით, ოღონდ ამ დალისტულს მოაშორებს ჰედერებს, და შემდეგ wc-1 ის ქომანდით, პირდაპირ მოგვცემს ქაუნთს.
   3. k get all —selector env=prod —no-headers | wc -l - ესეც ანალოგიურია, ოღონდ ეს დალისტავს პოდების მაგივრად ყველა რესურს რაც არის სისტემაში(მათ ჯამს)
   4. k get all —selector env=prod,bu=finance,tier=frontend - შესაბამისად ჩვენ სელექტორები, თუ რამდენიმე მათგანი გვჭირდება, შეგვიძლია მძიმეებით გამოვყოთ ერთმანეთისგან

   Fourth Chapter Second Lab - Rollbacks&rollupd

   1. kubectl rollout status deployment/nginx - როდესაც დიფლოიმენთი იწყებს ამოწევას, ამ ქომანდით შეგვიძლია გავიგოთ სტატუსი.
   2. kubectl rollout history deployment/nginx - ამით შეგვიძლია გავიგოთ დიფლოიმენთების ისტორია რევიზიების მიხედვით
   3. kubectl rollout history deployment nginx --revision=1 - შეგვიძლია მივუთითოთ კონკრეტული რევიზია, და ამ რევიზიაზე მივიღოთ დამატებითი ინფორმაცია
   4. kubectl set image deployment nginx nginx=nginx:1.17 --record - თუ რექორდს გაავყოლებთ, რევიზიის ისტორიის სათაურში წაიღებს ამ ამბავს და გვეცოდინება თუ რა იყო ცვლილება
   5. kubectl rollout undo deployment nginx --to-revision=1 - ამ ქომანდით კი დიფლოიმენთს პირველ რევიზიამდე ვაროლბექებთ.
   💡 არსებობს სულ სამი განსხვავებული **Deployment Strategy**

   Recreate - ყველა ვერსია ერთად კვდება და ყველა ახალი ვერსია ერტად იწყება ამოწევას - ამ დროს აპლიკაცია არის დაუნში

   rolling update - არის დიფოლთ სტრატეგია, ამ დროს თითო პოდი კვდება და თითო ახალი ამოდის, ამ დროს აპლიკაცია არ არის დაუნში

   Blue Green - ამ დროს ახალი ვერსია ამოდის ისე რომ ძველი ვერსიაც არ ვკდება, ტრაფიკი მიდის ისევ მთლიანად ძველი ვერსიისკენ და როცა მზად იქნება ახალი ვერსიები, მერე ერთდროულად ეგრევე გადადის ახალ ვერსიაზე ტრაფიკი, Blue არის ძველი Green არის ახალი დიფლოიმენთი Canary - ქენერი დეფლოიმენთის დროს, ასევე ამოგვაქვს ახალი ვერსია, თუმცა, ბლუ გრინის მსგავსად, ერთდროულად არ ვახდენთ მასზე გადართავს, ამის ნაცვლად, ტრაფიკის გარკვეულ პროცენტს ვრთავთ ბალანსერიდან ქანარის ახალ ვერსიებზე ,მაგალითად მხოლოდ 10% -ს თუ ყველაფერი კარგად იქნა, ნელ-ნელა ამას ვზრდით და საბოლოოდ მთლიანად გადავდივართ ახალზე

   Fourth Chapter Third Lab - Jobs And CronJobs

   CronJob - ის სინტაქსი გამოიყურება შემდეგნაირად

   

   backofflimit და completions: - ბექოფლიმიტი არის თუ რამდენი მცდელობა შეუძლია ჯობს განახორციელოს წარმატებულ მცდელობამდე, ხოლო ქომფლეიშენს არის ის წარმატებული მცდელობების რაოდენობა, რამდენიც გვჭირდება ჩვენ ჯამში.

   parallelism - ეს ქომანდი იწერება იამლში მაშინ, როცა ჩვენ რამდენიმე საქსესფულ ქეისი გვჭირდება, და შეგვიძლია ჯობები ერთმანეთის პარალელურად გავუშავთ, და უნდა მივუთითოთ პარალელურად არმდენ ჯობს ვუშვებთ.

   Fifth Chapter First Lab - Services & Ingress

   1. ClusterIP - მაშინ გვჭირდება, თუ გვჭირდება რომ სერვისებმა კლასტერს შიგნით იკომუნიცირონ ერთმანეთთან
   2. NodePort - გვჭირდება მაშინ, როცა გვჭირდება გარეთ საკომუნიკაციო პორტი, თუ ჩვენ ვიყენებთ, apps.oshdgt.hq.tbc:9000/accountstbc/ - ეს :9000 - არის NodePort რითიც კლასტერს გარედან ვწვდებით თუნდაც სვაგერს
   3. თუმცა რადგან NodePort არის ძალიან დიდი, აქ ჩვენ ვიყენებთ proxy-server - ს რომლის პორტიც არის 80, ეს პროქსი სერვერი მიმართავს უკვე ჩვენს nodeport -ს. პროქსი სერვერზე მომართვისთვის კი საიტზე პორტის მიწერა აღარ არის საჭირო.
   4. თუ ინგრესს მივაჯდებით დისქრაიბით და შევცვლით /path - ს კონკრეტული ფეიჯი ახალი ფესის ქვეშ დარეზოლვდება
   5. k create ingress ingress-pay -n critical-space —rule=”/pay=pay-service:8282” - ეს შექმნის ინგრესის ახალ სერვისს, რომელსაც ინგრეს-ფეი ქვია, და მისი რული იქნება, რომ ყველა ტრაფიკი რაც შევა /pay - ზე გადანაწილდეს pay-service - ზე რომელიც დგას 8282 პორტზე.
   6. annotations: nginx.ingress.kubernetes.io/rewrite-target: / - ასეთ დროს, ამასაც რო გავუწერთ ინგრესში, მივიღებთ, რომ ყველა ვინც /pay - პასს მოადგება, ინგრესი დაარედაირექთებს ჰოსტზე.

   Sixth Chapter First Lab - Persistent Volume

   1. თუ გვინდა რომ პოდის ლოგები, კონკრეტულ ადგილას შევინახოთ, ამისთვის საჭიროა, რომ პირველ რიგში დავაედიტოთ პოდი. k edit pod podname, უნდა ვიპოვოთ volumes: და დავამატოთ ახალი ვოლიუმი.

   volumes:
   - name: log-volume
   	hostPath: 
   		 path: /var/log/webapp

   რის შემდეგაც შეიქმნება აღნიშნული ვოლიუმი მაგ სახელით და ჩაეწერება ეგ პასი, იმისთვის რომ კონტეინერი დავლინქოთ ამ ახალ ველიუმთან, საჭიროა, რომ კონტეინერის სპეცში volumeMounts: - ის ქვეშ ჩავწეროთ შემდეგნაირად

   volumeMounts: 
   - mountPath: /log
   	name: log-volume

   ამის შემდეგ, კონტეინერი მოძებნის log-volume - სახელის მქონე ვოლიუმს, და ის რაც კონტეინერში /log - ის ქვეშ იწერება, ჩაიწერება უკვე /var/log/webapp - ის ქვეშ.

   1. Persistent Volume და Persistent Volume Claims - პირველი არის ზოგადი ვოლიუმის შექმნისთვის, რო შექმნა სთორიჯი, სადაც ჩაიწერება შენთვის სასურველი ლოგები ან ნებიმისერი პოდის დეითა, ხოლო ქლეიმები არის იუზერის მხრიდან შესაქმნელი, ეს ქლეიმები ბაინდინგს უკეთებს ვოლიუმებს და თამაშობს გადამტანს იდეაში დეითასი პერსისტენტ ვოლიუმში.

Seventh Chapter First Lab - KubeConfig

1. kubectl config use-context research —kubeconfig /root/my-kube-config - აქ ვეუბნებით, რომ მოცემულ კუბკონფიგში, მთავარ კონფიგად გამოიყენოს research - არსებულის ნაცვლად.

Seventh Chapter Second Lab - RBAC

1. RBAC - დროს ჩვენ ვქმნით კონკრეტულ ექსეს ჯგუფებს და მას ვანიჭებთ ჩვენთვის სასურველ იუზერებს. მაგალIთად ვქმნით როლს - ადმინისტრატორს, მას ვანიჭებთ უფლებას, რომ დალისტოს გააკეთოს, განაახლოს, წაშალოს ესა თუ ის რესურსი, და შემდეგ ვქმნით RoleBinding - ებს და ამ როლებს ვანიჭებთ კონკრეტულ იუზერებს.
2. K get roles - k get rolebindings
3. K auth can-i create deployments or K auth can-i delete nodes - ამ ქომანდებით შეგიძლია შეამოწმო შენს როლს რაც კუბკონფიგში გაქვს, შეუძლია თუ არა კონკრეტული ოპერაციების განხორციელება.
4. k auth can-i create pods —as dev-user - ესეც იგივეა, ოღონდ კონკრეტული იუზერისას ჩეკავ
5. k auth can-i create pods —as dev-user —namespace=test - იგივე, ოღონდ იგივე უფლებას ამოწმებ ტესტ ნეიმსფეისში
6. cat /etc/kubernetes/manifest/kube-apiserver.yaml - ბაი დეფოლთათ, ქუბ აპისერვერის სეთნგები არის ამ მისამართზე.
7. ეს მაშინ, როცა უშუალოდ კონკრეტულ იუზერს გვინდა კონკრეტული უფლება ჩავურთოთ კონკრეტულ რესურსზე.

- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - create

Seventh Chapter Third Lab - ClusterRole

1. როცა დისქრაიბს უკეთებ კლასტერროლს და ხედავ, რომ რესურსებში ჩაწერილი არის * . * - ეს სმაილი არ არის, ეს ყველა რესურსს ნიშნავს 😄
2. k create clusterrole michelle-role —verb=get,list,watch —resource=nodes - ეს შექმნის კლასტერროლს მიჩელისთვის, სადაც გეთი ლისტი და ვოჩის უფლება იქნება ნოუდებზე.
3. k create clusterrolebinding michelle-role-binding —clusterrole=michelle-role —user=michelle - ეს უკვე არის ბაინდინგი, სადაც მიშელს ვაბაინდებთ იმ კლასტერროლზე რაც მანამდე შევქმენით.
4. Kubectl api-resources - რომელიც დალისტავს ყველა აპირესურსის ქაინდს.

Seventh Chapter Fourth Lab - Adm. Controllers

1. ედმიშენ კონტროლერები მაშინ გვჭირდება, როცა RBAC - ჩვენთვის საკმარისი აღარ არის, და სექიურითის უფრო მაღალი დონე გვჭირდება. მაგალითად ასეთია AlwaysPullImages - როცა პოდი იქმნება, ყოველთვის ახალი იმიჯი იფულება - DefaultStorage Class - EventRateLimit - NamespaceExists და სხვები.
2. k run nginx —image=nginx —namespace=blue - თუ ბლუ ნეიმსფეისი არ გვაქვს, მაშინ დარეჯექთდება ავტომატურად ედმიშენ კონტროლერიც მიერ.
3. kubectl exec kube-apiserver-controlplane -n kube-system —kube-apiserver -h | grep enable-admission-plugins - ამით დალისტავთ თუ რა ედმიშენ კონტოლერები არის ბაი დეფოლთათ კლასტერში.
4. kube-apiserver - ის პოდში უნდა ჩაემატოს - —enable-admission-plugins= - აქ ყველა ახალი ედმიშენ კონტროლერები, ანუ ეს ნიშნავს, რომ თუ ბლუ ნეიმსფეისი არ არსებობს, და ჩვენ მაგ ადგილას ჩავსვავთ ასე - —enable-admission-plugins=NamespaceAutoProvision - სურათი გვექნება ასეთი, პოდი დასტარტვისას გაივლის აუთენთიფიკაციას, შემდეგ ავტორიზაციას და მერე როცა გადავა ედმიშენ კონტროლერის ნაწილზე, ნახავს, რომ ნეიმსფეისი არ არსებობს, ამ ფლაგინის დახმარებით შექმნის ნეიმსფეისს და ჩასვავს ახალ პოდს მასში.
5. ps -ef | grep kube-apiserver | grep admission-plugins - რადგან კუბ-აპისერვერი არის მიმდინარე პროცესი, ის ps -ef ქომანდით შეგვიძლი მოვძებნოთ