Application Lifecycle Considerations
When a user changes the configuration for an application, the new configuration will be submitted via the Helm upgrade command. Refer to Updating a Deployment for editing application configurations in Fleet Command.
In Fleet Command, applications are updated by removing the current deployment and creating a new deployment with the updated application.
This should not require considerations from an application perspective unless users can deploy an updated application side-by-side with an older version. In that case, the application should prevent conflicts such as sharing a NodePort, or the application documentation should outline how the application can be configured to avoid this.
Some system updates may require a reboot. The Fleet Command Stack will automatically restart applications after the system is running if a reboot is needed.
Applications should be able to recover gracefully and persist through system updates or system reboots.
System updates may also include version or API changes to Kubernetes, Helm, CUDA or OS components. Applications should be developed to be resilient to any component changes and otherwise document requirements to be evaluated before administrators apply system updates. The below examples provide some context to what it means to develop a resilient application for Fleet Command.
Application containers should support running with the Containerd version used in the Fleet Command Stack. For more information, refer to Containerd release notes.
Application containers should support the Docker version used in the Fleet Command Stack. When building an application with Docker, following the standard best practices for building containerized applications.
For more information, refer to Docker release notes.
API Changes to Kubernetes
Applications should be developed based on the Kubernetes version used in the Fleet Command Stack. If the application is developed with a different version of Kubernetes, it may fail to run the workloads on the edge system because of API changes between versions.
For example, an application should be developed based on the apps/v1 API version from Kubernetes 1.18 or later, as the API versions apps/v1beta1 or apps/v1beta2 have been deprecated and will no longer work.
Daemonsets, deployments, and replicasets resources should also use API version apps/v1, not extensions/v1beta1. For more information about API Changes, refer to Kubernetes 1.18 Release notes.
Application Helm charts should be developed based on the Helm version used in the Fleet Command Stack. If you’re using different Helm versions, use the Helm version which supports the version of Kubernetes used in the Fleet Command Stack. Refer to Helm supported Kubernetes versions for more details.
For example, an application should be developed based on Helm 3; if the application is developed with Helm 2, refer to the changes since Helm 2 to update the Helm chart.
For more information about Helm changes, refer to Helm Release Notes.
NVIDIA CUDA Driver Changes
Applications should be developed based on the CUDA version supported by the driver used in the Fleet Command Stack In general, CUDA supports backward compatibility, but not forward compatibility. This means that the latest CUDA version may not currently be supported by Fleet Command, but applications built on older CUDA versions should continue to function. More information about CUDA compatibility can be found here.
For more information about CUDA version changes, refer to CUDA Release Notes.