Use Case: Use Kubernetes to deploy a network operation as a Service leveraging the Gateway API

[doonhammer]

Overview
The current implementation of the Gateway API appears to be based on a network proxy model as its core networking construct. This use case/issue makes the case to broaden the scope of the Gateway API to a non proxy model.

Kubernetes provides an environment to deploy, orchestrate and auto scale services. This use case is to investigate the requirements for using Kubernetes as a vehicle for providing network services, such as IPS,IDS,Encrypt/Decrypt, NAT, Content Inspection/Enhancement. The key differentiator from other use cases is that the service within Kubernetes is not a network endpoint but rather a network service that acts on the flow and forwards it to its intended destination. The rules that are applied by the network service will depend on the original src/dst network parameters. Typically default rules are applied to all traffic and then more specific rules are applied to segments of the traffic.

Another way to look at this use case would be to enable Kubernetes using the Gateway API to deploy a similar solution to the AWS Gateway Load Balancer

Examples could be:

All traffic from this subnet should be sent to an IPS before delivery to the final destination. The original network parameters (src/dst etc) must be preserved as the rules applied depend on the src/dst.
Add traffic that matches a set of conditions should be enhanced before delivery to an external destination.

Requirements

1. Original src/dst network information must be preserved and delivered to the network service.
2. Additional metadata may be delivered to the network service on a per session basis.
3. The system must autoscale to the available network bandwidth.
4. Any L4 load balancer that is Kubernetes compatible must be available to use.
5. The solution must enable “sticky sessions” to individual network service Pods.
6. The network service must be able to filter traffic by IP and Port.
7. The network service must be able to receive all traffic on any IP and any Port.

Possible Implementations
The external load balancer of the Kubernetes cluster would be the next hop for all traffic between subnet A and B. The traffic goes through the gateway where it gets enhanced by adding a tunnel with appropriate metadata and sent to a network service Pod. The network service Pod receives the flow and applies the appropriate logic, swaps the src and dst of the tunnel and sends it back to the gateway. The gateway removes the tunnel header, perhaps applying some logic based on metadata and forwards the flow to its original destination.

[youngnick]

I think that "Using a Gateway to define a DMZ" is another way to describe this use case, maybe?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.