linkerd2
linkerd2 copied to clipboard
IPv6 semantics differ from Kubernetes without Linkerd
What is the issue?
If a workload is created in a dual stack cluster, with a dual stack service, but the pod does NOT listen on IPv6, all traffic will fail. Without linkerd this generally works since the client will happy-eyeballs between the two ipfamilies (or maybe not; but curl does).
With linkerd, it appears regardless of the IP family of the incoming request, the IPv6 pod IP will always be used.
How can it be reproduced?
apiVersion: apps/v1
kind: Deployment
metadata:
name: echo
spec:
selector:
matchLabels:
app: echo
template:
metadata:
labels:
app: echo
spec:
securityContext:
sysctls:
- name: net.ipv4.ip_unprivileged_port_start
value: "0"
containers:
- name: echo
image: gcr.io/istio-testing/app:latest
imagePullPolicy: IfNotPresent
args:
- --port=80
- --bind-ip=80
env:
- name: INSTANCE_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
---
apiVersion: v1
kind: Service
metadata:
name: echo
spec:
ipFamilies:
- IPv6
- IPv4
ipFamilyPolicy: RequireDualStack
selector:
app: echo
ports:
- name: http
port: 80
Example app above that only binds to IPv4 address.
Logs, error output, etc
Error is a 502 gateway error. Sorry I tore down the env so don't have the full log. linkerd diagnostics endpoints
only shows one IPv6 address.
output of linkerd check -o short
n/a
Environment
v1.30.0 kind edge-24.6.1
Possible solution
I am not sure really what is the right behavior. Part of what led me down this path was exploring how we should behave in this scenario in Istio. I thought it might be helpful to bring up in case this was unexpected, or warrants some document, etc.
Additional context
No response
Would you like to work on fixing this bug?
no