The first step is to get the logs. On the second shell, run the following:

kubectl logs <frontend-pod-name>

You will see entries, like this:

"GET /guestbook.php?cmd=set&key=messages&value=,test%201,test%202,test%204,test%20456,this%20entry%20should%20not%20be%20present%20in%20redis%20db HTTP/1.1" 200 1345 "https://handsonaks-ingress.westus2.cloudapp.azure.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0"

So you know that the error is somewhere when writing to the database in the "set" section of the code.

On the other cloud shell window, edit the file to print out debug messages:

  if ($_GET['cmd'] == 'set') {
    if(!defined('STDOUT')) define('STDOUT', fopen('php://stdout', 'w'));
    fwrite(STDOUT, "hostname at the beginning of 'set' command ");
    fwrite(STDOUT, $host);
    fwrite(STDOUT, "
");

Add a new entry to the browser and look at the logs again:

kc logs <frontend-pod-name>

You will see this entry:

hostname at the beginning of 'set' command redis-master

So we "know" that the error is between this line and the starting of the client, so the setting of the $host = 'localhost' must be the offending error. This error is not as uncommon as you think it would be, and as we just saw could have easily gone through QA unless there had been a specific instruction to refresh the browser. It could have worked perfectly will for the developer, as they could have a running redis server on the local machine.

Delete the offending line, and save the file:

 18   if ($_GET['cmd'] == 'set') {
 19     if(!defined('STDOUT')) define('STDOUT', fopen('php://stdout', 'w'));
 20     fwrite(STDOUT, "hostname at the beginning of 'set' command");
 21     fwrite(STDOUT, $host);
 22     fwrite(STDOUT, "
");
 23     $client = new PredisClient([

Add a new entry to the browser and hit Refresh to be sure:

The following points summarize some common errors and methods to fix the errors:

• Errors can come in many shapes and forms.
• Most of the errors encountered by the deployment team are configuration issues.
• Logs are your friend.
• Adding kubectl exec to a container is your next best friend.
• Note this a serious security risk, as it pretty much lets the operator do what they want.
• Anything printed to stdout and stderr shows up in the logs (independent of the application/language/logging framework).