Bird
Raised Fist0
Kubernetesdevops~5 mins

Network policies for traffic control in Kubernetes - Commands & Configuration

Choose your learning style10 modes available
Introduction
Sometimes, you want to control which parts of your app can talk to each other inside your Kubernetes cluster. Network policies help you block or allow traffic between pods to keep your app safe and organized.
When you want to allow only specific pods to access a database pod.
When you want to block all traffic to a sensitive backend service except from a frontend pod.
When you want to limit communication between different teams' apps running in the same cluster.
When you want to test how your app behaves with restricted network access.
When you want to improve security by reducing unnecessary network connections.
Config File - network-policy.yaml
network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 80

This file creates a network policy named allow-frontend-to-backend in the default namespace.

The podSelector selects pods with label app: backend, meaning this policy applies to backend pods.

The policyTypes set to Ingress means it controls incoming traffic to these pods.

The ingress rule allows traffic only from pods labeled app: frontend on TCP port 80.

This blocks all other incoming traffic to backend pods except from frontend pods on port 80.

Commands
This command applies the network policy to the cluster, creating the rule that controls traffic to backend pods.
Terminal
kubectl apply -f network-policy.yaml
Expected OutputExpected
networkpolicy.networking.k8s.io/allow-frontend-to-backend created
This command shows the details of the network policy to verify it was created correctly.
Terminal
kubectl get networkpolicy allow-frontend-to-backend -o yaml
Expected OutputExpected
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-frontend-to-backend namespace: default spec: ingress: - from: - podSelector: matchLabels: app: frontend ports: - port: 80 protocol: TCP podSelector: matchLabels: app: backend policyTypes: - Ingress
→
-o yaml - Outputs the network policy details in YAML format for easy reading
This command gives a human-readable summary of the network policy and its rules.
Terminal
kubectl describe networkpolicy allow-frontend-to-backend
Expected OutputExpected
Name: allow-frontend-to-backend Namespace: default Labels: <none> Annotations: <none> PodSelector: app=backend PolicyTypes: Ingress Ingress: From: PodSelector: app=frontend Ports: TCP:80
Key Concept

If you remember nothing else from this pattern, remember: network policies let you control which pods can talk to which pods inside your Kubernetes cluster.

Common Mistakes
Not labeling pods correctly to match the network policy selectors
The network policy won't apply to any pods if labels don't match, so traffic won't be controlled as expected.
Make sure pods have the exact labels used in the network policy's podSelector and from podSelector.
Assuming network policies allow traffic by default
When any network policy selects a pod, all other traffic is blocked unless explicitly allowed.
Always define all needed ingress and egress rules for pods selected by network policies.
Applying network policies in the wrong namespace
Network policies only affect pods in the namespace they are created in.
Create network policies in the same namespace as the pods you want to control.
Summary
Create a network policy YAML file to define allowed traffic between pods.
Apply the network policy using kubectl apply to enforce traffic rules.
Verify the policy with kubectl get and kubectl describe commands.

Practice

(1/5)
1. What is the primary purpose of a Kubernetes NetworkPolicy?
easy
A. To control traffic flow between pods and namespaces
B. To schedule pods on specific nodes
C. To manage storage volumes for pods
D. To monitor pod resource usage

Solution

  1. Step 1: Understand NetworkPolicy role

    Kubernetes NetworkPolicy is designed to control how pods communicate with each other and with other network endpoints.
  2. Step 2: Identify correct function

    It specifically allows or blocks traffic between pods and namespaces to improve security.
  3. Final Answer:

    To control traffic flow between pods and namespaces -> Option A
  4. Quick Check:

    NetworkPolicy controls pod traffic = A [OK]
Hint: NetworkPolicy controls pod communication, not scheduling or storage [OK]
Common Mistakes:
  • Confusing NetworkPolicy with pod scheduling
  • Thinking NetworkPolicy manages storage
  • Assuming NetworkPolicy monitors resources
2. Which of the following is the correct syntax to specify a pod selector in a NetworkPolicy YAML?
easy
A. podSelector: matchLabels: app: frontend
B. podSelector: labels: app=frontend
C. podSelector: app: frontend
D. podSelector: matchLabels: {app: frontend}

Solution

  1. Step 1: Recall podSelector syntax

    The correct syntax uses matchLabels under podSelector with key-value pairs properly indented.
  2. Step 2: Compare options

    podSelector: matchLabels: app: frontend correctly uses podSelector: matchLabels: app: frontend. podSelector: matchLabels: {app: frontend} uses braces which is invalid YAML here.
  3. Final Answer:

    podSelector: matchLabels: app: frontend -> Option A
  4. Quick Check:

    Use matchLabels with key: value YAML format [OK]
Hint: Use matchLabels with key: value indentation for podSelector [OK]
Common Mistakes:
  • Using incorrect YAML braces {} in podSelector
  • Writing labels as key=value instead of key: value
  • Omitting matchLabels keyword
3. Given this NetworkPolicy snippet, what traffic is allowed?
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 3306
medium
A. All pods can access db pods on any port
B. Only pods with label role=db can access frontend pods on port 3306
C. Only pods with label role=frontend can access db pods on TCP port 3306
D. No traffic is allowed to db pods

Solution

  1. Step 1: Analyze podSelector and ingress rules

    The policy selects pods with label role: db. It allows ingress only from pods with role: frontend on TCP port 3306.
  2. Step 2: Interpret traffic allowed

    Only pods labeled frontend can connect to db pods on port 3306. Other traffic is blocked.
  3. Final Answer:

    Only pods with label role=frontend can access db pods on TCP port 3306 -> Option C
  4. Quick Check:

    Ingress from frontend pods on port 3306 = C [OK]
Hint: Check podSelector and ingress from podSelector with ports [OK]
Common Mistakes:
  • Assuming all pods can access db pods
  • Confusing source and destination pod labels
  • Ignoring port restrictions
4. You wrote this NetworkPolicy but traffic is still blocked:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend-ns
    ports:
    - protocol: TCP
      port: 3306
What is the likely error?
medium
A. Port 3306 must be specified as a string
B. Namespace label key should be 'kubernetes.io/metadata.name' not 'name'
C. Protocol TCP is not supported in NetworkPolicy
D. podSelector is missing in the ingress rule

Solution

  1. Step 1: Check namespaceSelector label key

    Namespace labels usually use the key kubernetes.io/metadata.name for the namespace name, not just name.
  2. Step 2: Understand impact on traffic

    Using incorrect label key means no namespaces match, so ingress is blocked.
  3. Final Answer:

    Namespace label key should be 'kubernetes.io/metadata.name' not 'name' -> Option B
  4. Quick Check:

    Correct namespace label key fixes traffic block = D [OK]
Hint: Use correct namespace label key: kubernetes.io/metadata.name [OK]
Common Mistakes:
  • Using wrong label key for namespaceSelector
  • Thinking protocol TCP is unsupported
  • Misunderstanding port data type requirements
5. You want to allow all pods in namespace 'frontend' to access pods labeled 'role=db' only on port 5432 TCP, but block all other traffic. Which NetworkPolicy YAML snippet correctly achieves this?
hard
A. spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: name: frontend ports: - protocol: UDP port: 5432
B. spec: podSelector: matchLabels: role: db ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 5432
C. spec: podSelector: matchLabels: role: frontend ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: db ports: - protocol: TCP port: 5432
D. spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend ports: - protocol: TCP port: 5432

Solution

  1. Step 1: Identify podSelector and allowed source

    The policy must select pods with role: db and allow ingress only from pods in namespace 'frontend'. This requires namespaceSelector with correct label key.
  2. Step 2: Check port and protocol correctness

    Port must be 5432 TCP. spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend ports: - protocol: TCP port: 5432 uses correct protocol TCP and correct namespace label key kubernetes.io/metadata.name.
  3. Step 3: Verify other options

    spec: podSelector: matchLabels: role: db ingress: - from: - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 5432 uses podSelector for frontend pods, not namespaceSelector, so it restricts source pods incorrectly. spec: podSelector: matchLabels: role: frontend ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: db ports: - protocol: TCP port: 5432 selects wrong pods and namespaces. spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: name: frontend ports: - protocol: UDP port: 5432 uses wrong protocol UDP and wrong namespace label key.
  4. Final Answer:

    spec: podSelector: matchLabels: role: db ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend ports: - protocol: TCP port: 5432 -> Option D
  5. Quick Check:

    Correct podSelector, namespaceSelector, TCP port 5432 = A [OK]
Hint: Use podSelector for db pods, namespaceSelector with correct label, TCP port 5432 [OK]
Common Mistakes:
  • Using podSelector instead of namespaceSelector for source
  • Wrong namespace label key
  • Using UDP instead of TCP for port 5432
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard