Merge pull request #80378 from openshift-cherrypick-robot/cherry-pick-75632-to-enterprise-4.17

[enterprise-4.17] OSDOCS-8391 rosaworkshop deploying app health check

_topic_maps/_topic_map_rosa.yml

@@ -192,6 +192,8 @@ Topics:
     File: cloud-experts-deploying-application-lab-overview
   - Name: Deployment
     File: cloud-experts-deploying-application-deployment
+  - Name: Health Check
+    File: cloud-experts-deploying-application-health-check
   - Name: Networking
     File: cloud-experts-deploying-application-networking
   - Name: Storage

cloud_experts_tutorials/cloud-experts-deploying-application/cloud-experts-deploying-application-health-check.adoc

@@ -0,0 +1,75 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="cloud-experts-deploying-application-health-check"]
+= Tutorial: Health Check
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: cloud-experts-deploying-application-health-check
+
+toc::[]
+
+//rosaworkshop.io content metadata
+//Brought into ROSA product docs 2024-01-26
+
+
+You can see how Kubernetes responds to pod failure by intentionally crashing your pod and making it unresponsive to the Kubernetes liveness probes.
+
+== Preparing your desktop
+
+. Split your desktop screen between the OpenShift web console and the OSToy application web console so that you can see the results of your actions immediately.
++
+image::5-ostoy-splitscreen.png[Splitscreen desktop with the OSToy application and the web console]
++
+If you cannot split your screen, open the OSToy application web console in another tab so you can quickly switch to the OpenShift web console after activating the features in the application. 
+
+. From the OpenShift web console, select *Workloads > Deployments > ostoy-frontend* to view the OSToy deployment. 
++
+image::5-ostoy-deployview.png[The web console deployments page]
+
+== Crashing the pod 
+
+. From the OSToy application web console, click *Home* in the left menu, and enter a message in the *Crash Pod* box, for example, `This is goodbye!`. 
+
+. Click *Crash Pod*.
++
+image::5-ostoy-crashpod.png[OSToy crash pod selection]
++
+The pod crashes and Kubernetes should restart the pod.
++
+image::5-ostoy-crashmsg.png[OSToy pod crash message]
+
+== Viewing the revived pod
+
+. From the OpenShift web console, quickly switch to the *Deployments* screen. You will see that the pod turns yellow, meaning it is down. It should quickly revive and turn blue. The revival process happens quickly so you might miss it.
++
+image::5-ostoy-podcrash.gif[Deployment details page]
+
+.Verification
+
+. From the web console, click  *Pods > ostoy-frontend-xxxxxxx-xxxx* to change to the pods screen.
++
+image::5-ostoy-events.png[Pod overview page]
+
+. Click the *Events* sub-tab and verify that the container crashed and restarted.
++
+image::5-ostoy-podevents.png[Pod events list]
+
+== Making the application malfunction
+
+Keep the pod events page open from the previous 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 the previous step, the application stops responding with a `200 HTTP code`. After 3 consecutive failures, Kubernetes will stop the pod and restart it. From the web console, switch back to the pod events page and you will see that the liveness probe failed and the pod restarted.
+
+The following image shows an example of what you should 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.