# Incorrect request response mapping for a few requests in a Kubernetes environment **URL:** \ **Category:** Beats\ **Tags:** docker, packetbeat\ **Created:** [October 9, 2019, 10:43am UTC](https://discuss.elastic.co/t/incorrect-request-response-mapping-for-a-few-requests-in-a-kubernetes-environment/202814 "2019-10-09T10:43:37Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![kumud.t](https://avatars.discourse-cdn.com/v4/letter/k/c2a13f/32.png) [@kumud.t](https://discuss.elastic.co/u/kumud.t)\ **Post date:** [October 9, 2019, 10:43am UTC](https://discuss.elastic.co/t/incorrect-request-response-mapping-for-a-few-requests-in-a-kubernetes-environment/202814/1 "2019-10-09T10:43:37Z")
I have installed packetbeat OSS (v6.8.3) using [this](https://github.com/elastic/examples/blob/master/MonitoringKubernetes/packetbeat-kubernetes.yaml) YAML reference on a K8s cluster (v 1.10.13) with Docker (v 17.9.0) running on Debian GNU/Linux 9 (stretch) (4.9.0-7-amd64). The traffic ingress to our applications works this way. AWS ALB -\> A K8s node port -\> Ambassador API Gateway pod (running inside the cluster) -\> K8s service -\> Application pod However, I have observed that the requests were being mapped to responses from other services running in the same cluster in some rare cases. Is there a way to fix this? Or Is this a bug in Packetbeat? Also, it would be great if someone can help me understand the request-response mapping criteria in an environment like Kubernetes. Also, Kubernetes metadata is not being captured despite using the above configuration. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [November 6, 2019, 10:43am UTC](https://discuss.elastic.co/t/incorrect-request-response-mapping-for-a-few-requests-in-a-kubernetes-environment/202814/2 "2019-11-06T10:43:39Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.