This message was deleted.
# rke2a
adamant-kite-43734
04/11/2024, 5:33 PMThis message was deleted.
e
echoing-father-81877
04/11/2024, 5:38 PMipv4
Copy code
lima@lima-ubuntu-sensor: curl localhost/api/system/healthcheck
{"message":"OK"} Copy code
ubuntu@ip-10-0-2-157:~$ curl [::1]
^C Copy code
kube-system rke2-ingress-nginx-controller LoadBalancer 2001:cafe:43:1::17eb 2600:xxxx 80:32429/TCP,443:31213/TCP 23h
ubuntu@ip-10-0-2-157:~$ curl [2001:cafe:43:1::17eb]/api/system/healthcheck
{"message":"OK"} Copy code
+ ip6tables -t filter -A FORWARD -d 2001:cafe:43:1::17eb/128 -p TCP --dport 80 -j DROP
+ ip6tables -t nat -I PREROUTING -p TCP --dport 80 -j DNAT --to '[2001:cafe:43:1::17eb]:80'
+ ip6tables -t nat -I POSTROUTING -d 2001:cafe:43:1::17eb/128 -p TCP -j MASQUERADEechoing-father-81877
04/11/2024, 5:51 PMlooks like service lb on ipv4 opens up on the ipv4 interface, which makes sense as to why localhost can reach it, not sure why ipv6 is using
2001:cafe:43:1::17eb Copy code
+ iptables -t filter -A FORWARD -d 10.43.114.190/32 -p TCP --dport 80 -j DROP
+ iptables -t nat -I PREROUTING -p TCP --dport 80 -j DNAT --to 10.43.114.190:80
+ iptables -t nat -I POSTROUTING -d 10.43.114.190/32 -p TCP -j MASQUERADEc
creamy-pencil-82913
04/11/2024, 7:25 PMIt’s been a bit since servicelb was updated on rke2, I think that’s fixed on k3s and probably needs to be pulled through.
creamy-pencil-82913
04/11/2024, 7:26 PMis that ipv6 address not the v6 clusterip for that service?
e
echoing-father-81877
04/16/2024, 7:52 PMThat ipv6 address is the clusterIP, yes. However, the usage is different now, where on ipv4 I can connect to localhost:<443/80> for example, I cannot do that with the ipv6 counterpart using ::1
c
creamy-pencil-82913
04/16/2024, 8:03 PMSo the servicelb pod uses HostPort to get traffic for the service port, I’m not sure if those are expected to be accessible via the ipv6 loopback or not. That is just core Kubernetes behavior.