કુબરનેટ્સમાં નેટવર્કિંગ માટે કેલિકો: પરિચય અને થોડો અનુભવ

લેખનો હેતુ વાચકને કુબરનેટ્સમાં નેટવર્કિંગ અને નેટવર્ક નીતિઓનું સંચાલન કરવાની મૂળભૂત બાબતો તેમજ પ્રમાણભૂત ક્ષમતાઓને વિસ્તારતા તૃતીય-પક્ષ કેલિકો પ્લગઇનનો પરિચય કરાવવાનો છે. રસ્તામાં, રૂપરેખાંકનની સરળતા અને કેટલીક સુવિધાઓ અમારા ઓપરેટિંગ અનુભવમાંથી વાસ્તવિક ઉદાહરણોનો ઉપયોગ કરીને દર્શાવવામાં આવશે.

કુબરનેટ્સ નેટવર્કિંગ એપ્લાયન્સનો ઝડપી પરિચય

નેટવર્ક વિના કુબરનેટ્સ ક્લસ્ટરની કલ્પના કરી શકાતી નથી. અમે તેમની મૂળભૂત બાબતો પર પહેલાથી જ સામગ્રી પ્રકાશિત કરી છે: “Kubernetes માં નેટવર્કીંગ માટે સચિત્ર માર્ગદર્શિકા"અને"સુરક્ષા વ્યાવસાયિકો માટે કુબરનેટ્સ નેટવર્ક નીતિઓનો પરિચય».

આ લેખના સંદર્ભમાં, એ નોંધવું અગત્યનું છે કે K8s પોતે કન્ટેનર અને નોડ્સ વચ્ચે નેટવર્ક કનેક્ટિવિટી માટે જવાબદાર નથી: આ માટે, વિવિધ CNI પ્લગઈન્સ (કન્ટેનર નેટવર્કિંગ ઈન્ટરફેસ). આ ખ્યાલ વિશે વધુ અમે તેઓએ મને પણ કહ્યું.

ઉદાહરણ તરીકે, આ પ્લગઈનો સૌથી સામાન્ય છે ફલાનીલ — દરેક નોડ પર બ્રિજ ઉભા કરીને, તેને સબનેટ સોંપીને તમામ ક્લસ્ટર નોડ્સ વચ્ચે સંપૂર્ણ નેટવર્ક કનેક્ટિવિટી પૂરી પાડે છે. જો કે, સંપૂર્ણ અને અનિયંત્રિત સુલભતા હંમેશા ફાયદાકારક હોતી નથી. ક્લસ્ટરમાં અમુક પ્રકારની ન્યૂનતમ અલગતા પ્રદાન કરવા માટે, ફાયરવોલના રૂપરેખાંકનમાં દખલ કરવી જરૂરી છે. સામાન્ય કિસ્સામાં, તે સમાન 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 પ્રકારના ટ્રાફિક છે: પોડમાં પ્રવેશવું (ઇન્ગ્રેસ) અને તેમાંથી બહાર નીકળવું (એગ્રેસ).

વાસ્તવમાં, આંદોલનની દિશાના આધારે રાજકારણ આ બે વર્ગોમાં વહેંચાયેલું છે.

આગળની આવશ્યક વિશેષતા પસંદગીકાર છે; જેને નિયમ લાગુ પડે છે. આ પોડ (અથવા પોડ્સનું જૂથ) અથવા પર્યાવરણ (એટલે ​​કે નેમસ્પેસ) હોઈ શકે છે. એક મહત્વપૂર્ણ વિગત: આ બંને પ્રકારની વસ્તુઓમાં લેબલ હોવું આવશ્યક છે (લેબલ કુબરનેટીસ પરિભાષામાં) - આ તે છે જેની સાથે રાજકારણીઓ કામ કરે છે.

અમુક પ્રકારના લેબલ દ્વારા એકીકૃત પસંદગીકારોની મર્યાદિત સંખ્યા ઉપરાંત, વિવિધ ભિન્નતાઓમાં “બધું જ/દરેકને મંજૂરી આપો/નકારો” જેવા નિયમો લખવાનું શક્ય છે. આ હેતુ માટે, ફોર્મની રચનાઓનો ઉપયોગ કરવામાં આવે છે:

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

— આ ઉદાહરણમાં, પર્યાવરણમાં તમામ પોડ્સ આવતા ટ્રાફિકથી અવરોધિત છે. વિપરીત વર્તન નીચેના બાંધકામ સાથે પ્રાપ્ત કરી શકાય છે:

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

એ જ રીતે આઉટગોઇંગ માટે:

  podSelector: {}
  policyTypes:
  - Egress

- તેને બંધ કરવા માટે. અને અહીં શું શામેલ કરવું તે છે:

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

ક્લસ્ટર માટે CNI પ્લગઇનની પસંદગી પર પાછા ફરવું, તે નોંધવું યોગ્ય છે દરેક નેટવર્ક પ્લગઇન NetworkPolicy ને સપોર્ટ કરતું નથી. ઉદાહરણ તરીકે, પહેલેથી જ ઉલ્લેખિત ફ્લેનેલ નેટવર્ક નીતિઓને કેવી રીતે ગોઠવવી તે જાણતું નથી, જે તે સીધું કહ્યું છે સત્તાવાર ભંડારમાં. ત્યાં એક વિકલ્પનો પણ ઉલ્લેખ છે - એક ઓપન સોર્સ પ્રોજેક્ટ કાલિકો, જે નેટવર્ક નીતિઓના સંદર્ભમાં Kubernetes API ના માનક સમૂહને નોંધપાત્ર રીતે વિસ્તૃત કરે છે.

કેલિકો: સિદ્ધાંતને જાણવું

કેલિકો પ્લગઇનનો ઉપયોગ ફ્લેનેલ (સબપ્રોજેક્ટ કેનાલ) અથવા સ્વતંત્ર રીતે, નેટવર્ક કનેક્ટિવિટી અને ઉપલબ્ધતા વ્યવસ્થાપન ક્ષમતાઓ બંનેને આવરી લે છે.

K8s “બોક્સ્ડ” સોલ્યુશન અને કેલિકોમાંથી API સેટનો ઉપયોગ કરવાથી કઈ તકો મળે છે?

NetworkPolicy માં શું બિલ્ટ છે તે અહીં છે:

• રાજકારણીઓ પર્યાવરણ દ્વારા મર્યાદિત છે;
• નીતિઓ લેબલ સાથે ચિહ્નિત શીંગો પર લાગુ થાય છે;
• નિયમો શીંગો, વાતાવરણ અથવા સબનેટ પર લાગુ કરી શકાય છે;
• નિયમોમાં પ્રોટોકોલ, નામ અથવા સાંકેતિક પોર્ટ સ્પષ્ટીકરણો હોઈ શકે છે.

કેલિકો આ કાર્યોને કેવી રીતે વિસ્તૃત કરે છે તે અહીં છે:

• નીતિઓ કોઈપણ ઑબ્જેક્ટ પર લાગુ કરી શકાય છે: પોડ, કન્ટેનર, વર્ચ્યુઅલ મશીન અથવા ઇન્ટરફેસ;
• નિયમોમાં ચોક્કસ ક્રિયા (પ્રતિબંધ, પરવાનગી, લોગિંગ) શામેલ હોઈ શકે છે;
• નિયમોનું લક્ષ્ય અથવા સ્ત્રોત પોર્ટ, પોર્ટની શ્રેણી, પ્રોટોકોલ, HTTP અથવા ICMP વિશેષતાઓ, IP અથવા સબનેટ (4થી અથવા 6ઠ્ઠી પેઢી), કોઈપણ પસંદગીકારો (નોડ્સ, યજમાનો, વાતાવરણ) હોઈ શકે છે;
• વધુમાં, તમે DNAT સેટિંગ્સ અને ટ્રાફિક ફોરવર્ડિંગ નીતિઓનો ઉપયોગ કરીને ટ્રાફિકના પેસેજનું નિયમન કરી શકો છો.

કેલિકો રિપોઝીટરીમાં GitHub પર પ્રથમ કમિટ જુલાઇ 2016 ની છે, અને એક વર્ષ પછી પ્રોજેક્ટે કુબરનેટ્સ નેટવર્ક કનેક્ટિવિટીનું આયોજન કરવામાં અગ્રણી સ્થાન મેળવ્યું - આનો પુરાવો છે, ઉદાહરણ તરીકે, સર્વેક્ષણ પરિણામો દ્વારા, ધ ન્યૂ સ્ટેક દ્વારા હાથ ધરવામાં આવે છે:

K8 સાથે ઘણા મોટા વ્યવસ્થાપિત ઉકેલો, જેમ કે એમેઝોન EX, Azure AKS, Google GKE અને અન્ય લોકોએ તેનો ઉપયોગ કરવા માટે ભલામણ કરવાનું શરૂ કર્યું.

પ્રદર્શન માટે, અહીં બધું સરસ છે. તેમના ઉત્પાદનના પરીક્ષણમાં, કેલિકો ડેવલપમેન્ટ ટીમે ખગોળશાસ્ત્રીય કામગીરી દર્શાવી, 50000 ભૌતિક ગાંઠો પર 500 થી વધુ કન્ટેનર ચલાવીને 20 કન્ટેનર પ્રતિ સેકન્ડના નિર્માણ દર સાથે. સ્કેલિંગ સાથે કોઈ સમસ્યા ઓળખવામાં આવી નથી. આવા પરિણામો જાહેર કરવામાં આવ્યા હતા પહેલેથી જ પ્રથમ સંસ્કરણની જાહેરાત પર. થ્રુપુટ અને સંસાધન વપરાશ પર ધ્યાન કેન્દ્રિત કરતા સ્વતંત્ર અભ્યાસો પણ પુષ્ટિ કરે છે કે કેલિકોનું પ્રદર્શન લગભગ ફ્લેનેલ જેટલું સારું છે. ઉદાહરણ તરીકે:

પ્રોજેક્ટ ખૂબ જ ઝડપથી વિકાસ કરી રહ્યો છે, તે લોકપ્રિય ઉકેલો સંચાલિત K8s, OpenShift, OpenStack માં કામને સમર્થન આપે છે, ક્લસ્ટરનો ઉપયોગ કરતી વખતે કેલિકોનો ઉપયોગ કરવો શક્ય છે. કોપ્સ, ત્યાં સેવા મેશ નેટવર્ક્સના નિર્માણના સંદર્ભો છે (અહીં એક ઉદાહરણ છે Istio સાથે જોડાણમાં વપરાય છે).

કેલિકો સાથે પ્રેક્ટિસ કરો

વેનીલા કુબરનેટ્સનો ઉપયોગ કરવાના સામાન્ય કિસ્સામાં, CNI ઇન્સ્ટોલ કરવું ફાઇલનો ઉપયોગ કરવા માટે નીચે આવે છે calico.yaml, સત્તાવાર વેબસાઇટ પરથી ડાઉનલોડ, ઉપયોગ કરીને kubectl apply -f.

નિયમ પ્રમાણે, પ્લગઇનનું વર્તમાન સંસ્કરણ કુબરનેટ્સના નવીનતમ 2-3 સંસ્કરણો સાથે સુસંગત છે: જૂના સંસ્કરણોમાં કામગીરીનું પરીક્ષણ કરવામાં આવતું નથી અને તેની ખાતરી આપવામાં આવતી નથી. વિકાસકર્તાઓના મતે, કેલિકો 3.10 થી ઉપરના Linux કર્નલ પર CentOS 7, Ubuntu 16 અથવા Debian 8 પર ચાલે છે, iptables અથવા IPVSની ટોચ પર.

પર્યાવરણની અંદર અલગતા

સામાન્ય સમજણ માટે, કેલિકો નોટેશનમાં નેટવર્ક નીતિઓ પ્રમાણભૂત કરતાં કેવી રીતે અલગ છે અને નિયમો બનાવવાનો અભિગમ તેમની વાંચનક્ષમતા અને ગોઠવણીની સુગમતાને કેવી રીતે સરળ બનાવે છે તે સમજવા માટે ચાલો એક સરળ કેસ જોઈએ:

ક્લસ્ટરમાં 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 પોર્ટ પર આવતા ટ્રાફિકને મંજૂરી આપી છે. અને તેઓએ સ્પષ્ટપણે બીજું કંઈપણ પ્રતિબંધિત કર્યું નથી. નેટવર્ક પોલિસી દેખાય કે તરત જ, તેમાં ઉલ્લેખિત તમામ પસંદગીકારો અલગ થવાનું શરૂ કરે છે, સિવાય કે અન્યથા ઉલ્લેખિત હોય. જો કે, આઇસોલેશન નિયમો પસંદગીકાર દ્વારા આવરી લેવામાં આવતાં અન્ય પદાર્થો પર લાગુ પડતા નથી.

ઉદાહરણ ઉપયોગ કરે છે 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 સાથે જોડાય છે અને, જ્યારે કનેક્ટ થાય છે, ત્યારે પોડ્સ અને સેવાઓના ક્લસ્ટર સબનેટના રૂટ મેળવે છે. પુનઃપ્રારંભ અને સરનામાંમાં ફેરફાર દરમિયાન સેવાઓ ન ગુમાવવા માટે સમગ્ર સબનેટને દબાણ કરવામાં આવે છે.

રૂપરેખાંકનમાં પોર્ટ પ્રમાણભૂત છે, જે એપ્લિકેશનને ગોઠવવાની અને તેને કુબરનેટ્સ ક્લસ્ટરમાં સ્થાનાંતરિત કરવાની પ્રક્રિયા પર કેટલીક ઘોંઘાટ લાદે છે. ઉદાહરણ તરીકે, એ જ AWS માં UDP માટે લોડબેલેન્સર શાબ્દિક રીતે ગયા વર્ષના અંતમાં પ્રદેશોની મર્યાદિત સૂચિમાં દેખાયો, અને નોડપોર્ટનો ઉપયોગ તમામ ક્લસ્ટર નોડ્સ પર ફોરવર્ડિંગને કારણે થઈ શકતો નથી અને તેના માટે સર્વર ઉદાહરણોની સંખ્યાને માપવાનું અશક્ય છે. દોષ સહનશીલતા હેતુઓ. ઉપરાંત, તમારે બંદરોની ડિફૉલ્ટ શ્રેણી બદલવી પડશે...

સંભવિત ઉકેલો શોધવાના પરિણામે, નીચેની પસંદગી કરવામાં આવી હતી:

1. VPN સાથે પોડ્સ નોડ દીઠ સુનિશ્ચિત થયેલ છે hostNetwork, એટલે કે, વાસ્તવિક IP પર.
2. દ્વારા સેવા બહાર પોસ્ટ કરવામાં આવે છે ClusterIP. નોડ પર પોર્ટ ભૌતિક રીતે ઇન્સ્ટોલ કરેલું છે, જે બહારથી નાના રિઝર્વેશન (વાસ્તવિક IP સરનામાની શરતી હાજરી) સાથે સુલભ છે.
3. નોડ કે જેના પર પોડ ગુલાબ છે તે નક્કી કરવું એ અમારી વાર્તાના અવકાશની બહાર છે. હું ફક્ત એટલું જ કહીશ કે તમે નોડ પર સેવાને ચુસ્તપણે "નેલ" કરી શકો છો અથવા એક નાની સાઇડકાર સેવા લખી શકો છો જે VPN સેવાના વર્તમાન IP સરનામાનું નિરીક્ષણ કરશે અને ક્લાયન્ટ્સ સાથે નોંધાયેલા DNS રેકોર્ડ્સને સંપાદિત કરશે - જેની પાસે પૂરતી કલ્પના છે.

રૂટીંગ પરિપ્રેક્ષ્યમાં, અમે VPN સર્વર દ્વારા જારી કરાયેલ તેના IP સરનામા દ્વારા VPN ક્લાયંટને વિશિષ્ટ રીતે ઓળખી શકીએ છીએ. નીચે આવા ક્લાયન્ટની સેવાઓની ઍક્સેસને પ્રતિબંધિત કરવાનું આદિમ ઉદાહરણ છે, ઉપરોક્ત રેડિસ પર સચિત્ર છે:

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