Service Deployment
Overview
The Service Deployment application empowers Apolo users to deploy any containerized application within a Kubernetes environment. It offers seamless integration with various Apolo features, including public domain exposure with authentication, autoscaling, monitoring, logging and many more.
By utilizing the Service Deployment app, users can streamline their deployment processes, ensure consistent environments across development and production, and integrate seamlessly with Apolo's monitoring and logging tools for enhanced observability.
The Service Deployment app provides the following functionalities:
Container Deployment: deploy any container image into the Kubernetes environment.
Public Domain Exposure: optionally expose deployments under a public domain name with an optional platform authentication.
Autoscaling: optionally, enable and configure Horizontal Pod Autoscaler (HPA) based on CPU and memory utilization. More exotic auto-scaling configuration will be available soon with integration of Keda autoscaler.
Monitoring and Logging: Collect logs and monitor the deployment's performance.
Integrations support: integrate with other solutions to support the deployment, like using custom private container registry.
Use Cases
Web Services: Deploy RESTful APIs or web applications that require public access with secure authentication mechanisms.
Microservices Architecture: Manage and scale microservices independently, leveraging Apolo's autoscaling features to handle varying loads efficiently.
Data Processing Pipelines: Run data ingestion, transformation, and processing tasks that can benefit from containerization and orchestration.
Machine Learning Inference: Serve machine learning models in production, ensuring high availability and scalability.
Custom Applications: Deploy bespoke applications tailored to specific business needs, integrating with other services and tools within the Apolo ecosystem.
Installing
The easiest way to learn is by doing, so in this case we are going to deploy simplistic web server, a hashicorp/http-echo container that has the only job — respond to the request with the configured payload.
Select "Service Deployment" application at Apolo web console
Access the Apolo web console and go to the "Apps" section. We presume you are already authorized in web console and a participant of organization and project.
Now we configure application parameters
Configure application
Resource Preset: Here you select an appropriate preset that specifies CPU, memory and GPU resources for your workload.
For our use-case some tiny preset should work well, e.g., cpu-mini.
Container Image: Specify the container image repository and tag. Optionally, you could attach image pull secrets from dockerhub or other container image registry app.
For our example, we set container image repository to hashicorp/http-echo, tag to 1.0.0 and leave registry secrets integration blank. We do not need custom registry integration int this case.
Autoscaling: Enable and configure HPA settings, including minimum and maximum replicas, and target CPU and memory utilization percentages.
Here even though the API load will be tiny, we still enable it with 1 min and 3 max replicas and set autoscaling triggers at 70% for both CPU and memory consumption.
Container: allows one to adjust container parameters. For instance, set any necessary arguments for the container command or the command itself. One can also add environment variables, either with plain text values, or mounted as platform secrets. Here you can also configure Apolo Files mounts to be accessible from within the deployed container.
In our case, we add two arguments for the server, -text="hello apolo" and -listen=:8080 so it serves static text for HTTP request on the port 8080. As for the environment variables or storage mounts, we do not to add anything for now.
Networking: Configure which ports should be exposed, ingress settings, and port mappings.
In our example, we protect HTTP ingress with platform auth services and expose a single port 8080 matching the previous configuration and expose it with a prefix path type with path /.
Healthcheks: help you to monitor liveness of the service and restart it if needed. This configuration is quite flexible, allowing one to monitor HTTP, gRPC endpoints, TCP socket or just simple bash command (exec). For HTTP and gRPC the response should be of 2xx status code, TCP connection should be opened and exec should exit with status code 0.
Enable "Health check probes" and set startup & readiness probes to performHTTP health check with 30 seconds startup delay, 10 seconds period and allow it up to 5 failures before triggering the restart of the container. Set healthcheck timeout to 5 seconds.
Triggering installation
After clicking the "install" button, you will be redirected to the application details page and Apolo will take care of application installation.
In a minute, you could hit "refresh" button or wait while the web console updates status of the application. It should switch into "healthy" state. Now you could use the application.
Usage
The application usage highly depend on what is deployed under the hood. By default, the application outputs include two HTTP endpoints, if at least one HTTP port was configured, as in our example.
To view these endpoint details, you could scroll down application details page.
Access via public domain
In our example, the publicly available domain name is displayed in the list of application outputs. It is also protected by platform auth, and in-cluster domain name are displayed. In order to use public domain name, one should have access to the same organization, cluster and project. Let's verify it.
Intra-cluster access
In many cases, you'll need to access your applications from other applications or from within the jobs. For this case, each application's public domain endpoint has a corresponding intra-cluster sibling with some differences though:
Intra-cluster endpoints obviously are not accessible outside of the cluster or other clusters
Intra-cluster endpoints are not protected by platform auth, neither they have TLS (at least, for now).
Intra-cluster endpoints are not limited to HTTP-only traffic, you could also communicate in binary protocols on the TCP/UDP levels.
Intra-cluster endpoints are only accessible from within the workloads that belong to the same project.
Intra-cluster endpoints are not "port-forwarded" to 443 port, instead, you should connect to the same port you specified in the configuration file.
For our case, let's connect to the application from within the simplistic curl job & hit the HTTP API endpoint with a GET request:
Cleanup
When the application is not needed anymore, you could remove it by clicking the "uninstall" button on the installed app details/status screen.
References
Last updated
Was this helpful?
