Working principles of the ack-onepilot component

Workflow

ack-onepilot consists of two parts: a webhook service and an init container. The webhook service acts as a Kubernetes mutating admission webhook. For more information, see Mutating admission webhook.

The webhook service modifies Kubernetes pods before they are persistently stored in etcd.

The webhook service performs the following operations on pods:

1. 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.

2. 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 or the version of the agent that you configure. For more information, see Control the ARMS agent version.