From ce830b2867030694347f0939dc6edeaacf17118d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Robert=20G=C3=BCnzler?= Date: Tue, 4 Jul 2017 19:07:06 +0200 Subject: [PATCH] Clear up use of hostPort with DaemonSet Reading through the communication patterns it was not obvious to me that the `hostPort` option is something I have to set myself. While the **DNS** and **Service** options explicitly say one has to *create a service*. --- docs/concepts/workloads/controllers/daemonset.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/concepts/workloads/controllers/daemonset.md b/docs/concepts/workloads/controllers/daemonset.md index 00bd7951a6..86d36efbd2 100644 --- a/docs/concepts/workloads/controllers/daemonset.md +++ b/docs/concepts/workloads/controllers/daemonset.md @@ -106,7 +106,7 @@ Some possible patterns for communicating with pods in a DaemonSet are: - **Push**: Pods in the DaemonSet are configured to send updates to another service, such as a stats database. They do not have clients. -- **NodeIP and Known Port**: Pods in the DaemonSet use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of nodes ips somehow, and know the port by convention. +- **NodeIP and Known Port**: Pods in the DaemonSet can use a `hostPort`, so that the pods are reachable via the node IPs. Clients know the list of nodes ips somehow, and know the port by convention. - **DNS**: Create a [headless service](/docs/user-guide/services/#headless-services) with the same pod selector, and then discover DaemonSets using the `endpoints` resource or retrieve multiple A records from DNS.