ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਲਈ ਕੈਲੀਕੋ: ਜਾਣ-ਪਛਾਣ ਅਤੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਅਨੁਭਵ

ਲੇਖ ਦਾ ਉਦੇਸ਼ ਪਾਠਕ ਨੂੰ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਪ੍ਰਬੰਧਨ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਬੁਨਿਆਦ ਬਾਰੇ ਜਾਣੂ ਕਰਵਾਉਣਾ ਹੈ, ਨਾਲ ਹੀ ਤੀਜੀ-ਧਿਰ ਕੈਲੀਕੋ ਪਲੱਗਇਨ ਜੋ ਮਿਆਰੀ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਰਸਤੇ ਦੇ ਨਾਲ, ਸੰਰਚਨਾ ਦੀ ਸੌਖ ਅਤੇ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਸਾਡੇ ਓਪਰੇਟਿੰਗ ਅਨੁਭਵ ਤੋਂ ਅਸਲ ਉਦਾਹਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਵੇਗਾ।

ਕੁਬਰਨੇਟਸ ਨੈਟਵਰਕਿੰਗ ਉਪਕਰਣ ਦੀ ਇੱਕ ਤੇਜ਼ ਜਾਣ-ਪਛਾਣ

ਇੱਕ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੀ ਕਲਪਨਾ ਇੱਕ ਨੈੱਟਵਰਕ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਹਨਾਂ ਦੀਆਂ ਮੂਲ ਗੱਲਾਂ 'ਤੇ ਸਮੱਗਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਚੁੱਕੇ ਹਾਂ: "ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਲਈ ਇੱਕ ਸਚਿੱਤਰ ਗਾਈਡ"ਅਤੇ"ਸੁਰੱਖਿਆ ਪੇਸ਼ੇਵਰਾਂ ਲਈ ਕੁਬਰਨੇਟਸ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਜਾਣ-ਪਛਾਣ".

ਇਸ ਲੇਖ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਇਹ ਨੋਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ 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 ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਵੱਡੇ ਪ੍ਰਬੰਧਿਤ ਹੱਲ, ਜਿਵੇਂ ਕਿ ਐਮਾਜ਼ਾਨ ਈ.ਕੇ.ਐਸ, Azure AKS, Google GKE ਅਤੇ ਹੋਰਾਂ ਨੇ ਇਸਦੀ ਵਰਤੋਂ ਲਈ ਸਿਫਾਰਸ਼ ਕਰਨੀ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ।

ਪ੍ਰਦਰਸ਼ਨ ਲਈ, ਇੱਥੇ ਸਭ ਕੁਝ ਵਧੀਆ ਹੈ. ਆਪਣੇ ਉਤਪਾਦ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ, ਕੈਲੀਕੋ ਵਿਕਾਸ ਟੀਮ ਨੇ ਖਗੋਲ-ਵਿਗਿਆਨਕ ਪ੍ਰਦਰਸ਼ਨ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ, 50000 ਭੌਤਿਕ ਨੋਡਾਂ 'ਤੇ 500 ਤੋਂ ਵੱਧ ਕੰਟੇਨਰਾਂ ਨੂੰ 20 ਕੰਟੇਨਰਾਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਦੀ ਰਚਨਾ ਦਰ ਨਾਲ ਚਲਾਇਆ। ਸਕੇਲਿੰਗ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਪਛਾਣੀ ਗਈ। ਅਜਿਹੇ ਨਤੀਜੇ ਐਲਾਨ ਕੀਤੇ ਗਏ ਸਨ ਪਹਿਲਾਂ ਹੀ ਪਹਿਲੇ ਸੰਸਕਰਣ ਦੀ ਘੋਸ਼ਣਾ 'ਤੇ. ਥ੍ਰੁਪੁੱਟ ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਸੁਤੰਤਰ ਅਧਿਐਨ ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ ਕੈਲੀਕੋ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਫਲੈਨਲ ਦੀ ਤਰ੍ਹਾਂ ਹੀ ਚੰਗੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ:

ਪ੍ਰੋਜੈਕਟ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ, ਇਹ K8s, OpenShift, OpenStack, ਪ੍ਰਬੰਧਿਤ ਪ੍ਰਸਿੱਧ ਹੱਲਾਂ ਵਿੱਚ ਕੰਮ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਕਲੱਸਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕੈਲੀਕੋ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੰਭਵ ਹੈ. ਕਿੱਕ, ਸੇਵਾ ਜਾਲ ਨੈੱਟਵਰਕ ਦੇ ਨਿਰਮਾਣ ਦੇ ਹਵਾਲੇ ਹਨ (ਇੱਥੇ ਇੱਕ ਉਦਾਹਰਨ ਹੈ Istio ਦੇ ਨਾਲ ਜੋੜ ਕੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ).

ਕੈਲੀਕੋ ਨਾਲ ਅਭਿਆਸ ਕਰੋ

ਵਨੀਲਾ ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਆਮ ਮਾਮਲੇ ਵਿੱਚ, CNI ਸਥਾਪਤ ਕਰਨਾ ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਹੇਠਾਂ ਆਉਂਦਾ ਹੈ calico.yaml, ਅਧਿਕਾਰਤ ਵੈੱਬਸਾਈਟ ਤੋਂ ਡਾਊਨਲੋਡ ਕੀਤਾ, ਵਰਤ ਕੇ kubectl apply -f.

ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਪਲੱਗਇਨ ਦਾ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਕੁਬਰਨੇਟਸ ਦੇ ਨਵੀਨਤਮ 2-3 ਸੰਸਕਰਣਾਂ ਦੇ ਅਨੁਕੂਲ ਹੈ: ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਓਪਰੇਸ਼ਨ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇਸਦੀ ਗਰੰਟੀ ਨਹੀਂ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਦੇ ਅਨੁਸਾਰ, ਕੈਲੀਕੋ iptables ਜਾਂ IPVS ਦੇ ਸਿਖਰ 'ਤੇ, CentOS 3.10, Ubuntu 7 ਜਾਂ Debian 16 'ਤੇ ਚੱਲ ਰਹੇ 8 ਤੋਂ ਉੱਪਰ ਲੀਨਕਸ ਕਰਨਲ 'ਤੇ ਚੱਲਦਾ ਹੈ।

ਵਾਤਾਵਰਣ ਦੇ ਅੰਦਰ ਇਕੱਲਤਾ

ਇੱਕ ਆਮ ਸਮਝ ਲਈ, ਆਉ ਇਹ ਸਮਝਣ ਲਈ ਇੱਕ ਸਧਾਰਨ ਕੇਸ ਵੇਖੀਏ ਕਿ ਕੈਲੀਕੋ ਨੋਟੇਸ਼ਨ ਵਿੱਚ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਮਿਆਰੀ ਨੀਤੀਆਂ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰੀਆਂ ਹਨ ਅਤੇ ਨਿਯਮ ਬਣਾਉਣ ਦੀ ਪਹੁੰਚ ਉਹਨਾਂ ਦੀ ਪੜ੍ਹਨਯੋਗਤਾ ਅਤੇ ਸੰਰਚਨਾ ਲਚਕਤਾ ਨੂੰ ਕਿਵੇਂ ਸਰਲ ਬਣਾਉਂਦੀ ਹੈ:

ਕਲੱਸਟਰ ਵਿੱਚ 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

ਰੈਗੂਲਰ 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 ਕਲਾਇੰਟ ਦੀ ਵਿਲੱਖਣ ਪਛਾਣ ਕਰ ਸਕਦੇ ਹਾਂ। ਹੇਠਾਂ ਅਜਿਹੇ ਗਾਹਕ ਦੀ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਸੀਮਤ ਕਰਨ ਦਾ ਇੱਕ ਮੁੱਢਲਾ ਉਦਾਹਰਨ ਹੈ, ਉੱਪਰ ਦੱਸੇ 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) - ਲੀਨਕਸ ਕੰਟੇਨਰਾਂ ਲਈ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਅਤੇ ਸਟੈਂਡਰਡ".

ਸਰੋਤ: www.habr.com