-
Notifications
You must be signed in to change notification settings - Fork 100
Deeper Architecture Description
Users of Acorn will only ever interact with the Acorn API Server. The Acorn API server is a Kubernetes-style API that is made accessible through the Kubernetes API aggregation layer. Running the command kubectl api-resources | grep api.acorn.io on a cluster with Acorn installed will show a list of resources exposed through the Acorn API Server. The CRUD operations for these objects go through the Acorn API Server, including all those from the Acorn CLI.
API servers typically have a database where state is stored between requests. Instead of maintaining its own database, the Acorn API Server uses Kubernetes and etcd in the form of CRDs (the internal.acorn.io group). These CRDs are internal and a user should never need to interact with them directly. There is a translation layer in the Acorn API Server that ensures that the internal objects are presented, stored, and updated correctly.
For example, when a user makes a GET request to the Acorn API Server for an app, the Acorn API Server will get the corresponding object from Kubernetes etcd (appinstance.internal.acorn.io), translate it to an API object (app.api.acorn.io), and return that to the caller. This GET request can be made through the Acorn CLI with acorn app APP_NAME or with kubectl -n acorn get app.api.acorn.io APP_NAME. Note that the namespace used in the kubectl command depends on the Acorn project.
Similarly, when a user makes a request to update and app (app.api.acorn.io), then the Acorn API Server will translate that back to an appinstance.internal.acorn.io and store it in etcd. This update can come from acorn update APP_NAME or kubectl apply -f app.yaml. Note, however, it is not possible to use kubectl edit on api.acorn.io objects.
The endpoints exposed by the Acorn API Server can be found in the stores map. Many of these store their state via CRDs in etcd, but others (like apps/log) don't.
For Acorn we wanted a custom API server so we can have full control over the API, namely the ability to do streaming responses and custom subresources. But, a custom API server needs to store data somewhere. We use CRDs for our storage so that to eliminate issues with running another data store.