This document describes how to troubleshoot during or after deploying PWA on the Kubernetes cluster, so you can fix occurring issues immediately.
For more detailed information on the current CI/CD process on PWA and the most typical problems and questions, see Cookbook - Intershop Commerce Platform DevOps - CI Use Cases for Progressive Web App.
Add the AKS cluster to local kubectl config.
>>> az login >>> az aks get-credentials --admin --subscription <SUBSCRIPTION_ID> -g <RESOURCE_GROUP_NAME> -n <CLUSTER_NAME>
Check available <cstmr>
namespaces which host the customer project environment. Their names can be found in the table PWA CI/CD of the customer system page in your Confluence space.
Set default namespace for kubectl.
>>> kubectl get namespace >>> kubectl config set-context --current --namespace=pwa-<cstmr>-<env>
Validate the selection.
>>> kubectl get pod
To check events for the namespace object during/after the deployment, use the below command. You should be able to see errors at an early stage during startup of a container or problems with memory/CPU resources, etc.:
>>> kubectl get events -w
To stop events, press CTRL
+C
.
To narrow event logs to a Pod object, use the following command and see the Events:
section.
>>> kubectl describe pod <POD_NAME>
Run kubectl get deployments
to check if the deployment has been created.
If the deployment is still being created, the READY
column displays how many replicas of the application are ready compared to the desired count.
To see the deployment status, run kubectl rollout status deployment/<DPL_NAME>
.
If the deployment is successful, the output is similar to the following:
deployment "<DPL_NAME>" successfully rolled out
To see the Pod status, run kubectl get pods
.
The output should be similar to:
NAME READY STATUS RESTARTS AGE <cstmr>-int-edit-pwa-main-84b6b79887-fs6d8 1/1 Running 0 15h <cstrm>-int-edit-pwa-main-cache-77667db86c-zzbhs 1/1 Running 0 14h <cstrm>-int-pwa-main-6dc65c7786-z769l 1/1 Running 0 15h <cstrm>-int-pwa-main-cache-6ddb497f4d-v24np 1/1 Running 0 14h
To see logs and check why a storefront is not working despite a successful deployment, enter the following:
>>> kubectl logs <POD_NAME>
>>> kubectl exec ${POD_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
To check logs on a running Pod, enter as follows:
>>> kubectl exec ${POD_NAME} -- /var/log/cassandra/system.log
It is also possible to enter the Pod and run the command in a shell terminal:
>>> kubectl exec -it <POD_NAME> -- /bin/bash
To get an overview of current resource usage on Kubernetes Pod, for example, CPU/memory, go to Pod exec
mode:
>>> kubectl exec -it <POD_NAME> -- /bin/bash >>> cat /sys/fs/cgroup/cpu/cpuacct.usage >>> cat /sys/fs/cgroup/memory/memory.usage_in_bytes
Compare the resources with the default for the respective environment in flux-caas-int or flux-caas-prd.
To check that the desired version is applied, run:
>>> kubectl get pod <POD_NAME> | grep <VERSION>
Check helm list
to view releases of the specified namespace (names of Helm releases).
Enter helm history <RELEASE_NAME>
to view the Helm history.
A change log appears with the status of deployment. Status deployed
indicates a successful deployment.
Get values of the current configuration of deployment: helm get values <RELEASE_NAME>
.
To roll back to the previous version after an unsuccessful deployment, run the following command omitting any argument.
To check customer <RELEASE_NAME>
, run helm list
. If the table output is empty, use the following pattern pwa-<cstmr>-<env>
.
>>> helm rollback <RELEASE_NAME>
If you need to roll back to a specific previous version, check for latest revision numbers by running as follows:
>>> helm history <RELEASE_NAME> >>> helm rollback <RELEASE_NAME> [REVISION]
After completing the deployment, customers often request that the cache be cleared. To do so, follow these steps:
>>> kubectl get deploy >>> kubectl rollout restart deployment <DEPLOYMENT_NAME>