For reference, this is the organization of the Kubernetes Cluster from a hierarchal perspective, in the structure of physical node, namespaces & node level containers, down to services, and sub-services:
- admin/
- management-api
- Allows for higher level administration through a central API should anyone need to make hot-fixes to sub-systems or services like Triton where management is exposed over a gRPC API
- Ultimately flux will sync changes to most things, however Triton is a grey area where some things are done within the application and are not altering a config file
- management-api
- backend/
- backend-api (Handles all frontend interaction storage and request ingress)
- salesforce-ui-api (Stages interactions in pacific-coast)
- Tracks user UI interactions for better data collection
- core-ml/
- dev-tools/
- pacfic-coast/
- vault/
- vendors/
- crm-vendor-api
- Responsible for pulling / migrating vendor data from CRMs
- This is not to be confused with salesforce-api which pushes to our centralized salesforce which pulls data based on vendor auth. In this case, we look at our database, load our data to the vendor-api and in parallel, build and extend the salesforce API to merge the two data sources in a clean, clear blend. More on this another-time
- vendor-api
- vendor-cache ( memcached / postgres )
- vendor-dashboard
- crm-vendor-api
Structure is as follows:
namespace/
- service
- subservice
- pods (Not shown)
Note: Subservices do not actually run within a service. They run seperately and simply provide routing within the namespace or set of services.
Note: Each namespace has its own Calico configurations and each service its own rules within Envoy which is why they are not mentioned as components.