Kubernetes Ingress Controller #1514

Open
opened 2026-04-05 19:32:19 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @frantjc on 5/7/2025

Initial post with questions and edits after a bit of digging.

Hello!

I use Kubernetes in my Homelab and am interested in implementing an Ingress Controller that uses Newt to expose Services by registering with some pre-existing Pangolin instance.

I'm hoping that someone can help me understand the internal interactions between Pangolin and Newt to accomplish this. I'll try to keep the Kubernetes jargon out of my questions.

Firstly, suppose that I know the ID of a Newt instance (say 2ix2t8xk22ubpfy) that's already connected to my Pangolin. Now suppose I want to tell Pangolin "Hey, any traffic with the host example.com, use this TLS key pair and send the traffic to Newt 2ix2t8xk22ubpfy." Does Pangolin expose an API to accomplish that?

EDIT: It seems Pangolin only generates its own TLS key pair and doesn't accept being told a pair to use. The latter functionality would need to be added to Pangolin to support this.

Secondly, once the traffic hits Newt, how does Newt know where to forward it? Based on the documentation, that must be something that is configured in Pangolin as well since it isn't an argument to newt. Does a single Newt instance support multiple upstreams? Or is it 1:1?

EDIT: It looks like "Resource Targets" are how you configure a Newt to know where to send traffic and it is 1:many, but it's slightly lacking in routing functionality. To implement the Kubernetes Ingress spec, the "Resource Target" would need to support path matching to decide what ip:port to forward traffic to, similar to how the "Resource Rule" supports path matching to decide whether to accept or drop traffic.

Thanks in advance.

Enhancements that I think would be needed in Pangolin to support this endeavor after a bit of digging.

Editted after tinkering around a bit--see above. Summary:

To achieve this functionality, I think that two enhancements would need added to Pangolin.

First, "Resources" would need to accept being told what TLS key pair to use rather than always generating their own.

Second, "Resource Targets" would need to support path matching to decide what ip:port to forward traffic to, similar to how "Resource Rules" support path matching to decide whether to accept or drop traffic.

I'm not particularly interested in making changes to Pangolin itself, but would be happy to build the Ingress Controller on top of it if it was updated to support this functionality. Are these features something that the Pangolin developers are interested in adding to support that?

*Originally created by @frantjc on 5/7/2025* ### Initial post with questions and edits after a bit of digging. Hello! I use Kubernetes in my Homelab and am interested in implementing an [Ingress Controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) that uses Newt to expose Services by registering with some pre-existing Pangolin instance. I'm hoping that someone can help me understand the internal interactions between Pangolin and Newt to accomplish this. I'll try to keep the Kubernetes jargon out of my questions. Firstly, suppose that I know the ID of a Newt instance (say `2ix2t8xk22ubpfy`) that's already connected to my Pangolin. Now suppose I want to tell Pangolin "Hey, any traffic with the host `example.com`, use this TLS key pair and send the traffic to Newt `2ix2t8xk22ubpfy`." Does Pangolin expose an API to accomplish that? > **EDIT:** It seems Pangolin only generates its own TLS key pair and doesn't accept being told a pair to use. The latter functionality would need to be added to Pangolin to support this. Secondly, once the traffic hits Newt, how does Newt know where to forward it? Based on the documentation, that must be something that is configured in Pangolin as well since it isn't an argument to `newt`. Does a single Newt instance support multiple upstreams? Or is it 1:1? > **EDIT:** It looks like "Resource Targets" are how you configure a Newt to know where to send traffic and it is 1:many, but it's slightly lacking in routing functionality. To implement the Kubernetes Ingress spec, the "Resource Target" would need to support path matching to decide what `ip:port` to forward traffic to, similar to how the "Resource Rule" supports path matching to decide whether to accept or drop traffic. Thanks in advance. ### Enhancements that I think would be needed in Pangolin to support this endeavor after a bit of digging. Editted after tinkering around a bit--see above. Summary: To achieve this functionality, I think that two enhancements would need added to Pangolin. First, "Resources" would need to accept being told what TLS key pair to use rather than always generating their own. Second, "Resource Targets" would need to support path matching to decide what `ip:port` to forward traffic to, similar to how "Resource Rules" support path matching to decide whether to accept or drop traffic. I'm not particularly interested in making changes to Pangolin itself, but would be happy to build the Ingress Controller on top of it if it was updated to support this functionality. Are these features something that the Pangolin developers are interested in adding to support that?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/pangolin#1514