Gateway
The Gateway is the central point of entry for the Opni system. It is a multi-faceted API server that manages connections and communication with agents. The Gateway comprises several servers, each with a specific role.
-
Public gRPC API Server: This is the only publicly accessible server, and offers a minimal set of APIs necessary for agents to authenticate and connect to the gateway. Most other APIs are handled within a long-lived bidirectional stream that is initially established by connecting to a service on this endpoint.
-
Internal Management Server: This server provides RESTful APIs for core internal resources such as clusters, bootstrap tokens, RBAC, and capabilities. It also allows for API extensions, which allow plugins to expose additional custom gRPC services at the same endpoint as the core management API. These are privileged endpoints and are not exposed outside the cluster.
-
Internal HTTP Server: This server handles the
/metricsendpoint and the admin dashboard. The dashboard is a single page app served from static web assets embedded into the binary at build time. The HTTP server also allows for API extensions, allowing plugins to register custom routes. Similar to the management server, these are privileged endpoints. -
Local HTTP Server: This server, only accessible within the Gateway pod, handles the
/debug/pprofendpoint for diagnostics and the/healthzendpoint for kubelet health checks.
The Gateway uses the hashicorp/go-plugin library to manage plugins. A fixed set of interfaces, known as "plugin APIs" are available for plugins to implement in order to interact with different systems within the Gateway. A single plugin binary can provide implementations for multiple "plugins", making it more of a "plugin host" than a plugin itself.
Plugins contain the majority of the implementation details and logic for the "capabilities" of Opni, such as Monitoring and Logging, as well as other APIs that are not part of the core gateway.
The Plugin Loader is responsible for loading plugin binaries from disk. Each binary can contain any number of "plugins" or "plugin APIs" as described above. Plugin code is stored in the plugins/ directory, and each binary is prefixed with plugin_. Plugins are loaded at startup and are not unloaded or restarted. The load order is indeterminate, and plugins do not have dependencies.