why_telemetery_agents_talk

Signed-off-by: AugustasV <[email protected]>

Author: AugustasV

content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md

@@ -8,31 +8,20 @@ weight: 70
 
 <!-- overview -->
 
-With Kubernetes 1.20 dockershim was deprecated. From the
-[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)
-you might already know that most apps do not have a direct dependency on runtime hosting
-containers. However, there are still a lot of telemetry and security agents
-that has a dependency on docker to collect containers metadata, logs and
-metrics. This document aggregates information on how to detect these
-dependencies and links on how to migrate these agents to use generic tools or
-alternative runtimes.
+Docker is being deprecated. You can find a deprecation FAQ at [Don't Panic: Kubernetes and Docker](https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/). Most apps do not have a direct dependency on runtime hosting containers. However, there are still a lot of telemetry and monitoring agents that has a dependency on docker to collect containers metadata, logs and metrics. This document aggregates information on how to detect these dependencies and links on how to migrate these agents to use generic tools or alternative runtimes.
 
 ## Telemetry and security agents
 
-There are a few ways agents may run on Kubernetes cluster. Agents may run on
-nodes directly or as DaemonSets.
+There are a few ways agents may be run on kubernetes cluster. Agents have a direct 
+dependency on Docker when they run on nodes or as daemonsets. Some telemetry and 
+security agents may rely on certain logs or metrics specific for Docker that would not 
+be available any longer. This document does not cover these cases.
 
-### Why do telemetry agents rely on Docker?
+### Why do telemetry agents talk to Docker?
 
-Historically, Kubernetes was built on top of Docker. Kubernetes is managing
-networking and scheduling, Docker was placing and operating containers on a
-node. So you can get scheduling-related metadata like a pod name from Kubernetes
-and containers state information from Docker. Over time more runtimes were
-created to manage containers. Also there are projects and Kubernetes features
-that generalize container status information extraction across many runtimes.
+Historically, Kubernetes was built on top of Docker. Kubernetes is managing networking and scheduling, Docker was placing and operating containers on a node. So you can get scheduling-related metadata like a pod name from Kubernetes and containers state information from Docker. Over time more runtimes were created to manage containers. Also there are projects and kubernetes features that generalize container status information extraction across many runtimes.
 
-Some agents are tied specifically to the Docker tool. The agents may run
-commands like [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/)
+But some agents are still Docker-dependent. They may run commands like [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/)
 or [`docker top`](https://docs.docker.com/engine/reference/commandline/top/) to list
 containers and processes or [docker logs](https://docs.docker.com/engine/reference/commandline/logs/)
 to subscribe on docker logs. With the deprecating of Docker as a container runtime,