కుబెర్నెట్స్‌లో నెట్‌వర్కింగ్ కోసం కాలికో: పరిచయం మరియు కొద్దిగా అనుభవం

కుబెర్నెట్స్‌లో నెట్‌వర్కింగ్ మరియు మేనేజ్‌మెంట్ నెట్‌వర్క్ విధానాల యొక్క ప్రాథమికాలను రీడర్‌కు పరిచయం చేయడం, అలాగే ప్రామాణిక సామర్థ్యాలను విస్తరించే థర్డ్-పార్టీ కాలికో ప్లగ్ఇన్‌ను పరిచయం చేయడం కథనం యొక్క ఉద్దేశ్యం. అలాగే, కాన్ఫిగరేషన్ యొక్క సౌలభ్యం మరియు కొన్ని ఫీచర్లు మా ఆపరేటింగ్ అనుభవం నుండి నిజమైన ఉదాహరణలను ఉపయోగించి ప్రదర్శించబడతాయి.

కుబెర్నెటెస్ నెట్‌వర్కింగ్ ఉపకరణానికి శీఘ్ర పరిచయం

నెట్‌వర్క్ లేకుండా కుబెర్నెట్స్ క్లస్టర్‌ను ఊహించలేము. మేము ఇప్పటికే వాటి ప్రాథమిక విషయాలపై విషయాలను ప్రచురించాము: "కుబెర్నెటెస్‌లో నెట్‌వర్కింగ్‌కు ఇలస్ట్రేటెడ్ గైడ్"మరియు"సెక్యూరిటీ ప్రొఫెషనల్స్ కోసం కుబెర్నెట్స్ నెట్‌వర్క్ పాలసీలకు ఒక పరిచయం".

ఈ కథనం సందర్భంలో, కంటైనర్లు మరియు నోడ్‌ల మధ్య నెట్‌వర్క్ కనెక్టివిటీకి K8s బాధ్యత వహించదని గమనించడం ముఖ్యం: దీని కోసం, వివిధ CNI ప్లగిన్‌లు (కంటైనర్ నెట్‌వర్కింగ్ ఇంటర్‌ఫేస్). మేము ఈ భావన గురించి మరింత వారు కూడా నాకు చెప్పారు.

ఉదాహరణకు, ఈ ప్లగిన్‌లలో అత్యంత సాధారణమైనది ఒక దినుసు సన్నకంబళి — ప్రతి నోడ్‌పై వంతెనలను పెంచడం ద్వారా, దానికి సబ్‌నెట్‌ను కేటాయించడం ద్వారా అన్ని క్లస్టర్ నోడ్‌ల మధ్య పూర్తి నెట్‌వర్క్ కనెక్టివిటీని అందిస్తుంది. అయినప్పటికీ, పూర్తి మరియు క్రమబద్ధీకరించబడని ప్రాప్యత ఎల్లప్పుడూ ప్రయోజనకరంగా ఉండదు. క్లస్టర్‌లో కొంత రకమైన కనీస ఐసోలేషన్‌ను అందించడానికి, ఫైర్‌వాల్ యొక్క కాన్ఫిగరేషన్‌లో జోక్యం చేసుకోవడం అవసరం. సాధారణ సందర్భంలో, ఇది అదే CNI నియంత్రణలో ఉంచబడుతుంది, అందుకే iptablesలో ఏదైనా మూడవ పక్షం జోక్యాలను తప్పుగా అర్థం చేసుకోవచ్చు లేదా పూర్తిగా విస్మరించవచ్చు.

మరియు కుబెర్నెటెస్ క్లస్టర్‌లో నెట్‌వర్క్ పాలసీ మేనేజ్‌మెంట్ నిర్వహించడం కోసం “అవుట్ ఆఫ్ ది బాక్స్” అందించబడింది నెట్‌వర్క్ పాలసీ API. ఎంచుకున్న నేమ్‌స్పేస్‌లలో పంపిణీ చేయబడిన ఈ వనరు, ఒక అప్లికేషన్ నుండి మరొక యాప్‌కి యాక్సెస్‌ని వేరు చేయడానికి నియమాలను కలిగి ఉండవచ్చు. ఇది నిర్దిష్ట పాడ్‌లు, ఎన్విరాన్‌మెంట్‌లు (నేమ్‌స్పేస్‌లు) లేదా IP చిరునామాల బ్లాక్‌ల మధ్య యాక్సెసిబిలిటీని కాన్ఫిగర్ చేయడానికి కూడా మిమ్మల్ని అనుమతిస్తుంది:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

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

2 రకాల ట్రాఫిక్‌లు ఉన్నాయని తార్కికంగా ఉంది: పాడ్‌లోకి ప్రవేశించడం (ఇంగ్రెస్) మరియు దాని నుండి బయటకు వెళ్లడం (ఎగ్రెస్).

వాస్తవానికి, ఉద్యమ దిశ ఆధారంగా రాజకీయాలు ఈ 2 వర్గాలుగా విభజించబడ్డాయి.

తదుపరి అవసరమైన లక్షణం ఎంపిక సాధనం; నియమం ఎవరికి వర్తిస్తుంది. ఇది పాడ్ (లేదా పాడ్‌ల సమూహం) లేదా పర్యావరణం (అంటే నేమ్‌స్పేస్) కావచ్చు. ఒక ముఖ్యమైన వివరాలు: ఈ రెండు రకాల వస్తువులు తప్పనిసరిగా లేబుల్‌ని కలిగి ఉండాలి (లేబుల్ కుబెర్నెటెస్ పరిభాషలో) - ఇవి రాజకీయ నాయకులు పనిచేసేవి.

ఒక రకమైన లేబుల్‌తో ఏకీకృతమైన పరిమిత సంఖ్యలో సెలెక్టర్‌లతో పాటు, విభిన్న వైవిధ్యాలలో "అన్నిటినీ అనుమతించు/నిరాకరించు" వంటి నియమాలను వ్రాయడం సాధ్యమవుతుంది. ఈ ప్రయోజనం కోసం, ఫారమ్ యొక్క నిర్మాణాలు ఉపయోగించబడతాయి:

  podSelector: {}
  ingress: []
  policyTypes:
  - Ingress

- ఈ ఉదాహరణలో, పర్యావరణంలోని అన్ని పాడ్‌లు ఇన్‌కమింగ్ ట్రాఫిక్ నుండి నిరోధించబడ్డాయి. కింది నిర్మాణంతో వ్యతిరేక ప్రవర్తనను సాధించవచ్చు:

  podSelector: {}
  ingress:
  - {}
  policyTypes:
  - Ingress

అదేవిధంగా అవుట్‌గోయింగ్ కోసం:

  podSelector: {}
  policyTypes:
  - Egress

- దాన్ని ఆఫ్ చేయడానికి. మరియు ఏమి చేర్చాలో ఇక్కడ ఉంది:

  podSelector: {}
  egress:
  - {}
  policyTypes:
  - Egress

క్లస్టర్ కోసం CNI ప్లగ్ఇన్ ఎంపికకు తిరిగి రావడం, అది గమనించదగ్గ విషయం ప్రతి నెట్‌వర్క్ ప్లగిన్ నెట్‌వర్క్ పాలసీకి మద్దతు ఇవ్వదు. ఉదాహరణకు, ఇప్పటికే పేర్కొన్న Flannel నెట్‌వర్క్ విధానాలను ఎలా కాన్ఫిగర్ చేయాలో తెలియదు అది సూటిగా చెప్పబడింది అధికారిక రిపోజిటరీలో. ప్రత్యామ్నాయం కూడా అక్కడ ప్రస్తావించబడింది - ఓపెన్ సోర్స్ ప్రాజెక్ట్ కాలికో, ఇది నెట్‌వర్క్ విధానాల పరంగా కుబెర్నెట్స్ APIల ప్రామాణిక సెట్‌ను గణనీయంగా విస్తరిస్తుంది.

కాలికో: సిద్ధాంతాన్ని తెలుసుకోవడం

కాలికో ప్లగ్ఇన్‌ను ఫ్లాన్నెల్ (ఉపప్రాజెక్ట్.)తో ఏకీకరణలో ఉపయోగించవచ్చు కాలువ) లేదా స్వతంత్రంగా, నెట్‌వర్క్ కనెక్టివిటీ మరియు లభ్యత నిర్వహణ సామర్థ్యాలు రెండింటినీ కవర్ చేస్తుంది.

K8s “బాక్స్‌డ్” సొల్యూషన్ మరియు కాలికో నుండి API సెట్‌ని ఉపయోగించడం ఏ అవకాశాలను అందిస్తుంది?

నెట్‌వర్క్ పాలసీలో నిర్మించబడినవి ఇక్కడ ఉన్నాయి:

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

కాలికో ఈ ఫంక్షన్‌లను ఎలా విస్తరిస్తుందో ఇక్కడ ఉంది:

• విధానాలు ఏదైనా వస్తువుకు వర్తించవచ్చు: పాడ్, కంటైనర్, వర్చువల్ మెషీన్ లేదా ఇంటర్‌ఫేస్;
• నియమాలు నిర్దిష్ట చర్యను కలిగి ఉంటాయి (నిషేధం, అనుమతి, లాగింగ్);
• నియమాల లక్ష్యం లేదా మూలం పోర్ట్, పోర్ట్‌ల శ్రేణి, ప్రోటోకాల్‌లు, HTTP లేదా ICMP లక్షణాలు, IP లేదా సబ్‌నెట్ (4వ లేదా 6వ తరం), ఏదైనా సెలెక్టర్లు (నోడ్‌లు, హోస్ట్‌లు, ఎన్విరాన్‌మెంట్‌లు) కావచ్చు;
• అదనంగా, మీరు DNAT సెట్టింగ్‌లు మరియు ట్రాఫిక్ ఫార్వార్డింగ్ విధానాలను ఉపయోగించి ట్రాఫిక్ మార్గాన్ని నియంత్రించవచ్చు.

కాలికో రిపోజిటరీలో GitHubపై మొదటి కమిట్‌లు జూలై 2016 నాటివి, మరియు ఒక సంవత్సరం తర్వాత కుబెర్నెట్స్ నెట్‌వర్క్ కనెక్టివిటీని నిర్వహించడంలో ప్రాజెక్ట్ ప్రముఖ స్థానాన్ని ఆక్రమించింది - ఉదాహరణకు, సర్వే ఫలితాల ద్వారా, ది న్యూ స్టాక్ నిర్వహించింది:

K8లతో అనేక పెద్ద మేనేజ్డ్ సొల్యూషన్‌లు, వంటివి అమెజాన్ EKS, అజూర్ AKS, Google GKE మరియు ఇతరులు దీనిని ఉపయోగం కోసం సిఫార్సు చేయడం ప్రారంభించారు.

పనితీరు విషయానికొస్తే, ఇక్కడ ప్రతిదీ చాలా బాగుంది. వారి ఉత్పత్తిని పరీక్షించడంలో, కాలికో డెవలప్‌మెంట్ బృందం ఖగోళ పనితీరును ప్రదర్శించింది, సెకనుకు 50000 కంటైనర్‌ల సృష్టి రేటుతో 500 ఫిజికల్ నోడ్‌లపై 20 కంటే ఎక్కువ కంటైనర్‌లను నడుపుతోంది. స్కేలింగ్‌తో ఎలాంటి సమస్యలు గుర్తించబడలేదు. అటువంటి ఫలితాలు ప్రకటించారు ఇప్పటికే మొదటి వెర్షన్ యొక్క ప్రకటన వద్ద. నిర్గమాంశ మరియు వనరుల వినియోగంపై దృష్టి సారించే స్వతంత్ర అధ్యయనాలు కూడా కాలికో యొక్క పనితీరు ఫ్లాన్నెల్ వలె దాదాపుగా మంచిదని నిర్ధారించాయి. ఉదాహరణకు:

ప్రాజెక్ట్ చాలా త్వరగా అభివృద్ధి చెందుతోంది, ఇది K8s, OpenShift, OpenStack నిర్వహించబడే ప్రసిద్ధ పరిష్కారాలలో పనికి మద్దతు ఇస్తుంది, ఉపయోగించి క్లస్టర్‌ను అమలు చేసేటప్పుడు కాలికోను ఉపయోగించడం సాధ్యమవుతుంది కోప్స్, సర్వీస్ మెష్ నెట్‌వర్క్‌ల నిర్మాణానికి సూచనలు ఉన్నాయి (ఇక్కడ ఒక ఉదాహరణ ఉంది ఇస్టియోతో కలిపి ఉపయోగించబడుతుంది).

కాలికోతో ప్రాక్టీస్ చేయండి

వనిల్లా కుబెర్నెట్‌లను ఉపయోగించే సాధారణ సందర్భంలో, CNIని ఇన్‌స్టాల్ చేయడం ఫైల్‌ను ఉపయోగించడం వరకు వస్తుంది calico.yaml, అధికారిక వెబ్‌సైట్ నుండి డౌన్‌లోడ్ చేయబడింది, ఉపయోగించడం ద్వార kubectl apply -f.

నియమం ప్రకారం, ప్లగ్ఇన్ యొక్క ప్రస్తుత వెర్షన్ కుబెర్నెట్స్ యొక్క తాజా 2-3 సంస్కరణలకు అనుకూలంగా ఉంటుంది: పాత సంస్కరణల్లో ఆపరేషన్ పరీక్షించబడదు మరియు హామీ ఇవ్వబడదు. డెవలపర్‌ల ప్రకారం, iptables లేదా IPVS పైన CentOS 3.10, Ubuntu 7 లేదా Debian 16 రన్నింగ్ 8 కంటే ఎక్కువ ఉన్న Linux కెర్నల్‌లపై Calico రన్ అవుతుంది.

పర్యావరణం లోపల ఒంటరితనం

సాధారణ అవగాహన కోసం, కాలికో సంజ్ఞామానంలోని నెట్‌వర్క్ విధానాలు ప్రామాణిక వాటి నుండి ఎలా విభిన్నంగా ఉన్నాయో మరియు నియమాలను రూపొందించే విధానం వాటి రీడబిలిటీ మరియు కాన్ఫిగరేషన్ సౌలభ్యాన్ని ఎలా సులభతరం చేస్తుందో అర్థం చేసుకోవడానికి ఒక సాధారణ సందర్భాన్ని చూద్దాం:

క్లస్టర్‌లో 2 వెబ్ అప్లికేషన్‌లు ఉన్నాయి: Node.js మరియు PHPలో, వాటిలో ఒకటి Redisని ఉపయోగిస్తుంది. Node.jsతో కనెక్టివిటీని కొనసాగిస్తూనే, PHP నుండి Redisకి యాక్సెస్‌ను బ్లాక్ చేయడానికి, కింది విధానాన్ని వర్తింపజేయండి:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-redis-nodejs
spec:
  podSelector:
    matchLabels:
      service: redis
  ingress:
  - from:
    - podSelector:
        matchLabels:
          service: nodejs
    ports:
    - protocol: TCP
      port: 6379

ముఖ్యంగా మేము Node.js నుండి Redis పోర్ట్‌కి ఇన్‌కమింగ్ ట్రాఫిక్‌ను అనుమతించాము. మరియు వారు స్పష్టంగా మరేదైనా నిషేధించలేదు. NetworkPolicy కనిపించిన వెంటనే, అందులో పేర్కొనబడిన అన్ని సెలెక్టర్‌లు నిర్దేశించబడితే మినహా వేరుచేయబడటం ప్రారంభమవుతుంది. అయితే, సెలెక్టర్ కవర్ చేయని ఇతర వస్తువులకు ఐసోలేషన్ నియమాలు వర్తించవు.

ఉదాహరణ ఉపయోగిస్తుంది apiVersion కుబెర్నెట్స్ పెట్టె వెలుపల ఉంది, కానీ దానిని ఉపయోగించకుండా ఏదీ మిమ్మల్ని నిరోధించదు కాలికో డెలివరీ నుండి అదే పేరుతో ఉన్న వనరు. అక్కడ వాక్యనిర్మాణం మరింత వివరంగా ఉంది, కాబట్టి మీరు ఈ క్రింది రూపంలో పై కేసు కోసం నియమాన్ని తిరిగి వ్రాయవలసి ఉంటుంది:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-redis-nodejs
spec:
  selector: service == 'redis'
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: service == 'nodejs'
    destination:
      ports:
      - 6379

సాధారణ NetworkPolicy API ద్వారా మొత్తం ట్రాఫిక్‌ను అనుమతించడం లేదా తిరస్కరించడం కోసం పైన పేర్కొన్న నిర్మాణాలు అర్థం చేసుకోవడం మరియు గుర్తుంచుకోవడం కష్టంగా ఉండే కుండలీకరణాలతో కూడిన నిర్మాణాలను కలిగి ఉంటాయి. కాలికో విషయంలో, ఫైర్‌వాల్ నియమం యొక్క తర్కాన్ని వ్యతిరేకంగా మార్చడానికి, కేవలం మార్చండి action: Allow న action: Deny.

పర్యావరణం ద్వారా వేరుచేయడం

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

ప్రోమేతియస్, ఒక నియమం వలె, ఒక ప్రత్యేక సేవా వాతావరణంలో ఉంచబడింది - ఉదాహరణలో ఇది ఇలా నేమ్‌స్పేస్ అవుతుంది:

apiVersion: v1
kind: Namespace
metadata:
  labels:
    module: prometheus
  name: kube-prometheus

ఫీల్డ్ metadata.labels ఇది ప్రమాదం కాదని తేలింది. పైన పేర్కొన్న విధంగా, namespaceSelector (అలాగే podSelector) లేబుల్‌లతో పనిచేస్తుంది. అందువల్ల, నిర్దిష్ట పోర్ట్‌లోని అన్ని పాడ్‌ల నుండి కొలమానాలను తీసుకోవడానికి, మీరు ఒక రకమైన లేబుల్‌ను జోడించాలి (లేదా ఇప్పటికే ఉన్న వాటి నుండి తీసుకోవాలి), ఆపై వంటి కాన్ఫిగరేషన్‌ను వర్తింపజేయాలి:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          module: prometheus
    ports:
    - protocol: TCP
      port: 9100

మరియు మీరు కాలికో విధానాలను ఉపయోగిస్తే, సింటాక్స్ ఇలా ఉంటుంది:

apiVersion: crd.projectcalico.org/v1
kind: NetworkPolicy
metadata:
  name: allow-metrics-prom
spec:
  ingress:
  - action: Allow
    protocol: TCP
    source:
      namespaceSelector: module == 'prometheus'
    destination:
      ports:
      - 9100

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

కాలికో సృష్టికర్తల ప్రకారం, ఉత్తమమైన అభ్యాసం ఏమిటంటే, “ప్రతిదీ బ్లాక్ చేయండి మరియు మీకు కావాల్సిన వాటిని స్పష్టంగా తెరవండి” విధానం, దీనిలో డాక్యుమెంట్ చేయబడింది అధికారిక డాక్యుమెంటేషన్ (ఇతరులు ఇదే విధానాన్ని అనుసరిస్తారు - ముఖ్యంగా, లో ఇప్పటికే పేర్కొన్న వ్యాసం).

అదనపు కాలికో ఆబ్జెక్ట్‌లను ఉపయోగించడం

కాలికో APIల యొక్క విస్తరించిన సెట్ ద్వారా మీరు పాడ్‌లకే పరిమితం కాకుండా నోడ్‌ల లభ్యతను నియంత్రించవచ్చని నేను మీకు గుర్తు చేస్తున్నాను. ఉపయోగించి క్రింది ఉదాహరణలో GlobalNetworkPolicy క్లస్టర్‌లో ICMP అభ్యర్థనలను పాస్ చేసే సామర్థ్యం మూసివేయబడింది (ఉదాహరణకు, పాడ్ నుండి నోడ్‌కి, పాడ్‌ల మధ్య లేదా నోడ్ నుండి IP పాడ్‌కి పింగ్‌లు):

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: block-icmp
spec:
  order: 200
  selector: all()
  types:
  - Ingress
  - Egress
  ingress:
  - action: Deny
    protocol: ICMP
  egress:
  - action: Deny
    protocol: ICMP

పై సందర్భంలో, క్లస్టర్ నోడ్‌లు ICMP ద్వారా ఒకదానికొకటి "చేరుకోవడం" ఇప్పటికీ సాధ్యమే. మరియు ఈ సమస్య ద్వారా పరిష్కరించబడుతుంది GlobalNetworkPolicy, ఒక ఎంటిటీకి వర్తింపజేయబడింది HostEndpoint:

apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: deny-icmp-kube-02
spec:
  selector: "role == 'k8s-node'"
  order: 0
  ingress:
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow
    protocol: ICMP
---
apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: kube-02-eth0
  labels:
    role: k8s-node
spec:
  interfaceName: eth0
  node: kube-02
  expectedIPs: ["192.168.2.2"]

VPN కేసు

చివరగా, ఒక ప్రామాణిక సెట్ విధానాలు సరిపోనప్పుడు, క్లస్టర్ దగ్గరి ఇంటరాక్షన్ విషయంలో కాలికో ఫంక్షన్‌లను ఉపయోగించడం గురించి నేను చాలా నిజమైన ఉదాహరణ ఇస్తాను. వెబ్ అప్లికేషన్‌ను యాక్సెస్ చేయడానికి, క్లయింట్లు VPN టన్నెల్‌ను ఉపయోగిస్తారు మరియు ఈ యాక్సెస్ కఠినంగా నియంత్రించబడుతుంది మరియు ఉపయోగం కోసం అనుమతించబడిన నిర్దిష్ట సేవల జాబితాకు పరిమితం చేయబడింది:

క్లయింట్లు ప్రామాణిక UDP పోర్ట్ 1194 ద్వారా VPNకి కనెక్ట్ చేయబడతారు మరియు కనెక్ట్ అయినప్పుడు, పాడ్‌లు మరియు సేవల క్లస్టర్ సబ్‌నెట్‌లకు మార్గాలను అందుకుంటారు. పునఃప్రారంభాలు మరియు చిరునామా మార్పుల సమయంలో సేవలను కోల్పోకుండా మొత్తం సబ్‌నెట్‌లు నెట్టబడతాయి.

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

సాధ్యమయ్యే పరిష్కారాల ద్వారా శోధించిన ఫలితంగా, ఈ క్రిందివి ఎంపిక చేయబడ్డాయి:

1. VPNతో పాడ్‌లు ఒక్కో నోడ్‌కి షెడ్యూల్ చేయబడ్డాయి hostNetwork, అంటే, అసలు IPకి.
2. సేవ ద్వారా బయట పోస్ట్ చేయబడింది ClusterIP. నోడ్‌లో పోర్ట్ భౌతికంగా ఇన్‌స్టాల్ చేయబడింది, ఇది చిన్న రిజర్వేషన్‌లతో (నిజమైన IP చిరునామా యొక్క షరతులతో కూడిన ఉనికి) బయటి నుండి యాక్సెస్ చేయబడుతుంది.
3. పాడ్ రోజ్ ఏ నోడ్‌ని నిర్ణయించడం అనేది మా కథ యొక్క పరిధికి మించినది. మీరు సేవను నోడ్‌కి గట్టిగా "నెయిల్" చేయవచ్చని లేదా VPN సేవ యొక్క ప్రస్తుత IP చిరునామాను పర్యవేక్షించే మరియు క్లయింట్‌లతో నమోదు చేయబడిన DNS రికార్డులను సవరించే చిన్న సైడ్‌కార్ సేవను వ్రాయవచ్చని నేను చెప్తాను - ఎవరికైనా తగినంత ఊహ ఉంది.

రౌటింగ్ కోణం నుండి, VPN సర్వర్ ద్వారా జారీ చేయబడిన దాని IP చిరునామా ద్వారా మేము VPN క్లయింట్‌ను ప్రత్యేకంగా గుర్తించగలము. అటువంటి క్లయింట్ యొక్క సేవలకు యాక్సెస్‌ను పరిమితం చేయడానికి ఒక ఆదిమ ఉదాహరణ క్రింద ఉంది, పైన పేర్కొన్న Redisలో వివరించబడింది:

apiVersion: crd.projectcalico.org/v1
kind: HostEndpoint
metadata:
  name: vpnclient-eth0
  labels:
    role: vpnclient
    environment: production
spec:
  interfaceName: "*"
  node: kube-02
  expectedIPs: ["172.176.176.2"]
---
apiVersion: crd.projectcalico.org/v1
kind: GlobalNetworkPolicy
metadata:
  name: vpn-rules
spec:
  selector: "role == 'vpnclient'"
  order: 0
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    protocol: TCP
    destination:
      ports: [6379]
  - action: Allow
    protocol: UDP
    destination:
      ports: [53, 67]

ఇక్కడ, పోర్ట్ 6379 కి కనెక్ట్ చేయడం ఖచ్చితంగా నిషేధించబడింది, కానీ అదే సమయంలో DNS సేవ యొక్క ఆపరేషన్ భద్రపరచబడుతుంది, నియమాలను రూపొందించేటప్పుడు దీని పనితీరు చాలా తరచుగా బాధపడుతుంది. ఎందుకంటే, గతంలో పేర్కొన్నట్లుగా, సెలెక్టర్ కనిపించినప్పుడు, పేర్కొనకపోతే డిఫాల్ట్ తిరస్కరణ విధానం దానికి వర్తించబడుతుంది.

ఫలితాలు

అందువల్ల, కాలికో యొక్క అధునాతన APIని ఉపయోగించి, మీరు క్లస్టర్‌లో మరియు చుట్టుపక్కల రూటింగ్‌ను ఫ్లెక్సిబుల్‌గా కాన్ఫిగర్ చేయవచ్చు మరియు డైనమిక్‌గా మార్చవచ్చు. సాధారణంగా, దీని ఉపయోగం ఫిరంగితో పిచ్చుకలను కాల్చినట్లుగా కనిపిస్తుంది మరియు BGP మరియు IP-IP సొరంగాలతో L3 నెట్‌వర్క్‌ని అమలు చేయడం అనేది ఫ్లాట్ నెట్‌వర్క్‌లో సాధారణ కుబెర్నెట్స్ ఇన్‌స్టాలేషన్‌లో భయంకరంగా కనిపిస్తుంది... అయితే, ఈ సాధనం చాలా ఆచరణీయంగా మరియు ఉపయోగకరంగా కనిపిస్తుంది. .

భద్రతా అవసరాలకు అనుగుణంగా క్లస్టర్‌ను వేరుచేయడం ఎల్లప్పుడూ సాధ్యపడకపోవచ్చు మరియు ఇక్కడే కాలికో (లేదా ఇలాంటి పరిష్కారం) రెస్క్యూకి వస్తుంది. ఈ కథనంలో ఇవ్వబడిన ఉదాహరణలు (చిన్న మార్పులతో) AWSలోని మా క్లయింట్‌ల యొక్క అనేక ఇన్‌స్టాలేషన్‌లలో ఉపయోగించబడతాయి.

PS

మా బ్లాగులో కూడా చదవండి:

• «సెక్యూరిటీ ప్రొఫెషనల్స్ కోసం కుబెర్నెట్స్ నెట్‌వర్క్ పాలసీలకు ఒక పరిచయం";
• "కుబెర్నెట్స్‌లో నెట్‌వర్కింగ్‌కు ఇలస్ట్రేటెడ్ గైడ్": భాగాలు 1 మరియు 2 (నెట్‌వర్క్ మోడల్, ఓవర్‌లే నెట్‌వర్క్‌లు), పార్ట్ 3 (సేవలు మరియు ట్రాఫిక్ ప్రాసెసింగ్);
• «కంటైనర్ నెట్‌వర్కింగ్ ఇంటర్‌ఫేస్ (CNI) - నెట్‌వర్క్ ఇంటర్‌ఫేస్ మరియు Linux కంటైనర్‌లకు ప్రామాణికం".

మూలం: www.habr.com