A hypershift dump with --dump-guest-cluster will be attached.

Any pod running on this hosted cluster's worker nodes can:

$ nslookup kubernetes.default.svc.cluster.local
Server:        172.30.0.10
Address:    172.30.0.10#53Name:    kubernetes.default.svc.cluster.local
Address: 172.30.0.1

but cannot connect to this service by the service IP:
$ curl -k https://172.30.0.1:443/readyz
curl: (7) Failed to connect to 172.30.0.1 port 443: Connection refused

Pods can use the default AdvertiseAddress, 172.20.0.1 to connect to the kube-apiserver:
$ curl -k https://172.20.0.1:443/readyz
ok

4.13.13

There are two hostedclusters on this same management cluster in the same state, but we aren't sure about the root cause/how to reproduce it

1. Unknown

Pods on a hosted cluster's workers have connectivity to their kube apiserver via the service IP.

One suspicious thing that we noticed is that the management cluster itself upgraded to 4.13.15 at the same time that these problems started occurring on the hostedcluster, but we aren't sure if they are strictly related.