Why Set internalTrafficPolicy: Local in Kubernetes Service?

Understanding InternalTrafficPolicy Property

The <a href="https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/#using-service-internal-traffic-policy" rel="nofollow noreferrer">internalTrafficPolicy</a> property of a Kubernetes Service dictates how traffic within the cluster is handled when directed to that service’s IP address. Setting it to Local ensures internal network requests are resolved by Pod resources on the same node, effectively dropping or rerouting any external inbound connections meant for this localized communication flow.

Scenarios Requiring Local Traffic Policy

While your understanding is largely correct, there exist specific scenarios where an internalTrafficPolicy: Local configuration benefits cluster operation and security posture - notably with DaemonSets or in situations demanding deterministic traffic routing.

DaemonSet Management & Service Traffic Policy

In environments using a Pod Template managed by a <code>DaemonSet</code>—each node is guaranteed to host the same set of daemons, ensuring consistent internal service communication across nodes without external network interaction:

apiVersion: apps/v1beta2
kind: DaemonSet
metadata: ...  # (omitted for brevity)
spec:  
    template:    
        spec:                            
            containers:               
              - name: logging-agent        
                image: myloggingimage      

Here, setting internalTrafficPolicy to Local would help prevent these internal service communications from traversing the cluster network. This is crucial for operations where inbound log ingestion or metrics collection could misrepresent data sources if routed across nodes—logged as incorrect origins due to external communication paths instead of direct, localized node-specific actions:

apiVersion: v1
kind: Service                            
metadata:  # (omitted for brevity)        
spec:  
    internalTrafficPolicy: Local     
...       
---           
# Pod Specification that backs our previously defined DaemonSet. Each node will host the same logging agent pod, with local traffic policy ensuring service communication remains within its scope of originating resources without network traversal beyond direct access to other nodes in cluster networking—aiding both data integrity and security:  
spec:                            
    ports:              
        - protocol: TCP     
          port: 54320       # Logging/metrics agent listening on this localized interface.        

Topology-aware Traffic Routing for Internal Services

As referenced by KEP-2086, the motivation behind proposing this internal traffic policy option is to allow controlled and predictable routing of service communication within a cluster. This can be instrumental for applications with critical services that must only communicate internally—within nodes, not crossing them:

apiVersion: v1    
kind: Service                           
metadata:   
spec:         
 internalTrafficPolicy: Local     
...       
# Pod specifications using Internal Traffic Policy to ensure service communication is strictly localized, for critical systems that require deterministic and secure data handling protocols. Such configurations prevent accidental external exposure of sensitive information or misrepresented origins in logs/metrics outputs due to inter-node traffic:
spec:         
 internalTrafficPolicy: Local     
...       

In summary, internalTrafficPolicy is crucial for specific use cases where service communication must remain within the bounds of a node and cluster network—a strategy supporting both operational integrity (correct log/metrics source identification) and security through minimized cross-node traffic. While less common in everyday Kubernetes deployments, this policy proves vital under special conditions outlined above.