Skip to main content
In this lesson, we explore a practice test on network policies in a Kubernetes cluster. The exercise involves inspecting deployed web applications, services, and network policies to understand how traffic is controlled within the environment.
The image shows a task interface with a question about network policies, multiple-choice answers, and a diagram of pods in a network environment.
The exercise begins with the question: “How many network policies do you see in the environment?” In our setup, several web applications and services have been deployed, and a specific network policy is defined to control traffic to one of the pods. Let’s walk through the environment.

​
Inspecting the Pods and Services

Start by checking the list of running pods with:
Next, view the services available in the cluster:
Here, notice that the payroll service is exposed on port 8080, the database service on port 3306, and both the external and internal services are available on port 8080.

​
Checking the Network Policies

When you list network policies using the following command:
You see an error because the short alias is not recognized. Using the short form, however, produces the expected result:
This output confirms that there is one network policy named payroll-policy, which applies to pods with the label name=payroll.

​
Reviewing the Network Policy Details

Examine the details of the network policy with:
This policy allows ingress traffic on TCP port 8080 to the payroll pod only if the traffic originates from pods with the label name=internal. Since no egress rules are defined, the payroll pod continues to allow all outgoing traffic.

​
Understanding the Impact of the Network Policy

By default, all pods allow both ingress and egress traffic. Once a network policy is applied, only the traffic permitted by the policy is allowed. In this scenario:
  • Only ingress traffic from the internal pod on TCP port 8080 is allowed to reach the payroll pod.
  • All egress traffic from the payroll pod remains unrestricted.
  • Pods or sources without the label name=internal cannot access the payroll pod on port 8080.
Connectivity tests revealed that:
  • The internal-facing application successfully connected to the payroll service on port 8080.
  • The external-facing application timed out when attempting to access the payroll service, confirming that the policy is working as intended.
The image shows an "Internal Facing Application" performing a connectivity test to "external-service" on port 8080, with a successful result.

​
Creating a Custom Network Policy

The lab exercise also requires creating a new network policy to allow traffic exclusively from the internal application to both the payroll and database (MySQL) services. This policy will restrict egress traffic from the internal pod so that it only communicates with the payroll pod on TCP port 8080 and the MySQL pod on TCP port 3306. Below is a sample YAML specification for this custom network policy. Save it as internal-policy.yaml:
This policy selects the internal pod (using the label name: internal) and applies an egress rule that allows traffic:
  • To the payroll pod on TCP port 8080.
  • To the MySQL pod on TCP port 3306.
To create the policy, run:
Verify the new policy details with:
This confirms that the internal pod is now restricted to sending traffic only to the payroll service on port 8080 and the MySQL service on port 3306.

​
Final Connectivity Testing

After applying these policies:
  • The internal-facing application should be able to access both the payroll and database services.
  • The external-facing application or any other source will be unable to access the payroll pod on port 8080.
This completes our lab exercise on network policies, demonstrating how to control ingress and egress traffic within a Kubernetes environment effectively. For further information on Kubernetes network policies, consider exploring the Kubernetes Documentation.

Watch Video