குபெர்னெட்ஸில் நெட்வொர்க்கிங்கிற்கான காலிகோ: அறிமுகம் மற்றும் ஒரு சிறிய அனுபவம்

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

குபெர்னெட்ஸ் நெட்வொர்க்கிங் அப்ளையன்ஸுக்கு ஒரு விரைவான அறிமுகம்

நெட்வொர்க் இல்லாமல் ஒரு குபெர்னெட்ஸ் கிளஸ்டரை கற்பனை செய்து பார்க்க முடியாது. அவற்றின் அடிப்படைகள் குறித்த பொருட்களை நாங்கள் ஏற்கனவே வெளியிட்டுள்ளோம்: "குபெர்னெட்ஸில் நெட்வொர்க்கிங்கிற்கான விளக்கப்பட வழிகாட்டி"மேலும்"பாதுகாப்பு நிபுணர்களுக்கான குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகளுக்கு ஒரு அறிமுகம்".

இந்த கட்டுரையின் சூழலில், கொள்கலன்கள் மற்றும் முனைகளுக்கு இடையிலான பிணைய இணைப்புக்கு K8s பொறுப்பேற்காது என்பதை கவனத்தில் கொள்ள வேண்டும்: இதற்காக, பல்வேறு CNI செருகுநிரல்கள் (கன்டெய்னர் நெட்வொர்க்கிங் இன்டர்ஃபேஸ்). இந்த கருத்தை பற்றி மேலும் அவர்களும் என்னிடம் சொன்னார்கள்.

எடுத்துக்காட்டாக, இந்த செருகுநிரல்களில் மிகவும் பொதுவானது flannel — ஒவ்வொரு முனையிலும் பிரிட்ஜ்களை உயர்த்தி, அதற்கு ஒரு சப்நெட்டை ஒதுக்குவதன் மூலம் அனைத்து கிளஸ்டர் முனைகளுக்கும் இடையே முழு பிணைய இணைப்பை வழங்குகிறது. இருப்பினும், முழுமையான மற்றும் கட்டுப்பாடற்ற அணுகல் எப்போதும் பயனளிக்காது. கிளஸ்டரில் சில வகையான குறைந்தபட்ச தனிமைப்படுத்தலை வழங்க, ஃபயர்வாலின் கட்டமைப்பில் தலையிட வேண்டியது அவசியம். பொது வழக்கில், இது அதே CNI இன் கட்டுப்பாட்டின் கீழ் வைக்கப்படுகிறது, அதனால்தான் iptables இல் ஏதேனும் மூன்றாம் தரப்பு தலையீடுகள் தவறாக விளக்கப்படலாம் அல்லது முற்றிலும் புறக்கணிக்கப்படலாம்.

குபெர்னெட்ஸ் கிளஸ்டரில் நெட்வொர்க் கொள்கை நிர்வாகத்தை ஒழுங்கமைப்பதற்கான "அவுட் ஆஃப் தி பாக்ஸ்" வழங்கப்படுகிறது NetworkPolicy 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 செருகுநிரலின் தேர்வுக்குத் திரும்புவது, அது கவனிக்கத்தக்கது ஒவ்வொரு பிணைய சொருகியும் NetworkPolicy ஐ ஆதரிக்காது. எடுத்துக்காட்டாக, ஏற்கனவே குறிப்பிட்டுள்ள Flannel க்கு நெட்வொர்க் கொள்கைகளை எவ்வாறு கட்டமைப்பது என்று தெரியவில்லை நேரடியாக சொல்லப்படுகிறது அதிகாரப்பூர்வ களஞ்சியத்தில். ஒரு மாற்று அங்கு குறிப்பிடப்பட்டுள்ளது - ஒரு திறந்த மூல திட்டம் காலிகோ, இது நெட்வொர்க் கொள்கைகளின் அடிப்படையில் குபெர்னெட்ஸ் APIகளின் நிலையான தொகுப்பை கணிசமாக விரிவுபடுத்துகிறது.

காலிகோவைப் பற்றி தெரிந்துகொள்வது: கோட்பாடு

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

K8s "பாக்ஸ்டு" தீர்வு மற்றும் காலிகோவில் இருந்து API தொகுப்பைப் பயன்படுத்துவது என்ன வாய்ப்புகளை வழங்குகிறது?

நெட்வொர்க் பாலிசியில் கட்டமைக்கப்பட்டவை இதோ:

• அரசியல்வாதிகள் சுற்றுச்சூழலால் மட்டுப்படுத்தப்பட்டவர்கள்;
• லேபிள்களால் குறிக்கப்பட்ட காய்களுக்கு கொள்கைகள் பயன்படுத்தப்படுகின்றன;
• காய்கள், சூழல்கள் அல்லது சப்நெட்களுக்கு விதிகள் பயன்படுத்தப்படலாம்;
• விதிகளில் நெறிமுறைகள், பெயரிடப்பட்ட அல்லது குறியீட்டு போர்ட் விவரக்குறிப்புகள் இருக்கலாம்.

இந்த செயல்பாடுகளை காலிகோ எவ்வாறு நீட்டிக்கிறது என்பது இங்கே:

• கொள்கைகள் எந்தவொரு பொருளுக்கும் பயன்படுத்தப்படலாம்: பாட், கொள்கலன், மெய்நிகர் இயந்திரம் அல்லது இடைமுகம்;
• விதிகள் ஒரு குறிப்பிட்ட செயலைக் கொண்டிருக்கலாம் (தடை, அனுமதி, பதிவு செய்தல்);
• விதிகளின் இலக்கு அல்லது மூலமானது ஒரு போர்ட், போர்ட்களின் வரம்பு, நெறிமுறைகள், HTTP அல்லது ICMP பண்புக்கூறுகள், IP அல்லது சப்நெட் (4வது அல்லது 6வது தலைமுறை), ஏதேனும் தேர்வாளர்கள் (முனைகள், ஹோஸ்ட்கள், சூழல்கள்);
• கூடுதலாக, டிஎன்ஏடி அமைப்புகள் மற்றும் ட்ராஃபிக் ஃபார்வர்டிங் கொள்கைகளைப் பயன்படுத்தி போக்குவரத்தை நீங்கள் கட்டுப்படுத்தலாம்.

காலிகோ களஞ்சியத்தில் உள்ள GitHub இல் முதன்முதலில் 2016 ஆம் ஆண்டு ஜூலை மாதம் தொடங்கப்பட்டது, மேலும் ஒரு வருடம் கழித்து இந்த திட்டம் குபெர்னெட்ஸ் நெட்வொர்க் இணைப்பை ஒழுங்கமைப்பதில் முன்னணி இடத்தைப் பிடித்தது - இது சாட்சியமாக உள்ளது, எடுத்துக்காட்டாக, கணக்கெடுப்பு முடிவுகள், தி நியூ ஸ்டாக் நடத்தியது:

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

செயல்திறனைப் பொறுத்தவரை, இங்கே எல்லாம் நன்றாக இருக்கிறது. அவர்களின் தயாரிப்பைச் சோதித்ததில், காலிகோ டெவலப்மென்ட் குழுவானது வானியல் செயல்திறனை நிரூபித்தது, 50000 இயற்பியல் முனைகளில் 500 க்கும் மேற்பட்ட கொள்கலன்களை வினாடிக்கு 20 கொள்கலன்கள் உருவாக்க விகிதத்துடன் இயக்கியது. அளவிடுதலில் எந்த பிரச்சனையும் கண்டறியப்படவில்லை. அத்தகைய முடிவுகள் அறிவிக்கப்பட்டன ஏற்கனவே முதல் பதிப்பின் அறிவிப்பில். செயல்திறன் மற்றும் வள நுகர்வு ஆகியவற்றில் கவனம் செலுத்தும் சுயாதீன ஆய்வுகள் காலிகோவின் செயல்திறன் Flannel இன் செயல்திறன் போலவே இருப்பதை உறுதிப்படுத்துகிறது. உதாரணமாக:

திட்டம் மிக விரைவாக உருவாகி வருகிறது, இது K8s, OpenShift, OpenStack நிர்வகிக்கப்படும் பிரபலமான தீர்வுகளில் வேலையை ஆதரிக்கிறது, ஒரு கிளஸ்டரைப் பயன்படுத்தும்போது காலிகோவைப் பயன்படுத்த முடியும் உதை, சர்வீஸ் மெஷ் நெட்வொர்க்குகளின் கட்டுமானம் பற்றிய குறிப்புகள் உள்ளன (இங்கே ஒரு உதாரணம் இஸ்டியோவுடன் இணைந்து பயன்படுத்தப்படுகிறது).

காலிகோவுடன் பயிற்சி செய்யுங்கள்

வெண்ணிலா குபெர்னெட்ஸைப் பயன்படுத்தும் பொதுவான வழக்கில், CNI ஐ நிறுவுவது கோப்பைப் பயன்படுத்துகிறது calico.yaml, அதிகாரப்பூர்வ இணையதளத்தில் இருந்து பதிவிறக்கம் செய்யப்பட்டது, பயன்படுத்தி kubectl apply -f.

ஒரு விதியாக, சொருகி தற்போதைய பதிப்பு குபெர்னெட்ஸின் சமீபத்திய 2-3 பதிப்புகளுடன் இணக்கமானது: பழைய பதிப்புகளில் செயல்பாடு சோதிக்கப்படவில்லை மற்றும் உத்தரவாதம் இல்லை. டெவலப்பர்களின் கூற்றுப்படி, காலிகோ லினக்ஸ் கர்னல்களில் 3.10 இயங்கும் CentOS 7, Ubuntu 16 அல்லது Debian 8, iptables அல்லது IPVS ஆகியவற்றின் மேல் இயங்குகிறது.

சூழலுக்குள் தனிமைப்படுத்தல்

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

கிளஸ்டரில் 2 இணைய பயன்பாடுகள் உள்ளன: Node.js மற்றும் PHP இல், அவற்றில் ஒன்று Redis ஐப் பயன்படுத்துகிறது. PHP இலிருந்து Redisக்கான அணுகலைத் தடுக்க, Node.js உடன் இணைப்பைப் பராமரிக்கும் போது, ​​பின்வரும் கொள்கையைப் பயன்படுத்தவும்:

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

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

கலிகோவின் படைப்பாளிகளின் கூற்றுப்படி, "எல்லாவற்றையும் தடுத்து, உங்களுக்குத் தேவையானதை வெளிப்படையாகத் திறக்கவும்" என்ற அணுகுமுறையே சிறந்த நடைமுறையாகும். அதிகாரப்பூர்வ ஆவணங்கள் (மற்றவர்கள் இதே அணுகுமுறையைப் பின்பற்றுகிறார்கள் - குறிப்பாக, இல் ஏற்கனவே குறிப்பிட்டுள்ள கட்டுரை).

கூடுதல் காலிகோ பொருட்களைப் பயன்படுத்துதல்

காலிகோ ஏபிஐகளின் நீட்டிக்கப்பட்ட தொகுப்பின் மூலம், காய்களுக்கு மட்டுப்படுத்தாமல், கணுக்களின் கிடைக்கும் தன்மையை நீங்கள் கட்டுப்படுத்தலாம் என்பதை உங்களுக்கு நினைவூட்டுகிறேன். பின்வரும் எடுத்துக்காட்டில் பயன்படுத்தி 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, அதாவது, உண்மையான ஐபிக்கு.
2. சேவை வெளியில் வெளியிடப்படுகிறது ClusterIP. முனையில் ஒரு போர்ட் உடல் ரீதியாக நிறுவப்பட்டுள்ளது, இது சிறிய முன்பதிவுகளுடன் வெளியில் இருந்து அணுகக்கூடியது (உண்மையான ஐபி முகவரியின் நிபந்தனை இருப்பு).
3. நெற்று ரோஜாவின் முனையைத் தீர்மானிப்பது எங்கள் கதையின் எல்லைக்கு அப்பாற்பட்டது. நீங்கள் சேவையை ஒரு முனையில் இறுக்கமாக "ஆணி" செய்யலாம் அல்லது VPN சேவையின் தற்போதைய ஐபி முகவரியைக் கண்காணிக்கும் மற்றும் வாடிக்கையாளர்களுடன் பதிவுசெய்யப்பட்ட 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 உடன் இணைப்பது கண்டிப்பாக தடைசெய்யப்பட்டுள்ளது, ஆனால் அதே நேரத்தில் டிஎன்எஸ் சேவையின் செயல்பாடு பாதுகாக்கப்படுகிறது, விதிகளை உருவாக்கும் போது அதன் செயல்பாடு அடிக்கடி பாதிக்கப்படுகிறது. ஏனெனில், முன்பு குறிப்பிட்டபடி, ஒரு தேர்வாளர் தோன்றும் போது, ​​குறிப்பிடப்படாத வரையில், இயல்புநிலை மறுப்புக் கொள்கை அதற்குப் பயன்படுத்தப்படும்.

முடிவுகளை

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

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

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• «பாதுகாப்பு நிபுணர்களுக்கான குபெர்னெட்ஸ் நெட்வொர்க் கொள்கைகளுக்கு ஒரு அறிமுகம்";
• "குபெர்னெட்ஸில் நெட்வொர்க்கிங் செய்ய ஒரு விளக்கப்பட வழிகாட்டி": பாகங்கள் 1 மற்றும் 2 (நெட்வொர்க் மாடல், மேலடுக்கு நெட்வொர்க்குகள்), பகுதி 3 (சேவைகள் மற்றும் போக்குவரத்து செயலாக்கம்);
• «கொள்கலன் நெட்வொர்க்கிங் இடைமுகம் (CNI) - பிணைய இடைமுகம் மற்றும் லினக்ஸ் கொள்கலன்களுக்கான தரநிலை".

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