🥇Jinsi ya kuunganisha makundi ya Kubernetes katika vituo tofauti vya data

Karibu kwenye mfululizo wetu wa Kubernetes Quick Start. Hii ni safu ya kawaida yenye maswali ya kuvutia zaidi tunayopokea mtandaoni na katika mafunzo yetu. Mtaalam wa Kubernetes anajibu.

Mtaalamu wa leo ni Daniel Polenchik (Daniele Polencic) Daniel anafanya kazi kama mwalimu na msanidi programu katika Jifunze8s.

Ikiwa unataka kujibiwa swali lako katika chapisho linalofuata, wasiliana nasi kwa barua pepe au Twitter: @learnk8s.

Umekosa machapisho yaliyotangulia? Wapate hapa.

Jinsi ya kuunganisha nguzo za Kubernetes katika vituo tofauti vya data?

Kwa kifupi: Kubefed v2 inakuja hivi karibuni, na pia ninapendekeza kusoma kuhusu Msafirishaji и mradi wa mpangilio wa nguzo nyingi.

Mara nyingi, miundombinu inaigwa na kusambazwa katika mikoa mbalimbali, hasa katika mazingira yaliyodhibitiwa.

Ikiwa eneo moja halipatikani, trafiki itaelekezwa kwingine ili kuepuka kukatizwa.

Ukiwa na Kubernetes, unaweza kutumia mkakati sawa na kusambaza mzigo wa kazi katika maeneo mbalimbali.

Unaweza kuwa na kundi moja au zaidi kwa kila timu, eneo, mazingira, au mchanganyiko wa vipengele hivi.

Vikundi vyako vinaweza kupangishwa katika mawingu tofauti na kwenye majengo.

Lakini unapangaje miundombinu ya kuenea kwa kijiografia kama hii?
Je, unahitaji kuunda nguzo moja kubwa kwa mazingira kadhaa ya wingu kwenye mtandao mmoja?
Au una vikundi vingi vidogo na utafute njia ya kudhibiti na kusawazisha?

Kundi moja la uongozi

Kuunda nguzo moja kwenye mtandao mmoja sio rahisi sana.

Fikiria una ajali, muunganisho kati ya sehemu za nguzo umepotea.

Ikiwa una seva kuu moja, nusu ya rasilimali haitaweza kupokea amri mpya kwa sababu hawataweza kuwasiliana na bwana.

Na wakati huo huo unayo meza za zamani za kuelekeza (kube-proxy haiwezi kupakua mpya) na hakuna maganda ya ziada (kubelet haiwezi kuomba masasisho).

Ili kufanya mambo kuwa mbaya zaidi, ikiwa Kubernetes haioni nodi, inaashiria kama yatima na inasambaza maganda yaliyokosekana kwa nodi zilizopo.

Matokeo yake, una maganda mara mbili zaidi.

Ukitengeneza seva kuu moja kwa kila mkoa, kutakuwa na shida na algorithm ya makubaliano kwenye hifadhidata ya etcd. (takriban. mh. - Kwa kweli, hifadhidata ya etcd sio lazima iwe iko kwenye seva kuu. Inaweza kuendeshwa kwenye kundi tofauti la seva katika eneo moja. Kweli, wakati huo huo kupata hatua ya kushindwa kwa nguzo. Lakini haraka.)

matumizi nk algorithm ya raftkujadili thamani kabla ya kuiandika kwa diski.
Hiyo ni, matukio mengi lazima yafikie makubaliano kabla ya serikali kuandikiwa nk.

Ikiwa muda wa kusubiri kati ya matukio ya etcd huongezeka kwa kasi, kama ilivyo kwa matukio matatu etcd katika mikoa tofauti, inachukua muda mrefu kujadili thamani na kuiandika kwenye diski.
Hii inaonekana katika vidhibiti vya Kubernetes.

Msimamizi wa kidhibiti anahitaji muda zaidi ili kujifunza kuhusu mabadiliko na kuandika majibu kwenye hifadhidata.

Na kwa kuwa hakuna mtawala mmoja, lakini kadhaa, majibu ya mnyororo na nguzo nzima huanza kufanya kazi polepole sana.

etcd ni nyeti sana kwa latency Nyaraka rasmi zinapendekeza kutumia SSD badala ya anatoa ngumu za kawaida.

Kwa sasa hakuna mifano mizuri ya mtandao mkubwa kwa kundi moja.

Kimsingi, jumuiya ya wasanidi programu na kikundi cha nguzo ya SIG wanajaribu kufikiria jinsi ya kupanga vikundi kwa njia sawa na Kubernetes hupanga vyombo.

Chaguo 1: shirikisho la nguzo na kubefed

Jibu rasmi kutoka kwa nguzo ya SIG - kubefed2, toleo jipya la mteja asili wa shirikisho la kube na mwendeshaji.

Kwa mara ya kwanza, tulijaribu kudhibiti mkusanyiko wa vikundi kama kitu kimoja kwa kutumia zana ya shirikisho la kube.

Mwanzo ulikuwa mzuri, lakini mwishowe shirikisho la kube halikupata umaarufu kwa sababu halikusaidia rasilimali zote.

Iliauni uwasilishaji na huduma zilizoshirikishwa, lakini si StatefulSets, kwa mfano.
Pia, usanidi wa shirikisho ulipitishwa kwa njia ya maelezo na haukubadilika.

Hebu fikiria jinsi unavyoweza kuelezea ugawaji wa nakala kwa kila nguzo katika shirikisho kwa kutumia maelezo pekee.

Ilikuwa ni fujo kabisa.

SIG-cluster ilifanya kazi nyingi baada ya kubefed v1 na kuamua kushughulikia shida kutoka kwa pembe tofauti.

Badala ya maelezo, waliamua kuachilia kidhibiti ambacho kimewekwa kwenye vikundi. Inaweza kubinafsishwa kwa kutumia Ufafanuzi wa Rasilimali Maalum (CRDs).

Kwa kila nyenzo ambayo itakuwa sehemu ya shirikisho, una ufafanuzi maalum wa CRD na sehemu tatu:

ufafanuzi wa kawaida wa rasilimali, kwa mfano kupeleka;
sehemu placement, ambapo unafafanua jinsi rasilimali itasambazwa katika shirikisho;
sehemu override, ambapo kwa rasilimali maalum unaweza kuondokana na uzito na vigezo kutoka kwa kuwekwa.

Huu hapa ni mfano wa uwasilishaji wa pamoja na sehemu za uwekaji na ubatilishaji.

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

Kama unaweza kuona, usambazaji unasambazwa katika vikundi viwili: cluster1 и cluster2.

Kundi la kwanza linatoa nakala tatu, na la pili limewekwa kwa 5.

Ikiwa unahitaji udhibiti zaidi wa idadi ya nakala, kubefed2 hutoa kitu kipya cha ReplicaSchedulingPreference ambapo nakala zinaweza kupimwa:

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

Muundo wa CRD na API bado hazijawa tayari, na kazi inayoendelea inaendelea katika hazina rasmi ya mradi.

Endelea kufuatilia kubefed2, lakini kumbuka kuwa bado haifai kwa uzalishaji.

Jifunze zaidi kuhusu kubefed2 kutoka nakala rasmi kuhusu kubefed2 kwenye blogi kuhusu Kubernetes na ndani hazina rasmi ya mradi wa kubefed.

Chaguo 2: kuchanganya makundi katika mtindo wa Booking.com

Watengenezaji wa Booking.com hawakufanya kazi kwenye kubefed v2, lakini walikuja na Shipper - mwendeshaji wa usambazaji kwenye vikundi kadhaa, katika mikoa kadhaa na katika mawingu kadhaa.

Msafirishaji kwa kiasi fulani sawa na kubefed2.

Zana zote mbili hukuruhusu kubinafsisha mkakati wako wa uwekaji wa nguzo nyingi (nguzo zipi zinatumika na zina nakala ngapi).

Lakini Lengo la Mtumaji Shehena ni kupunguza hatari ya makosa wakati wa kujifungua.

Katika Shipper, unaweza kufafanua mfululizo wa hatua zinazoelezea mgawanyo wa nakala kati ya uwekaji uliopita na wa sasa na kiasi cha trafiki inayoingia.

Unaposukuma nyenzo kwenye kundi, kidhibiti cha Shipper husambaza mabadiliko hayo kwa makundi yote yaliyounganishwa.

Pia, Shipper ni mdogo sana.

Kwa mfano, inakubali chati za usukani kama ingizo na haiungi mkono rasilimali za vanilla.
Kwa ujumla, Shipper hufanya kazi kama hii.

Badala ya uwasilishaji wa kawaida, unahitaji kuunda rasilimali ya programu ambayo inajumuisha chati ya 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

Mtumaji Shehena ni chaguo nzuri kwa ajili ya kusimamia nguzo nyingi, lakini uhusiano wake wa karibu na Helm huingia tu kwenye njia.

Itakuwaje ikiwa sote tutahama kutoka Helm kwenda Customize au nahodha?

Pata maelezo zaidi kuhusu Shipper na falsafa yake katika taarifa hii rasmi kwa vyombo vya habari.

Ikiwa unataka kuchimba ndani ya nambari, kuelekea kwenye hazina rasmi ya mradi.

Chaguo la 3: kuunganisha nguzo za "uchawi".

Kubefed v2 na Shipper hufanya kazi na shirikisho la nguzo, kutoa nyenzo mpya kwa vikundi kupitia ufafanuzi wa rasilimali maalum.

Lakini vipi ikiwa hutaki kuandika upya bidhaa zote, StatefulSets, DaemonSets, n.k. ili kuunganisha?

Jinsi ya kujumuisha nguzo iliyopo katika shirikisho bila kubadilisha YAML?

multi-cluster-scheduler ni mradi wa Admirality, ambayo inahusika na kuratibu mzigo wa kazi kwenye vikundi.

Lakini badala ya kuja na njia mpya ya kuingiliana na nguzo na kufunga rasilimali katika ufafanuzi maalum, kipanga-ratiba cha vikundi vingi kimepachikwa katika mzunguko wa kawaida wa maisha wa Kubernetes na hukatiza simu zote zinazounda ganda.

Kila pod iliyoundwa inabadilishwa mara moja na dummy.

matumizi ya vipanga-vikundi vingi vijiti vya wavuti kwa marekebisho ya ufikiajikukatiza simu na kuunda ganda lisilofanya kazi.

Poda asili hupitia mzunguko mwingine wa kupanga ambapo, baada ya kupigia kura shirikisho zima, uamuzi wa uwekaji unafanywa.

Hatimaye, ganda hutolewa kwa nguzo lengwa.

Matokeo yake, una pod ya ziada ambayo haifanyi chochote, inachukua nafasi tu.

Faida ni kwamba haukuhitaji kuandika rasilimali mpya ili kuchanganya vifaa.

Kila rasilimali inayounda ganda iko tayari kuunganishwa kiotomatiki.

Hii inafurahisha, kwa sababu ghafla una vifaa vilivyosambazwa katika mikoa kadhaa, na hata haukugundua. Walakini, hii ni hatari kabisa, kwa sababu kila kitu hapa kinategemea uchawi.

Lakini wakati Shipper anajaribu kupunguza athari za usafirishaji, kipanga-ratiba cha vikundi vingi hushughulikia kazi za jumla zaidi na labda inafaa zaidi kwa kazi za kundi.

Haina utaratibu wa juu wa utoaji wa taratibu.

Zaidi kuhusu multi-cluster-scheduler inaweza kupatikana katika ukurasa rasmi wa kumbukumbu.

Ikiwa unataka kusoma kuhusu kipanga-ratiba cha vikundi vingi kikifanya kazi, Admiralty anayo kesi ya matumizi ya kuvutia na Argo - mtiririko wa kazi, matukio, CI na CD Kubernetes.

Zana zingine na suluhisho

Kuunganisha na kudhibiti vikundi vingi ni kazi ngumu, na hakuna suluhisho la ulimwengu wote.

Ikiwa ungependa kuchunguza mada hii zaidi, hapa kuna baadhi ya nyenzo:

Nyambizi na Rancher ni zana inayounganisha mitandao inayowekelea ya makundi tofauti ya Kubernetes.
Matumizi ya Lengo la mnyororo wa rejareja Unimatrix pamoja na Spinnaker ili kupanga utumaji kwenye vikundi vingi.
Jaribu kutumia IPV6 na mtandao mmoja katika mikoa kadhaa.
Unaweza kutumia mesh ya huduma, kwa mfano Istio ya kuunganisha nguzo nyingi.
Cilium, programu-jalizi ya kiolesura cha mtandao wa chombo, inatoa kazi ya matundu ya nguzo, ambayo inakuwezesha kuchanganya makundi kadhaa

Ni hayo tu kwa leo

Asante kwa kusoma hadi mwisho!

Ikiwa unajua jinsi ya kuunganisha nguzo nyingi kwa ufanisi zaidi, Tuambie.

Tutaongeza njia yako kwenye viungo.

Shukrani za pekee kwa Chris Nesbitt-Smith (Chris Nesbitt-Smith) na Vincent de Sme (Vincent De Smet) (mhandisi wa kuaminika katika swatmobile.io) kwa kusoma makala na kushiriki habari muhimu kuhusu jinsi shirikisho linavyofanya kazi.

Chanzo: mapenzi.com

Jinsi ya kuunganisha nguzo za Kubernetes katika vituo tofauti vya data