Ինչպես միացնել Kubernetes կլաստերները տարբեր տվյալների կենտրոններում

Բարի գալուստ մեր Kubernetes Quick Start շարք: Սա սովորական սյունակ է ամենահետաքրքիր հարցերով, որոնք մենք ստանում ենք առցանց և մեր դասընթացների ժամանակ: Kubernetes-ի փորձագետը պատասխանում է.

Այսօրվա փորձագետը Դանիել Պոլենչիկն է (Դանիելե Պոլենչիչ) Դանիելն աշխատում է որպես հրահանգիչ և ծրագրային ապահովման մշակող Learnk8s.

Եթե ​​ցանկանում եք, որ ձեր հարցին պատասխան տրվի հաջորդ գրառման մեջ, կապվեք մեզ էլփոստով կամ Twitter՝ @learnk8s.

Բաց թողե՞լ եք նախորդ գրառումները Գտեք դրանք այստեղ.

Ինչպե՞ս միացնել Kubernetes կլաստերները տվյալների տարբեր կենտրոններում:

Համառոտ: Kubefed v2 շուտով, և ես նաև խորհուրդ եմ տալիս կարդալ դրա մասին Առաքիչ и բազմակլաստերային-ծրագրավորող նախագիծ.

Շատ հաճախ ենթակառուցվածքները կրկնօրինակվում և բաշխվում են տարբեր տարածաշրջաններում, հատկապես վերահսկվող միջավայրերում:

Եթե ​​մի շրջան անհասանելի է, երթևեկությունը վերահղվում է մյուսը՝ ընդհատումներից խուսափելու համար:

Kubernetes-ի հետ դուք կարող եք օգտագործել նմանատիպ ռազմավարություն և բաշխել ծանրաբեռնվածությունը տարբեր տարածաշրջաններում:

Դուք կարող եք ունենալ մեկ կամ մի քանի կլաստերներ յուրաքանչյուր թիմում, տարածաշրջանում, միջավայրում կամ այս տարրերի համակցությունում:

Ձեր կլաստերները կարող են տեղակայվել տարբեր ամպերում և ներքին տարածքներում:

Բայց ինչպե՞ս եք պլանավորում ենթակառուցվածքը նման աշխարհագրական տարածման համար:
Ձեզ անհրաժեշտ է ստեղծել մեկ մեծ կլաստեր մի քանի ամպային միջավայրերի համար մեկ ցանցի միջոցով:
Կամ ունե՞ք շատ փոքր կլաստերներ և գտնեք դրանք կառավարելու և համաժամանակացնելու միջոց:

Մեկ առաջնորդական կլաստեր

Մեկ ցանցի վրա մեկ կլաստեր ստեղծելն այնքան էլ հեշտ չէ:

Պատկերացրեք, որ վթարի եք ենթարկվել, կլաստերի հատվածների միջև կապը կորել է:

Եթե ​​դուք ունեք մեկ գլխավոր սերվեր, ռեսուրսների կեսը չի կարողանա նոր հրամաններ ստանալ, քանի որ նրանք չեն կարողանա կապվել վարպետի հետ:

Եվ միևնույն ժամանակ դուք ունեք հին երթուղային աղյուսակներ (kube-proxy չի կարող ներբեռնել նորերը) և ոչ մի լրացուցիչ պատիճ (kubelet-ը չի կարող թարմացումներ պահանջել):

Իրավիճակն ավելի վատթարացնելու համար, եթե Kubernetes-ը հանգույց չի տեսնում, այն նշում է որպես որբ և բացակայող հանգույցները բաժանում է գոյություն ունեցող հանգույցներին:

Արդյունքում դուք երկու անգամ ավելի շատ պատիճ ունեք:

Եթե ​​յուրաքանչյուր տարածաշրջանի համար մեկ գլխավոր սերվեր ստեղծեք, etcd տվյալների բազայում կոնսենսուսի ալգորիթմի հետ կապված խնդիրներ կլինեն: (մոտ. խմբ. — Փաստորեն, etcd տվյալների բազան պարտադիր չէ, որ տեղակայված լինի հիմնական սերվերների վրա: Այն կարող է գործարկվել նույն տարածաշրջանի սերվերների առանձին խմբի վրա: Ճիշտ է, միևնույն ժամանակ կլաստերի ձախողման կետ ստանալը։ Բայց արագ.)

etcd օգտագործում raft ալգորիթմարժեքի շուրջ բանակցություններ վարելու համար այն սկավառակի վրա գրելուց առաջ:
Այսինքն, ատյանների մեծամասնությունը պետք է կոնսենսուսի հասնի, նախքան պետությունը կարող է գրվել etcd-ում:

Եթե ​​etcd օրինակների միջև ուշացումը կտրուկ աճում է, ինչպես դա տեղի է ունենում տարբեր տարածաշրջաններում երեք etcd օրինակների դեպքում, երկար ժամանակ է պահանջվում արժեքի շուրջ բանակցություններ վարելու և այն սկավառակի վրա գրելու համար:
Սա արտացոլված է Kubernetes կարգավորիչներում:

Վերահսկիչի կառավարչին ավելի շատ ժամանակ է պետք, որպեսզի իմանա փոփոխության մասին և գրի պատասխանը տվյալների բազայում:

Եվ քանի որ չկա մեկ վերահսկիչ, այլ մի քանի, առաջանում է շղթայական ռեակցիա, և ամբողջ կլաստերը սկսում է շատ դանդաղ աշխատել.

etcd-ն այնքան զգայուն է ուշացման համար, որ Պաշտոնական փաստաթղթերը խորհուրդ են տալիս սովորական կոշտ սկավառակների փոխարեն օգտագործել SSD-ներ.

Ներկայումս մեկ կլաստերի համար մեծ ցանցի լավ օրինակներ չկան:

Հիմնականում մշակողների համայնքը և SIG-կլաստերի խումբը փորձում են պարզել, թե ինչպես կազմակերպել կլաստերները այնպես, ինչպես Kubernetes-ը կազմակերպում է կոնտեյներները:

Տարբերակ 1. կլաստերային ֆեդերացիա kubefed-ով

Պաշտոնական պատասխան SIG-կլաստերի կողմից. kubefed2, սկզբնական kube ֆեդերացիայի հաճախորդի և օպերատորի նոր տարբերակը.

Առաջին անգամ մենք փորձեցինք կառավարել կլաստերների հավաքածուն որպես մեկ օբյեկտ՝ օգտագործելով kube ֆեդերացիայի գործիքը:

Մեկնարկը լավ էր, բայց ի վերջո kube ֆեդերացիան երբեք հայտնի չդարձավ, քանի որ այն չէր ապահովում բոլոր ռեսուրսները:

Այն աջակցում էր դաշնային առաքումներին և ծառայություններին, բայց ոչ StatefulSets-ին, օրինակ:
Նաև ֆեդերացիայի կոնֆիգուրացիան փոխանցվել է անոտացիաների տեսքով և ճկուն չի եղել։

Պատկերացրեք, թե ինչպես կարող եք նկարագրել ֆեդերացիայի յուրաքանչյուր կլաստերի կրկնօրինակի բաժանումը` օգտագործելով պարզապես ծանոթագրություններ:

Լրիվ խառնաշփոթ էր։

SIG-cluster-ը մեծ աշխատանք կատարեց 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-ի մասին բլոգում և in 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-ի հետ միայն խանգարում են:

Իսկ եթե մենք բոլորս անցնենք Helm-ից դեպի հարմարեցնել կամ կապիտան?

Իմացեք ավելին Shipper-ի և նրա փիլիսոփայության մասին այստեղ այս պաշտոնական մամուլի հաղորդագրությունը.

Եթե ​​ցանկանում եք խորանալ կոդը, Գնացեք ծրագրի պաշտոնական շտեմարան.

Տարբերակ 3. «կախարդական» կլաստերի միաձուլում

Kubefed v2-ը և Shipper-ը աշխատում են կլաստերային դաշնության հետ՝ նոր ռեսուրսներ տրամադրելով կլաստերներին՝ հատուկ ռեսուրսների սահմանման միջոցով:

Բայց ինչ անել, եթե դուք չեք ցանկանում վերաշարադրել բոլոր առաքումները, StatefulSets, DaemonSets և այլն, որպեսզի միաձուլվեն:

Ինչպե՞ս ներառել գոյություն ունեցող կլաստերը ֆեդերացիայի մեջ՝ առանց YAML-ի փոխելու:

multi-cluster-scheduler-ը Admirality նախագիծ է, որը վերաբերում է կլաստերների վրա աշխատանքային բեռների պլանավորմանը։

Սակայն կլաստերի հետ փոխազդելու և ռեսուրսները մաքսային սահմանումներով փաթեթավորելու նոր եղանակ ստեղծելու փոխարեն, բազմակլաստերային ժամանակացույցը ներդրվում է ստանդարտ Kubernetes-ի կյանքի ցիկլի մեջ և ընդհատում բոլոր զանգերը, որոնք ստեղծում են պատյաններ:

Ստեղծված յուրաքանչյուր պատիճ անմիջապես փոխարինվում է կեղծամով:

բազմակի կլաստերային ժամանակացույցի օգտագործում վեբկեռիկներ՝ մուտքի փոփոխման համարզանգը ընդհատելու և անգործուն կեղծ պատիճ ստեղծելու համար:

Բնօրինակ պատիճն անցնում է պլանավորման մեկ այլ ցիկլով, որտեղ ամբողջ ֆեդերացիայի հարցումներից հետո կայացվում է տեղաբաշխման որոշում:

Ի վերջո, պատիճը առաքվում է թիրախային կլաստերին:

Արդյունքում, դուք ունեք լրացուցիչ պատիճ, որը ոչինչ չի անում, պարզապես տարածք է զբաղեցնում:

Առավելությունն այն է, որ անհրաժեշտ չէր նոր ռեսուրսներ գրել մատակարարումները համատեղելու համար:

Յուրաքանչյուր ռեսուրս, որը ստեղծում է պատիճ, ավտոմատ կերպով պատրաստ է միաձուլման:

Սա հետաքրքիր է, քանի որ հանկարծ դուք ունեք մատակարարումներ, որոնք բաշխված են մի քանի մարզերում, և դուք նույնիսկ չեք նկատել: Այնուամենայնիվ, սա բավականին ռիսկային է, քանի որ այստեղ ամեն ինչ հենված է մոգության վրա:

Բայց մինչ Shipper-ը փորձում է հիմնականում մեղմել առաքումների ազդեցությունը, բազմակի կլաստերային ժամանակացույցը կատարում է ավելի ընդհանուր առաջադրանքներ և, հավանաբար, ավելի հարմար է խմբաքանակային աշխատանքների համար:

Այն չունի աստիճանական առաքման առաջադեմ մեխանիզմ։

Multi-cluster-scheduler-ի մասին ավելին կարող եք գտնել այստեղ Պաշտոնական պահեստի էջ.

Եթե ​​ցանկանում եք կարդալ գործողության մեջ գտնվող բազմակլաստերային պլանավորողի մասին, Admiralty-ն ունի հետաքրքիր օգտագործման դեպք Argo-ի հետ — աշխատանքային հոսքեր, իրադարձություններ, CI և CD Kubernetes:

Այլ գործիքներ և լուծումներ

Բազմաթիվ կլաստերների միացումը և կառավարումը բարդ խնդիր է, և չկա համընդհանուր լուծում:

Եթե ​​ցանկանում եք ավելի մանրամասն ուսումնասիրել այս թեման, այստեղ կան որոշ ռեսուրսներ.

• Submariner կողմից Rancher գործիք է, որը միացնում է տարբեր Kubernetes կլաստերների կափարիչ ցանցերը:
• Target-ի մանրածախ ցանցն օգտագործում է Unimatrix-ը համատեղվում է Spinnaker-ի հետ՝ կազմակերպելու տեղակայումը բազմաթիվ կլաստերներում.
• Փորձեք օգտագործել IPV6 և միասնական ցանց մի քանի մարզերում.
• Դուք կարող եք օգտագործել սպասարկման ցանց, օրինակ Istio մի քանի կլաստերների միացման համար.
• Cilium-ը՝ բեռնարկղային ցանցի ինտերֆեյսի պլագին, առաջարկում է կլաստերի ցանցի ֆունկցիան, որը թույլ է տալիս միավորել մի քանի կլաստերներ

Այսօրվա համար այսքանը

Շնորհակալություն մինչև վերջ կարդալու համար:

Եթե ​​դուք գիտեք, թե ինչպես միացնել մի քանի կլաստերներ ավելի արդյունավետ, ասա մեզ.

Մենք ձեր մեթոդը կավելացնենք հղումներին:

Հատուկ շնորհակալություն Քրիս Նեսբիթ-Սմիթին (Քրիս Նեսբիթ-Սմիթ) և Վինսենթ դե Սմե (Վինսենթ Դե Սմեթ) (հուսալիության ինժեներ swatmobile.io) հոդվածը կարդալու և ֆեդերացիայի աշխատանքի մասին օգտակար տեղեկությունների փոխանակման համար:

Source: www.habr.com