წიგნი "Kubernetes for DevOps"

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

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

ვისთვის არის წიგნი?

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

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

რა კითხვებზე პასუხობს წიგნი?

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

• „მაინტერესებს, რატომ უნდა დახარჯო დრო ამ ტექნოლოგიაზე. რა პრობლემების გადაჭრაში დამეხმარება მე და ჩემს გუნდს?”
• „კუბერნეტესი საინტერესო ჩანს, მაგრამ შესვლის საკმაოდ მაღალი ბარიერი აქვს. მარტივი მაგალითის მომზადება არ არის რთული, მაგრამ შემდგომი ადმინისტრირება და გამართვა რთულია. ჩვენ გვსურს მივიღოთ სანდო რჩევები იმის შესახებ, თუ როგორ მართავენ ადამიანები Kubernetes კლასტერებს რეალურ სამყაროში და რა პრობლემები შეგვხვდება.
• ”სუბიექტური რჩევა სასარგებლო იქნება. Kubernetes-ის ეკოსისტემა ახალ გუნდებს არჩევის ძალიან ბევრ ვარიანტს აძლევს. როდესაც ერთი და იგივე საქმის გაკეთების რამდენიმე გზა არსებობს, როგორ იცით რომელია საუკეთესო? როგორ გავაკეთოთ არჩევანი?

და ალბათ ყველაზე მნიშვნელოვანი ყველა კითხვაზე:

• "როგორ გამოვიყენო Kubernetes ჩემი კომპანიის შეფერხების გარეშე?"

ამონაწერი. კონფიგურაცია და საიდუმლო ობიექტები

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

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

Kubernetes გთავაზობთ რამდენიმე სხვადასხვა გზას კონფიგურაციის მართვისთვის. პირველ რიგში, შეგიძლიათ აპლიკაციას გადასცეთ მნიშვნელობები გარემოს ცვლადების მეშვეობით, რომლებიც მითითებულია pod wrapper-ის სპეციფიკაციაში (იხ. „Environment Variables“ 192 გვერდზე). მეორეც, კონფიგურაციის მონაცემების შენახვა შესაძლებელია პირდაპირ Kubernetes-ში ConfigMap-ისა და Secret ობიექტების გამოყენებით.

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

მიმდინარეობს pod shells-ის განახლება, როდესაც კონფიგურაცია იცვლება

წარმოიდგინეთ, რომ გაქვთ განლაგება თქვენს კლასტერში და გსურთ შეცვალოთ რამდენიმე მნიშვნელობა მის ConfigMap-ში. თუ იყენებთ Helm დიაგრამას (იხ. „Helm: Package Manager for Kubernetes“ გვერდზე 102), შეგიძლიათ ავტომატურად აღმოაჩინოთ კონფიგურაციის ცვლილება და გადატვირთოთ თქვენი pod ჭურვები ერთი სუფთა ხრიკით. დაამატეთ შემდეგი ანოტაცია თქვენი განლაგების სპეციფიკაციაში:

checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
       | sha256sum }}

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

სენსიტიური მონაცემები Kubernetes-ში

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

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

დასაწყებად, გადახედეთ კუბერნეტის მანიფესტს საიდუმლო ობიექტისთვის (იხ. hello-secret-env/k8s/secret.yaml):

apiVersion: v1
kind: Secret
metadata:
    name: demo-secret
stringData:
    magicWord: xyzzy

ამ მაგალითში, magicWord-ის პირადი გასაღები არის xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing)). სიტყვა xyzzy ზოგადად ძალიან სასარგებლოა კომპიუტერების სამყაროში. ConfigMap-ის მსგავსად, თქვენ შეგიძლიათ შეინახოთ მრავალი გასაღები და მნიშვნელობა საიდუმლო ობიექტში. აქ, სიმარტივისთვის, ჩვენ ვიყენებთ მხოლოდ ერთ გასაღები-მნიშვნელობის წყვილს.

საიდუმლო ობიექტების გამოყენება გარემოს ცვლადებად

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

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-env
          ports:
             - containerPort: 8888
          env:
             - name: GREETING
               valueFrom:
               secretKeyRef:
                  name: demo-secret
                  key: magicWord

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

kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created

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

kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888

მისამართის გახსნისას localhost:9999/ თქვენ უნდა ნახოთ შემდეგი:

The magic word is "xyzzy"

საიდუმლო ობიექტების ჩაწერა ფაილებში

ამ მაგალითში ჩვენ დავამაგრებთ საიდუმლო ობიექტს კონტეინერს ფაილის სახით. კოდი მდებარეობს დემო საცავში hello-secret-file საქაღალდეში.

საიდუმლო ფაილად დასაკავშირებლად, ჩვენ გამოვიყენებთ შემდეგ განლაგებას:

spec:
   containers:
       - name: demo
          image: cloudnatived/demo:hello-secret-file
          ports:
              - containerPort: 8888
          volumeMounts:
              - name: demo-secret-volume
                mountPath: "/secrets/"
                readOnly: true
   volumes:
      - name: demo-secret-volume
        secret:
           secretName: demo-secret

როგორც ქვეგანყოფილებაში „კონფიგურაციის ფაილების შექმნა ConfigMap ობიექტებიდან“ გვ. 240, ჩვენ ვქმნით მოცულობას (ამ შემთხვევაში დემო-საიდუმლო მოცულობა) და ვამაგრებთ მას კონტეინერში სპეციფიკაციის volumeMounts განყოფილებაში. mountPath ველი არის /secrets, ამიტომ Kubernetes შექმნის ერთ ფაილს ამ საქაღალდეში საიდუმლო ობიექტში განსაზღვრული თითოეული გასაღების/მნიშვნელობის წყვილისთვის.

ჩვენს მაგალითში, ჩვენ განვსაზღვრეთ მხოლოდ ერთი გასაღები-მნიშვნელობის წყვილი, სახელწოდებით magicWord, ასე რომ, manifest შექმნის მხოლოდ წასაკითხად ფაილს /secrets/magicWord კონტეინერში მგრძნობიარე მონაცემებით.

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

The magic word is "xyzzy"

საიდუმლო საგნების კითხვა

წინა განყოფილებაში ჩვენ გამოვიყენეთ kubectl describe ბრძანება ConfigMap-ის შინაარსის საჩვენებლად. იგივე შეიძლება გაკეთდეს Secret-ით?

kubectl describe secret/demo-secret
Name:          demo-secret

Namespace:      default
Labels:             <none>
Annotations:
Type:               Opaque

Data
====
magicWord: 5   bytes

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

მგრძნობიარე მონაცემების დაშიფრული YAML ვერსიის სანახავად გამოიყენეთ kubectl get ბრძანება:

kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
   magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaque

base64

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

იმის გამო, რომ მგრძნობიარე ინფორმაცია შეიძლება იყოს ორობითი და არა გამომავალი (როგორც TLS დაშიფვრის გასაღების შემთხვევაში), საიდუმლო ობიექტები ყოველთვის ინახება base64 ფორმატში.

ტექსტი beHl6enk= არის ჩვენი საიდუმლო სიტყვის xyzzy ბაზის64 კოდირებული ვერსია. ამის გადამოწმება შეგიძლიათ ტერმინალში base64 — decode ბრძანების გაშვებით:

echo "eHl6enk=" | base64 --decode
xyzzy

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

თუ საჭიროა base64-ის ზოგიერთი ტექსტის დაშიფვრა (მაგალითად, საიდუმლოში ჩასმა), გამოიყენეთ base64 ბრძანება არგუმენტების გარეშე:

echo xyzzy | base64
eHl6enkK

საიდუმლო ობიექტებზე წვდომა

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

მონაცემთა პასიური დაშიფვრა

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

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

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

kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
        --experimental-encryption-provider-config=...

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

კონფიდენციალური მონაცემების შენახვა

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

kind: Secret
metadata:
    annotations:
        "helm.sh/resource-policy": keep

საიდუმლო ობიექტების მართვის სტრატეგიები

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

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

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

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

ავტორების შესახებ

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

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

» მეტი ინფორმაცია წიგნის შესახებ შეგიძლიათ იხილოთ აქ გამომცემლის ვებსაიტზე
» სარჩევი
» ნაწყვეტი

Khabrozhiteley-ზე 25% ფასდაკლება კუპონის გამოყენებით - კუბერნეტები

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

წყარო: www.habr.com