@@ -354,6 +354,46 @@ For example, a newly-created pod that is supposed to be able to reach both Pod A
354
354
on Node 1 and Pod B on Node 2 may find that it can reach Pod A immediately,
355
355
but cannot reach Pod B until a few seconds later.
356
356
357
+ ## NetworkPolicy and ` hostNetwork ` pods
358
+
359
+ NetworkPolicy behaviour for ` hostNetwork ` pods is undefined, but it should be limited to 2 possibilities:
360
+ - The network plugin can distinguish ` hostNetwork ` pod traffic from all other traffic
361
+ (including being able to distinguish traffic from different ` hostNetwork ` pods on
362
+ the same node), and will apply NetworkPolicy to ` hostNetwork ` pods just like it does
363
+ to pod-network pods.
364
+ - The network plugin cannot properly distinguish ` hostNetwork ` pod traffic,
365
+ and so it ignores ` hostNetwork ` pods when matching ` podSelector ` and ` namespaceSelector ` .
366
+ Traffic to/from ` hostNetwork ` pods is treated the same as all other traffic to/from the node IP.
367
+ (This is the most common implementation.)
368
+
369
+ This applies when
370
+ 1 . a ` hostNetwork ` pod is selected by ` spec.podSelector ` .
371
+
372
+ ``` yaml
373
+ ...
374
+ spec :
375
+ podSelector :
376
+ matchLabels :
377
+ role : client
378
+ ...
379
+ ```
380
+
381
+ 2 . a ` hostNetwork ` pod is selected by a ` podSelector ` or ` namespaceSelector ` in an ` ingress ` or ` egress ` rule.
382
+
383
+ ``` yaml
384
+ ...
385
+ ingress :
386
+ - from :
387
+ - podSelector :
388
+ matchLabels :
389
+ role : client
390
+ ...
391
+ ```
392
+
393
+ At the same time, since ` hostNetwork ` pods have the same IP addresses as the nodes they reside on,
394
+ their connections will be treated as node connections. For example, you can allow traffic
395
+ from a ` hostNetwork ` Pod using an ` ipBlock ` rule.
396
+
357
397
## What you can't do with network policies (at least, not yet)
358
398
359
399
As of Kubernetes {{< skew currentVersion >}}, the following functionality does not exist in the
0 commit comments