http://localhost:8080/openshift_netapp/3.fault_tolerance/index.html In this lab we’ll dig deeper into how the state of your application is managed. We’ll cause some crashes, see how kubernetes responds, and understand the impact re-deploying applications. Key Terms DeploymentConfig - Describes a hosted appliation. Contains information such as the name of container image, number of copies to be run, and environment parameters. Deployment - an update to your application triggered by a image change, config change, or just by manually requesting one ReplicationController - Ensures that a specified number of replicas of a pod are running at all times. Starts new pods if old pods terminate or crash. Hugo en-us Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/openshift_netapp/3.fault_tolerance/application_health/index.html Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/openshift_netapp/3.fault_tolerance/application_health/index.html Kubernetes monitors your pods and the containers inside those pods. Let’s take a look at the information we can access. The topology overview screen is available at https://console-openshift-console.apps.aegis-core.fdlabs.dev/topology/ns/-workspace and provides a good deal of information at a glance. Start by expanding the deployment information box by clicking the nexus deployment. This will expand the information view and give us a high level view of key information such as: http://localhost:8080/openshift_netapp/3.fault_tolerance/crash_recovery/index.html Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/openshift_netapp/3.fault_tolerance/crash_recovery/index.html Let’s test an application crash scenario. Click on the “Terminal” tab to connect to a running shell in your pod. Run the ps x command to get a list of processes. You’ll notice a java process is running, this is our actual Nexus server. $ ps aux PID TTY STAT TIME COMMAND 1 ? Ssl 0:55 java -Dnexus-work=/sonatype-work -Dnexus-webapp-context-path=/nexus -Xms256m -Xmx768m -cp conf/:lib/* -server -Djava.net.preferIPv4Stack=true org.sonatype.nexus.bootstrap.Launcher ./conf/jetty.xml ./conf/jetty-requestlog.xml 60 ? Ss+ 0:00 /bin/sh 67 ? Ss 0:00 /bin/sh 80 ? R+ 0:00 ps x Now run kill 1 to force that java process to quit. This emulates what could happen in the case of a hard crash of our application. You should notice in a couple of seconds that your terminal stops accepting input and a warning pops up on your screen. http://localhost:8080/openshift_netapp/3.fault_tolerance/node_failure/index.html Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/openshift_netapp/3.fault_tolerance/node_failure/index.html In the previous step we showed how a container can be restarted if the application running inside it crashes. What happens if there’s an OS issue or hardware failure on the node hosting the application causing the actual pod to fail in a way that is not recoverable? In this case the replication controller will deploy an entirely new pod, potentially to a new node. Let’s emulate this by deleting a pod. Click the actions drop-down then select “delete”. http://localhost:8080/openshift_netapp/3.fault_tolerance/lifecycle/index.html Tue, 05 May 2020 13:15:09 -0400 http://localhost:8080/openshift_netapp/3.fault_tolerance/lifecycle/index.html Let’s browse back to our Nexus application at https://nexus--workspace.apps.aegis-core.fdlabs.dev/nexus/. Our application is still there and, despite all the crashes and pod rebuilds we just caused it seems relatively unharmed. Now click on the “Repositories” button on the left hand menu to view a list of repositories. Look at the list of repositories and recall back to the end of Lab #2 when we created a new repository.