🥇வெவ்வேறு தரவு மையங்களில் குபெர்னெட்ஸ் கிளஸ்டர்களை எவ்வாறு இணைப்பது

எங்கள் Kubernetes விரைவு தொடக்கத் தொடருக்கு வரவேற்கிறோம். ஆன்லைனிலும் எங்கள் பயிற்சிகளிலும் நாங்கள் பெறும் மிகவும் சுவாரஸ்யமான கேள்விகளைக் கொண்ட வழக்கமான பத்தி இது. குபெர்னெட்ஸ் நிபுணர் பதிலளிக்கிறார்.

இன்றைய நிபுணர் டேனியல் பொலென்சிக் (டேனியல் போலென்சிக்) டேனியல் பயிற்றுவிப்பாளராகவும் மென்பொருள் உருவாக்குநராகவும் பணியாற்றுகிறார் Learnk8s.

உங்கள் கேள்விக்கு அடுத்த பதிவில் பதில் கிடைக்க வேண்டுமானால், மின்னஞ்சல் மூலம் எங்களை தொடர்பு கொள்ளவும் அல்லது Twitter: @learnk8s.

முந்தைய பதிவுகள் தவறவிட்டதா? அவற்றை இங்கே கண்டுபிடி.

வெவ்வேறு தரவு மையங்களில் குபெர்னெட்ஸ் கிளஸ்டர்களை எவ்வாறு இணைப்பது?

சுருக்கமாக: Kubefed v2 விரைவில், மற்றும் பற்றி படிக்கவும் பரிந்துரைக்கிறேன் ஏற்றுமதி செய்பவர் и பல-கிளஸ்டர்-திட்டமிடல் திட்டம்.

பெரும்பாலும், உள்கட்டமைப்பு பல்வேறு பகுதிகளில், குறிப்பாக கட்டுப்படுத்தப்பட்ட சூழல்களில் நகலெடுக்கப்பட்டு விநியோகிக்கப்படுகிறது.

ஒரு பகுதி கிடைக்கவில்லை என்றால், குறுக்கீடுகளைத் தவிர்க்க போக்குவரத்து மற்றொரு பகுதிக்கு திருப்பி விடப்படும்.

Kubernetes மூலம், நீங்கள் இதேபோன்ற உத்தியைப் பயன்படுத்தலாம் மற்றும் வெவ்வேறு பிராந்தியங்களில் பணிச்சுமைகளை விநியோகிக்கலாம்.

ஒரு குழு, பகுதி, சூழல் அல்லது இந்த உறுப்புகளின் கலவையில் ஒன்று அல்லது அதற்கு மேற்பட்ட கிளஸ்டர்களை நீங்கள் வைத்திருக்கலாம்.

உங்கள் கிளஸ்டர்களை வெவ்வேறு மேகங்கள் மற்றும் வளாகத்தில் ஹோஸ்ட் செய்யலாம்.

ஆனால் அத்தகைய புவியியல் பரவலுக்கான உள்கட்டமைப்பை எவ்வாறு திட்டமிடுகிறீர்கள்?
ஒரே நெட்வொர்க்கில் பல கிளவுட் சூழல்களுக்கு ஒரு பெரிய கிளஸ்டரை உருவாக்க வேண்டுமா?
அல்லது பல சிறிய க்ளஸ்டர்கள் உள்ளதா மற்றும் அவற்றைக் கட்டுப்படுத்தவும் ஒத்திசைக்கவும் வழி கண்டுபிடிக்க வேண்டுமா?

ஒரு தலைமைக் குழு

ஒரே நெட்வொர்க்கில் ஒரு கிளஸ்டரை உருவாக்குவது அவ்வளவு எளிதானது அல்ல.

உங்களுக்கு விபத்து ஏற்பட்டுள்ளதாக கற்பனை செய்து பாருங்கள், கிளஸ்டர் பிரிவுகளுக்கு இடையேயான இணைப்பு துண்டிக்கப்பட்டது.

உங்களிடம் ஒரு முதன்மை சேவையகம் இருந்தால், பாதி ஆதாரங்கள் புதிய கட்டளைகளைப் பெற முடியாது, ஏனெனில் அவர்களால் மாஸ்டரைத் தொடர்பு கொள்ள முடியாது.

அதே நேரத்தில் உங்களிடம் பழைய ரூட்டிங் அட்டவணைகள் உள்ளன (kube-proxy புதியவற்றைப் பதிவிறக்க முடியாது) மேலும் கூடுதல் காய்கள் இல்லை (குபெலெட் புதுப்பிப்புகளைக் கோர முடியாது).

நிலைமையை மோசமாக்க, குபெர்னெட்டஸ் ஒரு முனையைப் பார்க்கவில்லை என்றால், அது அனாதை எனக் குறிக்கும் மற்றும் காணாமல் போன காய்களை ஏற்கனவே உள்ள முனைகளுக்கு விநியோகம் செய்கிறது.

இதன் விளைவாக, உங்களிடம் இரண்டு மடங்கு காய்கள் உள்ளன.

ஒவ்வொரு பிராந்தியத்திற்கும் ஒரு முதன்மை சேவையகத்தை உருவாக்கினால், etcd தரவுத்தளத்தில் ஒருமித்த அல்காரிதத்தில் சிக்கல்கள் இருக்கும். (தோராயமாக எட். — உண்மையில், etcd தரவுத்தளமானது முதன்மை சேவையகங்களில் இருக்க வேண்டிய அவசியமில்லை. ஒரே பிராந்தியத்தில் உள்ள ஒரு தனி குழு சேவையகங்களில் இதை இயக்கலாம். உண்மை, அதே நேரத்தில் கிளஸ்டரின் தோல்வியின் ஒரு புள்ளியைப் பெறுகிறது. ஆனால் விரைவாக.)

etcd பயன்படுத்துகிறது ராஃப்ட் அல்காரிதம்மதிப்பை வட்டில் எழுதுவதற்கு முன் பேச்சுவார்த்தை நடத்த.
அதாவது, மாநிலத்தை etcdக்கு எழுதுவதற்கு முன், பெரும்பாலான நிகழ்வுகள் ஒருமித்த கருத்தை எட்ட வேண்டும்.

வெவ்வேறு பகுதிகளில் உள்ள மூன்று etcd நிகழ்வுகளைப் போலவே, etcd நிகழ்வுகளுக்கு இடையிலான தாமதம் வியத்தகு முறையில் அதிகரித்தால், ஒரு மதிப்பை பேச்சுவார்த்தை நடத்தி வட்டில் எழுதுவதற்கு நீண்ட நேரம் எடுக்கும்.
இது குபெர்னெட்ஸ் கட்டுப்படுத்திகளில் பிரதிபலிக்கிறது.

கட்டுப்பாட்டு மேலாளருக்கு மாற்றத்தைப் பற்றி அறிந்து கொள்ளவும், தரவுத்தளத்திற்கு பதிலை எழுதவும் அதிக நேரம் தேவைப்படுகிறது.

ஒரு கட்டுப்படுத்தி இல்லை, ஆனால் பல, ஒரு சங்கிலி எதிர்வினை விளைகிறது மற்றும் முழு கிளஸ்டரும் மிக மெதுவாக வேலை செய்யத் தொடங்குகிறது.

etcd மிகவும் தாமதமாக உணர்திறன் கொண்டது வழக்கமான ஹார்டு டிரைவ்களுக்குப் பதிலாக SSDகளைப் பயன்படுத்த அதிகாரப்பூர்வ ஆவணங்கள் பரிந்துரைக்கின்றன.

ஒரு கிளஸ்டருக்கான பெரிய நெட்வொர்க்கிற்கான சிறந்த எடுத்துக்காட்டுகள் எதுவும் தற்போது இல்லை.

அடிப்படையில், டெவலப்பர் சமூகமும் SIG-கிளஸ்டர் குழுவும் குபெர்னெட்டஸ் கன்டெய்னர்களை ஆர்கெஸ்ட்ரேட் செய்வது போல் கிளஸ்டர்களை எவ்வாறு ஒழுங்கமைப்பது என்பதைக் கண்டுபிடிக்க முயற்சிக்கின்றனர்.

விருப்பம் 1: kubefed உடன் கிளஸ்டர் கூட்டமைப்பு

SIG-கிளஸ்டரிடமிருந்து அதிகாரப்பூர்வ பதில் - kubefed2, அசல் kube ஃபெடரேஷன் கிளையன்ட் மற்றும் ஆபரேட்டரின் புதிய பதிப்பு.

முதன்முறையாக, குபே ஃபெடரேஷன் கருவியைப் பயன்படுத்தி கிளஸ்டர்களின் தொகுப்பை ஒரே பொருளாக நிர்வகிக்க முயற்சித்தோம்.

ஆரம்பம் நன்றாக இருந்தது, ஆனால் இறுதியில் குபே கூட்டமைப்பு பிரபலமாகவில்லை, ஏனெனில் அது அனைத்து வளங்களையும் ஆதரிக்கவில்லை.

இது ஃபெடரேட் டெலிவரிகள் மற்றும் சேவைகளை ஆதரித்தது, எடுத்துக்காட்டாக, StatefulSets அல்ல.
மேலும், கூட்டமைப்பு உள்ளமைவு சிறுகுறிப்புகளின் வடிவத்தில் அனுப்பப்பட்டது மற்றும் நெகிழ்வானதாக இல்லை.

சிறுகுறிப்புகளைப் பயன்படுத்தி ஒரு கூட்டமைப்பில் உள்ள ஒவ்வொரு கிளஸ்டருக்கான பிரதி பகிர்வை நீங்கள் எவ்வாறு விவரிக்கலாம் என்று கற்பனை செய்து பாருங்கள்.

இது ஒரு முழுமையான குழப்பமாக இருந்தது.

SIG-cluster kubefed v1 க்குப் பிறகு நிறைய வேலைகளைச் செய்தது மற்றும் சிக்கலை வேறு கோணத்தில் அணுக முடிவு செய்தது.

சிறுகுறிப்புகளுக்குப் பதிலாக, கிளஸ்டர்களில் நிறுவப்பட்ட ஒரு கட்டுப்படுத்தியை வெளியிட முடிவு செய்தனர். தனிப்பயன் வள வரையறைகளை (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 பற்றிய அதிகாரப்பூர்வ கட்டுரை குபெர்னெட்ஸ் மற்றும் இன் பற்றிய வலைப்பதிவில் குபெஃபெட் திட்டத்தின் அதிகாரப்பூர்வ களஞ்சியம்.

விருப்பம் 2: Booking.com பாணியில் கிளஸ்டர்களை இணைத்தல்

Booking.com இன் டெவலப்பர்கள் kubefed v2 இல் வேலை செய்யவில்லை, ஆனால் அவர்கள் ஷிப்பரைக் கொண்டு வந்தனர் - பல கிளஸ்டர்களில், பல பிராந்தியங்களில் மற்றும் பல மேகங்களில் டெலிவரி செய்வதற்கான ஒரு ஆபரேட்டர்.

ஏற்றுமதி செய்பவர் kubefed2 ஐப் போன்றது.

இரண்டு கருவிகளும் உங்கள் மல்டி-கிளஸ்டர் வரிசைப்படுத்தல் உத்தியைத் தனிப்பயனாக்க அனுமதிக்கின்றன (எந்த கிளஸ்டர்கள் பயன்படுத்தப்படுகின்றன மற்றும் அவற்றில் எத்தனை பிரதிகள் உள்ளன).

ஆயினும் விநியோகத்தின் போது ஏற்படும் பிழைகளின் அபாயத்தைக் குறைப்பதே ஷிப்பரின் குறிக்கோள்.

ஷிப்பரில், முந்தைய மற்றும் தற்போதைய வரிசைப்படுத்தல் மற்றும் உள்வரும் போக்குவரத்தின் அளவு ஆகியவற்றுக்கு இடையேயான பிரதிகளின் பிரிவை விவரிக்கும் தொடர் படிகளை நீங்கள் வரையறுக்கலாம்.

நீங்கள் ஒரு வளத்தை ஒரு கிளஸ்டருக்குத் தள்ளும்போது, ஷிப்பர் கன்ட்ரோலர் அந்த மாற்றத்தை இணைக்கப்பட்ட அனைத்து கிளஸ்டர்களிலும் அதிகரிக்கும்.

மேலும், ஷிப்பர் மிகவும் குறைவாக உள்ளது.

உதாரணமாக, இது ஹெல்ம் விளக்கப்படங்களை உள்ளீடாக ஏற்றுக்கொள்கிறது மற்றும் வெண்ணிலா வளங்களை ஆதரிக்காது.
பொதுவாக, ஷிப்பர் இப்படித்தான் செயல்படுகிறார்.

நிலையான விநியோகத்திற்குப் பதிலாக, ஹெல்ம் விளக்கப்படத்தை உள்ளடக்கிய பயன்பாட்டு ஆதாரத்தை நீங்கள் உருவாக்க வேண்டும்:

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

பல கிளஸ்டர்களை நிர்வகிப்பதற்கு ஷிப்பர் ஒரு நல்ல வழி, ஆனால் ஹெல்முடனான அதன் நெருங்கிய உறவு மட்டுமே வழியில் வருகிறது.

நாம் அனைவரும் ஹெல்மில் இருந்து மாறினால் என்ன ஆகும் தனிப்பயனாக்கலாம் அல்லது kapitan?

ஷிப்பர் மற்றும் அதன் தத்துவம் பற்றி மேலும் அறிக இந்த அதிகாரப்பூர்வ செய்திக்குறிப்பு.

நீங்கள் குறியீட்டை தோண்டி எடுக்க விரும்பினால், அதிகாரப்பூர்வ திட்ட களஞ்சியத்திற்குச் செல்லவும்.

விருப்பம் 3: "மேஜிக்" கிளஸ்டர் இணைத்தல்

Kubefed v2 மற்றும் Shipper ஆகியவை கிளஸ்டர் கூட்டமைப்புடன் இணைந்து செயல்படுகின்றன, தனிப்பயன் வள வரையறை மூலம் கிளஸ்டர்களுக்கு புதிய ஆதாரங்களை வழங்குகின்றன.

ஆனால் நீங்கள் அனைத்து டெலிவரிகள், ஸ்டேட்ஃபுல்செட்ஸ், டெமான்செட்ஸ் போன்றவற்றை ஒன்றிணைக்க மீண்டும் எழுத விரும்பவில்லை என்றால் என்ன செய்வது?

YAML ஐ மாற்றாமல் ஏற்கனவே உள்ள கிளஸ்டரை ஒரு கூட்டமைப்பில் சேர்ப்பது எப்படி?

பல-கிளஸ்டர்-திட்டமிடல் என்பது ஒரு அட்மிராலிட்டி திட்டமாகும், இது கிளஸ்டர்களில் பணிச்சுமைகளை திட்டமிடுவதைக் கையாள்கிறது.

ஆனால் தனிப்பயன் வரையறைகளில் க்ளஸ்டருடன் தொடர்புகொள்வதற்கும் வளங்களை மூடுவதற்கும் ஒரு புதிய வழியைக் கொண்டு வருவதற்குப் பதிலாக, மல்டி-கிளஸ்டர்-திட்டமிடல் நிலையான குபெர்னெட்ஸ் வாழ்க்கைச் சுழற்சியில் உட்பொதிக்கப்பட்டு, காய்களை உருவாக்கும் அனைத்து அழைப்புகளையும் இடைமறிக்கும்.

உருவாக்கப்பட்ட ஒவ்வொரு நெற்றும் உடனடியாக ஒரு போலி மூலம் மாற்றப்படும்.

பல-கிளஸ்டர்-திட்டமிடல் பயன்படுத்துகிறது அணுகல் மாற்றத்திற்கான webhooksஅழைப்பை இடைமறித்து, செயலற்ற போலி பாட் ஒன்றை உருவாக்கவும்.

அசல் பாட் மற்றொரு திட்டமிடல் சுழற்சியில் செல்கிறது, அங்கு முழு கூட்டமைப்பையும் வாக்களித்த பிறகு, ஒரு வேலை வாய்ப்பு முடிவு எடுக்கப்படுகிறது.

இறுதியாக, நெற்று இலக்கு கிளஸ்டருக்கு வழங்கப்படுகிறது.

இதன் விளைவாக, உங்களிடம் கூடுதல் பாட் உள்ளது, அது எதையும் செய்யாது, இடத்தை எடுத்துக்கொள்கிறது.

சப்ளைகளை இணைக்க நீங்கள் புதிய ஆதாரங்களை எழுத வேண்டியதில்லை என்பதே இதன் நன்மை.

ஒரு பாட் உருவாக்கும் ஒவ்வொரு வளமும் தானாக ஒன்றிணைக்க தயாராக இருக்கும்.

இது சுவாரஸ்யமானது, ஏனென்றால் திடீரென்று நீங்கள் பல பிராந்தியங்களில் விநியோகிக்கப்பட்டுள்ளீர்கள், மேலும் நீங்கள் கவனிக்கவில்லை. இருப்பினும், இது மிகவும் ஆபத்தானது, ஏனென்றால் இங்கே எல்லாம் மந்திரத்தில் உள்ளது.

ஆனால் ஷிப்பர் டெலிவரிகளின் தாக்கத்தை குறைக்க முயற்சிக்கும்போது, மல்டி-கிளஸ்டர்-திட்டமிடல் மிகவும் பொதுவான பணிகளைக் கையாளுகிறது மற்றும் தொகுதி வேலைகளுக்கு மிகவும் பொருத்தமானது.

இது மேம்பட்ட படிப்படியான விநியோக பொறிமுறையைக் கொண்டிருக்கவில்லை.

மல்டி-கிளஸ்டர்-திட்டமிடுபவர் பற்றி மேலும் காணலாம் அதிகாரப்பூர்வ களஞ்சிய பக்கம்.

செயல்பாட்டில் உள்ள பல-கிளஸ்டர்-திட்டமிடுதலைப் பற்றி நீங்கள் படிக்க விரும்பினால், அட்மிரால்டி உள்ளது ஆர்கோவுடன் சுவாரஸ்யமான பயன்பாட்டு வழக்கு - பணிப்பாய்வுகள், நிகழ்வுகள், CI மற்றும் CD Kubernetes.

பிற கருவிகள் மற்றும் தீர்வுகள்

பல கிளஸ்டர்களை இணைத்தல் மற்றும் நிர்வகிப்பது ஒரு சிக்கலான பணியாகும், மேலும் உலகளாவிய தீர்வு எதுவும் இல்லை.

இந்த தலைப்பை நீங்கள் மேலும் ஆராய விரும்பினால், இங்கே சில ஆதாரங்கள் உள்ளன:

ராஞ்சர் மூலம் நீர்மூழ்கிக் கப்பல் பல்வேறு குபெர்னெட்ஸ் கிளஸ்டர்களின் மேலடுக்கு நெட்வொர்க்குகளை இணைக்கும் ஒரு கருவியாகும்.
சில்லறை சங்கிலி இலக்கு பயன்பாடுகள் யூனிமேட்ரிக்ஸ் ஸ்பின்னேக்கருடன் இணைந்து பல கிளஸ்டர்களில் வரிசைப்படுத்தலைத் திட்டமிடுகிறது.
IPV6 ஐப் பயன்படுத்தி முயற்சிக்கவும் பல பிராந்தியங்களில் ஒரே நெட்வொர்க்.
எடுத்துக்காட்டாக, நீங்கள் ஒரு சேவை கண்ணியைப் பயன்படுத்தலாம் பல கிளஸ்டர்களை இணைப்பதற்கான இஸ்டியோ.
Cilium, ஒரு கொள்கலன் நெட்வொர்க் இடைமுக செருகுநிரல், வழங்குகிறது கிளஸ்டர் மெஷ் செயல்பாடு, இது பல கிளஸ்டர்களை இணைக்க உங்களை அனுமதிக்கிறது

இன்னைக்கு அவ்வளவுதான்

இறுதிவரை படித்ததற்கு நன்றி!

பல கிளஸ்டர்களை எவ்வாறு திறமையாக இணைப்பது என்பது உங்களுக்குத் தெரிந்தால், எங்களிடம் சொல்.

உங்கள் முறையை இணைப்புகளில் சேர்ப்போம்.

கிறிஸ் நெஸ்பிட்-ஸ்மித்துக்கு சிறப்பு நன்றி (கிறிஸ் நெஸ்பிட்-ஸ்மித்) மற்றும் வின்சென்ட் டி ஸ்மே (வின்சென்ட் டி ஸ்மெட்) (நம்பகப் பொறியாளர் swatmobile.io) கட்டுரையைப் படித்து, கூட்டமைப்பு எவ்வாறு செயல்படுகிறது என்பதைப் பற்றிய பயனுள்ள தகவல்களைப் பகிர்வதற்கு.

ஆதாரம்: www.habr.com

வெவ்வேறு தரவு மையங்களில் Kubernetes கிளஸ்டர்களை எவ்வாறு இணைப்பது