🥇వివిధ డేటా సెంటర్లలో కుబెర్నెట్స్ క్లస్టర్‌లను ఎలా కనెక్ట్ చేయాలి

మా Kubernetes క్విక్ స్టార్ట్ సిరీస్‌కి స్వాగతం. ఇది ఆన్‌లైన్‌లో మరియు మా శిక్షణలలో మేము స్వీకరించే అత్యంత ఆసక్తికరమైన ప్రశ్నలతో కూడిన సాధారణ కాలమ్. కుబెర్నెటెస్ నిపుణుడు సమాధానాలు.

నేటి నిపుణుడు డేనియల్ పోలెన్‌చిక్ (డేనియల్ పోలెన్సిక్) డేనియల్ బోధకుడు మరియు సాఫ్ట్‌వేర్ డెవలపర్‌గా పనిచేస్తున్నారు లెర్క్8లు.

తదుపరి పోస్ట్‌లో మీ ప్రశ్నకు సమాధానం కావాలంటే, ఇమెయిల్ ద్వారా మమ్మల్ని సంప్రదించండి లేదా ట్విట్టర్: @learnk8s.

మునుపటి పోస్ట్‌లు మిస్ అయ్యాయా? వాటిని ఇక్కడ కనుగొనండి.

వివిధ డేటా సెంటర్లలో Kubernetes క్లస్టర్‌లను ఎలా కనెక్ట్ చేయాలి?

క్లుప్తంగా: Kubefed v2 త్వరలో వస్తుంది, మరియు నేను గురించి చదవమని కూడా సిఫార్సు చేస్తున్నాను ఎగుమతి и బహుళ-క్లస్టర్-షెడ్యూలర్ ప్రాజెక్ట్.

చాలా తరచుగా, అవస్థాపన వివిధ ప్రాంతాలలో ప్రత్యేకించి నియంత్రిత వాతావరణాలలో ప్రతిరూపం మరియు పంపిణీ చేయబడుతుంది.

ఒక ప్రాంతం అందుబాటులో లేకుంటే, అంతరాయాలను నివారించడానికి ట్రాఫిక్ మరొక ప్రాంతానికి దారి మళ్లించబడుతుంది.

కుబెర్నెట్స్‌తో, మీరు ఒకే విధమైన వ్యూహాన్ని ఉపయోగించవచ్చు మరియు వివిధ ప్రాంతాలలో పనిభారాన్ని పంపిణీ చేయవచ్చు.

మీరు ఒక్కో బృందం, ప్రాంతం, పర్యావరణం లేదా ఈ అంశాల కలయికకు ఒకటి లేదా అంతకంటే ఎక్కువ క్లస్టర్‌లను కలిగి ఉండవచ్చు.

మీ క్లస్టర్‌లను వేర్వేరు క్లౌడ్‌లలో మరియు ఆన్-ప్రిమిసెస్‌లో హోస్ట్ చేయవచ్చు.

అయితే అటువంటి భౌగోళిక విస్తరణ కోసం మీరు మౌలిక సదుపాయాలను ఎలా ప్లాన్ చేస్తారు?
మీరు ఒకే నెట్‌వర్క్‌లో అనేక క్లౌడ్ పరిసరాల కోసం ఒక పెద్ద క్లస్టర్‌ని సృష్టించాలా?
లేదా అనేక చిన్న సమూహాలను కలిగి ఉన్నారా మరియు వాటిని నియంత్రించడానికి మరియు సమకాలీకరించడానికి ఒక మార్గాన్ని కనుగొనాలా?

ఒక నాయకత్వ క్లస్టర్

ఒకే నెట్‌వర్క్‌లో ఒక క్లస్టర్‌ని సృష్టించడం అంత సులభం కాదు.

మీకు ప్రమాదం జరిగిందని ఊహించుకోండి, క్లస్టర్ విభాగాల మధ్య కనెక్టివిటీ పోతుంది.

మీకు ఒక మాస్టర్ సర్వర్ ఉన్నట్లయితే, సగం వనరులు కొత్త ఆదేశాలను స్వీకరించలేవు ఎందుకంటే వారు మాస్టర్‌ను సంప్రదించలేరు.

మరియు అదే సమయంలో మీకు పాత రూటింగ్ పట్టికలు ఉన్నాయి (kube-proxy కొత్త వాటిని డౌన్‌లోడ్ చేయడం సాధ్యం కాదు) మరియు అదనపు పాడ్‌లు లేవు (కుబెలెట్ అప్‌డేట్‌లను అభ్యర్థించదు).

విషయాలను మరింత దిగజార్చడానికి, కుబెర్నెటెస్‌కు నోడ్ కనిపించకపోతే, అది అనాథగా గుర్తించి, తప్పిపోయిన పాడ్‌లను ఇప్పటికే ఉన్న నోడ్‌లకు పంపిణీ చేస్తుంది.

ఫలితంగా, మీరు రెండు రెట్లు ఎక్కువ పాడ్‌లను కలిగి ఉంటారు.

మీరు ప్రతి ప్రాంతానికి ఒక మాస్టర్ సర్వర్‌ని చేస్తే, etcd డేటాబేస్‌లో ఏకాభిప్రాయ అల్గారిథమ్‌తో సమస్యలు ఉంటాయి. (సుమారు ed. — నిజానికి, etcd డేటాబేస్ తప్పనిసరిగా మాస్టర్ సర్వర్‌లలో ఉండవలసిన అవసరం లేదు. ఇది అదే ప్రాంతంలోని ప్రత్యేక సర్వర్‌ల సమూహంలో అమలు చేయబడుతుంది. నిజమే, అదే సమయంలో క్లస్టర్ యొక్క వైఫల్యం యొక్క పాయింట్ పొందడం. కానీ త్వరగా.)

etcd ఉపయోగాలు తెప్ప అల్గోరిథండిస్క్‌కి వ్రాసే ముందు విలువను చర్చించడానికి.
అంటే, రాష్ట్రాన్ని etcdకి వ్రాయడానికి ముందు చాలా సందర్భాలు ఏకాభిప్రాయానికి రావాలి.

వివిధ ప్రాంతాలలో మూడు etcd ఉదంతాల మాదిరిగానే etcd ఉదంతాల మధ్య జాప్యం నాటకీయంగా పెరిగితే, విలువను చర్చించి డిస్క్‌కి వ్రాయడానికి చాలా సమయం పడుతుంది.
ఇది Kubernetes కంట్రోలర్‌లలో ప్రతిబింబిస్తుంది.

కంట్రోలర్ మేనేజర్ మార్పు గురించి తెలుసుకోవడానికి మరియు డేటాబేస్కు ప్రతిస్పందనను వ్రాయడానికి మరింత సమయం కావాలి.

మరియు ఒక నియంత్రిక లేనందున, అనేకం, గొలుసు ప్రతిచర్య ఫలితాలు మరియు మొత్తం క్లస్టర్ చాలా నెమ్మదిగా పని చేయడం ప్రారంభిస్తుంది.

etcd చాలా జాప్యం సెన్సిటివ్ సాధారణ హార్డ్ డ్రైవ్‌లకు బదులుగా SSDలను ఉపయోగించాలని అధికారిక డాక్యుమెంటేషన్ సిఫార్సు చేస్తుంది.

ఒకే క్లస్టర్ కోసం పెద్ద నెట్‌వర్క్‌కు ప్రస్తుతం మంచి ఉదాహరణలు లేవు.

ప్రాథమికంగా, డెవలపర్ కమ్యూనిటీ మరియు SIG-క్లస్టర్ గ్రూప్ కుబెర్నెట్స్ కంటైనర్‌లను ఆర్కెస్ట్రేట్ చేసే విధంగా క్లస్టర్‌లను ఎలా ఆర్కెస్ట్రేట్ చేయాలో గుర్తించడానికి ప్రయత్నిస్తున్నాయి.

ఎంపిక 1: కుబేఫెడ్‌తో క్లస్టర్ ఫెడరేషన్

SIG-క్లస్టర్ నుండి అధికారిక ప్రతిస్పందన - kubefed2, అసలు kube ఫెడరేషన్ క్లయింట్ మరియు ఆపరేటర్ యొక్క కొత్త వెర్షన్.

మొదటిసారిగా, మేము kube ఫెడరేషన్ సాధనాన్ని ఉపయోగించి క్లస్టర్‌ల సేకరణను ఒకే వస్తువుగా నిర్వహించడానికి ప్రయత్నించాము.

ప్రారంభం బాగానే ఉంది, కానీ చివరికి కుబే ఫెడరేషన్ అన్ని వనరులకు మద్దతివ్వనందున ఎప్పుడూ ప్రజాదరణ పొందలేదు.

ఇది ఫెడరేటెడ్ డెలివరీలు మరియు సేవలకు మద్దతు ఇచ్చింది, ఉదాహరణకు స్టేట్‌ఫుల్‌సెట్‌లకు కాదు.
అలాగే, ఫెడరేషన్ కాన్ఫిగరేషన్ ఉల్లేఖనాల రూపంలో ప్రసారం చేయబడింది మరియు అనువైనది కాదు.

కేవలం ఉల్లేఖనాలను ఉపయోగించి ఫెడరేషన్‌లోని ప్రతి క్లస్టర్‌కు ప్రతిరూప విభజనను మీరు ఎలా వివరించగలరో ఊహించండి.

ఇది పూర్తిగా గందరగోళంగా ఉంది.

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 ప్రతిరూపాలను వెయిట్ చేయగల కొత్త రెప్లికాషెడ్యూలింగ్ ప్రాధాన్యత వస్తువును అందిస్తుంది:

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 గురించి అధికారిక కథనం కుబెర్నెటెస్ మరియు ఇన్ గురించి బ్లాగ్‌లో kubefed ప్రాజెక్ట్ యొక్క అధికారిక రిపోజిటరీ.

ఎంపిక 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

బహుళ క్లస్టర్‌లను నిర్వహించడానికి షిప్పర్ మంచి ఎంపిక, కానీ హెల్మ్‌తో దాని సన్నిహిత సంబంధం మాత్రమే దారిలోకి వస్తుంది.

మనమందరం హెల్మ్ నుండి మారితే ఎలా ఉంటుంది అనుకూలీకరించండి లేదా కెప్టెన్?

షిప్పర్ మరియు దాని తత్వశాస్త్రం గురించి మరింత తెలుసుకోండి ఈ అధికారిక పత్రికా ప్రకటన.

మీరు కోడ్‌ని తీయాలనుకుంటే, అధికారిక ప్రాజెక్ట్ రిపోజిటరీకి వెళ్లండి.

ఎంపిక 3: “మ్యాజిక్” క్లస్టర్ విలీనం

Kubefed v2 మరియు షిప్పర్ క్లస్టర్ ఫెడరేషన్‌తో పని చేస్తాయి, అనుకూల వనరుల నిర్వచనం ద్వారా క్లస్టర్‌లకు కొత్త వనరులను అందిస్తాయి.

కానీ మీరు విలీనం చేయడానికి అన్ని డెలివరీలు, స్టేట్‌ఫుల్‌సెట్‌లు, డెమన్‌సెట్‌లు మొదలైనవాటిని తిరిగి వ్రాయకూడదనుకుంటే ఏమి చేయాలి?

YAMLని మార్చకుండా ఇప్పటికే ఉన్న క్లస్టర్‌ని ఫెడరేషన్‌లో ఎలా చేర్చాలి?

బహుళ-క్లస్టర్-షెడ్యూలర్ అనేది అడ్మిరాలిటీ ప్రాజెక్ట్, ఇది క్లస్టర్‌లపై పనిభారాన్ని షెడ్యూల్ చేయడంతో వ్యవహరిస్తుంది.

కానీ క్లస్టర్‌తో పరస్పర చర్య చేయడానికి మరియు కస్టమ్ డెఫినిషన్‌లలో వనరులను చుట్టడానికి కొత్త మార్గంతో ముందుకు రావడానికి బదులుగా, బహుళ-క్లస్టర్-షెడ్యూలర్ ప్రామాణిక కుబెర్నెట్స్ జీవితచక్రంలో పొందుపరచబడింది మరియు పాడ్‌లను సృష్టించే అన్ని కాల్‌లను అడ్డగిస్తుంది.

ప్రతి సృష్టించిన పాడ్ వెంటనే డమ్మీతో భర్తీ చేయబడుతుంది.

బహుళ-క్లస్టర్-షెడ్యూలర్ ఉపయోగాలు యాక్సెస్ సవరణ కోసం webhooksకాల్‌ని అడ్డగించి, నిష్క్రియ డమ్మీ పాడ్‌ని సృష్టించడానికి.

ఒరిజినల్ పాడ్ మరొక ప్లానింగ్ సైకిల్ ద్వారా వెళుతుంది, మొత్తం ఫెడరేషన్‌ను పోలింగ్ చేసిన తర్వాత, ప్లేస్‌మెంట్ నిర్ణయం తీసుకోబడుతుంది.

చివరగా, పాడ్ టార్గెట్ క్లస్టర్‌కి పంపిణీ చేయబడుతుంది.

ఫలితంగా, మీకు అదనపు పాడ్ ఉంది, అది ఏమీ చేయదు, కేవలం స్థలాన్ని తీసుకుంటుంది.

ప్రయోజనం ఏమిటంటే, మీరు సరఫరాలను కలపడానికి కొత్త వనరులను వ్రాయవలసిన అవసరం లేదు.

పాడ్‌ను సృష్టించే ప్రతి వనరు స్వయంచాలకంగా విలీనం చేయడానికి సిద్ధంగా ఉంటుంది.

ఇది ఆసక్తికరంగా ఉంది, ఎందుకంటే మీరు అకస్మాత్తుగా అనేక ప్రాంతాలలో సరఫరా చేయబడి ఉన్నారు మరియు మీరు గమనించలేదు. అయితే, ఇది చాలా ప్రమాదకరం, ఎందుకంటే ఇక్కడ ప్రతిదీ మాయాజాలంపై ఆధారపడి ఉంటుంది.

షిప్పర్ డెలివరీల ప్రభావాన్ని తగ్గించడానికి ప్రయత్నిస్తున్నప్పుడు, బహుళ-క్లస్టర్-షెడ్యూలర్ మరింత సాధారణ పనులను నిర్వహిస్తుంది మరియు బ్యాచ్ ఉద్యోగాలకు బాగా సరిపోతుంది.

దీనికి అధునాతన క్రమమైన డెలివరీ మెకానిజం లేదు.

బహుళ-క్లస్టర్-షెడ్యూలర్ గురించి మరింత ఇక్కడ చూడవచ్చు అధికారిక రిపోజిటరీ పేజీ.

మీరు చర్యలో బహుళ-క్లస్టర్-షెడ్యూలర్ గురించి చదవాలనుకుంటే, అడ్మిరల్టీ ఉంది ఆర్గోతో ఆసక్తికరమైన ఉపయోగం - వర్క్‌ఫ్లోలు, ఈవెంట్‌లు, CI మరియు CD Kubernetes.

ఇతర సాధనాలు మరియు పరిష్కారాలు

బహుళ క్లస్టర్‌లను కనెక్ట్ చేయడం మరియు నిర్వహించడం సంక్లిష్టమైన పని మరియు సార్వత్రిక పరిష్కారం లేదు.

మీరు ఈ అంశాన్ని మరింత అన్వేషించాలనుకుంటే, ఇక్కడ కొన్ని వనరులు ఉన్నాయి:

రాంచర్ ద్వారా జలాంతర్గామి వివిధ కుబెర్నెట్స్ క్లస్టర్‌ల ఓవర్‌లే నెట్‌వర్క్‌లను కనెక్ట్ చేసే సాధనం.
రిటైల్ చైన్ టార్గెట్ ఉపయోగాలు యూనిమ్యాట్రిక్స్ స్పిన్నకర్‌తో కలిపి బహుళ క్లస్టర్‌లలో విస్తరణను ఆర్కెస్ట్రేట్ చేస్తుంది.
IPV6ని ఉపయోగించి ప్రయత్నించండి మరియు అనేక ప్రాంతాలలో ఒకే నెట్‌వర్క్.
మీరు సేవా మెష్‌ని ఉపయోగించవచ్చు, ఉదాహరణకు బహుళ క్లస్టర్‌లను కనెక్ట్ చేయడానికి ఇస్టియో.
Cilium, ఒక కంటైనర్ నెట్వర్క్ ఇంటర్ఫేస్ ప్లగ్ఇన్, ఆఫర్లు క్లస్టర్ మెష్ ఫంక్షన్, ఇది అనేక సమూహాలను కలపడానికి మిమ్మల్ని అనుమతిస్తుంది

నేటికీ అంతే

చివరి వరకు చదివినందుకు ధన్యవాదాలు!

బహుళ క్లస్టర్‌లను మరింత సమర్థవంతంగా ఎలా కనెక్ట్ చేయాలో మీకు తెలిస్తే, మాకు చెప్పండి.

మేము మీ పద్ధతిని లింక్‌లకు జోడిస్తాము.

క్రిస్ నెస్బిట్-స్మిత్‌కు ప్రత్యేక ధన్యవాదాలు (క్రిస్ నెస్బిట్-స్మిత్) మరియు విన్సెంట్ డి స్మే (విన్సెంట్ డి స్మెట్) (విశ్వసనీయత ఇంజనీర్ swatmobile.io) కథనాన్ని చదవడం మరియు ఫెడరేషన్ ఎలా పని చేస్తుందనే దాని గురించి ఉపయోగకరమైన సమాచారాన్ని పంచుకోవడం కోసం.

మూలం: www.habr.com

వివిధ డేటా సెంటర్లలో Kubernetes క్లస్టర్‌లను ఎలా కనెక్ట్ చేయాలి