Lab 5 - Kubernetes Networking

Complete

Implement the HTTP API server application. You can use any programming language or technologies you want. If you are unsure which approach to use, it is recommended to use either Python FastAPI or Flask frameworks.

An OpenAPI specification for the API has also been prepared, so feel free to generate the HTTP API implementation in any suported languages and implement the logic of the HTTP methods. You can find the API specification here: History server OpenAPI specification

You can find an example skeleton for the Python Flask API (where Garage specific methods are not completed) here: History server Flask example

The main requirement is that you use the exact endpoints that have been specifed and that the price data message JSON format is the following:

[
  {
    "estonian_time": "2025-10-01T00:00:00+03:00",
    "price": 5.01,
    "timestamp": 1727730000
  },
  {
    "estonian_time": "2025-10-01T01:00:00+03:00",
    "price": 3.21,
    "timestamp": 1727733600
  },
  {
    "estonian_time": "2025-10-02T00:00:00+03:00",
    "price": 78.57,
    "timestamp": 1727816400
  }
]

Garage exposes an S3-compatible API, so for the Garage integration, use the official AWS SDK for Python: Boto3. The Garage guide for building your own app provides reasonable examples to start with. Boto3 S3 client methods put_object, get_object, head_bucket (raises a ClientError if the bucket does not exist), and create_bucket should be enough to implement everything needed.

The Boto3 client for Garage should point endpoint_url at the Garage service, use garage as the region, and use path-style addressing. For example:

import os
import boto3
from botocore.client import Config

s3 = boto3.client(
    "s3",
    endpoint_url=os.environ["GARAGE_URI"],  # e.g. http://garage:3900
    aws_access_key_id=os.environ["ACCESS_KEY"],
    aws_secret_access_key=os.environ["SECRET_KEY"],
    region_name="garage",
    config=Config(signature_version="s3v4", s3={"addressing_style": "path"}),
)

Garage connection authentication variables (ACCESS_KEY, SECRET_KEY, and Garage URI should be read in from the environment variables and not hard coded). Also, when storing the data in Garage, you can use the value of the day variable (For example 2025-09-29) as part of the filename. Data should be stored in the price-data Garage bucket. It would be best if the application also checks that the price-data bucket exists and creates it if it does not exist.

After the code is ready and tested, publish the Docker image to the Docker hub. Name of the Docker image in DockerHub should be history-server.

Complete

Configure the price fetcher script to read the address of the History data server from system enviorenment variable named HISTORY_SERVER_URI. We will later configure this value through the Kubernetes CronJob manifest when we create a Kubernetes Service for the history data server.

Inside the script, once the data has been collected from Elering API, prepare a JSON, and send a POST request (For example using the requests.post() method in Python) at the History data server API endpoint address HISTORY_SERVER_URI/api/prices?day={tomorrow}, where the tomorrow variable format is 2025-09-29.

Prepare the data in the same JSON format as shown in the previous section and attach it as the request body to the HTTP POST request. Hint: It is ok to replace Elering CSV API request with a similiar JSON request to avoid CSV to JSON parsing steps.

Complete

Inspect an IP address of the echoserver Service (Test Kubernetes from lab3):

kubectl describe service/echoserver -n default
# Name:              echoserver
# Namespace:         default
# ...
# IP:                10.106.242.153
# IPs:               10.106.242.153
# Port:              <unset>  80/TCP
# ...

The IP above is cluster-scoped IP meaning it is available only within the cluster.

Complete

In the production namespace:

1. create a history-server Deployment for the history server app using the image you have built previously;
2. create a ClusterIP-type Service (name - history-server, listening port - 80) for the Deployment and validate if it works using curl;
3. build the adjusted price-fetcher app, which sends price data to the history-server endpoint, and update the existing CronJob.

NB:

1. Please, use the following labels for the history-server Deployment: app=electricity-calculator, microservice=history-server. Make sure to add them both to the metadata of the Deployment and to the metadata of the pod template;

2. Create a new secret named price-data-secret in the production namespace to store the Garage key credentials for the price-data bucket. You can get the credentials (Key ID and Secret key) with the following command:

   kubectl exec -it garage-0 -n production -- /garage key info price-fetcher-key --show-secret
   

   Then create a manifest file (for example price-data-secret.yaml) for the secret, replacing the placeholders with the values from the output above:

   apiVersion: v1
   kind: Secret
   metadata:
     name: price-data-secret
     namespace: production
   type: Opaque
   stringData: #(1)
     ACCESS_KEY: <Key ID>
     SECRET_KEY: <Secret key>
   

   1. stringData accepts plain-text values, Kubernetes base64-encodes them into the data field when the secret is created

   And apply it:

   kubectl apply -f price-data-secret.yaml -n production
   

   The history-server Deployment should use the credentials from the price-data-secret to set up necessary system enviorenment variables.

3. Update the price-fetcher CronJob specification and add a system enviorenment variable (env:) named HISTORY_SERVER_URI, which defines how to connect to the history server. Its value should be the Service address of the history server: http://history-server.production.svc.cluster.local:80

Hint: To reference the Garage service use http://garage:3900 (Boto3 requires the protocol to be specified before the hostname in endpoint_url). You can find the explanation in the service discovery section.

Complete

Let's create a NodePort service for the echoserver in the default namespace:

apiVersion: v1
kind: Service
metadata:
  name: echoserver-service-nodeport
  namespace: default
spec:
  type: NodePort
  selector:
    app: echoserver
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30001

It works as a previous service selecting Pods by app: echoserver label, but uses a different hostname (echoserver-service-nodeport) for discovery.

After inspecting it, you can see the network-specific data:

kubectl describe service/echoserver-service-nodeport
# ...
# IPs:                      10.109.11.56
# Port:                     <unset>  80/TCP
# TargetPort:               80/TCP
# NodePort:                 <unset>  30001/TCP
# ...

Complete

Let's create a PostgreSQL StatefulSet with this config:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgresql-hl-test
  namespace: test
spec:
  selector:
    matchLabels:
      app: postgresql-hl-test
  serviceName: postgresql-hl #(1)
  replicas: 2 #(2)
  template:
    metadata:
      labels:
        app: postgresql-hl-test
    spec:
      containers:
      - name: postgres
        image: postgres:17.6
        imagePullPolicy: "Always"
        env: #(3)
        - name: POSTGRES_DB
          value: "test"
        - name: POSTGRES_USER
          value: "test"
        - name: POSTGRES_PASSWORD
          value: "postgres-password"
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: postgredb
        ports:
        - containerPort: 5432
          name: postgres-port
      volumes: #(4)
        - name: postgredb
          emptyDir: {}

1. A name of the headless service created later; used for service discovery between created Pods
2. Number of PostgreSQL replicas
3. Environment variables for PostgreSQL database setup
4. PostgreSQL doesn't use any persistent storage for now

Also, let's create a headless service with the aforementioned name.

apiVersion: v1
kind: Service
metadata:
  name: postgresql-hl
  namespace: test
spec:
  clusterIP: None
  selector:
    app: postgresql-hl-test
  ports:
  - port: 5432
    targetPort: 5432

You can check the created endpoints and see one name has two linked endpoints:

kubectl get endpoints -n test
# NAME            ENDPOINTS                         AGE
# postgresql-hl   10.0.1.213:5432,10.0.2.190:5432   12m

The description of the postgresql-hl service shows 2 endpoints for the postgresql Pods, meaning, you can access each one separately.

...
IP:                None
IPs:               None
Port:              <unset>  5432/TCP
TargetPort:        5432/TCP
Endpoints:         10.0.1.181:5432,10.0.1.42:5432
...

For testing, let's use one of 2 pods to connect to another:

kubectl exec -it postgresql-hl-test-0 -n test -- /bin/bash
# ...
export PGPASSWORD='postgres-password'
psql -h postgresql-hl-test-1.postgresql-hl -U test
# psql (15.4)
# Type "help" for help.

# test=>

After testing, you should see successful connection to the database.

Complete

First of all, let's install the Gateway API CRDs:

kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_gateways.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_backendtlspolicies.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_tlsroutes.yaml
kubectl apply --server-side -f https://raw.githubusercontent.com/kubernetes-sigs/gateway-api/v1.6.1/config/crd/standard/gateway.networking.k8s.io_tcproutes.yaml

Then upgrade Cilium with Gateway API and NodePort support enabled:

cilium upgrade --version 1.20.1 --set gatewayAPI.enabled=true --set kubeProxyReplacement=true --set nodePort.enabled=true

Enable host network mode for Gateways:

cilium config set gateway-api-hostnetwork-enabled true

Finally, restart the Cilium Pods to force them to reload the configuration (this may not always be needed):

kubectl rollout restart deploy/cilium-operator -n kube-system
kubectl rollout restart ds/cilium -n kube-system

NB! restarting Cilium will disable cilium hubble NodePort again. You should enable it again (check lab 3).

Complete

Let's create a Gateway for echoserver:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: echoserver-gateway
  namespace: default
spec:
  gatewayClassName: cilium #(1)
  listeners:
  - name: http
    protocol: HTTP
    port: 31112 #(2)
    allowedRoutes:
      namespaces:
        from: Same #(3)

1. GatewayClass created by Cilium; tells Kubernetes that Cilium implements this Gateway
2. Node port which the Gateway listens on each node (host network mode). Use 31112 for this lab
3. Only routes from the same namespace (default) can attach to this Gateway

And an HTTPRoute that forwards traffic from the Gateway to the echoserver Service:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echoserver-route
  namespace: default
spec:
  parentRefs: #(1)
  - name: echoserver-gateway
  hostnames:
  - echoserver.PUBLIC_NODE_IP.nip.io #(2)
  rules: #(6)
  - matches:
    - path:
        type: PathPrefix
        value: / #(3)
    backendRefs:
    - name: echoserver #(4)
      port: 80 #(5)

1. Gateway this route attaches to
2. Hostname for the service. Please, replace the PUBLIC_NODE_IP with actual IP of your control-plane node.
3. HTTPRoute allows different paths for services, in this lab we use only root
4. Service name to lookup
5. Service port to target
6. nip.io forwards traffic to the publicly available IP on third domain level (PUBLIC_NODE_IP in the example)

Complete

Let's create a new namespace called k8s-lab5:

kubectl create namespace k8s-lab5

Complete

An example policy allowing access to echoserver in default namespace is:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: echoserver-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: echoserver
  policyTypes:
    - Ingress
  ingress:
    - from:
      - namespaceSelector:
          matchLabels: #(1)
            kubernetes.io/metadata.name: k8s-lab5
      - podSelector:
          matchLabels: #(2)
            app: nginx
      ports:
        - protocol: TCP
          port: 80

1. All the Pods from k8s-lab5 namespace can access the Pod
2. All the Pods from the same namespace and labels name=nginx can access the Pod

Create a network policy via the manifest above in the default namespace.

NB: This policy could break the lab3-05 check in the scoring site. If this happens, please follow cleanup instructions after completion of the main content of this lab.

Complete

You need to create network policy for Garage Pods. For this policy, isolate the Garage Pods from all connections except ones from history-server Pod within the same production namespace.

NB: please use garage-network-policy name.