ML Classifier Deployment Guide

the kloudmate ml classifier is an ai powered data security module that natively integrates with your telemetry pipeline by leveraging advanced machine learning engines alongside pattern matching rules, it automatically inspects database queries in real time to meticulously detect sensitive information, such as pii (personally identifiable information) and phi (protected health information) it then dynamically enriches your traces with risk fingerprints before your telemetry ever leaves your infrastructure this guide covers two strategies for deploying the kloudmate ml classifier standalone deployment via docker compose on a simple machine enterprise deployment via kubernetes (k8s) strategy 1 standalone machine via docker compose when to use this strategy? use this strategy if you are running the classifier on a single vm or physical host where the km agent is already running prerequisites docker engine and docker compose are installed the km agent is running on the host machine, listening to otlp http traffic on port 4318 prepare the compose file create a docker compose yaml file on your machine it is configured to run the classifier with optimized cpu/memory limits to handle the ml nlp models if you need the ml classifier to reach out to the km agent running directly on the host machine, docker uses the special dns host docker internal to route traffic to the host docker compose yaml version '3 8' services ml classifier image ghcr io/kloudmate/dam classifierr\ latest build context dockerfile dockerfile container name km ml classifier ports \ "8080 8080" environment \ http workers=2 \ log level=info volumes \ /config yaml /app/config yaml\ ro deploy resources limits cpus '2 0' memory 4g reservations memory 512m restart unless stopped healthcheck test \["cmd", "curl", " f", "http //localhost 8080/health"] interval 30s timeout 10s retries 3 networks \ km network networks km network driver bridge start the classifier navigate to the directory containing docker compose yaml and run \# start the classifier in detached mode docker compose up d \# check the logs to ensure models are loaded docker compose logs f configure km agent update your host agent's configuration to route traces to the classifier container since the classifier exposes port 8080 to the host processors \# km classifier endpoint "http //localhost 8080" # the classifier is bound to localhost 8080 timeout 500ms batch timeout 2s max batch size 100 strategy 2 enterprise cluster via kubernetes when to use this strategy? use this strategy if you are deploying the classifier to a kubernetes cluster alongside the kloudmate agent ecosystem prerequisites active kubernetes cluster with kubectl access helm or standard k8s networking setup deploy the configuration the classifier relies on a configmap ( configmap yaml ) to define the presidio patterns and gliner labels kubectl apply f k8s/configmap yaml deploy the service & application apply the kubernetes service and deployment manifests the deployment automatically allocates 4gi of memory and spins up 2 http workers for concurrent classification service yaml apiversion v1 kind service metadata name ml classifier namespace km agent labels app ml classifier component dam classifier spec type clusterip selector app ml classifier ports \ name http port 8080 targetport 8080 protocol tcp deployment yaml apiversion apps/v1 kind deployment metadata name ml classifier namespace km agent labels app ml classifier component dam classifier spec replicas 1 selector matchlabels app ml classifier template metadata labels app ml classifier component dam classifier spec containers \ name classifier image ghcr io/kloudmate/dam classifier\ latest imagepullpolicy always ports \ name http containerport 8080 protocol tcp resources \# gliner small model ( 400mb) requests memory "512mi" cpu "250m" limits memory "4gi" cpu "2" env \ name km agent endpoint value "km agent svc km agent svc cluster local 4318" \ name log level value "info" \ name http workers value "2" volumemounts \ name config mountpath /app/config yaml subpath config yaml readonly true volumes \ name config configmap name ml classifier config \# ensure pods are spread across nodes topologyspreadconstraints \ maxskew 1 topologykey kubernetes io/hostname whenunsatisfiable scheduleanyway labelselector matchlabels app ml classifier kubectl apply f service yaml kubectl apply f deployment yaml verify deployment verify that the pod has started properly and the gliner models have been downloaded into memory \# check if the pod is running kubectl get pods n km agent l app=ml classifier \# verify model loading logs kubectl logs n km agent l app=ml classifier f configure km agent in k8s in your km agent's config (if deployed as a separate pod in the same namespace), configure the processor to hit the fully qualified internal dns of the service we just created otel collector config yaml \# agent configuration with dam processor receivers otlp protocols grpc endpoint 0 0 0 0 4317 http endpoint 0 0 0 0 4318 processors batch timeout 1s send batch size 1024 memory limiter check interval 1s limit mib 512 spike limit mib 128 \# dam classifier processor (using the correct type name from factory go) km classifier endpoint "http //ml classifier km agent svc cluster local 8080" # fully qualified k8s service url timeout 500ms batch timeout 2s max batch size 100 enable batching true skip if no query true max idle conns 100 max conns per host 100 exporters otlp endpoint "https //otel kloudmate com 4318" tls insecure true debug verbosity detailed service pipelines traces receivers \[otlp] processors \[memory limiter, km classifier, batch] exporters \[otlp] verifying classification is working regardless of the deployment strategy, you can verify the setup by observing the km agent logs (ensure level debug is enabled temporarily) the traced applications will start showing dam lineage fingerprint , dam lineage risk , and extracted pii/phi properties dynamically added to the payload before arriving at your backend