Making My Platform API Reconcile Application Updates

In the previous post, the author built a basic behavior for the Platform Lab. They created an API specification for an Application called "greeting-service", which included details such as image, replicas, and port configurations. This resulted in the creation of Kubernetes resources like a Deployment and a Service. However, the author raised an important question: what happens when the Application changes?

The author explored how to reconcile application updates, ensuring that the platform updates existing resources instead of deleting and recreating them. They used the kubectl patch command to modify the Application's specifications, such as image version, replicas, and port configurations. After updating the Application, the author observed that Kubernetes incremented the metadata.generation field, indicating that the desired Application specification had changed.

The author then examined the controller logic, which relied on the Application's spec to build the desired state of dependent resources like Deployments and Services. When the Application changed, the controller recalculated the desired state of these resources and reconciled them with the actual resources. This approach simplified the controller's implementation, as creation and updates used the same model.

After updating the Application, the author verified the changes in the Deployment and Service resources using kubectl commands. They confirmed that the Deployment had the correct number of replicas, the updated container image, and the specified port configurations. They also verified that the Service used the updated port and targetPort values.

To ensure that the operator was updating existing resources instead of deleting and recreating them, the author captured the Deployment's UID before the update. After applying the changes, the UID remained the same, indicating that the existing resources were updated rather than recreated.

In summary, the author demonstrated that the Platform API could effectively reconcile application updates by updating existing Kubernetes resources instead of recreating them. This approach simplified the controller's implementation and ensured that the platform handled higher-level changes, such as updating the port configuration, with minimal resource modifications.