ਸੁਰੱਖਿਆ ਪੇਸ਼ੇਵਰਾਂ ਲਈ ਕੁਬਰਨੇਟਸ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਜਾਣ-ਪਛਾਣ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਲੇਖ ਦੇ ਲੇਖਕ, ਰੀਯੂਵੇਨ ਹੈਰੀਸਨ, ਕੋਲ ਸੌਫਟਵੇਅਰ ਵਿਕਾਸ ਵਿੱਚ 20 ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਦਾ ਤਜਰਬਾ ਹੈ, ਅਤੇ ਅੱਜ ਟੂਫਿਨ ਦੇ ਸੀਟੀਓ ਅਤੇ ਸਹਿ-ਸੰਸਥਾਪਕ ਹਨ, ਇੱਕ ਕੰਪਨੀ ਜੋ ਸੁਰੱਖਿਆ ਨੀਤੀ ਪ੍ਰਬੰਧਨ ਹੱਲ ਤਿਆਰ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਕਿ ਉਹ Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਨੂੰ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਨੈੱਟਵਰਕ ਵਿਭਾਜਨ ਲਈ ਇੱਕ ਕਾਫ਼ੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਟੂਲ ਵਜੋਂ ਦੇਖਦਾ ਹੈ, ਉਹ ਇਹ ਵੀ ਮੰਨਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਅਮਲ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਇੰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ। ਇਹ ਸਮੱਗਰੀ (ਕਾਫ਼ੀ ਵਿਸ਼ਾਲ) ਇਸ ਮੁੱਦੇ ਬਾਰੇ ਮਾਹਿਰਾਂ ਦੀ ਜਾਗਰੂਕਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਅਤੇ ਲੋੜੀਂਦੀਆਂ ਸੰਰਚਨਾਵਾਂ ਬਣਾਉਣ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਮਦਦ ਕਰਨ ਲਈ ਹੈ।

ਅੱਜ, ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ ਆਪਣੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕੁਬਰਨੇਟਸ ਦੀ ਚੋਣ ਕਰ ਰਹੀਆਂ ਹਨ। ਇਸ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਦਿਲਚਸਪੀ ਇੰਨੀ ਜ਼ਿਆਦਾ ਹੈ ਕਿ ਕੁਝ ਕੁਬਰਨੇਟਸ ਨੂੰ "ਡਾਟਾ ਸੈਂਟਰ ਲਈ ਨਵਾਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ" ਕਹਿ ਰਹੇ ਹਨ। ਹੌਲੀ-ਹੌਲੀ, ਕੁਬਰਨੇਟਸ (ਜਾਂ k8s) ਨੂੰ ਕਾਰੋਬਾਰ ਦੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਵਜੋਂ ਸਮਝਿਆ ਜਾਣ ਲੱਗਾ ਹੈ, ਜਿਸ ਲਈ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਸਮੇਤ ਪਰਿਪੱਕ ਵਪਾਰਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸੰਗਠਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸੁਰੱਖਿਆ ਪੇਸ਼ੇਵਰਾਂ ਲਈ ਜੋ ਕੁਬਰਨੇਟਸ ਨਾਲ ਕੰਮ ਕਰਕੇ ਉਲਝੇ ਹੋਏ ਹਨ, ਅਸਲ ਖੁਲਾਸਾ ਪਲੇਟਫਾਰਮ ਦੀ ਡਿਫੌਲਟ ਨੀਤੀ ਹੋ ਸਕਦੀ ਹੈ: ਹਰ ਚੀਜ਼ ਦੀ ਆਗਿਆ ਦਿਓ।

ਇਹ ਗਾਈਡ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗੀ; ਸਮਝੋ ਕਿ ਉਹ ਨਿਯਮਤ ਫਾਇਰਵਾਲਾਂ ਦੇ ਨਿਯਮਾਂ ਤੋਂ ਕਿਵੇਂ ਵੱਖਰੇ ਹਨ। ਇਹ ਕੁਝ ਕਮੀਆਂ ਨੂੰ ਵੀ ਕਵਰ ਕਰੇਗਾ ਅਤੇ ਕੁਬਰਨੇਟਸ 'ਤੇ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਮਦਦ ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ ਪ੍ਰਦਾਨ ਕਰੇਗਾ।

Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ

Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀ ਵਿਧੀ ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ ਲੇਅਰ (OSI ਮਾਡਲ ਵਿੱਚ ਤੀਜਾ) 'ਤੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਤੈਨਾਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਆਪਸੀ ਤਾਲਮੇਲ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਵਿੱਚ ਆਧੁਨਿਕ ਫਾਇਰਵਾਲਾਂ ਦੀਆਂ ਕੁਝ ਉੱਨਤ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਘਾਟ ਹੈ, ਜਿਵੇਂ ਕਿ OSI ਲੇਅਰ 7 ਇਨਫੋਰਸਮੈਂਟ ਅਤੇ ਖਤਰੇ ਦਾ ਪਤਾ ਲਗਾਉਣਾ, ਪਰ ਉਹ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਦਾ ਇੱਕ ਬੁਨਿਆਦੀ ਪੱਧਰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕ ਵਧੀਆ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ।

ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਪੌਡਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀਆਂ ਹਨ

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

ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ

ਹੋਰ ਕੁਬਰਨੇਟਸ ਸਰੋਤਾਂ ਵਾਂਗ, ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ YAML ਵਿੱਚ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਐਪਲੀਕੇਸ਼ਨ balance ਤੱਕ ਪਹੁੰਚ postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਇਹ ਸਕਰੀਨਸ਼ਾਟ, ਅਗਲੇ ਸਾਰੇ ਸਮਾਨਾਂ ਵਾਂਗ, ਮੂਲ ਕੁਬਰਨੇਟਸ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਹੀਂ, ਬਲਕਿ ਟੂਫਿਨ ਓਰਕਾ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਜੋ ਕਿ ਅਸਲ ਲੇਖ ਦੇ ਲੇਖਕ ਦੀ ਕੰਪਨੀ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਜਿਸਦਾ ਜ਼ਿਕਰ ਸਮੱਗਰੀ ਦੇ ਅੰਤ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਹੈ।)

ਤੁਹਾਡੀ ਆਪਣੀ ਨੈੱਟਵਰਕ ਨੀਤੀ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ YAML ਦੇ ਬੁਨਿਆਦੀ ਗਿਆਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਹ ਭਾਸ਼ਾ ਇੰਡੈਂਟੇਸ਼ਨ 'ਤੇ ਅਧਾਰਤ ਹੈ (ਟੈਬਾਂ ਦੀ ਬਜਾਏ ਸਪੇਸ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ)। ਇੱਕ ਇੰਡੈਂਟਡ ਐਲੀਮੈਂਟ ਇਸਦੇ ਉੱਪਰਲੇ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਇੰਡੈਂਟਡ ਐਲੀਮੈਂਟ ਨਾਲ ਸਬੰਧਤ ਹੈ। ਇੱਕ ਨਵੀਂ ਸੂਚੀ ਤੱਤ ਇੱਕ ਹਾਈਫਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਬਾਕੀ ਸਾਰੇ ਤੱਤਾਂ ਦਾ ਰੂਪ ਹੁੰਦਾ ਹੈ ਕੁੰਜੀ-ਮੁੱਲ.

YAML ਵਿੱਚ ਨੀਤੀ ਦਾ ਵਰਣਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਵਰਤੋਂ kubectlਇਸ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਬਣਾਉਣ ਲਈ:

kubectl create -f policy.yaml

ਨੈੱਟਵਰਕ ਨੀਤੀ ਨਿਰਧਾਰਨ

ਕੁਬਰਨੇਟਸ ਨੈੱਟਵਰਕ ਨੀਤੀ ਨਿਰਧਾਰਨ ਵਿੱਚ ਚਾਰ ਤੱਤ ਸ਼ਾਮਲ ਹਨ:

1. podSelector: ਇਸ ਨੀਤੀ (ਟੀਚੇ) ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਪੌਡਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ - ਲੋੜੀਂਦਾ;
2. policyTypes: ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਕਿਸ ਕਿਸਮ ਦੀਆਂ ਨੀਤੀਆਂ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ: ਪ੍ਰਵੇਸ਼ ਅਤੇ/ਜਾਂ ਨਿਕਾਸੀ - ਵਿਕਲਪਿਕ, ਪਰ ਮੈਂ ਇਸਨੂੰ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ;
3. ingress: ਪਰਿਭਾਸ਼ਿਤ ਆਗਿਆ ਹੈ ਆਉਣ ਵਾਲੇ ਟਾਰਗੇਟ ਪੌਡਾਂ ਲਈ ਆਵਾਜਾਈ ਵਿਕਲਪਿਕ ਹੈ;
4. egress: ਪਰਿਭਾਸ਼ਿਤ ਆਗਿਆ ਹੈ ਆਊਟਗੋਇੰਗ ਟਾਰਗੇਟ ਪੌਡਸ ਤੋਂ ਆਵਾਜਾਈ ਵਿਕਲਪਿਕ ਹੈ।

ਕੁਬਰਨੇਟਸ ਵੈੱਬਸਾਈਟ ਤੋਂ ਲਈ ਗਈ ਉਦਾਹਰਨ (ਮੈਂ ਬਦਲਿਆ role 'ਤੇ app), ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਾਰੇ ਚਾਰ ਤੱਤ ਕਿਵੇਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: 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

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਸਾਰੇ ਚਾਰ ਤੱਤਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਸਿਰਫ਼ ਲਾਜ਼ਮੀ ਹੈ podSelector, ਹੋਰ ਮਾਪਦੰਡ ਲੋੜ ਅਨੁਸਾਰ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ ਛੱਡ ਦਿੰਦੇ ਹੋ policyTypes, ਨੀਤੀ ਦੀ ਵਿਆਖਿਆ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤੀ ਜਾਵੇਗੀ:

• ਮੂਲ ਰੂਪ ਵਿੱਚ, ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਪ੍ਰਵੇਸ਼ ਵਾਲੇ ਪਾਸੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਨੀਤੀ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਇਹ ਮੰਨ ਲਵੇਗਾ ਕਿ ਸਾਰੇ ਆਵਾਜਾਈ ਦੀ ਮਨਾਹੀ ਹੈ।
• ਨਿਕਾਸ ਵਾਲੇ ਪਾਸੇ ਦਾ ਵਿਵਹਾਰ ਸੰਬੰਧਿਤ ਨਿਕਾਸੀ ਪੈਰਾਮੀਟਰ ਦੀ ਮੌਜੂਦਗੀ ਜਾਂ ਗੈਰਹਾਜ਼ਰੀ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਵੇਗਾ।

ਗਲਤੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਮੈਂ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਹਮੇਸ਼ਾ ਇਸ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰੋ policyTypes.

ਉਪਰੋਕਤ ਤਰਕ ਦੇ ਅਨੁਸਾਰ, ਜੇਕਰ ਪੈਰਾਮੀਟਰ ingress ਅਤੇ / ਜਾਂ egress ਛੱਡਿਆ ਗਿਆ, ਨੀਤੀ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰੇਗੀ (ਹੇਠਾਂ "ਸਟਰਿੱਪਿੰਗ ਨਿਯਮ" ਦੇਖੋ)।

ਪੂਰਵ-ਨਿਰਧਾਰਤ ਨੀਤੀ ਇਜਾਜ਼ਤ ਹੈ

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

ਨੇਮਸਪੇਸ

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

ਜ਼ਿਆਦਾਤਰ ਕੁਬਰਨੇਟਸ ਕੰਪੋਨੈਂਟਸ ਵਾਂਗ, ਨੈੱਟਵਰਕ ਪਾਲਿਸੀਆਂ ਇੱਕ ਖਾਸ ਨੇਮਸਪੇਸ ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ। ਬਲਾਕ ਵਿੱਚ metadata ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਨੀਤੀ ਕਿਸ ਸਪੇਸ ਨਾਲ ਸਬੰਧਤ ਹੈ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

ਜੇਕਰ ਮੇਟਾਡੇਟਾ ਵਿੱਚ ਨੇਮਸਪੇਸ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਸਿਸਟਮ kubectl (ਮੂਲ ਰੂਪ ਵਿੱਚ) ਵਿੱਚ ਨਿਰਧਾਰਿਤ ਨੇਮਸਪੇਸ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

ਮੈਂ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਨੇਮਸਪੇਸ ਦਿਓ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਇੱਕ ਨੀਤੀ ਨਹੀਂ ਲਿਖ ਰਹੇ ਹੋ ਜੋ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਤੋਂ ਵੱਧ ਨਾਮ-ਸਥਾਨਾਂ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ।

ਮੁੱਖ ਤੱਤ podSelector ਪਾਲਿਸੀ ਵਿੱਚ ਨੇਮਸਪੇਸ ਤੋਂ ਪੌਡਸ ਦੀ ਚੋਣ ਕਰੇਗਾ ਜਿਸ ਨਾਲ ਪਾਲਿਸੀ ਸਬੰਧਤ ਹੈ (ਇਸ ਨੂੰ ਕਿਸੇ ਹੋਰ ਨੇਮਸਪੇਸ ਤੋਂ ਪੌਡਸ ਤੱਕ ਪਹੁੰਚ ਤੋਂ ਇਨਕਾਰ ਕੀਤਾ ਗਿਆ ਹੈ)।

ਇਸੇ ਤਰ੍ਹਾਂ, ਪੋਡਸਿਲੈਕਟਰ ਪ੍ਰਵੇਸ਼ ਅਤੇ ਨਿਕਾਸੀ ਬਲਾਕਾਂ ਵਿੱਚ ਸਿਰਫ਼ ਉਹਨਾਂ ਦੇ ਆਪਣੇ ਨਾਮ-ਸਥਾਨ ਤੋਂ ਪੌਡਾਂ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਤੱਕ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨਾਲ ਨਹੀਂ ਜੋੜਦੇ namespaceSelector (ਇਸ ਬਾਰੇ “ਨੇਮ ਸਪੇਸ ਅਤੇ ਪੌਡਸ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰੋ” ਭਾਗ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ)।

ਨੀਤੀ ਨਾਮਕਰਨ ਨਿਯਮ

ਪਾਲਿਸੀ ਦੇ ਨਾਮ ਇੱਕੋ ਨੇਮ ਸਪੇਸ ਵਿੱਚ ਵਿਲੱਖਣ ਹਨ। ਇੱਕੋ ਸਪੇਸ ਵਿੱਚ ਇੱਕੋ ਨਾਮ ਦੀਆਂ ਦੋ ਪਾਲਿਸੀਆਂ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ, ਪਰ ਵੱਖ-ਵੱਖ ਸਪੇਸ ਵਿੱਚ ਇੱਕੋ ਨਾਮ ਵਾਲੀਆਂ ਨੀਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਉਦੋਂ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕੋ ਨੀਤੀ ਨੂੰ ਕਈ ਥਾਵਾਂ 'ਤੇ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਮੈਨੂੰ ਖਾਸ ਤੌਰ 'ਤੇ ਨਾਮਕਰਨ ਵਿਧੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਪਸੰਦ ਹੈ। ਇਸ ਵਿੱਚ ਟਾਰਗੇਟ ਪੌਡਸ ਦੇ ਨਾਲ ਨੇਮਸਪੇਸ ਨਾਮ ਨੂੰ ਜੋੜਨਾ ਸ਼ਾਮਲ ਹੈ। ਉਦਾਹਰਣ ਲਈ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

ਲੇਬਲ

ਤੁਸੀਂ ਕਸਟਮ ਲੇਬਲ ਨੂੰ ਕੁਬਰਨੇਟਸ ਆਬਜੈਕਟ, ਜਿਵੇਂ ਕਿ ਪੌਡ ਅਤੇ ਨੇਮਸਪੇਸ ਨਾਲ ਜੋੜ ਸਕਦੇ ਹੋ। ਲੇਬਲ (ਲੇਬਲ - ਟੈਗ) ਕਲਾਉਡ ਵਿੱਚ ਟੈਗਸ ਦੇ ਬਰਾਬਰ ਹਨ। Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਚੁਣਨ ਲਈ ਲੇਬਲ ਵਰਤਦੀਆਂ ਹਨ ਫਲੀਆਂਜਿਸ ਲਈ ਉਹ ਲਾਗੂ ਹੁੰਦੇ ਹਨ:

podSelector:
  matchLabels:
    role: db

… ਜਾਂ ਨਾਮ ਸਥਾਨਜਿਸ ਲਈ ਉਹ ਅਪਲਾਈ ਕਰਦੇ ਹਨ। ਇਹ ਉਦਾਹਰਨ ਅਨੁਸਾਰੀ ਲੇਬਲਾਂ ਦੇ ਨਾਲ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਾਰੇ ਪੌਡਾਂ ਦੀ ਚੋਣ ਕਰਦੀ ਹੈ:

namespaceSelector:
  matchLabels:
    project: myproject

ਇੱਕ ਸਾਵਧਾਨੀ: ਵਰਤਣ ਵੇਲੇ namespaceSelector ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਦੁਆਰਾ ਚੁਣੇ ਗਏ ਨਾਮ-ਸਥਾਨਾਂ ਵਿੱਚ ਸਹੀ ਲੇਬਲ ਹੈ. ਧਿਆਨ ਰੱਖੋ ਕਿ ਬਿਲਟ-ਇਨ ਨੇਮਸਪੇਸ ਜਿਵੇਂ ਕਿ default и kube-system, ਮੂਲ ਰੂਪ ਵਿੱਚ ਲੇਬਲ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦੇ ਹਨ।

ਤੁਸੀਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਇੱਕ ਸਪੇਸ ਵਿੱਚ ਇੱਕ ਲੇਬਲ ਜੋੜ ਸਕਦੇ ਹੋ:

kubectl label namespace default namespace=default

ਉਸੇ ਸਮੇਂ, ਭਾਗ ਵਿੱਚ ਨਾਮ-ਸਥਾਨ metadata ਅਸਲ ਸਪੇਸ ਨਾਮ ਦਾ ਹਵਾਲਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਲੇਬਲ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ

ਫਾਇਰਵਾਲ ਨੀਤੀਆਂ ਵਿੱਚ ਸਰੋਤਾਂ ਅਤੇ ਮੰਜ਼ਿਲਾਂ ਦੇ ਨਾਲ ਨਿਯਮ ਹੁੰਦੇ ਹਨ। Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਨੂੰ ਇੱਕ ਟੀਚੇ ਲਈ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ - ਪੌਡਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਜਿਸ 'ਤੇ ਉਹ ਲਾਗੂ ਹੁੰਦੇ ਹਨ - ਅਤੇ ਫਿਰ ਪ੍ਰਵੇਸ਼ ਅਤੇ/ਜਾਂ ਨਿਕਾਸੀ ਟ੍ਰੈਫਿਕ ਲਈ ਨਿਯਮ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ। ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਨੀਤੀ ਦਾ ਟੀਚਾ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਾਰੇ ਪੌਡ ਹੋਣਗੇ default ਕੁੰਜੀ ਦੇ ਨਾਲ ਲੇਬਲ ਦੇ ਨਾਲ app ਅਤੇ ਅਰਥ db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: 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

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

ਇਹ ਦੋ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦੇ ਬਰਾਬਰ ਹੈ: ਇਨਗ੍ਰੇਸ → ਟਾਰਗੇਟ; ਟੀਚਾ → ਨਿਕਾਸੀ।

Egress ਅਤੇ DNS (ਮਹੱਤਵਪੂਰਨ!)

ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਆਵਾਜਾਈ ਨੂੰ ਸੀਮਤ ਕਰਕੇ, DNS 'ਤੇ ਵਿਸ਼ੇਸ਼ ਧਿਆਨ ਦਿਓ - Kubernetes ਇਸ ਸੇਵਾ ਦੀ ਵਰਤੋਂ IP ਪਤਿਆਂ 'ਤੇ ਸੇਵਾਵਾਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਉਣ ਲਈ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੀ ਨੀਤੀ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ ਕਿਉਂਕਿ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ ਹੈ balance DNS ਤੱਕ ਪਹੁੰਚ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

ਤੁਸੀਂ DNS ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਖੋਲ੍ਹ ਕੇ ਇਸਨੂੰ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

ਆਖਰੀ ਤੱਤ to ਖਾਲੀ ਹੈ, ਅਤੇ ਇਸਲਈ ਇਹ ਅਸਿੱਧੇ ਤੌਰ 'ਤੇ ਚੁਣਦਾ ਹੈ ਸਾਰੇ ਨਾਮ-ਸਥਾਨਾਂ ਵਿੱਚ ਸਾਰੇ ਪੌਡ, ਇਜਾਜ਼ਤ ਦੇ ਰਿਹਾ ਹੈ balance DNS ਸਵਾਲਾਂ ਨੂੰ ਉਚਿਤ ਕੁਬਰਨੇਟਸ ਸੇਵਾ (ਆਮ ਤੌਰ 'ਤੇ ਸਪੇਸ ਵਿੱਚ ਚੱਲਦਾ ਹੈ) ਨੂੰ ਭੇਜੋ kube-system).

ਇਹ ਪਹੁੰਚ ਕੰਮ ਕਰਦੀ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਆਗਿਆਕਾਰੀ ਅਤੇ ਅਸੁਰੱਖਿਅਤ, ਕਿਉਂਕਿ ਇਹ DNS ਸਵਾਲਾਂ ਨੂੰ ਕਲੱਸਟਰ ਤੋਂ ਬਾਹਰ ਨਿਰਦੇਸ਼ਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਤੁਸੀਂ ਇਸਨੂੰ ਲਗਾਤਾਰ ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚ ਸੁਧਾਰ ਸਕਦੇ ਹੋ।

1. ਸਿਰਫ਼ DNS ਸਵਾਲਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ ਅੰਦਰ ਜੋੜ ਕੇ ਕਲੱਸਟਰ namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. ਸਿਰਫ਼ ਨਾਮ-ਸਥਾਨ ਦੇ ਅੰਦਰ DNS ਸਵਾਲਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ kube-system.

ਅਜਿਹਾ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਨੇਮਸਪੇਸ ਵਿੱਚ ਇੱਕ ਲੇਬਲ ਜੋੜਨਾ ਹੋਵੇਗਾ kube-system: kubectl label namespace kube-system namespace=kube-system - ਅਤੇ ਇਸਨੂੰ ਪਾਲਿਸੀ ਵਿੱਚ ਲਿਖੋ namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. ਪਾਗਲ ਲੋਕ ਹੋਰ ਵੀ ਅੱਗੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ DNS ਸਵਾਲਾਂ ਨੂੰ ਇੱਕ ਖਾਸ DNS ਸੇਵਾ ਤੱਕ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹਨ kube-system. ਸੈਕਸ਼ਨ "ਨੇਮ ਸਪੇਸ ਅਤੇ ਪੌਡ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰੋ" ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ।

ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਨੇਮਸਪੇਸ ਪੱਧਰ 'ਤੇ DNS ਨੂੰ ਹੱਲ ਕਰਨਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇਸਨੂੰ ਹਰੇਕ ਸੇਵਾ ਲਈ ਖੋਲ੍ਹਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

ਖਾਲੀ podSelector ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਾਰੇ ਪੌਡ ਚੁਣਦਾ ਹੈ।

ਪਹਿਲਾ ਮੈਚ ਅਤੇ ਨਿਯਮ ਕ੍ਰਮ

ਪਰੰਪਰਾਗਤ ਫਾਇਰਵਾਲਾਂ ਵਿੱਚ, ਇੱਕ ਪੈਕੇਟ ਉੱਤੇ ਕਿਰਿਆ (ਇਜਾਜ਼ਤ ਜਾਂ ਇਨਕਾਰ) ਨੂੰ ਪਹਿਲੇ ਨਿਯਮ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਇਹ ਸੰਤੁਸ਼ਟ ਕਰਦਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਵਿੱਚ, ਨੀਤੀਆਂ ਦਾ ਕ੍ਰਮ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦਾ।

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਜਦੋਂ ਕੋਈ ਨੀਤੀਆਂ ਸੈਟ ਨਹੀਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਪੌਡਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਦੀ ਆਗਿਆ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉਹ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਜਾਣਕਾਰੀ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਨ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਨੀਤੀਆਂ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਦੁਆਰਾ ਪ੍ਰਭਾਵਿਤ ਹਰੇਕ ਪੌਡ ਨੂੰ ਚੁਣੀਆਂ ਗਈਆਂ ਸਾਰੀਆਂ ਨੀਤੀਆਂ ਦੇ ਵਿਘਨ (ਲਾਜ਼ੀਕਲ OR) ਦੇ ਅਨੁਸਾਰ ਅਲੱਗ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਪਾਲਿਸੀ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਨਾ ਹੋਣ ਵਾਲੀਆਂ ਫਲੀਆਂ ਖੁੱਲ੍ਹੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।

ਤੁਸੀਂ ਇੱਕ ਸਟ੍ਰਿਪਿੰਗ ਨਿਯਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ।

ਸਟ੍ਰਿਪਿੰਗ ਨਿਯਮ ("ਇਨਕਾਰ")

ਫਾਇਰਵਾਲ ਨੀਤੀਆਂ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦੀਆਂ ਹਨ ਜਿਸ ਦੀ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕੋਈ ਇਨਕਾਰੀ ਕਾਰਵਾਈ ਨਹੀਂ ਹੈ, ਹਾਲਾਂਕਿ, ਸਰੋਤ ਪੌਡਾਂ (ਪ੍ਰਵੇਸ਼) ਦੇ ਇੱਕ ਖਾਲੀ ਸਮੂਹ ਦੀ ਚੋਣ ਕਰਕੇ ਇੱਕ ਨਿਯਮਤ (ਅਨੁਕੂਲ) ਨੀਤੀ ਨਾਲ ਇੱਕ ਸਮਾਨ ਪ੍ਰਭਾਵ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

ਇਹ ਨੀਤੀ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਾਰੇ ਪੌਡਾਂ ਨੂੰ ਚੁਣਦੀ ਹੈ ਅਤੇ ਆਉਣ ਵਾਲੇ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਤੋਂ ਇਨਕਾਰ ਕਰਦੇ ਹੋਏ, ਪ੍ਰਵੇਸ਼ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਛੱਡਦੀ ਹੈ।

ਇਸੇ ਤਰ੍ਹਾਂ, ਤੁਸੀਂ ਇੱਕ ਨੇਮਸਪੇਸ ਤੋਂ ਸਾਰੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦੇ ਹੋ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਨੇਮਸਪੇਸ ਵਿੱਚ ਪੌਡਾਂ ਤੱਕ ਟ੍ਰੈਫਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੀਆਂ ਕੋਈ ਵੀ ਵਾਧੂ ਪਾਲਿਸੀਆਂ ਇਸ ਨਿਯਮ ਉੱਤੇ ਪਹਿਲ ਦੇਣਗੀਆਂ (ਫਾਇਰਵਾਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਅਸਵੀਕਾਰ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਆਗਿਆ ਨਿਯਮ ਜੋੜਨ ਦੇ ਸਮਾਨ)।

ਹਰ ਚੀਜ਼ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ (ਕੋਈ-ਕੋਈ-ਕੋਈ-ਇਜਾਜ਼ਤ ਦਿਓ)

ਸਭ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿਓ ਨੀਤੀ ਬਣਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਉੱਪਰ ਦਿੱਤੀ ਗਈ ਇਨਕਾਰ ਨੀਤੀ ਨੂੰ ਖਾਲੀ ਤੱਤ ਨਾਲ ਪੂਰਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

ਤੱਕ ਪਹੁੰਚ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਸਾਰੇ ਨਾਮ-ਸਥਾਨਾਂ (ਅਤੇ ਸਾਰੇ IP) ਵਿੱਚ ਸਾਰੇ ਪੌਡ ਨਾਮ-ਸਪੇਸ ਵਿੱਚ ਕਿਸੇ ਵੀ ਪੌਡ ਲਈ default. ਇਹ ਵਿਵਹਾਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਮਰਥਿਤ ਹੁੰਦਾ ਹੈ, ਇਸਲਈ ਇਸਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਹੋਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਸਮੱਸਿਆ ਦਾ ਨਿਦਾਨ ਕਰਨ ਲਈ ਕੁਝ ਖਾਸ ਅਨੁਮਤੀਆਂ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਯੋਗ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।

ਸਿਰਫ਼ ਤੱਕ ਪਹੁੰਚ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਨਿਯਮ ਨੂੰ ਸੰਕੁਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਪੌਡਾਂ ਦਾ ਇੱਕ ਖਾਸ ਸਮੂਹ (app:balanceਨਾਮ-ਸਥਾਨ ਵਿੱਚ default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

ਨਿਮਨਲਿਖਤ ਨੀਤੀ ਕਲੱਸਟਰ ਤੋਂ ਬਾਹਰ ਕਿਸੇ ਵੀ IP ਤੱਕ ਪਹੁੰਚ ਸਮੇਤ ਸਾਰੇ ਪ੍ਰਵੇਸ਼ ਅਤੇ ਨਿਕਾਸੀ ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

ਕਈ ਨੀਤੀਆਂ ਦਾ ਸੰਯੋਗ ਕਰਨਾ

ਨੀਤੀਆਂ ਨੂੰ ਤਿੰਨ ਪੱਧਰਾਂ 'ਤੇ ਲਾਜ਼ੀਕਲ OR ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ; ਹਰੇਕ ਪੌਡ ਦੀਆਂ ਅਨੁਮਤੀਆਂ ਇਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਨੀਤੀਆਂ ਦੇ ਖੰਡਨ ਦੇ ਅਨੁਸਾਰ ਸੈੱਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ:

1. ਖੇਤਾਂ ਵਿੱਚ from и to ਤੱਤਾਂ ਦੀਆਂ ਤਿੰਨ ਕਿਸਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਇਹ ਸਾਰੇ OR ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਹਨ):

• namespaceSelector - ਪੂਰਾ ਨਾਮ-ਸਥਾਨ ਚੁਣਦਾ ਹੈ;
• podSelector - ਪੌਡ ਚੁਣਦਾ ਹੈ;
• ipBlock — ਇੱਕ ਸਬਨੈੱਟ ਚੁਣਦਾ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਉਪ-ਭਾਗਾਂ ਵਿੱਚ ਤੱਤਾਂ ਦੀ ਸੰਖਿਆ (ਇੱਕੋ ਜਿਹੇ ਵੀ) from/to ਸੀਮਿਤ ਨਹੀਂ। ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ ਲਾਜ਼ੀਕਲ OR ਦੁਆਰਾ ਜੋੜਿਆ ਜਾਵੇਗਾ।

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. ਪਾਲਿਸੀ ਸੈਕਸ਼ਨ ਦੇ ਅੰਦਰ ingress ਬਹੁਤ ਸਾਰੇ ਤੱਤ ਹੋ ਸਕਦੇ ਹਨ from (ਲਾਜ਼ੀਕਲ OR ਦੁਆਰਾ ਜੋੜਿਆ ਗਿਆ)। ਇਸੇ ਤਰ੍ਹਾਂ, ਸੈਕਸ਼ਨ egress ਬਹੁਤ ਸਾਰੇ ਤੱਤ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨ to (ਵਿਛੋੜੇ ਦੁਆਰਾ ਵੀ ਜੋੜਿਆ ਗਿਆ):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. ਵੱਖ-ਵੱਖ ਨੀਤੀਆਂ ਨੂੰ ਵੀ ਤਰਕਪੂਰਨ OR ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ

ਪਰ ਉਹਨਾਂ ਨੂੰ ਜੋੜਨ ਵੇਲੇ, ਇੱਕ ਸੀਮਾ ਹੈ ਜਿਸ 'ਤੇ ਇਸ਼ਾਰਾ ਕੀਤਾ ਕ੍ਰਿਸ ਕੂਨੀ: Kubernetes ਸਿਰਫ਼ ਵੱਖ-ਵੱਖ ਨਾਲ ਨੀਤੀਆਂ ਨੂੰ ਜੋੜ ਸਕਦੇ ਹਨ policyTypes (Ingress ਜ Egress). ਪ੍ਰਵੇਸ਼ (ਜਾਂ ਨਿਕਾਸ) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਾਲੀਆਂ ਨੀਤੀਆਂ ਇੱਕ ਦੂਜੇ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨਗੀਆਂ।

ਨਾਮ-ਸਥਾਨਾਂ ਵਿਚਕਾਰ ਸਬੰਧ

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਨਾਮ-ਸਥਾਨਾਂ ਵਿਚਕਾਰ ਜਾਣਕਾਰੀ ਸਾਂਝੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਇਸ ਨੂੰ ਇੱਕ ਅਸਵੀਕਾਰ ਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੋ ਟ੍ਰੈਫਿਕ ਆਊਟਗੋਇੰਗ ਅਤੇ/ਜਾਂ ਨਾਮ-ਸਪੇਸ ਵਿੱਚ ਆਉਣ ਨੂੰ ਰੋਕ ਦੇਵੇਗੀ (ਉਪਰ "ਸਟਰਿੱਪਿੰਗ ਨਿਯਮ" ਦੇਖੋ)।

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਨੇਮਸਪੇਸ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਬਲੌਕ ਕਰ ਲਿਆ ਹੈ (ਉਪਰੋਕਤ "ਸਟ੍ਰਿਪਿੰਗ ਨਿਯਮ" ਵੇਖੋ), ਤੁਸੀਂ ਇੱਕ ਖਾਸ ਨੇਮਸਪੇਸ ਤੋਂ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਇਨਕਾਰ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਵਿੱਚ ਅਪਵਾਦ ਬਣਾ ਸਕਦੇ ਹੋ namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

ਨਤੀਜੇ ਵਜੋਂ, ਨਾਮ-ਸਥਾਨ ਵਿੱਚ ਸਾਰੇ ਪੌਡ default ਪੌਡ ਤੱਕ ਪਹੁੰਚ ਹੋਵੇਗੀ postgres ਨਾਮ-ਸਥਾਨ ਵਿੱਚ database. ਪਰ ਜੇ ਤੁਸੀਂ ਐਕਸੈਸ ਖੋਲ੍ਹਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੋਵੇਗਾ postgres ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਿਰਫ਼ ਖਾਸ ਪੌਡਸ default?

ਨੇਮਸਪੇਸ ਅਤੇ ਪੌਡਸ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰੋ

Kubernetes ਸੰਸਕਰਣ 1.11 ਅਤੇ ਉੱਚਾ ਤੁਹਾਨੂੰ ਆਪਰੇਟਰਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ namespaceSelector и podSelector ਲਾਜ਼ੀਕਲ AND ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

ਇਸਦੀ ਵਿਆਖਿਆ ਆਮ OR ਦੀ ਬਜਾਏ AND ਵਜੋਂ ਕਿਉਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ?

ਨੋਟ ਕਰੋ podSelector ਹਾਈਫਨ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ। YAML ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ podSelector ਅਤੇ ਉਸ ਦੇ ਸਾਹਮਣੇ ਖੜ੍ਹਾ ਹੈ namespaceSelector ਉਸੇ ਸੂਚੀ ਤੱਤ ਨੂੰ ਵੇਖੋ. ਇਸ ਲਈ, ਉਹਨਾਂ ਨੂੰ ਲਾਜ਼ੀਕਲ AND ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।

ਪਹਿਲਾਂ ਇੱਕ ਹਾਈਫਨ ਜੋੜਨਾ podSelector ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਨਵੀਂ ਸੂਚੀ ਤੱਤ ਪੈਦਾ ਹੋਵੇਗਾ, ਜਿਸ ਨੂੰ ਪਿਛਲੇ ਇੱਕ ਨਾਲ ਜੋੜਿਆ ਜਾਵੇਗਾ namespaceSelector ਲਾਜ਼ੀਕਲ OR ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ।

ਇੱਕ ਖਾਸ ਲੇਬਲ ਨਾਲ ਫਲੀਆਂ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਸਾਰੇ ਨਾਮ-ਸਥਾਨਾਂ ਵਿੱਚ, ਖਾਲੀ ਦਰਜ ਕਰੋ namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

ਕਈ ਲੇਬਲਾਂ ਦੀ ਟੀਮ ਆਈ

ਮਲਟੀਪਲ ਆਬਜੈਕਟ (ਹੋਸਟ, ਨੈੱਟਵਰਕ, ਗਰੁੱਪ) ਵਾਲੀ ਫਾਇਰਵਾਲ ਲਈ ਨਿਯਮ ਲਾਜ਼ੀਕਲ OR ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਮਿਲਾਏ ਜਾਂਦੇ ਹਨ। ਜੇਕਰ ਪੈਕੇਟ ਸਰੋਤ ਮੇਲ ਖਾਂਦਾ ਹੈ ਤਾਂ ਹੇਠਾਂ ਦਿੱਤਾ ਨਿਯਮ ਕੰਮ ਕਰੇਗਾ Host_1 ਜਾਂ Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

ਇਸਦੇ ਉਲਟ, ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਲੇਬਲਾਂ ਵਿੱਚ podSelector ਜ namespaceSelector ਲਾਜ਼ੀਕਲ AND ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤਾ ਨਿਯਮ ਉਹਨਾਂ ਪੌਡਾਂ ਦੀ ਚੋਣ ਕਰੇਗਾ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਦੋਵੇਂ ਲੇਬਲ ਹਨ, role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

ਇਹੋ ਤਰਕ ਹਰ ਕਿਸਮ ਦੇ ਆਪਰੇਟਰਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਨੀਤੀ ਨਿਸ਼ਾਨਾ ਚੋਣਕਾਰ, ਪੌਡ ਚੋਣਕਾਰ, ਅਤੇ ਨੇਮਸਪੇਸ ਚੋਣਕਾਰ।

ਸਬਨੈੱਟ ਅਤੇ IP ਪਤੇ (IPBlocks)

ਫਾਇਰਵਾਲ ਇੱਕ ਨੈੱਟਵਰਕ ਨੂੰ ਵੰਡਣ ਲਈ VLAN, IP ਐਡਰੈੱਸ, ਅਤੇ ਸਬਨੈੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ, IP ਐਡਰੈੱਸ ਪੌਡਾਂ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਅਕਸਰ ਬਦਲ ਸਕਦੇ ਹਨ, ਇਸਲਈ ਲੇਬਲਾਂ ਦੀ ਵਰਤੋਂ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਵਿੱਚ ਪੌਡਾਂ ਅਤੇ ਨਾਮ-ਸਥਾਨਾਂ ਨੂੰ ਚੁਣਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਸਬਨੈੱਟ (ipBlocks) ਦੀ ਵਰਤੋਂ ਇਨਕਮਿੰਗ (ਪ੍ਰਵੇਸ਼) ਜਾਂ ਬਾਹਰ ਜਾਣ ਵਾਲੇ (ਨਿਕਾਸ) ਬਾਹਰੀ (ਉੱਤਰੀ-ਦੱਖਣ) ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵੇਲੇ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਨੀਤੀ ਨੇਮਸਪੇਸ ਤੋਂ ਸਾਰੇ ਪੌਡਾਂ ਲਈ ਖੁੱਲ੍ਹਦੀ ਹੈ default Google DNS ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ ਖਾਲੀ ਪੌਡ ਚੋਣਕਾਰ ਦਾ ਮਤਲਬ ਹੈ "ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਾਰੇ ਪੌਡ ਚੁਣੋ।"

ਇਹ ਨੀਤੀ ਸਿਰਫ਼ 8.8.8.8 ਤੱਕ ਪਹੁੰਚ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ; ਕਿਸੇ ਹੋਰ IP ਤੱਕ ਪਹੁੰਚ ਦੀ ਮਨਾਹੀ ਹੈ। ਇਸ ਲਈ, ਸੰਖੇਪ ਵਿੱਚ, ਤੁਸੀਂ ਅੰਦਰੂਨੀ Kubernetes DNS ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਬਲੌਕ ਕਰ ਦਿੱਤਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਅਜੇ ਵੀ ਇਸਨੂੰ ਖੋਲ੍ਹਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦਰਸਾਓ।

ਆਮ ਤੌਰ 'ਤੇ ipBlocks и podSelectors ਆਪਸ ਵਿੱਚ ਨਿਵੇਕਲੇ ਹਨ, ਕਿਉਂਕਿ ਪੌਡਾਂ ਦੇ ਅੰਦਰੂਨੀ IP ਐਡਰੈੱਸ ਵਿੱਚ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ipBlocks. ਇਸ਼ਾਰਾ ਕਰਕੇ ਅੰਦਰੂਨੀ IP ਪੌਡ, ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਇਹਨਾਂ ਪਤਿਆਂ ਦੇ ਨਾਲ ਪੌਡਾਂ ਤੋਂ/ਤੋਂ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੋਗੇ। ਅਭਿਆਸ ਵਿੱਚ, ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਹੋਵੋਗੇ ਕਿ ਕਿਹੜਾ IP ਪਤਾ ਵਰਤਣਾ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਪੌਡ ਚੁਣਨ ਲਈ ਨਹੀਂ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜਵਾਬੀ-ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ, ਹੇਠਾਂ ਦਿੱਤੀ ਨੀਤੀ ਵਿੱਚ ਸਾਰੇ IP ਸ਼ਾਮਲ ਹਨ ਅਤੇ ਇਸਲਈ ਹੋਰ ਸਾਰੇ ਪੌਡਾਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

ਤੁਸੀਂ ਪੌਡਾਂ ਦੇ ਅੰਦਰੂਨੀ IP ਪਤਿਆਂ ਨੂੰ ਛੱਡ ਕੇ, ਸਿਰਫ਼ ਬਾਹਰੀ IP ਤੱਕ ਪਹੁੰਚ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਹਾਡੀ ਪੌਡ ਦਾ ਸਬਨੈੱਟ 10.16.0.0/14 ਹੈ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

ਪੋਰਟ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ

ਆਮ ਤੌਰ 'ਤੇ, ਪੌਡ ਇੱਕ ਪੋਰਟ ਨੂੰ ਸੁਣਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਨੀਤੀਆਂ ਵਿੱਚ ਪੋਰਟ ਨੰਬਰਾਂ ਨੂੰ ਨਿਰਧਾਰਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਹਰ ਚੀਜ਼ ਨੂੰ ਡਿਫੌਲਟ ਵਜੋਂ ਛੱਡ ਸਕਦੇ ਹੋ। ਹਾਲਾਂਕਿ, ਨੀਤੀਆਂ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਪ੍ਰਤੀਬੰਧਿਤ ਬਣਾਉਣ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਤੁਸੀਂ ਅਜੇ ਵੀ ਪੋਰਟਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

ਨੋਟ ਕਰੋ ਕਿ ਚੋਣਕਾਰ ports ਬਲਾਕ ਦੇ ਸਾਰੇ ਤੱਤਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ to ਜ from, ਜਿਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ। ਵੱਖ-ਵੱਖ ਤੱਤਾਂ ਦੇ ਸੈੱਟਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਪੋਰਟਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ, ਸਪਲਿਟ ਕਰੋ ingress ਜ egress ਦੇ ਨਾਲ ਕਈ ਉਪ-ਭਾਗਾਂ ਵਿੱਚ to ਜ from ਅਤੇ ਹਰੇਕ ਵਿੱਚ ਆਪਣੇ ਪੋਰਟਾਂ ਨੂੰ ਰਜਿਸਟਰ ਕਰੋ:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

ਡਿਫੌਲਟ ਪੋਰਟ ਓਪਰੇਸ਼ਨ:

• ਜੇ ਤੁਸੀਂ ਪੋਰਟ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੰਦੇ ਹੋ (ports), ਇਸਦਾ ਮਤਲਬ ਹੈ ਸਾਰੇ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਸਾਰੀਆਂ ਪੋਰਟਾਂ;
• ਜੇਕਰ ਤੁਸੀਂ ਪ੍ਰੋਟੋਕੋਲ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ (protocol), ਇਸਦਾ ਮਤਲਬ ਹੈ TCP;
• ਜੇਕਰ ਤੁਸੀਂ ਪੋਰਟ ਪਰਿਭਾਸ਼ਾ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ (port), ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਸਾਰੀਆਂ ਪੋਰਟਾਂ।

ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ: ਪੂਰਵ-ਨਿਰਧਾਰਤ ਮੁੱਲਾਂ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ, ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸੋ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ।

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਪੌਡ ਪੋਰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਸਰਵਿਸ ਪੋਰਟਾਂ ਦੀ ਨਹੀਂ (ਇਸ ਬਾਰੇ ਅਗਲੇ ਪੈਰੇ ਵਿੱਚ ਹੋਰ)।

ਕੀ ਪੌਡ ਜਾਂ ਸੇਵਾਵਾਂ ਲਈ ਨੀਤੀਆਂ ਪਰਿਭਾਸ਼ਿਤ ਹਨ?

ਆਮ ਤੌਰ 'ਤੇ, ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਪੌਡ ਇੱਕ ਸੇਵਾ ਦੁਆਰਾ ਇੱਕ ਦੂਜੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ - ਇੱਕ ਵਰਚੁਅਲ ਲੋਡ ਬੈਲੈਂਸਰ ਜੋ ਸੇਵਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲੇ ਪੌਡਾਂ ਲਈ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਕੁਬਰਨੇਟਸ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਪੋਡ ਪੋਰਟਾਂ 'ਤੇ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਸਰਵਿਸ ਪੋਰਟਾਂ 'ਤੇ ਨਹੀਂ।

ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਕੋਈ ਸੇਵਾ ਪੋਰਟ 80 ਨੂੰ ਸੁਣਦੀ ਹੈ, ਪਰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਸਦੇ ਪੌਡਾਂ ਦੇ ਪੋਰਟ 8080 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰਦੀ ਹੈ, ਤਾਂ ਨੈੱਟਵਰਕ ਨੀਤੀ ਵਿੱਚ ਬਿਲਕੁਲ 8080 ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਜਿਹੀ ਵਿਧੀ ਨੂੰ ਉਪ-ਅਨੁਕੂਲ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: ਜੇ ਸੇਵਾ ਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ (ਜਿਨ੍ਹਾਂ ਦੇ ਪੌਡ ਸੁਣਦੇ ਹਨ) ਬਦਲਦੇ ਹਨ, ਤਾਂ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਹੋਵੇਗਾ।

ਸਰਵਿਸ ਮੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਨਵੀਂ ਆਰਕੀਟੈਕਚਰਲ ਪਹੁੰਚ (ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ Istio ਬਾਰੇ ਦੇਖੋ - ਲਗਭਗ ਅਨੁਵਾਦ।) ਤੁਹਾਨੂੰ ਇਸ ਸਮੱਸਿਆ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਸਹਾਇਕ ਹੈ.

ਕੀ ਇਨਗ੍ਰੇਸ ਅਤੇ ਈਗ੍ਰੇਸ ਦੋਵਾਂ ਨੂੰ ਰਜਿਸਟਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ?

ਛੋਟਾ ਜਵਾਬ ਹਾਂ ਹੈ, ਪੌਡ ਏ ਨੂੰ ਪੌਡ ਬੀ ਨਾਲ ਸੰਚਾਰ ਕਰਨ ਲਈ, ਇਸਨੂੰ ਇੱਕ ਆਊਟਗੋਇੰਗ ਕਨੈਕਸ਼ਨ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ (ਇਸਦੇ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਈਗ੍ਰੇਸ ਨੀਤੀ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ), ਅਤੇ ਪੌਡ ਬੀ ਇੱਕ ਆਉਣ ਵਾਲੇ ਕੁਨੈਕਸ਼ਨ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ( ਇਸਦੇ ਲਈ, ਇਸਦੇ ਅਨੁਸਾਰ, ਤੁਹਾਨੂੰ ਇੱਕ ਪ੍ਰਵੇਸ਼ ਨੀਤੀ ਦੀ ਜ਼ਰੂਰਤ ਹੈ। ਨੀਤੀ)।

ਹਾਲਾਂਕਿ, ਅਭਿਆਸ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ ਜਾਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਆਗਿਆ ਦੇਣ ਲਈ ਡਿਫੌਲਟ ਨੀਤੀ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ।

ਜੇ ਕੁਝ ਪੋਡ-ਸਰੋਤ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਦੁਆਰਾ ਚੁਣਿਆ ਜਾਵੇਗਾ ਐਡਰੈਸ-ਸਿਆਸਤਦਾਨ, ਇਸ 'ਤੇ ਲਗਾਈਆਂ ਗਈਆਂ ਪਾਬੰਦੀਆਂ ਉਨ੍ਹਾਂ ਦੇ ਮਨ-ਮੁਟਾਅ ਤੋਂ ਤੈਅ ਹੋਣਗੀਆਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪੌਡ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਦੀ ਆਗਿਆ ਦੇਣ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ -ਪਤਾ ਕਰਨ ਵਾਲੇ ਨੂੰ. ਜੇਕਰ ਇੱਕ ਪੌਡ ਨੂੰ ਕਿਸੇ ਨੀਤੀ ਦੁਆਰਾ ਨਹੀਂ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੇ ਆਊਟਗੋਇੰਗ (ਐਗਰੈਸ) ਟ੍ਰੈਫਿਕ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਆਗਿਆ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਇਸੇ ਤਰ੍ਹਾਂ, ਪੌਡ ਦੀ ਕਿਸਮਤ ਹੈਪਤਾ, ਇੱਕ ਜਾਂ ਵੱਧ ਦੁਆਰਾ ਚੁਣਿਆ ਗਿਆ ਪ੍ਰਵੇਸ਼-ਸਿਆਸਤਦਾਨ, ਉਹਨਾਂ ਦੇ ਵਿਛੋੜੇ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਣਗੇ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਸਰੋਤ ਪੌਡ ਤੋਂ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ. ਜੇਕਰ ਇੱਕ ਪੌਡ ਕਿਸੇ ਨੀਤੀ ਦੁਆਰਾ ਨਹੀਂ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੇ ਲਈ ਸਾਰੇ ਪ੍ਰਵੇਸ਼ ਟ੍ਰੈਫਿਕ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਆਗਿਆ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਹੇਠਾਂ ਸਟੇਟਫੁਲ ਜਾਂ ਸਟੇਟਲੈੱਸ ਦੇਖੋ।

ਲਾਗ

Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਲੌਗ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਇਸ ਨਾਲ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਕੋਈ ਨੀਤੀ ਉਦੇਸ਼ ਅਨੁਸਾਰ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਸੁਰੱਖਿਆ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੇਚੀਦਾ ਕਰਦੀ ਹੈ।

ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਲਈ ਆਵਾਜਾਈ ਦਾ ਨਿਯੰਤਰਣ

Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਤੁਹਾਨੂੰ ਬਾਹਰਲੇ ਭਾਗਾਂ ਵਿੱਚ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਡੋਮੇਨ ਨਾਮ (DNS) ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀਆਂ। ਇਹ ਤੱਥ ਮਹੱਤਵਪੂਰਨ ਅਸੁਵਿਧਾ ਵੱਲ ਖੜਦਾ ਹੈ ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬਾਹਰੀ ਮੰਜ਼ਿਲਾਂ ਤੱਕ ਸੀਮਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਸਥਿਰ IP ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ (ਜਿਵੇਂ ਕਿ aws.com)।

ਨੀਤੀ ਜਾਂਚ

ਫਾਇਰਵਾਲ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਦੇਣਗੇ ਜਾਂ ਗਲਤ ਨੀਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਵੀ ਕਰਨਗੇ। ਕੁਬਰਨੇਟਸ ਕੁਝ ਤਸਦੀਕ ਵੀ ਕਰਦਾ ਹੈ। kubectl ਦੁਆਰਾ ਇੱਕ ਨੈੱਟਵਰਕ ਨੀਤੀ ਸੈਟ ਕਰਦੇ ਸਮੇਂ, Kubernetes ਘੋਸ਼ਣਾ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਗਲਤ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਹੋਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਕੁਬਰਨੇਟਸ ਪਾਲਿਸੀ ਲਵੇਗਾ ਅਤੇ ਇਸਨੂੰ ਗੁੰਮ ਹੋਏ ਵੇਰਵਿਆਂ ਨਾਲ ਭਰ ਦੇਵੇਗਾ। ਉਹਨਾਂ ਨੂੰ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ:

kubernetes get networkpolicy <policy-name> -o yaml

ਇਹ ਗੱਲ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ ਕਿ ਕੁਬਰਨੇਟਸ ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰਣਾਲੀ ਅਢੁੱਕਵੀਂ ਨਹੀਂ ਹੈ ਅਤੇ ਕੁਝ ਕਿਸਮ ਦੀਆਂ ਤਰੁੱਟੀਆਂ ਨੂੰ ਖੁੰਝ ਸਕਦੀ ਹੈ।

ਐਗਜ਼ੀਕਿਊਸ਼ਨ

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

ਨੋਟ ਕਰੋ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਢੁਕਵੇਂ ਸਹਾਇਕ CNI ਤੋਂ ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਨੀਤੀ ਸੈਟ ਕਰਦੇ ਹੋ ਤਾਂ ਕੁਬਰਨੇਟਸ ਤੁਹਾਨੂੰ ਚੇਤਾਵਨੀ ਨਹੀਂ ਦੇਵੇਗਾ।

ਰਾਜਯੋਗ ਜਾਂ ਰਾਜ ਰਹਿਤ?

ਸਾਰੇ Kubernetes CNIs ਜਿਨ੍ਹਾਂ ਦਾ ਮੈਂ ਸਾਹਮਣਾ ਕੀਤਾ ਹੈ, ਉਹ ਰਾਜਪੂਰਨ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਕੈਲੀਕੋ ਲੀਨਕਸ ਕੰਟਰੈਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ)। ਇਹ ਪੋਡ ਨੂੰ ਇਸ ਨੂੰ ਮੁੜ ਸਥਾਪਿਤ ਕੀਤੇ ਬਿਨਾਂ ਸ਼ੁਰੂ ਕੀਤੇ TCP ਕੁਨੈਕਸ਼ਨ 'ਤੇ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਮੈਂ ਕੁਬਰਨੇਟਸ ਸਟੈਂਡਰਡ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹਾਂ ਜੋ ਸਟੇਟਮੈਂਟਲਤਾ ਦੀ ਗਰੰਟੀ ਦੇਵੇਗਾ।

ਐਡਵਾਂਸਡ ਸੁਰੱਖਿਆ ਨੀਤੀ ਪ੍ਰਬੰਧਨ

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਨੀਤੀ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਦੇ ਇੱਥੇ ਕੁਝ ਤਰੀਕੇ ਹਨ:

1. ਸਰਵਿਸ ਮੈਸ਼ ਆਰਕੀਟੈਕਚਰਲ ਪੈਟਰਨ ਸੇਵਾ ਪੱਧਰ 'ਤੇ ਵਿਸਤ੍ਰਿਤ ਟੈਲੀਮੈਟਰੀ ਅਤੇ ਟ੍ਰੈਫਿਕ ਨਿਯੰਤਰਣ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਸਾਈਡਕਾਰ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਅਸੀਂ ਲੈ ਸਕਦੇ ਹਾਂ ਆਈਸਟੀਓ.
2. ਕੁਝ CNI ਵਿਕਰੇਤਾਵਾਂ ਨੇ Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਤੋਂ ਪਰੇ ਜਾਣ ਲਈ ਆਪਣੇ ਸਾਧਨਾਂ ਨੂੰ ਵਧਾਇਆ ਹੈ।
3. ਟੂਫਿਨ ਓਰਕਾ ਕੁਬਰਨੇਟਸ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਦਿੱਖ ਅਤੇ ਆਟੋਮੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

Tufin Orca ਪੈਕੇਜ Kubernetes ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ (ਅਤੇ ਉਪਰੋਕਤ ਸਕ੍ਰੀਨਸ਼ੌਟਸ ਦਾ ਸਰੋਤ ਹੈ)।

ਵਾਧੂ ਜਾਣਕਾਰੀ

• GKE ਤੋਂ ਅਹਿਮਤ ਅਲਪ ਬਾਲਕਨ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੀਆਂ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀਆਂ ਉਦਾਹਰਨਾਂ;
• ਅਧਿਕਾਰਤ Kubernetes ਵੈੱਬਸਾਈਟ ਤੋਂ ਦਸਤਾਵੇਜ਼;
• ਕੁਬਰਨੇਟਸ ਨੈੱਟਵਰਕਿੰਗ ਮਾਡਲ ਲਈ ਇੱਕ ਗਾਈਡ;
• ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਸਕ੍ਰਿਪਟ.

ਸਿੱਟਾ

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

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਗਾਈਡ ਕੁਝ ਸਵਾਲਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਸੀਂ ਸਾਹਮਣਾ ਕਰ ਸਕਦੇ ਹੋ।

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• "ਇਸਟੀਓ ਨਾਲ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਵਾਪਸ ਜਾਓ": ਭਾਗ 1 (ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਜਾਣ ਪਛਾਣ), ਭਾਗ 2 (ਰੂਟਿੰਗ, ਟ੍ਰੈਫਿਕ ਕੰਟਰੋਲ), ਭਾਗ 3 (ਸੁਰੱਖਿਆ);
• "ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਲਈ ਇੱਕ ਇਲਸਟ੍ਰੇਟਿਡ ਗਾਈਡ": ਭਾਗ 1 ਅਤੇ 2 (ਨੈੱਟਵਰਕ ਮਾਡਲ, ਓਵਰਲੇ ਨੈੱਟਵਰਕ), ਭਾਗ 3 (ਸੇਵਾਵਾਂ ਅਤੇ ਟ੍ਰੈਫਿਕ ਪ੍ਰੋਸੈਸਿੰਗ);
• «ਸੁਰੱਖਿਆ-ਸੰਵੇਦਨਸ਼ੀਲ ਵਾਤਾਵਰਣ ਵਿੱਚ ਡੌਕਰ ਅਤੇ ਕੁਬਰਨੇਟਸ";
• «ਕੁਬਰਨੇਟਸ ਸੁਰੱਖਿਆ ਲਈ 9 ਵਧੀਆ ਅਭਿਆਸ";
• «ਕੁਬਰਨੇਟਸ ਹੈਕ ਦਾ ਸ਼ਿਕਾਰ ਹੋਣ (ਨਾ) ਦੇ 11 ਤਰੀਕੇ".

ਸਰੋਤ: www.habr.com