mirror of
https://github.com/edgelesssys/constellation.git
synced 2025-05-04 15:25:00 -04:00
Overwrite v2.0 in docs (#144)
This commit is contained in:
parent
0165a6be43
commit
d5d5448935
17 changed files with 245 additions and 176 deletions
|
@ -1,5 +1,5 @@
|
|||
# Emojivoto
|
||||
For a simple but fun demo application to test the general functionality of your confidential cluster, take a look at [Emojivoto](https://github.com/BuoyantIO/emojivoto).
|
||||
[Emojivoto](https://github.com/BuoyantIO/emojivoto) is a simple and fun application that's well suited to test the basic functionality of your cluster.
|
||||
|
||||
<!-- vale off -->
|
||||
|
||||
|
|
|
@ -1,10 +1,14 @@
|
|||
# Horizontal Pod Autoscaling
|
||||
This example demonstrates Constellation's autoscaling capabilities by utilizing a slightly adapted version of the Kubernetes [HorizontalPodAutoscaler Walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). During the following steps, we will see Constellation be able to spawn new VMs on demand, add them to the cluster and later on delete them again when the load has settled down.
|
||||
This example demonstrates Constellation's autoscaling capabilities by utilizing a slightly adapted version of the Kubernetes [HorizontalPodAutoscaler Walkthrough](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). During the following steps, Constellation will spawn new VMs on demand, verify them, add them to the cluster, and delete them again when the load has settled down.
|
||||
|
||||
## Requirements
|
||||
The cluster needs to be initialized with Kubernetes 1.23 or higher. In addition, autoscaling must be enabled to trigger Constellation to assign new nodes dynamically.
|
||||
|
||||
Just for this example specifically, the cluster should have as few worker nodes in the beginning as possible. Starting with a small cluster having only *one* control plane node and *one* worker node using one of the low-end supported VMs is recommended for an easier demonstration and saving costs. The example has been tested on Azure using a `Standard_DC4as_v5` and on GCP using `n2d-standard-4` instance.
|
||||
Just for this example specifically, the cluster should have as few worker nodes in the beginning as possible. We recommend starting with a small cluster with only *one* low-powered node for the control plane node and *one* low-powered worker node.
|
||||
|
||||
:::info
|
||||
We tested the example using instances of types `Standard_DC4as_v5` on Azure and `n2d-standard-4` on GCP.
|
||||
:::
|
||||
|
||||
## Setup
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
# Online Boutique
|
||||
[Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) is an e-commerce demo application by Google consisting of 11 separate microservices. Constellation is automatically able to set up a load balancer on your CSP, making it easy to expose services from your confidential cluster without any additional setup required.
|
||||
[Online Boutique](https://github.com/GoogleCloudPlatform/microservices-demo) is an e-commerce demo application by Google consisting of 11 separate microservices. In this demo, Constellation automatically sets up a load balancer on your CSP, making it easy to expose services from your confidential cluster.
|
||||
|
||||
<!-- vale off -->
|
||||
|
||||
|
@ -20,7 +20,7 @@
|
|||
kubectl wait --for=condition=available --timeout=300s -n boutique --all deployments
|
||||
```
|
||||
4. Get the external facing IP address of the frontend (with `<your-ip>` being a placeholder for the assigned IP from your CSP):
|
||||
```terminal-session
|
||||
```shell-session
|
||||
kubectl get service frontend-external -n boutique | awk '{print $4}'
|
||||
EXTERNAL-IP
|
||||
<your-ip>
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue