mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
31 lines
1.2 KiB
Plaintext
31 lines
1.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * rosa_learning/deploying_application_workshop/learning-deploying-application-health-check.adoc
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="learning-deploying-application-health-check-forced-malfunction_{context}"]
|
|
= Making the application malfunction
|
|
|
|
[role="_abstract"]
|
|
You can test your application's failure responses by intentionally causing the application to malfunction.
|
|
|
|
.Procedure
|
|
|
|
* From the OSToy application, click *Toggle Health* in the *Toggle Health Status* tile. Watch *Current Health* switch to *I'm not feeling all that well*.
|
|
+
|
|
image::5-ostoy-togglehealth.png[OSToy toggle health tile]
|
|
|
|
.Verification
|
|
|
|
After you make the application malfunction, the application stops responding with a `200 HTTP code`. After 3 consecutive failures, Kubernetes stops the pod and restarts it.
|
|
|
|
* From the web console, switch back to the pod events page to see that the liveness probe failed and the pod restarted.
|
|
|
|
The following image shows an example of what you will see on your pod events page.
|
|
|
|
image::5-ostoy-podevents2.png[Pod events list]
|
|
|
|
*A.* The pod has three consecutive failures.
|
|
|
|
*B.* Kubernetes stops the pod.
|
|
|
|
*C.* Kubernetes restarts the pod. |