Run runtime services in Kubernetes
Besides local execution of the vehicle runtime components, another way is to deploy them as containers in a Kubernetes control plane (like K3D). To create a K3D instance, we provide Visual Studio Code Tasks, a feature of Visual Studio Code. Additional information on tasks can be found here.
Quick Start: Each step has a task that is defined in .vscode/tasks.json:
- Core tasks (dependent on each other in the given order):
K3D - Install prerequisites: Install prerequisite components K3D, Helm, KubeCTL and Dapr without configuring them.
K3D - Configure control plane: Creates a local container registry used by K3D as well as an K3D cluster with Dapr enabled.
K3D - Deploy runtime: Deploys the runtime components (like KUKSA Data Broker, Seat Service, …) within the K3D cluster.
K3D - Build VehicleApp: Builds the VehicleApp and pushes it to the local K3D registry.
K3D - Deploy VehicleApp: Builds and deploys the VehicleApp via Helm to the K3D cluster.
Each task has the required dependencies defined. If you want to run the runtime in K3D, the task
K3D - Deploy VehicleApp will create and configure everything. So it’s enough to run that task.
- Optional helper tasks:
K3D - Deploy VehicleApp (without rebuild): Deploys the VehicleApp via Helm to the K3D cluster (without rebuilding it). That requires, that the task
K3D - Build VehicleApphas been executed once before.
K3D - Install tooling: Installs tooling for local debugging (K9s)
K3D - Uninstall runtime: Uninstalls the runtime components from the K3D cluster (without deleting the cluster).
K3D - Reset control plane: Deletes the K3D cluster and the registry with all deployed pods/services.
K3D is configured so that Mosquitto and the KUKSA Data Broker can be reached from outside the container over the ports
31883 (Mosquitto) and
30555(KUKSA Data Broker). The test runner, that is running outside of the cluster, can interact with these services over those ports.
To check the status of your K3D instance (running pods, containers, logs, …) you can either use the
kubectl utility or start K9s (after running the task
K3D - Install tooling once) in a terminal window to have a UI for interacting with the cluster.
Run as Bundle: To orchestrate these tasks, a task called
K3D - Deploy VehicleApp is available. This task runs the other tasks in the correct order. You can run this task by clicking
F1 and choose
Tasks: Run task, then select
K3D - Deploy VehicleApp.
Tasks Management: Visual Studio Code offers various other commands concerning tasks like Start/Terminate/Restart/… You can access them by pressing F1 and typing
task. A list with available task commands will appear.
Logging: Running tasks appear in the Terminals View of Visual Studio Code. From there, you can see the logs of each running task.
Uploading files to persistentVolume
Some applications (e.g. FeederCAN) might make it necessary to load custom files from mounted volume. For that reason, persistentVolume is created in k3d cluster.
All the files that are located in
deploy/runtime/k3d/volume will be uploaded to the k3d cluster dynamically. In order to mount files to the directory that is accessible by the application, please refer to the deployment configuration file:
deploy/runtime/k3d/volume are automatically reflected in PersistentVolume.
Uploading custom candump file to FeederCAN
FeederCAN requires candump file. Pre-defined candump file is part of docker container release, however, if necessary, there is an option to upload the custom file by:
- Creating/updating candump file with with name
- Recreating the feedercan pod:
kubectl delete pods -l app=feedercan
More information about FeederCan can be found here
- Tutorial: Start runtime services locally
- Tutorial: Setup and Explore Development Enviroment
- Concept: Deployment Model
- Concept: Build and release process
- Tutorial: Deploy a Python Vehicle App with Helm