როგორ დააკავშიროთ Kubernetes კლასტერები სხვადასხვა მონაცემთა ცენტრში

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

დღევანდელი ექსპერტი დანიელ პოლენჩიკია (დანიელ პოლენჩიჩი). დანიელი მუშაობს ინსტრუქტორად და პროგრამული უზრუნველყოფის შემქმნელად Learnk8s.

თუ გსურთ თქვენს კითხვაზე პასუხის გაცემა შემდეგ პოსტში, დაგვიკავშირდით ელექტრონული ფოსტით ან Twitter: @learnk8s.

გამოტოვეთ წინა პოსტები? იპოვეთ ისინი აქ.

როგორ დააკავშიროთ Kubernetes კლასტერები სხვადასხვა მონაცემთა ცენტრში?

მოკლედ: Kubefed v2 მალე გამოვადა ასევე გირჩევთ წაიკითხოთ გამგზავნი и მრავალ კლასტერულ-დაგეგმარის პროექტი.

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

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

Kubernetes-ით შეგიძლიათ გამოიყენოთ მსგავსი სტრატეგია და გადაანაწილოთ დატვირთვები სხვადასხვა რეგიონში.

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

თქვენი კლასტერები შეიძლება განთავსდეს სხვადასხვა ღრუბლებში და შიდა შენობაში.

მაგრამ როგორ გეგმავთ ინფრასტრუქტურას ასეთი გეოგრაფიული გავრცელებისთვის?
გჭირდებათ ერთი დიდი კლასტერის შექმნა რამდენიმე ღრუბლოვანი გარემოსთვის ერთი ქსელის საშუალებით?
ან გაქვთ ბევრი პატარა კლასტერი და იპოვეთ მათი კონტროლისა და სინქრონიზაციის გზა?

ერთი ლიდერობის კლასტერი

ერთი კლასტერის შექმნა ერთ ქსელზე არც ისე ადვილია.

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

თუ თქვენ გაქვთ ერთი ძირითადი სერვერი, რესურსების ნახევარი ვერ მიიღებს ახალ ბრძანებებს, რადგან ისინი ვერ დაუკავშირდებიან მასტერს.

და ამავე დროს თქვენ გაქვთ ძველი მარშრუტიზაციის ცხრილები (kube-proxy ვერ ჩამოტვირთავს ახლებს) და არ არის დამატებითი პოდები (კუბელეტს არ შეუძლია განახლებების მოთხოვნა).

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

შედეგად, თქვენ გაქვთ ორჯერ მეტი ჯიში.

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

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

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

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

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

etcd იმდენად ლატენტურად მგრძნობიარეა, რომ ოფიციალური დოკუმენტაცია გვირჩევს SSD-ების გამოყენებას ჩვეულებრივი მყარი დისკების ნაცვლად.

ამჟამად არ არსებობს დიდი ქსელის კარგი მაგალითები ერთი კლასტერისთვის.

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

ვარიანტი 1: კლასტერული ფედერაცია kubefed-ით

ოფიციალური პასუხი SIG-კლასტერიდან - kubefed2, ორიგინალური kube ფედერაციის კლიენტისა და ოპერატორის ახალი ვერსია.

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

დასაწყისი კარგი იყო, მაგრამ საბოლოოდ კუბის ფედერაცია არასოდეს გახდა პოპულარული, რადგან ყველა რესურსს არ უჭერდა მხარს.

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

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

ეს იყო სრული არეულობა.

SIG-კლასტერმა ბევრი იმუშავა kubefed v1-ის შემდეგ და გადაწყვიტა პრობლემას სხვა კუთხით მიუდგეს.

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

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

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

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

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

როგორც ხედავთ, მიწოდება ნაწილდება ორ კლასტერზე: cluster1 и cluster2.

პირველი კლასტერი აწვდის სამ რეპლიკას, ხოლო მეორე დაყენებულია 5-ზე.

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

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

CRD სტრუქტურა და API ჯერ არ არის მზად და აქტიური მუშაობა მიმდინარეობს პროექტის ოფიციალურ საცავში.

თვალი ადევნეთ kubefed2-ს, მაგრამ გახსოვდეთ, რომ ის ჯერ არ არის შესაფერისი წარმოებისთვის.

შეიტყვეთ მეტი kubefed2-ის შესახებ ოფიციალური სტატია kubefed2-ის შესახებ ბლოგში Kubernetes-ის შესახებ და ში Kubefed პროექტის ოფიციალური საცავი.

ვარიანტი 2: კლასტერების გაერთიანება Booking.com სტილში

Booking.com-ის დეველოპერები არ მუშაობდნენ kubefed v2-ზე, მაგრამ გამოვიდნენ Shipper - ოპერატორი მიწოდებისთვის რამდენიმე კლასტერზე, რამდენიმე რეგიონში და რამდენიმე ღრუბელში.

გამგზავნი გარკვეულწილად მსგავსი kubefed2.

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

მაგრამ გამგზავნის მიზანია შეამციროს მიწოდების დროს შეცდომების რისკი.

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

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

ასევე, გამგზავნი ძალიან შეზღუდულია.

მაგალითად, ის იღებს საჭის დიაგრამებს, როგორც შეყვანას და არ უჭერს მხარს ვანილის რესურსებს.
ზოგადად, Shipper მუშაობს ასე.

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

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

გამგზავნი კარგი ვარიანტია მრავალი კლასტერის მართვისთვის, მაგრამ მისი მჭიდრო ურთიერთობა Helm-თან მხოლოდ ხელს უშლის.

რა მოხდება, თუ ჩვენ ყველანი გადავდივართ ჰელმიდან მორგება ან კაპიტანი?

შეიტყვეთ მეტი Shipper-ისა და მისი ფილოსოფიის შესახებ აქ ამ ოფიციალურ პრესრელიზში.

თუ გსურთ ჩაწეროთ კოდი, გადადით პროექტის ოფიციალურ საცავში.

ვარიანტი 3: "ჯადოსნური" კლასტერების შერწყმა

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

მაგრამ რა მოხდება, თუ არ გსურთ ყველა მიწოდების, StatefulSets, DaemonSets და ა.შ. გადაწერა შერწყმის მიზნით?

როგორ შევიტანოთ არსებული კლასტერი ფედერაციაში YAML-ის შეცვლის გარეშე?

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

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

თითოეული შექმნილი პოდი მაშინვე იცვლება დუიმით.

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

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

და ბოლოს, pod მიეწოდება სამიზნე კლასტერს.

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

უპირატესობა ის არის, რომ თქვენ არ გჭირდებათ ახალი რესურსების დაწერა მარაგების გაერთიანებისთვის.

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

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

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

მას არ გააჩნია მოწინავე თანდათანობითი მიწოდების მექანიზმი.

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

თუ გსურთ წაიკითხოთ მრავალ კლასტერული განრიგის მოქმედებაში, Admiralty-ს აქვს საინტერესო გამოყენების შემთხვევა არგოსთან - სამუშაო პროცესები, მოვლენები, CI და CD Kubernetes.

სხვა ინსტრუმენტები და გადაწყვეტილებები

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

თუ გსურთ ამ თემის შემდგომი შესწავლა, აქ არის რამდენიმე რესურსი:

• წყალქვეშა ნავი რანჩერის მიერ არის ინსტრუმენტი, რომელიც აკავშირებს კუბერნეტის სხვადასხვა კლასტერების გადაფარვის ქსელებს.
• საცალო ქსელი Target იყენებს Unimatrix გაერთიანდა Spinnaker-თან, რათა მოახდინოს განლაგება მრავალ კლასტერში.
• სცადეთ გამოიყენოთ IPV6 და ერთიანი ქსელი რამდენიმე რეგიონში.
• მაგალითად, შეგიძლიათ გამოიყენოთ სერვისული ქსელი Istio მრავალი კლასტერის დასაკავშირებლად.
• Cilium, კონტეინერის ქსელის ინტერფეისის მოდული, გთავაზობთ კასეტური ბადის ფუნქცია, რომელიც საშუალებას გაძლევთ დააკავშიროთ რამდენიმე კლასტერი

დღეისთვის სულ ესაა

მადლობა ბოლომდე კითხვისთვის!

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

ჩვენ დავამატებთ თქვენს მეთოდს ბმულებზე.

განსაკუთრებული მადლობა კრის ნესბიტ-სმიტს (კრის ნესბიტ-სმიტი) და ვინსენტ დე სმი (ვინსენტ დე სმეტი) (სანდოობის ინჟინერი ქ swatmobile.io) სტატიის წასაკითხად და სასარგებლო ინფორმაციის გასაზიარებლად, თუ როგორ მუშაობს ფედერაცია.

წყარო: www.habr.com