Bird
Raised Fist0
Kubernetesdevops~5 mins

Ingress and egress rules in Kubernetes - Time & Space Complexity

Choose your learning style10 modes available
LearnWhyDeepVisualTryChallengeProjectRecallTime
Time Complexity: Ingress and egress rules
O(n)
Understanding Time Complexity

We want to understand how the time to process network rules grows as we add more rules in Kubernetes.

How does adding more ingress and egress rules affect the time Kubernetes takes to enforce them?

Scenario Under Consideration

Analyze the time complexity of the following Kubernetes NetworkPolicy snippet.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: example-policy
spec:
  podSelector:
    matchLabels:
      role: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 3306

This policy controls which pods can send traffic to or receive traffic from the selected pods.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Kubernetes checks each network packet against all ingress and egress rules.
  • How many times: For each packet, it loops through all rules to find matches.
How Execution Grows With Input

As the number of rules increases, the time to check each packet grows roughly in proportion.

Input Size (n rules)Approx. Operations per Packet
1010 checks
100100 checks
10001000 checks

Pattern observation: The time grows linearly as more rules are added.

Final Time Complexity

Time Complexity: O(n)

This means the time to process network rules grows directly with the number of rules.

Common Mistake

[X] Wrong: "Adding more rules won't affect performance much because checks happen instantly."

[OK] Correct: Each packet must be checked against every rule, so more rules mean more checks and more time.

Interview Connect

Understanding how rule checks scale helps you design efficient network policies and troubleshoot performance issues confidently.

Self-Check

"What if Kubernetes used a hash map to organize rules by pod labels? How would the time complexity change?"

Practice

(1/5)
1. What do Ingress rules control in Kubernetes NetworkPolicies?
easy
A. CPU resource limits for pods
B. Incoming traffic to pods
C. Storage access for pods
D. Outgoing traffic from pods

Solution

  1. Step 1: Understand the role of Ingress rules

    Ingress rules specify which incoming network traffic is allowed to reach the pods.

  2. Step 2: Differentiate from Egress rules

    Egress rules control outgoing traffic, not incoming.

  3. Final Answer:

    Incoming traffic to pods -> Option B

  4. Quick Check:

    Ingress = Incoming traffic [OK]
Hint: Ingress means incoming traffic control [OK]
Common Mistakes:
  • Confusing ingress with egress
  • Thinking ingress controls resource limits
  • Mixing network traffic with storage access
2. Which of the following is the correct syntax to allow all incoming traffic from pods in namespace frontend using a NetworkPolicy ingress rule?
easy
A. ingress: - from: - namespaceSelector: matchLabels: name: frontend
B. egress: - to: - namespaceSelector: matchLabels: name: frontend
C. ingress: - to: - namespaceSelector: matchLabels: name: frontend
D. egress: - from: - namespaceSelector: matchLabels: name: frontend

Solution

  1. Step 1: Identify ingress rule syntax

    Ingress rules use ingress: with from: to specify allowed sources.

  2. Step 2: Confirm namespaceSelector usage

    Using namespaceSelector with matchLabels is correct to select pods in a namespace.

  3. Final Answer:

    ingress: - from: - namespaceSelector: matchLabels: name: frontend -> Option A

  4. Quick Check:

    Ingress uses 'from' to allow incoming traffic [OK]
Hint: 'ingress' with 'from' allows incoming traffic sources [OK]
Common Mistakes:
  • Using 'to' instead of 'from' in ingress
  • Confusing ingress with egress syntax
  • Misplacing namespaceSelector under egress
3. Given this NetworkPolicy snippet, what traffic is allowed? 
egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
        except:
        - 10.0.0.5/32
medium
A. All outgoing traffic to 10.0.0.0/24 except 10.0.0.5
B. All incoming traffic from 10.0.0.0/24 except 10.0.0.5
C. All outgoing traffic to 10.0.0.5 only
D. All incoming traffic from 10.0.0.5 only

Solution

  1. Step 1: Analyze egress rule with ipBlock

    The rule allows outgoing traffic to IPs in 10.0.0.0/24 except 10.0.0.5.

  2. Step 2: Confirm direction and exceptions

    Egress means outgoing traffic; 'except' excludes 10.0.0.5 from allowed IPs.

  3. Final Answer:

    All outgoing traffic to 10.0.0.0/24 except 10.0.0.5 -> Option A

  4. Quick Check:

    Egress with ipBlock except excludes IPs [OK]
Hint: Egress 'to' with ipBlock allows excepted IPs blocked [OK]
Common Mistakes:
  • Confusing ingress with egress direction
  • Misreading 'except' as allowed IP
  • Mixing incoming and outgoing traffic
4. You wrote this NetworkPolicy egress rule but pods still cannot reach external IPs: 
egress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
What is the error?
medium
A. NetworkPolicy must not have egress rules
B. CIDR 0.0.0.0/0 is invalid
C. Missing 'ports' section
D. Egress rules use 'to', not 'from'

Solution

  1. Step 1: Check egress rule syntax

    Egress rules specify destinations with 'to', not 'from'. Using 'from' is invalid here.

  2. Step 2: Understand correct usage

    Correct egress syntax uses 'to' to define allowed outgoing IP blocks.

  3. Final Answer:

    Egress rules use 'to', not 'from' -> Option D

  4. Quick Check:

    Egress uses 'to' for destinations [OK]
Hint: Egress rules always use 'to' keyword [OK]
Common Mistakes:
  • Using 'from' in egress rules
  • Assuming CIDR 0.0.0.0/0 is invalid
  • Thinking ports are always required
5. You want to restrict pods to only receive traffic from pods in the same namespace and send traffic only to a specific external IP range 192.168.1.0/24. Which NetworkPolicy configuration achieves this?
hard
A. ingress: - from: - podSelector: {} egress: - from: - ipBlock: cidr: 192.168.1.0/24
B. ingress: - from: - namespaceSelector: {} egress: - to: - ipBlock: cidr: 10.0.0.0/24
C. ingress: - from: - podSelector: {} egress: - to: - ipBlock: cidr: 192.168.1.0/24
D. ingress: - to: - podSelector: {} egress: - to: - ipBlock: cidr: 192.168.1.0/24

Solution

  1. Step 1: Configure ingress to allow same-namespace pods

    Using podSelector: {} allows traffic from all pods in the same namespace.

  2. Step 2: Configure egress to allow only specific external IP range

    Egress uses to with ipBlock for 192.168.1.0/24 to restrict outgoing traffic.

  3. Final Answer:

    ingress: - from: - podSelector: {} egress: - to: - ipBlock: cidr: 192.168.1.0/24 -> Option C

  4. Quick Check:

    Ingress 'from' podSelector + Egress 'to' ipBlock [OK]
Hint: Ingress uses 'from' podSelector; egress uses 'to' ipBlock [OK]
Common Mistakes:
  • Using 'from' in egress rules
  • Using namespaceSelector instead of podSelector for ingress
  • Mixing 'to' and 'from' keywords incorrectly
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