Closed recursivetree closed 1 month ago
Update: I've tried to run the same setup using ipv4 addresses for services by changing the order of the address families in the cluster init command:
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server" sh -s - --cluster-init --cluster-cidr=10.42.0.0/16,fd93:c40c:7613::/56 --service-cidr=10.43.0.0/16,fd95:8606:8f22::/112
It seems to work with that. However, I'd still prefer to use ipv6 internally.
I don't know that pings (ICMPv6) are supposed to work against service clusterIPs? Remember that service clusterIPs don't actually exist anywhere, by default they are just iptables port forwards to the pod endpoints, managed by kube-proxy. Some CNIs have kube-proxy replacements that work differently, and kube-proxy itself has ipvs mode which changes things a bit.
Can you try hitting the service on its TCP port?
This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 45 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.
Environmental Info: K3s Version:
Node(s) CPU architecture, OS, and Version:
Cluster Configuration:
1 server
Describe the bug:
I've just initialized a dual stack cluster using the following command:
Afterwards, I've deployed a service and some pods:
Inside a pod, I can get the service's ip using the
POSTGRESQL_SERVICE_SERVICE_HOST
env variable:However, that IP of the service is unreachable:
Connecting using the IP od a pod behind the service works. Since the service cidr doesn't appear in the routing tables, I suspect it didn't get added?
Expected behavior:
The pod behind the service is reachable
Actual behavior:
the pod behind the service is unreachable