Kubernetes: route outgoing UDP traffic through service

While this answer does not fully solves your question I decided to place some information that might be helpful to case.

1. How can I route traffic through another service before it's send out to the internet?

The typical way for this is to use services to connect applications so your statement that you should use it is correct.

I would highly encourage you to check proxies section under cluster administration section. Especially take a look into kube-proxy which runs on each node and it used to reach services.

Kubernetes Networking uses CNI plugins to run traffic inside the cluster. There are variety of those providing a lot of functionalities such a calico, flannel. But for your case you might want to check Gravitational Wormhole plugin whic supports wireguard encryption options.

2. What would be the proper way to implement this? Can I convince Kubernetes to apply the routing for me when the Wireguard Pod starts up? Or should I maybe bypass Kubernetes completely and simply apply the rules myself in the container's entrypoint or something?

With usage of services like kube-proxy and iptables you have also load balancing provided for each kubernetes service. Here`s more information about services.

In iptables mode kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service, it installs iptables rules, which capture traffic to the Service's clusterIP and port, and redirect that traffic to one of the Service's backend sets. For each Endpoint object, it installs iptables rules which select a backend Pod

Kubernetes assigns this Service an IP address which is used by the Service proxies. The controller for the Service selector continuously scans for Pods that match its selector and the POSTs updates to an Endpoint object called for example "my-service".

To summarize for more fine traffic control between application and services within the cluster you may want to check Istio. There couple of reasons for this:

• Istio’s traffic management model relies on the Envoy proxies that are deployed along with your services. All traffic that your mesh services send and receive (data plane traffic) is proxied through Envoy, making it easy to direct and control traffic around your mesh without making any changes to your services.

• Breaking down a monolithic application into atomic services offers various benefits, including better agility, better scalability and better ability to reuse services. However, microservices also have particular security needs:

• To defend against man-in-the-middle attacks, they need traffic encryption. To provide flexible service access control, they need mutual TLS and fine-grained access policies. To determine who did what at what time, they need auditing tools.

• Istio uses ingress and egress gateways to configure load balancers executing at the edge of a service mesh. An ingress gateway allows you to define entry points into the mesh that all incoming traffic flows through. Egress gateway is a symmetrical concept; it defines exit points from the mesh. Egress gateways allow you to apply Istio features, for example, monitoring and route rules, to traffic exiting the mesh.

You can read more about here. It`s about configuring wireguard on hosts.

This article also might be interested for your use case. It describes wireguard config on the nodes/hosts.