Kubernetes හි ජාලකරණය සඳහා Calico: හැඳින්වීම සහ කුඩා අත්දැකීමක්

ලිපියේ පරමාර්ථය වන්නේ Kubernetes හි ජාලකරණය සහ කළමනාකරණය කිරීමේ ජාල ප්‍රතිපත්ති පිළිබඳ මූලික කරුණු මෙන්ම සම්මත හැකියාවන් පුළුල් කරන තෙවන පාර්ශවීය Calico ප්ලගිනය පාඨකයාට හඳුන්වා දීමයි. මාර්ගය දිගේ, වින්‍යාස කිරීමේ පහසුව සහ සමහර විශේෂාංග අපගේ මෙහෙයුම් අත්දැකීම් වලින් සැබෑ උදාහරණ භාවිතා කර පෙන්වනු ඇත.

Kubernetes ජාලකරණ උපකරණ සඳහා ඉක්මන් හැඳින්වීමක්

ජාලයක් නොමැතිව Kubernetes පොකුරක් සිතාගත නොහැකිය. අපි දැනටමත් ඔවුන්ගේ මූලික කරුණු පිළිබඳ තොරතුරු ප්‍රකාශයට පත් කර ඇත: "Kubernetes හි ජාලකරණය සඳහා නිදර්ශන මාර්ගෝපදේශයකි"සහ"ආරක්ෂක වෘත්තිකයන් සඳහා Kubernetes ජාල ප්‍රතිපත්ති පිළිබඳ හැඳින්වීමක්".

මෙම ලිපියේ සන්දර්භය තුළ, බහාලුම් සහ නෝඩ් අතර ජාල සම්බන්ධතාවය සඳහා K8s වගකිව යුතු නොවන බව සැලකිල්ලට ගැනීම වැදගත්ය: මේ සඳහා, විවිධ CNI ප්ලගින (බහාලුම් ජාල අතුරුමුහුණත). මෙම සංකල්පය ගැන වැඩි විස්තර අපි ඔවුන් මටත් කිව්වා.

උදාහරණයක් ලෙස, මෙම ප්ලගීන වඩාත් පොදු වේ ෆ්ලැනෙල් — එක් එක් නෝඩය මත පාලම් එසවීමෙන්, එයට අනුජාලයක් ලබා දීමෙන් සියලුම පොකුරු නෝඩ් අතර සම්පූර්ණ ජාල සම්බන්ධතාව සපයයි. කෙසේ වෙතත්, සම්පූර්ණ සහ නියාමනය නොකළ ප්රවේශය සෑම විටම ප්රයෝජනවත් නොවේ. පොකුරේ යම් ආකාරයක අවම හුදකලාවක් සහතික කිරීම සඳහා, ගිනි පවුරේ වින්යාසය තුළ මැදිහත් වීම අවශ්ය වේ. සාමාන්‍ය අවස්ථාවෙහිදී, එය එකම CNI පාලනය යටතේ තබා ඇත, එබැවින් iptables හි ඕනෑම තෙවන පාර්ශවීය මැදිහත්වීමක් වැරදි ලෙස අර්ථකථනය කිරීමට හෝ සම්පූර්ණයෙන්ම නොසලකා හැරිය හැක.

සහ Kubernetes පොකුරක් තුළ ජාල ප්‍රතිපත්ති කළමනාකරණය සංවිධානය කිරීම සඳහා "කොටුවෙන් පිටත" සපයනු ලැබේ 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 ක් ඇති බව තර්කානුකූලයි: පොඩ් එකට ඇතුල් වීම (ඇතුළත් වීම) සහ එයින් පිටතට යාම (Egress).

ඇත්ත වශයෙන්ම, දේශපාලනය මෙම වර්ග 2 කට බෙදා ඇත්තේ චලනය වන දිශාව මත ය.

ඊළඟට අවශ්‍ය ගුණාංගය වන්නේ තේරීම්කාරකයකි; රීතිය අදාළ වන තැනැත්තා. මෙය පොඩ් එකක් (හෝ කරල් සමූහයක්) හෝ පරිසරයක් (එනම් නාම අවකාශයක්) විය හැකිය. වැදගත් විස්තරයක්: මෙම වස්තූන් වර්ග දෙකෙහිම ලේබලයක් අඩංගු විය යුතුය (ලේබලය Kubernetes පාරිභාෂිතය තුළ) - දේශපාලකයන් ක්‍රියාත්මක වන්නේ මේවාය.

යම් ආකාරයක ලේබලයක් මගින් එක්සත් කරන ලද සීමිත තේරීම් කාරක සංඛ්‍යාවකට අමතරව, විවිධ වෙනස්කම් වලින් “සියල්ලට ඉඩ දෙන්න / ප්‍රතික්ෂේප කරන්න” වැනි නීති ලිවිය හැකිය. මෙම කාර්යය සඳහා, පෝරමයේ ඉදිකිරීම් භාවිතා කරනු ලැබේ:

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

- මෙම උදාහරණයේ දී, පරිසරයේ ඇති සියලුම කරල් පැමිණෙන ගමනාගමනයෙන් අවහිර කර ඇත. පහත සඳහන් ඉදිකිරීම් සමඟ ප්රතිවිරුද්ධ හැසිරීම සාක්ෂාත් කරගත හැකිය:

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

ඒ හා සමානව පිටතට යාම සඳහා:

  podSelector: {}
  policyTypes:
  - Egress

- එය නිවා දැමීමට. සහ ඇතුළත් කළ යුතු දේ මෙන්න:

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

පොකුරක් සඳහා CNI ප්ලගිනයක් තේරීම වෙත ආපසු යාම, එය සඳහන් කිරීම වටී සෑම ජාල ප්ලගිනයක්ම NetworkPolicy සඳහා සහය නොදක්වයි. උදාහරණයක් ලෙස, දැනටමත් සඳහන් කර ඇති Flannel ජාල ප්‍රතිපත්ති වින්‍යාස කරන්නේ කෙසේදැයි නොදනී ඒක කෙලින්ම කියනවා නිල ගබඩාවේ. විකල්පයක් ද එහි සඳහන් වේ - විවෘත මූලාශ්‍ර ව්‍යාපෘතියකි කැලිකෝ, ජාල ප්‍රතිපත්ති අනුව Kubernetes API වල සම්මත කට්ටලය සැලකිය යුතු ලෙස පුළුල් කරයි.

කැලිකෝ: න්‍යාය දැන හඳුනා ගැනීම

Calico ප්ලගිනය Flannel (උප ව්‍යාපෘතිය) සමඟ ඒකාබද්ධව භාවිතා කළ හැක ඇළ) හෝ ස්වාධීනව, ජාල සම්බන්ධතාවය සහ ලබා ගත හැකි කළමනාකරණ හැකියාවන් යන දෙකම ආවරණය කරයි.

K8s "කොටු" විසඳුම සහ Calico වෙතින් API කට්ටලය භාවිතා කරන අවස්ථා මොනවාද?

NetworkPolicy තුළ ගොඩනගා ඇති දේ මෙන්න:

• දේශපාලකයන් පරිසරයෙන් සීමා වී ඇත;
• ලේබල් වලින් සලකුණු කර ඇති කරල් සඳහා ප්‍රතිපත්ති යොදනු ලැබේ;
• කරල්, පරිසරය හෝ උපජාල සඳහා නීති යෙදිය හැක;
• රීති වල ප්‍රොටෝකෝල, නම් කරන ලද හෝ සංකේතාත්මක වරාය පිරිවිතර අඩංගු විය හැක.

Calico මෙම කාර්යයන් දිගු කරන ආකාරය මෙන්න:

• ඕනෑම වස්තුවකට ප්‍රතිපත්ති යෙදිය හැක: පොඩ්, බහාලුම්, අතථ්‍ය යන්ත්‍රය හෝ අතුරු මුහුණත;
• රීති වල නිශ්චිත ක්‍රියාවක් අඩංගු විය හැකිය (තහනම්, අවසරය, ලොග් කිරීම);
• රීතිවල ඉලක්කය හෝ මූලාශ්‍රය වරායක්, වරාය පරාසයක්, ප්‍රොටෝකෝල, HTTP හෝ ICMP ගුණාංග, IP හෝ උපජාල (4 වන හෝ 6 වන පරම්පරාව), ඕනෑම තේරීම් (නෝඩ්, ධාරක, පරිසරය) විය හැකිය;
• අතිරේකව, ඔබට DNAT සිටුවම් සහ ගමනාගමන යොමු කිරීමේ ප්‍රතිපත්ති භාවිතයෙන් ගමනාගමනය නියාමනය කළ හැක.

Calico ගබඩාවේ GitHub හි පළමු කැපවීම ජූලි 2016 දක්වා දිවෙන අතර වසරකට පසුව මෙම ව්‍යාපෘතිය Kubernetes ජාල සම්බන්ධතාවය සංවිධානය කිරීමේදී ප්‍රමුඛ ස්ථානයක් ගත්තේය - මෙය උදාහරණයක් ලෙස සමීක්ෂණ ප්‍රති results ල මගින් සනාථ වේ. The New Stack විසින් පවත්වන ලදී:

වැනි K8s සමඟ බොහෝ විශාල කළමනාකරණය කළ විසඳුම් Amazon EX, Azure AKS, ගූගල් GKE සහ වෙනත් අය එය භාවිතය සඳහා නිර්දේශ කිරීමට පටන් ගත්හ.

කාර්ය සාධනය සම්බන්ධයෙන් ගත් කල, මෙහි සෑම දෙයක්ම විශිෂ්ටයි. ඔවුන්ගේ නිෂ්පාදනය පරීක්ෂා කිරීමේදී, Calico සංවර්ධන කණ්ඩායම තාරකා විද්‍යාත්මක කාර්ය සාධනය පෙන්නුම් කළ අතර, තත්පරයකට බහාලුම් 50000 ක නිර්මානය කිරීමේ අනුපාතයක් සහිත භෞතික නෝඩ් 500 ක බහාලුම් 20 කට වඩා ධාවනය කරයි. පරිමාණය සමඟ ගැටළු හඳුනාගෙන නොමැත. එවැනි ප්රතිඵල නිවේදනය කරන ලදී දැනටමත් පළමු අනුවාදයේ නිවේදනයේ. ප්‍රතිදානය සහ සම්පත් පරිභෝජනය කෙරෙහි අවධානය යොමු කරන ස්වාධීන අධ්‍යයනයන් ද කැලිකෝගේ ක්‍රියාකාරිත්වය ෆ්ලැනෙල්ගේ කාර්ය සාධනය තරම්ම හොඳ බව සනාථ කරයි. උදාහරණයක් ලෙස:

ව්‍යාපෘතිය ඉතා ඉක්මනින් සංවර්ධනය වෙමින් පවතී, එය ජනප්‍රිය විසඳුම් කළමනාකරණය කරන K8s, OpenShift, OpenStack වල වැඩ සඳහා සහය දක්වයි, භාවිතා කරමින් පොකුරක් යෙදවීමේදී Calico භාවිතා කළ හැකිය kops, සේවා දැල් ජාල ඉදිකිරීම සඳහා යොමු ඇත (මෙන්න උදාහරණයක් Istio සමඟ ඒකාබද්ධව භාවිතා වේ).

කැලිකෝ සමඟ පුහුණු වන්න

වැනිලා Kubernetes භාවිතා කිරීමේ සාමාන්‍ය අවස්ථාවෙහිදී, CNI ස්ථාපනය කිරීම ගොනුව භාවිතා කිරීම දක්වා පැමිණේ calico.yaml, නිල වෙබ් අඩවියෙන් බාගත කර ඇත, භාවිතා කිරීම මගින් kubectl apply -f.

රීතියක් ලෙස, ප්ලගිනයේ වත්මන් අනුවාදය Kubernetes හි නවතම අනුවාද 2-3 සමඟ අනුකූල වේ: පැරණි අනුවාද වල ක්‍රියාකාරිත්වය පරීක්ෂා කර නොමැති අතර සහතික නොවේ. සංවර්ධකයින්ට අනුව, Calico iptables හෝ IPVS මත CentOS 3.10, Ubuntu 7 හෝ Debian 16 ධාවනය වන 8 ට වැඩි Linux කර්නල් මත ධාවනය වේ.

පරිසරය තුළ හුදකලා වීම

සාමාන්‍ය අවබෝධයක් සඳහා, Calico අංකනයේ ජාල ප්‍රතිපත්ති සම්මත ඒවාට වඩා වෙනස් වන ආකාරය සහ රීති නිර්මාණය කිරීමේ ප්‍රවේශය ඒවායේ කියවීමේ හැකියාව සහ වින්‍යාස කිරීමේ නම්‍යශීලී බව සරල කරන්නේ කෙසේද යන්න තේරුම් ගැනීමට සරල අවස්ථාවක් දෙස බලමු:

පොකුර තුළ වෙබ් යෙදුම් 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 Kubernetes කොටුවෙන් පිටත, නමුත් එය භාවිතා කිරීමෙන් කිසිවක් ඔබව වළක්වන්නේ නැත කැලිකෝ බෙදාහැරීමේ එකම නමේ සම්පත. එහි ඇති වාක්‍ය ඛණ්ඩය වඩාත් සවිස්තරාත්මක ය, එබැවින් ඔබට ඉහත නඩුව සඳහා රීතිය පහත පෝරමයට නැවත ලිවිය යුතුය:

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.

පරිසරයෙන් හුදකලා වීම

Prometheus හි එකතු කිරීම සහ Grafana භාවිතයෙන් වැඩිදුර විශ්ලේෂණය සඳහා යෙදුමක් ව්‍යාපාරික ප්‍රමිතික උත්පාදනය කරන තත්වයක් දැන් සිතන්න. උඩුගත කිරීමෙහි සංවේදී දත්ත අඩංගු විය හැක, පෙරනිමියෙන් නැවත ප්‍රසිද්ධියේ බැලිය හැක. අපි මෙම දත්ත පිරික්සීමේ ඇස්වලින් සඟවමු:

Prometheus, රීතියක් ලෙස, වෙනම සේවා පරිසරයක තබා ඇත - උදාහරණයේ දී එය මෙවැනි නාම අවකාශයක් වනු ඇත:

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

ඔබ Calico ප්‍රතිපත්ති භාවිතා කරන්නේ නම්, වාක්‍ය ඛණ්ඩය මේ වගේ වනු ඇත:

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

සාමාන්‍යයෙන්, විශේෂිත අවශ්‍යතා සඳහා මෙවැනි ප්‍රතිපත්ති එකතු කිරීමෙන්, පොකුරේ යෙදුම් ක්‍රියාත්මක කිරීමේදී ද්වේෂසහගත හෝ අහඹු මැදිහත්වීම් වලින් ඔබට ආරක්ෂා විය හැක.

Calico හි නිර්මාතෘවරුන්ට අනුව හොඳම භාවිතය වන්නේ ලේඛනගත කර ඇති “සියල්ල අවහිර කර ඔබට අවශ්‍ය දේ පැහැදිලිව විවෘත කරන්න” ප්‍රවේශයයි. නිල ලියකියවිලි (අනෙකුත් ඒ හා සමාන ප්රවේශයක් අනුගමනය කරයි - විශේෂයෙන්ම, in දැනටමත් සඳහන් කර ඇති ලිපිය).

අතිරේක කැලිකෝ වස්තු භාවිතා කිරීම

කැලිකෝ 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 නඩුව

අවසාන වශයෙන්, සම්මත ප්‍රතිපත්ති මාලාවක් ප්‍රමාණවත් නොවන විට, ආසන්න පොකුරු අන්තර්ක්‍රියා සඳහා Calico ශ්‍රිත භාවිතා කිරීම පිළිබඳ සැබෑ උදාහරණයක් මම දෙන්නෙමි. වෙබ් යෙදුම වෙත ප්‍රවේශ වීමට, සේවාදායකයින් VPN උමගක් භාවිතා කරන අතර, මෙම ප්‍රවේශය දැඩි ලෙස පාලනය වන අතර භාවිතයට අවසර දී ඇති විශේෂිත සේවා ලැයිස්තුවකට සීමා වේ:

සේවාලාභීන් සම්මත UDP port 1194 හරහා VPN වෙත සම්බන්ධ වන අතර, සම්බන්ධ වූ විට, Pods සහ සේවාවන්හි පොකුරු අනුජාල වෙත මාර්ග ලබා ගනී. නැවත ආරම්භ කිරීමේදී සහ ලිපින වෙනස් කිරීමේදී සේවා අහිමි නොවන පරිදි සම්පූර්ණ උපජාල තල්ලු කරනු ලැබේ.

වින්‍යාසයේ ඇති වරාය සම්මත වේ, එමඟින් යෙදුම වින්‍යාස කිරීමේ ක්‍රියාවලියට සහ එය Kubernetes පොකුරට මාරු කිරීමේ ක්‍රියාවලියට යම් යම් සූක්ෂ්මතා පනවයි. උදාහරණයක් ලෙස, 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 සේවාවේ ක්‍රියාකාරිත්වය සංරක්ෂණය කර ඇත, එහි ක්‍රියාකාරිත්වය බොහෝ විට නීති රීති සැකසීමේදී දුක් විඳිනවා. මක්නිසාද යත්, කලින් සඳහන් කළ පරිදි, තේරීම් කාරකයක් දිස්වන විට, වෙනත් ආකාරයකින් දක්වා නොමැති නම්, පෙරනිමි ප්‍රතික්ෂේප කිරීමේ ප්‍රතිපත්තිය එයට යොදනු ලැබේ.

ප්රතිඵල

මේ අනුව, Calico හි උසස් API භාවිතයෙන්, ඔබට නම්‍යශීලීව වින්‍යාසගත කිරීමට සහ පොකුර තුළ සහ අවට මාර්ගගත කිරීම් ගතිකව වෙනස් කළ හැක. සාමාන්‍යයෙන්, එහි භාවිතය කාලතුවක්කුවකින් ගේ කුරුල්ලන්ට වෙඩි තැබීමක් සේ පෙනෙන අතර, BGP සහ IP-IP උමං සහිත L3 ජාලයක් ක්‍රියාත්මක කිරීම පැතලි ජාලයක සරල Kubernetes ස්ථාපනයකදී බිහිසුණු බවක් පෙනේ... එසේ නොවුවහොත්, මෙවලම තරමක් ශක්‍ය සහ ප්‍රයෝජනවත් බව පෙනේ. .

ආරක්ෂක අවශ්‍යතා සපුරාලීම සඳහා පොකුරක් හුදකලා කිරීම සැමවිටම කළ නොහැකි විය හැකි අතර, Calico (හෝ ඒ හා සමාන විසඳුමක්) ගලවා ගැනීමට පැමිණේ. මෙම ලිපියේ දක්වා ඇති උදාහරණ (සුළු වෙනස් කිරීම් සහිතව) AWS හි අපගේ සේවාලාභීන්ගේ ස්ථාපනයන් කිහිපයක භාවිතා වේ.

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

• «ආරක්ෂක වෘත්තිකයන් සඳහා Kubernetes ජාල ප්‍රතිපත්ති පිළිබඳ හැඳින්වීමක්»;
• "Kubernetes හි ජාලකරණය සඳහා නිදර්ශන මාර්ගෝපදේශයක්": කොටස් 1 සහ 2 (ජාල ආකෘතිය, ආවරණ ජාල), 3 කොටස (සේවා සහ රථවාහන සැකසීම);
• «බහාලුම් ජාලකරණ අතුරුමුහුණත (CNI) - ජාල අතුරුමුහුණත සහ ලිනක්ස් බහාලුම් සඳහා සම්මත".

මූලාශ්රය: www.habr.com