whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #31469 from AugustasV/telemetery_security_agents

Browse Source 
Revise “Migrating telemetry and security agents from dockershim” task
This commit is contained in:
Kubernetes Prow Robot
2022-01-30 14:56:23 -08:00
committed by GitHub
parent 6712fbee60 80f4c27c66
commit 097b6c4b73
1 changed files with 20 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md
+20 -22
View File
@@ -8,37 +8,35 @@ weight: 70
<!-- overview --> <!-- overview -->
With Kubernetes 1.20 dockershim was deprecated. From the Kubernetes' support for direct integration with Docker Engine is deprecated, and will be removed. 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.
[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.
## Telemetry and security agents ## Telemetry and security agents
There are a few ways agents may run on Kubernetes cluster. Agents may run on Within a Kubernetes cluster there are a few different ways to run telemetry or security agents.
nodes directly or as DaemonSets. Some agents have a direct dependency on Docker Engine when they as DaemonSets or
directly on nodes.
### Why do telemetry agents rely on Docker? ### Why do some telemetry agents communicate with Docker Engine?
Historically, Kubernetes was built on top of Docker. Kubernetes is managing Historically, Kubernetes was written to work specifically with Docker Engine.
networking and scheduling, Docker was placing and operating containers on a Kubernetes took care of networking and scheduling, relying on Docker Engine for launching
node. So you can get scheduling-related metadata like a pod name from Kubernetes and running containers (within Pods) on a node. Some information that is relevant to telemetry,
and containers state information from Docker. Over time more runtimes were such as a pod name, is only available from Kubernetes components. Other data, such as container
created to manage containers. Also there are projects and Kubernetes features metrics, is not the responsibility of the container runtime. Early yelemetry agents needed to query the
that generalize container status information extraction across many runtimes. container runtime **and** Kubernetes to report an accurate picture. Over time, Kubernetes gained
the ability to support multiple runtimes, and now supports any runtime that is compatible with
the container runtime interface.
Some agents are tied specifically to the Docker tool. The agents may run Some telemetry agents rely specifically on Docker Engine tooling. For example, an agent
commands like [`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/) might run a command such as
[`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/)
or [`docker top`](https://docs.docker.com/engine/reference/commandline/top/) to list 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/) 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, to receive streamed logs. If nodes in your existing cluster use
Docker Engine, and you switch to a different container runtime,
these commands will not work any longer. these commands will not work any longer.
### Identify DaemonSets that depend on Docker {#identify-docker-dependency} ### Identify DaemonSets that depend on Docker Engine {#identify-docker-dependency}
If a pod wants to make calls to the `dockerd` running on the node, the pod must either: If a pod wants to make calls to the `dockerd` running on the node, the pod must either: