How to Deploy, Break, Debug and Fix a Guestbook App with Kubernetes

In this tutorial, we will show you how to build and deploy a simple multi-tier web application using Kubernetes. Then, we will break the application and use Sveltos to debug and fix it.

What is Sveltos?

Sveltos is a configuration management project for a fleet of Kubernetes clusters.

Create a guestbook with Redis and PHP with Sveltos

Using Sveltos, deploy following resources in managed clusters:

The Redis leader
Two Redis followers
The guestbook web frontend

The first step is to create two ConfigMaps in the management cluster:

wget https://raw.githubusercontent.com/projectsveltos/sveltos/main/docs/assets/snapshot_example/database.yaml
kubectl create configmap database --from-file database.yaml

wget https://raw.githubusercontent.com/projectsveltos/sveltos/main/docs/assets/snapshot_example/frontend.yaml
kubectl create configmap frontend --from-file frontend.yaml

The database.yaml ConfigMap contains the definition of a single replica Redis Pod and two replicas Redis Followers, both exposed via a service each.

The frontend.yaml ConfigMap contains the definition of the guestbook application. The guestbook app uses a PHP frontend that is configured to communicate with either the Redis follower or leader Services, depending on whether the request is a read or a write.

Once the ConfigMaps have been created, we can create a ClusterProfile instance:

kubectl apply -f https://raw.githubusercontent.com/projectsveltos/sveltos/main/docs/assets/snapshot_example/clusterprofile.yaml

That instance instructs Sveltos to deploy all those resources in all matching managed clusters.

We can verify that all Kubernetes resources are deployed by running the following command:

kubectl exec -it -n projectsveltos sveltosctl-0 -- ./sveltosctl show addons 
+-----------------------------+-----------------+-----------+----------------+---------+-------------------------------+------------------+
|           CLUSTER           |  RESOURCE TYPE  | NAMESPACE |      NAME      | VERSION |             TIME              | CLUSTER PROFILES |
+-----------------------------+-----------------+-----------+----------------+---------+-------------------------------+------------------+
| default/clusterapi-workload | :Service        | test      | frontend       | N/A     | 2023-08-26 04:53:22 -0700 PDT | guestbook        |
| default/clusterapi-workload | apps:Deployment | test      | redis-leader   | N/A     | 2023-08-26 04:53:21 -0700 PDT | guestbook        |
| default/clusterapi-workload | :Service        | test      | redis-leader   | N/A     | 2023-08-26 04:53:21 -0700 PDT | guestbook        |
| default/clusterapi-workload | apps:Deployment | test      | redis-follower | N/A     | 2023-08-26 04:53:21 -0700 PDT | guestbook        |
| default/clusterapi-workload | :Service        | test      | redis-follower | N/A     | 2023-08-26 04:53:22 -0700 PDT | guestbook        |
| default/clusterapi-workload | apps:Deployment | test      | frontend       | N/A     | 2023-08-26 04:53:22 -0700 PDT | guestbook        |
+-----------------------------+-----------------+-----------+----------------+---------+-------------------------------+-

This will output a table of all the addons that have been deployed, along with the cluster where they are deployed.

If the frontend Service is externally visible, a client can request the Service from outside the Kubernetes cluster. Alternative a Kubernetes user can use kubectl port-forward to access the service even though it uses a ClusterIP.

Configuration Snapshot

Sveltos can be instructed to take configuration snapshot. This features allows cluster admins to perform the following tasks:

Live snapshots of the running Sveltos configuration;
Recurring snapshots;
Versioned storage of the configuration;
Full viewing of any snapshot configuration including the differences between snapshots.

This is a Snapshot instance requiring Sveltos to take a configuration snapshot every hour

apiVersion: utils.projectsveltos.io/v1alpha1
kind: Snapshot
metadata:
  name: hourly
spec:
  schedule: "00 * * * *"
  storage: /collection

While everything is working we can take a snapshot.

Breaking the Guestbook App

Now that the application is deployed, we can break it. To do this, we can change the redis-follower Service label selector:

kubectl apply -f https://raw.githubusercontent.com/projectsveltos/sveltos/main/docs/assets/snapshot_example/database_broken.yaml

The label selector is used to select which pods are backing the service. This change inadvertently breaks the application: redis followers are not reachable by frontend anymore. Entries in the database are no longer visible.

Debugging Issues

Now that the application is broken, we can use Sveltos to debug this issue. To do this, we can take another snapshot of the Kubernetes configuration and compare it to the snapshot that was taken when the application was working fine:

kubectl exec -it -n projectsveltos sveltosctl-0 -- ./sveltosctl snapshot diff --snapshot=hourly --from-sample=2023-08-26:05:00:00 --to-sample=2023-08-26:05:20:00
+-----------------------------------+---------------+-----------+----------------+----------+--------------------------------+
|              CLUSTER              | RESOURCE TYPE | NAMESPACE |      NAME      |  ACTION  |            MESSAGE             |
+-----------------------------------+---------------+-----------+----------------+----------+--------------------------------+
| default/capi--clusterapi-workload | /Service      | test      | redis-follower | modified | use --raw-diff option to see   |
|                                   |               |           |                |          | diff                           |
+-----------------------------------+---------------+-----------+----------------+----------+--------------------------------+

kubectl exec -it -n projectsveltos sveltosctl-0 -- ./sveltosctl snapshot diff --snapshot=hourly --from-sample=2023-08-26:05:00:00 --to-sample=2023-08-26:05:20:00 --raw-diff
--- /Service test/redis-follower from /collection/snapshot/hourly/2023-08-26:05:00:00
+++ /Service test/redis-follower from /collection/snapshot/hourly/2023-08-26:05:20:00
@@ -13,7 +13,7 @@
     # the port that this service should serve on
   - port: 6379
   selector:
-    app: redis
+    app: redis-follower
     role: follower
     tier: backend

The change to the label selector is immediately obvious, and we can easily understand the issue that it has caused.

Rollback

In addition to taking snapshots and comparing them, Sveltos can also be used to rollback configuration. This can be helpful if you make a change to the configuration that breaks something, or if you need to revert to a previous version of the configuration.

kubectl exec -it -n projectsveltos sveltosctl-0 -- ./sveltosctl snapshot rollback --snapshot=hourly --sample=2023-08-26:05:00:00

👏 Support this project

I hope you enjoyed this article! If you did, please check out the GitHub repo for the project. The repo contains the code, documentation, and examples, so it’s a great resource for getting started. You can also star 🌟 the project if you found it helpful.
Thank you for reading!

Blog