Preparing the deployment of Unified Agent
Before you deploy the Unified Agent in Kubernetes environments, make sure that your environment meets the prerequisites.
General prerequisites
- Docker V18 or higher version
- Kubectl client on the environment from where you are installing
- If your system runs on SELinux, disable SElinux or set it to permissive mode when installing the Unified Agent.
System requirements
For detailed system requirements of Unified Agent and plug-ins, see System requirements for agents, data collectors, and plug-ins.
Special prerequisites for plug-ins
Some plug-ins have special requirements. Before you install the Unified Agent and enable these plug-ins, you must make sure to complete the following tasks.
IBM API Connect plug-in
- The API Connect toolkit is required to provide CLI commands to register the plug-in.
- The Unified Agent must be deployed in the same Kubernetes environment as IBM API Connect.
- This plug-in leverages Kubernetes Metrics API to get the pod CPU and Memory usage, so metrics server is required to be deployed in the cluster.
NGINX plug-in
Make sure that the NGINX monitoring interface is enabled.
-
Run the following command on the machine where you want to deploy the Unified Agent and check whether the NGINX monitoring interface is enabled:
http://pod_ip_or_nginx_host:18080/nginx_status
where
pod_ip_or_nginx_host
is the fully qualified hostname of the NGINX server.
If no status is returned, the NGINX monitoring interface is not enabled. -
The NGINX monitoring interface requires loading the
ngx_http_stub_status_module
module. This module helps in collecting basic performance metrics. You need only to get the Kubernetes SERVICE or POD IP and verify that the management interface is enabled. For example,http://NGINX_service_or_node_or_pod_ip:18080/nginx_status
. See the following command examples to help you determine whether NGINX workloads are running and confirm that their management interfaces are enabled.kubectl get po -n kube-system -o wide |grep nginx
The command returns output similar to the following example:
nginx-ingress-controller-jx8vb 1/1 Running 0 5h 10.1.253.201 9.42.75.39
- Verify the NGINX management interface status:
You can see the following example output:curl http://10.1.253.201:18080/nginx_status
Active connections: 9 server accepts handled requests 5372 5372 22532 Reading: 0 Writing: 2 Waiting: 7
-
Because the pod IP address can change, you can optionally create a service that points to the POD to get a static IP address. The following commands help create a service configuration:
kubectl describe po nginx-ingress-controller-jx8vb -n kube-system Name: nginx-ingress-controller-jx8vb Namespace: kube-system Priority: 0 PriorityClassName: <none> Node: 9.42.75.39/9.42.75.39 Start Time: Fri, 28 Sep 2018 23:46:39 -0400 Labels: app=nginx-ingress-controller
Note: Here the selector is
app=nginx-ingress-controller
. It might differ in your Kubernetes environment. -
Create a service resource file (
nginx-status.yaml
) as shown here:{ "apiVersion": "v1", "kind": "Service", "metadata": { "name": "nginx-status", "namespace": "kube-system", "labels": { "app": "nginx-status" } }, "spec": { "ports": [ { "name": "nginx-status", "protocol": "TCP", "port": 18080, "targetPort": 18080 } ], "selector": { "app": "nginx-ingress-controller" }, "type": "ClusterIP", "sessionAffinity": "None" } }
Note: Open port 18080 for NGINX status access.
-
Create the Kubernetes service resource by using the service resource file that you create, and obtain the service ip.
> kubectl create -f nginx-status.yaml > kubectl describe svc nginx-status -n kube-system Name: nginx-status Namespace: kube-system Labels: app=nginx-status Annotations: <none> Selector: name=nginx-ingress-controller Type: ClusterIP IP: 10.0.0.243 Port: nginx-status 18080/TCP TargetPort: 18080/TCP Endpoints: 9.37.22.210:18080 Session Affinity: None Events: <none>
-
Run
curl http://10.0.0.243:18080/nginx_status
. You can give the NGINX management interface URLhttp://10.0.0.243:18080/nginx_status
to the Helm Chart configuration. In on-premises installations, this module is not enabled by default. It must first be built and then enabled with the configuration parameter--with-http_stub_status_module
. See the NGINX documentation for enablement.