Networks

Kubernetes networks define how the pods in the same namespace will communicate with each other and the network endpoint.

Module

Networking is a central part of Kubernetes, but it can be challenging to understand exactly how it is expected to work.

Overview

At the end of this module, you will :

  • Learn what is a CNI

  • Learn to manage network rules

  • Learn to secure the communication within a cluster

Prerequisites

Create the directory data/networks in your home folder to manage the YAML file needed in this module.

mkdir ~/data/networks

Create

A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.

NetworkPolicy resources use labels to select pods and define rules which specify what traffic is allowed to the selected pods.

By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace

The create command can create a NetworkPolicy object based on a yaml file definition.

Exercise n°1

Deploy a default Network Policy for each resources in the default namespace to deny all ingress and egress traffic.

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

Create the resource based on the previous yaml file definition.

kubectl apply  -f data/networks/01_networkpolicy.yaml

Exercise n°2

Create a network policy to :

  • Allow the ingress traffic from :

    • The IP range : 172.17.0.0/16

    • The namespace transvers

    • The Pods labelized with the key role and the value frontend

    • The port 5432

  • Allow the egress traffic to :

    • The local network 10.0.0.0/24 on port 5432

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: testnetworkpolicy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
    - namespaceSelector:
        matchLabels:
          env: transvers
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 5432
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5432

Create the resource based on the previous yaml file definition.

kubectl apply  -f data/networks/02_networkpolicy.yaml

Get

The get command list the object asked. It could be a single object or a list of multiple objects comma separated. This command is useful to get the status of each object. The output can be formatted to only display some information based on some json search or external tools like tr, sort, uniq.

The default output display some useful information about each services :

  • Name : the name of the newly created resource

  • Pod-selector : the labels used to associate the Network Policy with the Pods

  • Age : the age since his creation

Exercise n°1

kubectl get networkpolicy

Describe

Once an object is running, it is inevitably a need to debug problems or check the configuration deployed.

The describe command display a lot of configuration information about the NetworkPolicies (labels, annotations, etc.) and the specific policies associated to the current NetworkPolicy (type, port, selectors, etc).

This command is really useful to introspect and debug an object deployed in a cluster.

Exercise n°1

Describe one of the existing Network Policy in the default namespace.

kubectl describe networkpolicy testnetworkpolicy

Explain

Kubernetes come with a lot of documentation about his objects and the available options in each one. Those information can be fin easily in command line or in the official Kubernetes documentation.

The explain command allows to directly ask the API resource via the command line tools to display information about each Kubernetes objects and their architecture.

Exercise n°1

Get the documentation of a specific field of a resource.

kubectl explain networkpolicy.spec

Add the --recursive flag to display all of the fields at once without descriptions.

Delete

The delete command delete resources by filenames, stdin, resources and names, or by resources and label selector.

Be careful on the deletion of a network policy, this can isolate resource or expose it and cause damaged to your services.

Note that the delete command does NOT do resource version checks, so if someone submits an update to a resource right when you submit a delete, their update will be lost along with the rest of the resource.

Exercise n°1

Delete the previous network policy in command line.

kubectl delete networkpolicy defaultnetworkpolicy testnetworkpolicy

Module exercise

The purpose of this section is to manage each steps of the lifecycle of an application to better understand each concepts of the Kubernetes course.

The main objective in this module is to understand how to secure the communication between Pods.

For more information about the application used all along the course, please refer to the Exercise App > Voting App link in the left panel.

Based on the principles explain in this module, try by your own to handle this steps. The development of a yaml file is recommended.

The file developed has to be stored in this directory : ~/data/votingapp/11_networks

  1. Create the default NetworkPolices of the voting-app namespace to :

    1. Deny all Ingress traffic

    2. Allow all Egress traffic

  2. Create the NetworkPolicies of the database Pods to :

    1. Allow the Ingress traffic on port 5432 only from the result and worker Pods

  3. Create the NetworkPolicies of the redis Pods to :

    1. Allow the Ingress traffic on port 6379 only from the vote and worker Pods

  4. Create the NetworkPolicies of the result Pods to :

    1. Allow the Ingress traffic on port 8080 only from everywhere

  5. Create the NetworkPolicies of the vote Pods to :

    1. Allow the Ingress traffic on port 8080 only from everywhere

External documentation

Those documentations can help you to go further in this topic :

PreviousAutoscalingNextRoutes

Last updated