No route to host/timeout error while reaching kube-api server

The indicated "i/o timeout" in the snippet seems to allude to some mechanism preventing network traffic. There are no communication limitations by default, though if you have something like Network Policies configured, it could be limiting cert-manager from accessing kube-apiserver. Do you have any limitations currently in-place? If so, cert-manager will require access to kube-apiserver, the target of your challenge mechanism (DNS/HTTP), and the associated issuer defined.

No route to host errors means there is a problem with the route table that defines where packets should be routed for a particular IP address.

For example, if you create an AWS VPC it will have a default route table that includes a route for all the IP addresses in the VPC to get routed within the VPC. That means anything in the VPC can send a packet to any other IP address of any other resource in the VPC and it will get routed correctly.

However, in that scenario, if you want to send a packet to 8.8.8.8 (Google's domain name server), by default there is no route in your route table. You send the packet and the networking services look for a route in the route table but there isn't one so they don't know which router to send the packet to next, so they send you back and error: "No Route To Host" (if you are lucky - in some cases AWS services don't provide any such error.)

To fix that scenario in a new VPC you add an Internet Gateway, and then you add a route in your table to send all traffic for IP addresses on the Internet (0.0.0.0/0) to your Internet Gateway. The VPC route is more specific so it will take precedence for IP addresses in the VPC. Anything else will match the second route to the Internet Gateway and be sent there.

I don't now if there's something specific you need to change for Kubernetes routing but the first place to look is the route table for your VPC. Make sure there is a route for an IP range that includes the IP address you are trying to reach.

Also, in some cases, you have what is called asynchronous routing, where you can send a packet out, but when the packet comes back, the networking routers don't know how to get it back to the host that made the request. In that case you have to add a route specifically for that return traffic.

I explain both those scenarios in more detail in these posts:

Resolving no route to host between two firewalls on your home network: https://medium.com/cloud-security/resolving-no-route-to-host-bca0413679ed

Resolving routing with a NAT, Site to Site VPN, and Transit Gateway https://medium.com/cloud-security/configure-a-transit-gateway-to-route-traffic-from-a-site-to-site-vpn-to-a-nat-d56561c43f8d

Although, those may not be specific to Kubernetes, they explain how routing works. You need to find where your routes are configured and add a route for <kubernetes svc ip> and tell the routers where to send the packets destined for that ip address. A route is missing somewhere in a route table.

It looks like routes are also defined in your CNI configuration so it may need to be added there. I see routes in this sample configuration:

https://kubernetes.io/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/