Several important updates have found their way to the latest Korifi release (v 0.7.0). This post goes into some detail about the different capabilities and how they are expected to impact users.
Cloud Foundry Korifi is designed to implement the Cloud Foundry abstraction over Kubernetes. The community’s contributions to Korifi can be grouped under three major themes. The first is to make the abstraction functional where it interacts with Kubernetes primitives. The second part is porting the Cloud Foundry experience, and the third is to work on general areas, improving the quality of the software. Together, the three areas help project a compelling developer experience.
The v 0.7.0 release has some important updates that fall into each of these categories.
More Support for Kubernetes Primitives
The abstraction with Kubernetes clusters is made more useful by converging Kubernetes primitives well with Cloud Foundry constructs. In this vein, the central authentication type in Cloud Foundry – named ‘User’, is mapped to a ServiceAccount. By default, the ‘User’ type is fully obfuscated in Kubernetes and an additional layer of processing was required for translating requests made by the default CF ‘User’ type. Now, a ServiceAccount can interact with the platform directly. For example, if you have a ServiceAccount and use the command cf set-org-role USERNAME ORG ROLE for system:serviceaccount:<namespace>:<name>.
Metadata can be added to Kubernetes clusters by using labels and annotations. These were missing in Cloud Foundry Korifi until now.
With v 0.7.0, there is full support for this Kubernetes feature. They both take the form of key-value pairs. Labels are meant to contain information that is useful for the Kubernetes system, typically called an ‘identifier’. This information can be used for scheduling pods, managing replicas, networking, routing services and the like. Annotations however contain human-readable information which serves an ancillary purpose. For example, it can contain information about the on-call SRE teams.
One of the most common challenges that software engineers face is maintaining cluster hygiene. As much as possible, unused and unwanted resources must be cleaned up. This requires a two-fold approach:
- Setting up automation and monitoring tools that can help manage workloads and objects.
- Clearly established guidelines to prevent creating excessive resources.
Towards this end, Korifi now has an updated mechanism to deal with cluster hygiene. The Korifi controllers will only allow a limited number of packages and builds/droplets to be maintained in the system for each application pushed via the app. It will also trigger a workflow to delete container images corresponding to any deleted package, build or droplet when applicable.
Parity With “Classic” Cloud Foundry
This release also includes a handful of features that bring more parity with the classic Cloud Foundry experience. The VCAP variable has been made available (as VCAP_APPLICATION) and expanded to include custom values to it too. Essentially all running applications in Cloud Foundry have a VCAP environment variable exposed through the app env endpoint. The complete VCAP documentation is available here.
When using microservices as the fundamental design paradigm for web applications and APIs, it is common to deploy more than a single application. This requires app manifests to contain more than one application in the manifest. In previous releases, Korifi did not support the inclusion of more than one application in the manifest. This feature is supported in CF-for-VMs, and therefore introducing this to Korifi makes it more natural for existing Cloud Foundry users.
One of the missing pieces for CF admin users was the ability to revoke permissions assigned to user accounts. This is a crucial feature to maintain the security across the platform. In this Korifi release, support has been included for the cf-unset-org-role and cf-unset-space-role commands. This involved implementing some processing for API endpoints relating to users and the actual api handlers for the DELETE method of the /v3/roles/guid endpoint.
Quality Improvements
The release also had some general improvements in the quality of the Korifi application. The usability of the logging service was improved with configurable log levels (INFO and DEBUG). For endpoints that are not available, the error messages were inappropriate and not contextual. This has been changed to reflect the unavailability of the endpoint. This also introduces better support for 404 and 405 errors which can be gracefully handed off to the CF routing package internally. Bugs causing unexpected app restarts (due to statefulset-runner app workload reconciler reruns) and task reruns (due to insufficient validation of TTLs) have been fixed.
Thank you 1st Time Contributors
We would also like to specially thank the contributors who have made their first contributions to Korifi! They are:
The full release notes are available here.
The community also managed to release a minor update (v0.7.1) to Korifi within the week, that fixes some bugs. Release notes available here.
We invite you all to try Korifi by checking out the new tutorials page, and following the install instructions given here.
