Kustomize-ის მოკლე შესავალი

Შენიშვნა. თარგმნა: სტატია დაწერა სკოტ ლოუმ, ინჟინერმა, რომელსაც აქვს დიდი გამოცდილება IT-ში, რომელიც არის შვიდი ნაბეჭდი წიგნის ავტორი/თანაავტორი (ძირითადად VMware vSphere-ზე). ის ახლა მუშაობს მის VMware შვილობილი კომპანია Heptio-ში (შეძენილია 2016 წელს), რომელიც სპეციალიზირებულია ღრუბლოვან გამოთვლებსა და Kubernetes-ში. თავად ტექსტი ემსახურება როგორც ლაკონურ და ადვილად გასაგებ შესავალს Kubernetes-ისთვის კონფიგურაციის მენეჯმენტში ტექნოლოგიის გამოყენებით. მორგება, რომელიც ცოტა ხნის წინ K8-ის ნაწილი გახდა.

Kustomize არის ინსტრუმენტი, რომელიც საშუალებას აძლევს მომხმარებლებს „მოახდინონ მარტივი, შაბლონების გარეშე YAML ფაილების მორგება სხვადასხვა მიზნებისთვის, დატოვონ ორიგინალური YAML ხელუხლებელი და გამოსაყენებელი“ (აღწერილობა პირდაპირ ნასესხები კუსტომიზება საცავი GitHub-ზე). Kustomize შეიძლება გაშვებული იყოს პირდაპირ ან, როგორც Kubernetes 1.14, გამოიყენოს kubectl -k მის ფუნქციონალობაზე წვდომისთვის (თუმცა Kubernetes 1.15-ის მიხედვით, ცალკე ორობითი უფრო ახალია, ვიდრე კუბექტლში ჩაშენებული შესაძლებლობები). (Შენიშვნა. თარგმნა: და ბოლო გამოშვებით კუბერნეტი 1.16 მორგება მხარდაჭერილი ასევე kubeadm უტილიტაში.) ამ პოსტში მინდა მკითხველს გავაცნო კუსტომიზების საფუძვლები.

მისი უმარტივესი ფორმით/აპლიკაციით, kustomize არის უბრალოდ რესურსების კოლექცია (YAML ფაილები, რომლებიც განსაზღვრავენ Kubernetes ობიექტებს: განლაგება, სერვისები და ა.შ.) პლუს ინსტრუქციების სია იმ ცვლილებებისთვის, რომლებიც უნდა განხორციელდეს ამ რესურსებში. ისევე, როგორც make იყენებს ინსტრუქციების კომპლექტს, რომელიც შეიცავს Makefileდა Docker აშენებს კონტეინერს ინსტრუქციების საფუძველზე Dockerfileმოხმარების მორგება kustomization.yaml შეინახოს ინსტრუქციები იმის შესახებ, თუ რა ცვლილებების შეტანა სურს მომხმარებელს რესურსების ერთობლიობაში.

აქ არის ფაილის მაგალითი kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

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

• საველე resources მიუთითებს რა (რომელი რესურსები) შეიცვლება კუსტომიზება. ამ შემთხვევაში, ის ეძებს რესურსებს ფაილებში deployment.yaml и service.yaml თქვენს დირექტორიაში (შეგიძლიათ მიუთითოთ სრული ან შედარებითი ბილიკები საჭიროების შემთხვევაში).
• საველე namePrefix ავალებს kustomize დაამატოთ გარკვეული პრეფიქსი (ამ შემთხვევაში - dev-) მიაწეროს name სფეროში განსაზღვრული ყველა რესურსი resources. ამრიგად, თუ განლაგება აქვს name მნიშვნელობით nginx-deployment, მორგება გახდის მას dev-nginx-deployment.
• საველე namespace ავალებს kustomize-ს დაემატოს მოცემული სახელთა სივრცე ყველა რესურსს. ამ შემთხვევაში, Deployment and Service მოხვდება სახელთა სივრცეში development.
• საბოლოოდ, ველი commonLabels შეიცავს ეტიკეტების ერთობლიობას, რომელიც დაემატება ყველა რესურსს. ჩვენს მაგალითში, kustomize მიანიჭებს ეტიკეტს რესურსებს სახელით environment და მნიშვნელობა development.

თუ მომხმარებელი აკეთებს kustomize build . დირექტორიაში ფაილთან ერთად kustomization.yaml და საჭირო რესურსები (მაგ. ფაილები deployment.yaml и service.yaml), შემდეგ გამოსავალზე მიიღებს ტექსტს, რომელშიც მითითებულია ცვლილებები kustomization.yaml.

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

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

kustomize build . > custom-config.yaml

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

kustomize build . | kubectl apply -f -

კუსტომიზაციის ფუნქციებზე წვდომა ასევე შესაძლებელია kubectl -k (კუბერნეტის 1.14 ვერსიიდან). თუმცა, გახსოვდეთ, რომ დამოუკიდებელი kustomize პაკეტი უფრო სწრაფად ახლდება, ვიდრე ინტეგრირებული kubectl პაკეტი (ყოველ შემთხვევაში, ასეა Kubernetes 1.15 გამოშვებაში).

მკითხველებმა შეიძლება ჰკითხონ: "რატომ არის ეს სირთულე, თუ თქვენ შეგიძლიათ პირდაპირ ფაილების რედაქტირება?" დიდი კითხვა. ჩვენს მაგალითში, მართლაც შეიძლება ფაილების შეცვლა deployment.yaml и service.yaml პირდაპირ, მაგრამ რა მოხდება, თუ ისინი სხვისი პროექტის ჩანგალი არიან? ფაილების შეცვლა პირდაპირ ართულებს (თუ არა შეუძლებელს) ჩანგლის ხელახალი ბაზა, როდესაც ცვლილებები ხდება საწყის/წყაროში. Kustomize-ის გამოყენება საშუალებას გაძლევთ მოახდინოთ ამ ცვლილებების ცენტრალიზება ფაილში kustomization.yaml, ორიგინალური ფაილების ხელუხლებლად დატოვება და ამით გაადვილებს ორიგინალური ფაილების ხელახალი ბაზა, საჭიროების შემთხვევაში.

Kustomize-ის სარგებელი აშკარა ხდება უფრო რთული გამოყენების შემთხვევებში. ზემოთ მოყვანილ მაგალითში kustomization.yaml და რესურსები იმავე დირექტორიაშია. თუმცა, kustomize მხარს უჭერს გამოყენების შემთხვევებს, როდესაც არის ბაზის კონფიგურაცია და მისი მრავალი ვარიანტი, ასევე ცნობილი როგორც ზედნადები. მაგალითად, მომხმარებელს სურდა აეღო Deployment and Service nginx-ისთვის, რომელიც მე გამოვიყენე, როგორც მაგალითი, და შეექმნა ამ ფაილების განვითარების, დადგმის და წარმოების ვერსიები (ან ვარიანტები). ამისათვის მას დასჭირდება ზემოაღნიშნული გადაფარვები და, ფაქტობრივად, თავად ძირითადი რესურსები.

გადაფარვებისა და ძირითადი რესურსების იდეის საილუსტრაციოდ (საბაზისო რესურსები), დავუშვათ, რომ დირექტორიებს აქვთ შემდეგი სტრუქტურა:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

ფაილში base/kustomization.yaml მომხმარებლები, რომლებიც იყენებენ ველს resources უბრალოდ გამოაცხადეთ რესურსები, რომლებიც უნდა შეიცავდეს კუსტომიზს.

თითოეულ ფაილში overlays/{dev,staging,prod}/kustomization.yaml მომხმარებლები მიმართავენ ბაზის კონფიგურაციას ველში resourcesდა შემდეგ მიუთითეთ კონკრეტული ცვლილებები მოცემული გარემო. მაგალითად, ფაილი overlays/dev/kustomization.yaml შეიძლება გამოიყურებოდეს ადრე მოცემულ მაგალითზე:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

ამ შემთხვევაში ფაილი overlays/prod/kustomization.yaml შეიძლება სრულიად განსხვავებული იყოს:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

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

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

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

Დამატებითი რესურსები

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

• შეცვალეთ ბაზის YAML კონფიგურაცია სხვადასხვა გარემოსთვის, აწარმოეთ/ტესტი Kustomize-ის გამოყენებით;
• Kustomize - შაბლონის გაკეთების სწორი გზა Kubernetes-ში;
• Kubernetes ობიექტების დეკლარაციული მართვა Customize-ის გამოყენებით;
• ზედა დინების ჩაფხუტის დიაგრამების მორგება Customize-ით.

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

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

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

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

• «ინსტრუმენტები Kubernetes-ზე გაშვებული აპლიკაციების დეველოპერებისთვის";
• «Kubernetes 1.14: ახალი ამბების ხაზგასმა";
• «ამსტერდამში 2019 წლის ჰელმის სამიტის ხუთი ძირითადი შედეგი";
• «პრაქტიკული გაცნობა პაკეტის მენეჯერთან Kubernetes - Helm".

წყარო: www.habr.com