Ingress and egress rules in Kubernetes - Step-by-Step Execution

Process Flow - Ingress and egress rules

Start: Pod wants to communicate

↓

Check Egress Rules

↓

Send Out

↓

Incoming Traffic

↓

Check Ingress Rules

↓

Deliver

↓

End Communication

Traffic from pods first passes egress rules to allow or block outgoing connections. Incoming traffic passes ingress rules to allow or block access to pods.

Execution Sample

Kubernetes

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web
spec:
  podSelector:
    matchLabels:
      role: web
  ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/24

This NetworkPolicy allows incoming traffic to pods with label role=web only from IPs in 10.0.0.0/24 subnet.

Process Table

Step	Traffic Direction	Source IP	Destination Pod	Rule Checked	Allowed?	Action
1	Egress	Pod A	External IP 8.8.8.8	Egress rule: allow all	Yes	Send Out
2	Ingress	IP 10.0.0.5	Pod with role=web	Ingress rule: allow from 10.0.0.0/24	Yes	Deliver
3	Ingress	IP 192.168.1.10	Pod with role=web	Ingress rule: allow from 10.0.0.0/24	No	Drop Packet
4	Egress	Pod B	External IP 192.168.1.10	Egress rule: allow all	Yes	Send Out
5	Ingress	IP 10.0.0.50	Pod without role=web	No ingress rule matches	No	Drop Packet
6	Egress	Pod C	External IP 10.0.0.5	Egress rule: deny all	No	Block Traffic

💡 Traffic is either allowed or blocked based on matching ingress and egress rules.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6
Traffic Status	Pending	Sent Out	Delivered	Dropped	Sent Out	Dropped	Blocked
Source IP	Pod A	Pod A	10.0.0.5	192.168.1.10	Pod B	10.0.0.50	Pod C
Destination Pod	8.8.8.8	8.8.8.8	role=web	role=web	192.168.1.10	no role=web	10.0.0.5

Key Moments - 3 Insights

Why is traffic from IP 192.168.1.10 to a pod with role=web dropped?

Because the ingress rule only allows traffic from 10.0.0.0/24 subnet, as shown in execution_table row 3 where Allowed? is No.

What happens if there is no ingress rule matching the incoming traffic?

The traffic is dropped by default, as seen in execution_table row 5 where no ingress rule matches and action is Drop Packet.

Why is egress traffic from Pod C blocked?

Because the egress rule denies all outgoing traffic for Pod C, shown in execution_table row 6 with Allowed? No and action Block Traffic.

Visual Quiz - 3 Questions

Look at the execution table, what is the action taken at step 3 for incoming traffic from IP 192.168.1.10?

A Deliver to pod

B Drop Packet

C Send Out

D Block Traffic

💡 Hint

Check the 'Action' column in execution_table row 3.

At which step does egress traffic get blocked?

A Step 2

B Step 4

C Step 6

D Step 1

💡 Hint

Look for 'Block Traffic' in the 'Action' column of execution_table.

If the ingress rule allowed all IPs, what would change at step 5?

A Traffic would be delivered

B Traffic would be blocked

C Traffic would be dropped

D No change

💡 Hint

Refer to execution_table row 5 where traffic is dropped due to no matching ingress rule.

Concept Snapshot

Ingress and egress rules control pod network traffic.
Egress rules filter outgoing traffic from pods.
Ingress rules filter incoming traffic to pods.
Traffic allowed by rules passes; else it is blocked or dropped.
Rules use selectors and IP blocks to specify allowed sources/destinations.

Full Transcript

Ingress and egress rules in Kubernetes control network traffic to and from pods. When a pod sends traffic out, egress rules check if the traffic is allowed. If allowed, the traffic goes out; if not, it is blocked. Incoming traffic to pods is checked against ingress rules. If the source IP matches allowed rules, traffic is delivered; otherwise, it is dropped. This example shows traffic from different IPs and pods being allowed or blocked based on these rules. Understanding these rules helps secure pod communication by controlling who can talk to whom.