Updates for exercise3.
This commit is contained in:
@ -12,12 +12,11 @@ We have our application deployed, let's scale it up to make sure it will be resi
|
|||||||
|
|
||||||
While **Services** provide discovery and load balancing for **Pods**, the higher level **Deployment** resource specifies how many replicas (pods) of our application will be created and is a simplistic way to configure scaling for the application.
|
While **Services** provide discovery and load balancing for **Pods**, the higher level **Deployment** resource specifies how many replicas (pods) of our application will be created and is a simplistic way to configure scaling for the application.
|
||||||
|
|
||||||
> Note: To learn more about **Deployments** refer to this [documentation](https://docs.openshift.com/container-platform/4.14/applications/deployments/what-deployments-are.html).
|
> Note: To learn more about **Deployments** refer to this [documentation](https://docs.openshift.com/container-platform/4.16/applications/deployments/what-deployments-are.html).
|
||||||
|
|
||||||
|
|
||||||
## 3.1 - Reviewing the parksmap deployment
|
## 3.1 - Reviewing the parksmap deployment
|
||||||
|
|
||||||
Let's start by confirming how many `replicas` we currently specify for our ParksMap application. We'll also use this exercise step to take a look at how all resources within OpenShift can be viewed and managed as [YAML](https://www.redhat.com/en/topics/automation/what-is-yaml) formatted text files which is extremely useful for more advanced automation and GitOps concepts.
|
Let's start by confirming how many `replicas` we currently specify for our ParksMap application. We'll also use this exercise step to take a look at how all resources within OpenShift can be viewed and managed as [YAML](https://www.redhat.com/en/topics/automation/what-is-yaml) formatted text files which is extremely useful for more advanced automation and GitOps concepts.
|
||||||
|
|
||||||
Start in the **Topology** view of the **Developer** perspective.
|
Start in the **Topology** view of the **Developer** perspective.
|
||||||
|
|
||||||
@ -31,12 +30,11 @@ spec:
|
|||||||
```
|
```
|
||||||
|
|
||||||
<Zoom>
|
<Zoom>
|
||||||
| |
|
| |
|
||||||
|:-------------------------------------------------------------------:|
|
|:-------------------------------------------------------------------:|
|
||||||
| *ParksMap application deployment replicas* |
|
| *ParksMap application deployment replicas* |
|
||||||
</Zoom>
|
</Zoom>
|
||||||
|
|
||||||
|
|
||||||
## 3.2 - Intentionally crashing the application
|
## 3.2 - Intentionally crashing the application
|
||||||
|
|
||||||
With our ParksMap application only having one pod replica currently it will not be tolerant to failures. OpenShift will automatically restart the single pod if it encounters a failure, however during the time the application pod takes to start back up our users will not be able to access the application.
|
With our ParksMap application only having one pod replica currently it will not be tolerant to failures. OpenShift will automatically restart the single pod if it encounters a failure, however during the time the application pod takes to start back up our users will not be able to access the application.
|
||||||
@ -58,12 +56,11 @@ kill 1
|
|||||||
The pod will automatically be restarted by OpenShift however if you refresh your second browser tab with the application **Route** you should be able to see the application is momentarily unavailable.
|
The pod will automatically be restarted by OpenShift however if you refresh your second browser tab with the application **Route** you should be able to see the application is momentarily unavailable.
|
||||||
|
|
||||||
<Zoom>
|
<Zoom>
|
||||||
| |
|
| |
|
||||||
|:-------------------------------------------------------------------:|
|
|:-------------------------------------------------------------------:|
|
||||||
| *Intentionally crashing the ParksMap application* |
|
| *Intentionally crashing the ParksMap application* |
|
||||||
</Zoom>
|
</Zoom>
|
||||||
|
|
||||||
|
|
||||||
## 3.3 - Scaling up the application
|
## 3.3 - Scaling up the application
|
||||||
|
|
||||||
As a best practice, wherever possible we should try to run multiple replicas of our pods so that if one pod is unavailable our application will continue to be available to users.
|
As a best practice, wherever possible we should try to run multiple replicas of our pods so that if one pod is unavailable our application will continue to be available to users.
|
||||||
@ -79,12 +76,11 @@ In the **Details** tab of the information pane click the **^ Increase the pod co
|
|||||||
Once the new pod is ready, repeat the steps from task `3.2` to crash one of the pods. You should see that the application continues to serve traffic thanks to our OpenShift **Service** load balancing traffic to the second **Pod**.
|
Once the new pod is ready, repeat the steps from task `3.2` to crash one of the pods. You should see that the application continues to serve traffic thanks to our OpenShift **Service** load balancing traffic to the second **Pod**.
|
||||||
|
|
||||||
<Zoom>
|
<Zoom>
|
||||||
| |
|
| |
|
||||||
|:-------------------------------------------------------------------:|
|
|:-------------------------------------------------------------------:|
|
||||||
| *Scaling up the ParksMap application* |
|
| *Scaling up the ParksMap application* |
|
||||||
</Zoom>
|
</Zoom>
|
||||||
|
|
||||||
|
|
||||||
## 3.4 - Self healing to desired state
|
## 3.4 - Self healing to desired state
|
||||||
|
|
||||||
In the previous example we saw what happened when we intentionally crashed our application. Let's see what happens if we just outright delete one of our ParksMap applications two **Pods**.
|
In the previous example we saw what happened when we intentionally crashed our application. Let's see what happens if we just outright delete one of our ParksMap applications two **Pods**.
|
||||||
@ -116,7 +112,6 @@ In our ParksMap **Deployment** we have declared we always want two replicas of o
|
|||||||
|
|
||||||
## 3.5 - Bonus objective: Autoscaling
|
## 3.5 - Bonus objective: Autoscaling
|
||||||
|
|
||||||
If you have time, take a while to explore the concepts of [HorizontalPodAutoscaling](https://docs.openshift.com/container-platform/4.14/nodes/pods/nodes-pods-autoscaling.html), [VerticalPodAutoscaling](https://docs.openshift.com/container-platform/4.14/nodes/pods/nodes-pods-vertical-autoscaler.html) and [Cluster autoscaling](https://docs.openshift.com/container-platform/4.14/machine_management/applying-autoscaling.html).
|
Before moving on feel free to take a moment to review the concepts of [HorizontalPodAutoscaling](https://docs.openshift.com/container-platform/4.16/nodes/pods/nodes-pods-autoscaling.html), [VerticalPodAutoscaling](https://docs.openshift.com/container-platform/4.16/nodes/pods/nodes-pods-vertical-autoscaler.html) and [Cluster autoscaling](https://docs.openshift.com/container-platform/4.16/machine_management/applying-autoscaling.html).
|
||||||
|
|
||||||
|
|
||||||
Well done, you've finished exercise 3! 🎉
|
Well done, you've finished exercise 3! 🎉
|
||||||
|
|||||||
Reference in New Issue
Block a user