This topic describes the working principles of ack-onepilot, a component that helps connect Kubernetes applications to Application Real-Time Monitoring Service (ARMS).
Workflow
The ack-onepilot component consists of two services: webhook and init container. The ack-onepilot webhook service functions as a mutating admission webhook of Kubernetes. For more information, see Mutating admission webhook.
The ack-onepilot webhook service modifies Kubernetes pods before they are persistently stored in etcd, as shown in the following flowchart.
The ack-onepilot webhook service performs the following operations on the pods:
Specify key environment variables for the pods.
For a Java application, the ack-onepilot webhook service automatically appends certain system parameters of the Java virtual machine (JVM) from the environment variable JAVA_TOOL_OPTIONS to the application during its startup. Then, JAVA_TOOL_OPTIONS injects the ARMS license key, application name, reporting region, and other information to locate the endpoint where data is reported. Additionally, JAVA_TOOL_OPTIONS injects the
-javaagent
parameter for the Java application to automatically locate the path where the ARMS agent resides and mount the agent during the application startup.For a Go application, parameters similar to
-javaagent
are not required.Add init containers to the pods.
Generally, init containers prepare the ARMS agent file and mount it to your pods using a volume. During startup, the application locates the prepared ARMS agent using JAVA_TOOL_OPTIONS in step 1 and mounts it to your Java process. Then, your observable data during the business process can be collected.
FAQ
Is the version of ack-onepilot related to that of the ARMS agent?
No, they are not necessarily related. The ack-onepilot component retrieves the corresponding agent package based on the backend configurations.