Basic Experiment¶

On This Page¶

Overview
Experiment Scenario
Architecture
Deployment
Interactive Testing Session

Overview¶

The Ping Pong experiment is a minimal yet effective demonstration of the blueprint capabilities. It shows how to deploy and operate distributed services across multiple Kubernetes clusters and evaluate their communication behavior.

Objectives¶

Demonstrate multi-cluster deployment across the continuum
Evaluate inter-cluster communication between distributed services
Analyze the impact of network conditions on application performance

Experiment Scenario¶

The experiment consists of two simple microservices:

Ping service (sender)
Pong service (receiver)

Services are deployed on separate Kubernetes clusters (e.g., edge vs cloud) to evaluate cross-cluster communication.

Architecture¶

Edge Cluster (Ping)  --->  Cloud Cluster (Pong)
                HTTP Requests

Deployment¶

STEP 0: Prerequisites¶

Before proceeding with next steps you have to complete the SETUP phase, which is a one-time operation. Once you have the CCBP-CLI set up and the SFCC initialized, you can proceed with the following steps to run a basic infrastructure experiment.

STEP 1: Create 3 Kubernetes Clusters¶

Use the CCBP-CLI to create three Kubernetes clusters: one for the Ping service, one for the Pong service, and one for interactive session.

A ready to-use cluster configuration can be found in the CCBP-CLI /experiments/kubeCluster.yaml experiments or you can download it and customize it according to your needs from the repo.

To create the clusters we exploit the SLICES-BI Operator , which allows us to define Kubernetes clusters as custom resources. The following command creates the three clusters using the provided configuration file:

kubectl apply -f /experiments/kubeCluster.yaml --kubeconfig /SlicesFile/kubeconfigs/sfcc.yaml

STEP 2: Clone the Ping Pong Repository¶

git clone https://gitlab.com/MMw_Unibo/platformeng/ping-pong-test

STEP 3: Get Kubeconfig for Clusters¶

Inside a ccbp-cli session, run the following command to retrieve the kubeconfig files for each cluster. This will allow you to interact with the clusters using kubectl or other Kubernetes tools.

getKubeconfigUtils <project_name> <experiment_name> <vm_name>
# Example:
getKubeconfigUtils ccbp ccbp-base master
getKubeconfigUtils ccbp ccbp-base edge1
getKubeconfigUtils ccbp ccbp-base edge2

Step 4: Deploy Pong Service¶

Includes:

Kubernetes Deployment (container, port, namespace)
Kubernetes Service (NodePort) for external access

kubectl apply -f answer-random/answer-random.yaml --kubeconfig /SlicesFile/kubeconfigs/master.yaml

STEP 5: Deploy Ping Service¶

Get the IP address of the Cluster where the Pong service is deployed:

slices bi list --experiment ccbp-base
or
kubectl get kubenodes --kubeconfig /SlicesFile/kubeconfigs/sfcc.yaml

Edit the ping deployment configuration to set the RANDOM_ADDRESS environment variable with the obtained IP address. The ping deployment configuration can be found in the ask-random/ask-random.yaml file.

 env:
    - name: RANDOM_ADDRESS
      value: "192.168.56.12"

Then deploy the ping service:

kubectl apply -f ask-random/ask-random.yaml --kubeconfig /SlicesFile/kubeconfigs/edge1.yaml

STEP 6: Observe Communication¶

Check the logs of the Ping service to see the responses from the Pong service:

kubectl logs -l app=ask-random --kubeconfig /SlicesFile/kubeconfigs/edge1.yaml

Or you can check the logs in the Monitoring-aaS Grafana dashboard, which is integrated with the CCBP for observability.

Interactive Testing Session¶

Start an interactive session inside a container hosted in one of the two clusters and experiment with packet loss and packet delay among the two Kubernetes clusters.

Step 1: Start Interactive Session¶

Deploy a curl pod on the third cluster:

kubectl apply -f deployments/curlpod.yaml --kubeconfig /SlicesFile/kubeconfigs/edge2.yaml

Access it:

kubectl exec -it curl --kubeconfig /SlicesFile/kubeconfigs/edge2.yaml -- /bin/sh

Run test request:

curl -s -w "Latency: %{time_total}s
" <PONG_IP>:<NODEPORT>/random

Step 2: Simulate Network Conditions¶

Log into the node hosting the curl pod and use tc to simulate different network conditions between the two clusters.

ssh -i /root/.ssh/ccbp_key ubuntu@<edge2_node_ip>

Simulate packet loss OR delay:

sudo tc qdisc add dev <interface> root netem loss 50%

sudo tc qdisc add dev <interface> root netem delay 30ms 5ms

Step 3: Observe Results¶

In the first terminal connected to the curl pod test the request latency when setting different loss conditions

 curl -s -w ' Latency: %{time_total}s\n' <PONG_IP>:30007/random