ProHoster > Blog > башкаруу > Ар кандай маалымат борборлорунда Kubernetes кластерлерин кантип туташтыруу керек

Ар кандай маалымат борборлорунда Kubernetes кластерлерин кантип туташтыруу керек

Ар кандай маалымат борборлорунда Kubernetes кластерлерин кантип туташтыруу керек
Биздин Kubernetes Quick Start сериясына кош келиңиз. Бул биз онлайн режиминде жана тренингдерибизде эң кызыктуу суроолорду камтыган кадимки рубрика. Kubernetes эксперти жооп берет.

Бүгүнкү эксперт Даниел Поленчик (Даниэле Поленчич). Даниел инструктор жана программалык камсыздоону иштеп чыгуучу болуп иштейт Learnk8s.

Сурооңузга кийинки постто жооп алгыңыз келсе, электрондук почта аркылуу биз менен байланыш же Twitter: @learnk8s.

Мурунку билдирүүлөрдү сагындыңызбы? Аларды бул жерден табыңыз.

Ар кандай маалымат борборлорунда Kubernetes кластерлерин кантип туташтыруу керек?

кыскача: Kubefed v2 жакында чыгат, жана мен дагы жөнүндө окууну сунуштайм Жөнөтүүчү и көп кластердик пландоочу долбоор.

Көбүнчө инфраструктура ар кандай аймактарда, өзгөчө көзөмөлдөнүүчү чөйрөлөрдө кайталанат жана бөлүштүрүлөт.

Эгер бир аймак жеткиликсиз болсо, жол кыймылы үзгүлтүккө учурабаш үчүн башка аймакка багытталат.

Kubernetes менен сиз окшош стратегияны колдонуп, жумуш жүгүн ар кайсы аймактарга тарата аласыз.

Ар бир команда, аймак, чөйрө же бул элементтердин айкалышы үчүн бир же бир нече кластерлер болушу мүмкүн.

Сиздин кластерлериңиз ар кандай булуттарда жана жерде жайгаштырылышы мүмкүн.

Бирок мындай географиялык жайылуу үчүн инфраструктураны кантип пландаштырасыз?
Сиз бир тармак аркылуу бир нече булут чөйрөсү үчүн бир чоң кластерди түзүшүңүз керекпи?
Же көптөгөн чакан кластерлерге ээ болуп, аларды көзөмөлдөө жана синхрондоштуруу жолун табасызбы?

Бир лидерлик кластери

Бир тармактын үстүнөн бир кластер түзүү анчалык деле оңой эмес.

Кырсыкка кабылганыңызды элестетиңиз, кластер сегменттеринин ортосундагы байланыш жоголуп кетти.

Эгер сизде бир башкы сервер болсо, ресурстардын жарымы жаңы буйруктарды ала албайт, анткени алар мастер менен байланыша алышпайт.

Жана ошол эле учурда сизде эски маршруттук таблицалар бар (kube-proxy жаңыларын жүктөй албайт) жана кошумча подколор жок (kubelet жаңыртууларды талап кыла албайт).

Андан да жаманы, эгерде Кубернетес түйүн көрбөсө, ал аны жетим деп белгилейт жана жок болгон түйүндөрдү учурдагы түйүндөргө бөлүштүрөт.

Натыйжада сизде эки эсе көп шишкебек бар.

Эгер сиз ар бир аймак үчүн бирден башкы сервер жасасаңыз, etcd маалымат базасында консенсус алгоритминде көйгөйлөр пайда болот. (болжол менен ред. — Чынында, etcd маалымат базасы сөзсүз эле башкы серверлерде жайгашуусу шарт эмес. Аны ошол эле аймактагы серверлердин өзүнчө тобунда иштетсе болот. Ырас, ошол эле учурда кластердин иштебей калган учурун алуу. Бирок тез.)

etcd колдонот сал алгоритмидискке жазуудан мурун баасын сүйлөшүү үчүн.
Башкача айтканда, мамлекеттик ж.б. жазууга чейин көпчүлүк учурлар консенсуска жетиши керек.

Эгерде etcd инстанцияларынын ортосундагы кечигүү, ар кайсы аймактардагы үч etcd инстанциясында болгондой, кескин көбөйсө, маанини сүйлөшүү жана аны дискке жазуу көп убакытты талап кылат.
Бул Kubernetes контроллерлорунда чагылдырылган.

Контроллердин менеджери өзгөртүү жөнүндө билүү жана маалымат базасына жооп жазуу үчүн көбүрөөк убакыт керек.

Жана бир эмес, бир нече контроллер бар болгондуктан, чынжыр реакциясы келип чыгат жана бүт кластер өтө жай иштей баштайт.

etcd ушунчалык кечигүү сезимтал болгондуктан Расмий документтер кадимки катуу дисктердин ордуна SSD дисктерин колдонууну сунуштайт.

Учурда бир кластер үчүн чоң тармактын жакшы үлгүлөрү жок.

Негизинен, иштеп чыгуучулардын коомчулугу жана SIG-кластер тобу Кубернетес контейнерлерди уюштургандай кластерлерди кантип уюштурууну чечүүгө аракет кылып жатышат.

1-вариант: kubefed менен кластердик федерация

SIG-кластеринен расмий жооп - kubefed2, баштапкы kube федерациясынын кардарынын жана операторунун жаңы версиясы.

Биринчи жолу биз kube федерациясынын куралын колдонуп, кластерлердин коллекциясын бирдиктүү объект катары башкарууга аракет кылдык.

Башталыш жакшы болду, бирок акыры кубе федерациясы эч качан популярдуу боло алган жок, анткени ал бардык ресурстарды колдобойт.

Ал федеративдүү жеткирүүлөрдү жана кызматтарды колдоду, бирок, мисалы, StatefulSets эмес.
Ошондой эле федерациянын конфигурациясы аннотациялар түрүндө берилип, ийкемдүү болгон эмес.

Жөн гана аннотацияларды колдонуу менен федерациядагы ар бир кластер үчүн репликаны бөлүүнү кантип сүрөттөп бере аларыңызды элестетиңиз.

Бул толугу менен баш аламандык болду.

SIG-кластери kubefed v1ден кийин көп иштерди жасап, көйгөйгө башка бурчтан мамиле кылууну чечти.

Аннотациялардын ордуна алар кластерлерге орнотулган контроллерди чыгарууну чечишти. Аны Custom Resource Definitions (CRDs) аркылуу ыңгайлаштырса болот.

Федерациянын бир бөлүгү боло турган ар бир ресурс үчүн сизде үч бөлүмдөн турган ыңгайлаштырылган 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 ушундай иштейт.

Стандарттык жеткирүүнүн ордуна, сиз 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ди өзгөртпөстөн, учурдагы кластерди федерацияга кантип кошуу керек?

көп кластердик пландоочу бул Адмиралдуулук долбоору, ал кластерлерде иш жүктөмдөрүн пландаштыруу менен алектенет.

Бирок кластер менен өз ара аракеттенүүнүн жана ресурстарды ыңгайлаштырылган аныктамаларга топтоонун жаңы ыкмасын ойлоп табуунун ордуна, көп кластердик пландоочу стандарттуу Kubernetes жашоо циклине киргизилген жана поддондорду жараткан бардык чалууларды токтотот.

Ар бир түзүлгөн поддон дароо муляж менен алмаштырылат.

көп кластердик пландоочу колдонот жетүү өзгөртүү үчүн webhooksчалууга тоскоол болуу жана бош муляжды түзүү.

Түпнуска подряд дагы бир пландоо циклинен өтөт, анда бүт федерацияны сурамжылоодон кийин, жайгаштыруу чечими кабыл алынат.

Акыр-аягы, поддон максаттуу кластерге жеткирилет.

Натыйжада, сизде эч нерсе кылбаган, жөн гана мейкиндикти ээлеген кошумча поддон бар.

Артыкчылыгы - жеткирүүлөрдү бириктирүү үчүн жаңы ресурстарды жазуунун кереги жок.

Подгон түзгөн ар бир ресурс автоматтык түрдө бириктирүүгө даяр.

Бул кызыктуу, анткени күтүлбөгөн жерден бир нече региондор боюнча бөлүштүрүлгөн материалдар бар жана сиз байкаган жоксуз. Бирок, бул өтө кооптуу, анткени бул жерде баары сыйкырга таянат.

Бирок, жүк ташуучу жеткирүүлөрдүн таасирин азайтууга аракет кылып жатканда, көп кластердик пландоочу көбүрөөк жалпы тапшырмаларды аткарат жана балким, пакеттик жумуштарга ылайыктуураак.

Ал акырындык менен жеткирүүнүн өнүккөн механизми жок.

Мульти-кластердик пландоочу жөнүндө кененирээк бул жерден тапса болот расмий репозиторий барагы.

Эгер сиз көп кластердик пландоочу жөнүндө окугуңуз келсе, Адмиралтите бар Argo менен кызыктуу колдонуу учуру — иш процесстери, окуялар, CI жана CD Kubernetes.

Башка куралдар жана чечимдер

Бир нече кластерлерди туташтыруу жана башкаруу татаал маселе жана универсалдуу чечим жок.

Эгер сиз бул теманы тереңирээк изилдегиңиз келсе, бул жерде кээ бир ресурстар:

Бүгүнкү күндө бардыгы ушул

Аягына чейин окуганыңыз үчүн рахмат!

Эгер сиз бир нече кластерлерди кантип натыйжалуу туташтырууну билсеңиз, бизге айт.

Биз сиздин ыкмаңызды шилтемелерге кошобуз.

Крис Несбитт-Смитке өзгөчө ыраазычылык (Крис Несбитт-Смит) жана Винсент де Сме (Винсент Де Смет) (ишенимдүүлүк боюнча инженер swatmobile.io) макаланы окуп, федерация кандай иштээри тууралуу пайдалуу маалымат менен бөлүшүү үчүн.

Source: www.habr.com

Комментарий кошуу