ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕಿಂಗ್ಗಾಗಿ ಕ್ಯಾಲಿಕೊ: ಪರಿಚಯ ಮತ್ತು ಸ್ವಲ್ಪ ಅನುಭವ

ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಮತ್ತು ಮ್ಯಾನೇಜಿಂಗ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಓದುಗರಿಗೆ ಪರಿಚಯಿಸುವುದು ಲೇಖನದ ಉದ್ದೇಶವಾಗಿದೆ, ಜೊತೆಗೆ ಪ್ರಮಾಣಿತ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ವಿಸ್ತರಿಸುವ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಕ್ಯಾಲಿಕೋ ಪ್ಲಗಿನ್. ದಾರಿಯುದ್ದಕ್ಕೂ, ನಮ್ಮ ಆಪರೇಟಿಂಗ್ ಅನುಭವದಿಂದ ನೈಜ ಉದಾಹರಣೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂರಚನೆಯ ಸುಲಭ ಮತ್ತು ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಉಪಕರಣಕ್ಕೆ ತ್ವರಿತ ಪರಿಚಯ

ನೆಟ್ವರ್ಕ್ ಇಲ್ಲದೆ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಲಾಗುವುದಿಲ್ಲ. ನಾವು ಈಗಾಗಲೇ ಅವರ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು ಪ್ರಕಟಿಸಿದ್ದೇವೆ: "ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕಿಂಗ್‌ಗೆ ಸಚಿತ್ರ ಮಾರ್ಗದರ್ಶಿ"ಮತ್ತು"ಭದ್ರತಾ ವೃತ್ತಿಪರರಿಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳಿಗೆ ಒಂದು ಪರಿಚಯ».

ಈ ಲೇಖನದ ಸಂದರ್ಭದಲ್ಲಿ, ಕಂಟೈನರ್‌ಗಳು ಮತ್ತು ನೋಡ್‌ಗಳ ನಡುವಿನ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕಕ್ಕೆ 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 ಪ್ಲಗಿನ್‌ನ ಆಯ್ಕೆಗೆ ಹಿಂತಿರುಗಿ, ಅದನ್ನು ಗಮನಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಪ್ರತಿಯೊಂದು ನೆಟ್‌ವರ್ಕ್ ಪ್ಲಗಿನ್ ನೆಟ್‌ವರ್ಕ್ ಪಾಲಿಸಿಯನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಲಾದ ಫ್ಲಾನೆಲ್ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳನ್ನು ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲ, ಅದು ಅದನ್ನು ನೇರವಾಗಿ ಹೇಳಲಾಗುತ್ತದೆ ಅಧಿಕೃತ ಭಂಡಾರದಲ್ಲಿ. ಪರ್ಯಾಯವನ್ನು ಸಹ ಅಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ - ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆ ಕ್ಯಾಲಿಕೊ, ಇದು ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳ ವಿಷಯದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ API ಗಳ ಪ್ರಮಾಣಿತ ಸೆಟ್ ಅನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವಿಸ್ತರಿಸುತ್ತದೆ.

ಕ್ಯಾಲಿಕೊ: ಸಿದ್ಧಾಂತವನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು

ಕ್ಯಾಲಿಕೋ ಪ್ಲಗಿನ್ ಅನ್ನು ಫ್ಲಾನೆಲ್ (ಉಪಪ್ರಾಜೆಕ್ಟ್) ನೊಂದಿಗೆ ಏಕೀಕರಣದಲ್ಲಿ ಬಳಸಬಹುದು ಕಾಲುವೆ) ಅಥವಾ ಸ್ವತಂತ್ರವಾಗಿ, ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕ ಮತ್ತು ಲಭ್ಯತೆ ನಿರ್ವಹಣೆ ಸಾಮರ್ಥ್ಯಗಳೆರಡನ್ನೂ ಒಳಗೊಂಡಿದೆ.

K8s "ಬಾಕ್ಸ್ಡ್" ಪರಿಹಾರ ಮತ್ತು ಕ್ಯಾಲಿಕೋದಿಂದ API ಸೆಟ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ಯಾವ ಅವಕಾಶಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ?

ನೆಟ್‌ವರ್ಕ್ ಪಾಲಿಸಿಯಲ್ಲಿ ಏನನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:

• ರಾಜಕಾರಣಿಗಳು ಪರಿಸರದಿಂದ ಸೀಮಿತರಾಗಿದ್ದಾರೆ;
• ಲೇಬಲ್‌ಗಳೊಂದಿಗೆ ಗುರುತಿಸಲಾದ ಪಾಡ್‌ಗಳಿಗೆ ನೀತಿಗಳನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ;
• ನಿಯಮಗಳನ್ನು ಪಾಡ್‌ಗಳು, ಪರಿಸರಗಳು ಅಥವಾ ಸಬ್‌ನೆಟ್‌ಗಳಿಗೆ ಅನ್ವಯಿಸಬಹುದು;
• ನಿಯಮಗಳು ಪ್ರೋಟೋಕಾಲ್‌ಗಳು, ಹೆಸರಿನ ಅಥವಾ ಸಾಂಕೇತಿಕ ಪೋರ್ಟ್ ವಿಶೇಷಣಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು.

ಕ್ಯಾಲಿಕೊ ಈ ಕಾರ್ಯಗಳನ್ನು ಹೇಗೆ ವಿಸ್ತರಿಸುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:

• ನೀತಿಗಳನ್ನು ಯಾವುದೇ ವಸ್ತುವಿಗೆ ಅನ್ವಯಿಸಬಹುದು: ಪಾಡ್, ಕಂಟೇನರ್, ವರ್ಚುವಲ್ ಯಂತ್ರ ಅಥವಾ ಇಂಟರ್ಫೇಸ್;
• ನಿಯಮಗಳು ನಿರ್ದಿಷ್ಟ ಕ್ರಿಯೆಯನ್ನು ಒಳಗೊಂಡಿರಬಹುದು (ನಿಷೇಧ, ಅನುಮತಿ, ಲಾಗಿಂಗ್);
• ಗುರಿ ಅಥವಾ ನಿಯಮಗಳ ಮೂಲವು ಪೋರ್ಟ್ ಆಗಿರಬಹುದು, ಪೋರ್ಟ್‌ಗಳ ಶ್ರೇಣಿ, ಪ್ರೋಟೋಕಾಲ್‌ಗಳು, HTTP ಅಥವಾ ICMP ಗುಣಲಕ್ಷಣಗಳು, IP ಅಥವಾ ಸಬ್‌ನೆಟ್ (4ನೇ ಅಥವಾ 6 ನೇ ತಲೆಮಾರಿನ), ಯಾವುದೇ ಆಯ್ಕೆದಾರರು (ನೋಡ್‌ಗಳು, ಹೋಸ್ಟ್‌ಗಳು, ಪರಿಸರಗಳು);
• ಹೆಚ್ಚುವರಿಯಾಗಿ, ನೀವು DNAT ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಟ್ರಾಫಿಕ್ ಫಾರ್ವರ್ಡ್ ನೀತಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಚಾರದ ಅಂಗೀಕಾರವನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು.

ಕ್ಯಾಲಿಕೊ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ GitHub ನಲ್ಲಿ ಮೊದಲ ಕಮಿಟ್‌ಗಳು ಜುಲೈ 2016 ರ ಹಿಂದಿನದು, ಮತ್ತು ಒಂದು ವರ್ಷದ ನಂತರ ಯೋಜನೆಯು ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ಸಂಘಟಿಸುವಲ್ಲಿ ಪ್ರಮುಖ ಸ್ಥಾನವನ್ನು ಪಡೆದುಕೊಂಡಿತು - ಇದು ಸಾಕ್ಷಿಯಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಸಮೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳು, ದಿ ನ್ಯೂ ಸ್ಟಾಕ್ ನಡೆಸಿತು:

K8s ಜೊತೆಗೆ ಅನೇಕ ದೊಡ್ಡ ನಿರ್ವಹಿಸಿದ ಪರಿಹಾರಗಳು, ಉದಾಹರಣೆಗೆ ಅಮೆಜಾನ್ EX, ಅಜುರೆ ಎಕೆಎಸ್, ಗೂಗಲ್ ಜಿಕೆಇ ಮತ್ತು ಇತರರು ಅದನ್ನು ಬಳಸಲು ಶಿಫಾರಸು ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು.

ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ. ತಮ್ಮ ಉತ್ಪನ್ನವನ್ನು ಪರೀಕ್ಷಿಸುವಲ್ಲಿ, ಕ್ಯಾಲಿಕೋ ಅಭಿವೃದ್ಧಿ ತಂಡವು ಖಗೋಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರದರ್ಶಿಸಿತು, 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 ಕರ್ನಲ್‌ಗಳಲ್ಲಿ ಕ್ಯಾಲಿಕೋ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಪರಿಸರದೊಳಗೆ ಪ್ರತ್ಯೇಕತೆ

ಸಾಮಾನ್ಯ ತಿಳುವಳಿಕೆಗಾಗಿ, ಕ್ಯಾಲಿಕೋ ಸಂಕೇತಗಳಲ್ಲಿನ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಪ್ರಮಾಣಿತ ಪದಗಳಿಗಿಂತ ಹೇಗೆ ಭಿನ್ನವಾಗಿವೆ ಮತ್ತು ನಿಯಮಗಳನ್ನು ರಚಿಸುವ ವಿಧಾನವು ಅವುಗಳ ಓದುವಿಕೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ನಮ್ಯತೆಯನ್ನು ಹೇಗೆ ಸರಳಗೊಳಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸರಳವಾದ ಪ್ರಕರಣವನ್ನು ನೋಡೋಣ:

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ 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 ಪೋರ್ಟ್‌ಗೆ ಒಳಬರುವ ದಟ್ಟಣೆಯನ್ನು ಅನುಮತಿಸಿದ್ದೇವೆ. ಮತ್ತು ಅವರು ಸ್ಪಷ್ಟವಾಗಿ ಬೇರೆ ಯಾವುದನ್ನೂ ನಿಷೇಧಿಸಲಿಲ್ಲ. ನೆಟ್‌ವರ್ಕ್ ಪಾಲಿಸಿ ಕಾಣಿಸಿಕೊಂಡ ತಕ್ಷಣ, ನಿರ್ದಿಷ್ಟಪಡಿಸದ ಹೊರತು ಅದರಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ಎಲ್ಲಾ ಆಯ್ಕೆದಾರರು ಪ್ರತ್ಯೇಕಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, ಪ್ರತ್ಯೇಕತೆಯ ನಿಯಮಗಳು ಆಯ್ಕೆಗಾರರಿಂದ ಒಳಗೊಂಡಿರದ ಇತರ ವಸ್ತುಗಳಿಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.

ಉದಾಹರಣೆ ಬಳಸುತ್ತದೆ 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

ನಿಯಮಿತ ನೆಟ್‌ವರ್ಕ್ ಪಾಲಿಸಿ 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 ಕ್ಲೈಂಟ್ ಅನ್ನು ಅನನ್ಯವಾಗಿ ಗುರುತಿಸಬಹುದು. ಅಂತಹ ಕ್ಲೈಂಟ್‌ನ ಸೇವೆಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸುವ ಒಂದು ಪ್ರಾಚೀನ ಉದಾಹರಣೆಯನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ, ಮೇಲೆ ತಿಳಿಸಿದ ರೆಡಿಸ್‌ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ:

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 ನಲ್ಲಿ ನಮ್ಮ ಕ್ಲೈಂಟ್‌ಗಳ ಹಲವಾರು ಸ್ಥಾಪನೆಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ.

ಪಿಎಸ್

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

• «ಭದ್ರತಾ ವೃತ್ತಿಪರರಿಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್ವರ್ಕ್ ನೀತಿಗಳಿಗೆ ಒಂದು ಪರಿಚಯ";
• "ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೆಟ್ವರ್ಕಿಂಗ್ಗೆ ಒಂದು ಸಚಿತ್ರ ಮಾರ್ಗದರ್ಶಿ": ಭಾಗಗಳು 1 ಮತ್ತು 2 (ನೆಟ್‌ವರ್ಕ್ ಮಾದರಿ, ಓವರ್‌ಲೇ ನೆಟ್‌ವರ್ಕ್‌ಗಳು), ಭಾಗ 3 (ಸೇವೆಗಳು ಮತ್ತು ಸಂಚಾರ ಪ್ರಕ್ರಿಯೆ);
• «ಕಂಟೈನರ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಇಂಟರ್‌ಫೇಸ್ (CNI) - ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು ಲಿನಕ್ಸ್ ಕಂಟೈನರ್‌ಗಳಿಗೆ ಪ್ರಮಾಣಿತ».

ಮೂಲ: www.habr.com