docs: Begin laying the groundwork for a 'how' section regarding egress gateways. #16

usize · 2025-11-06T21:43:56Z

This PR introduces the initial “How” section for the Egress Gateways proposal.

It defines a clear model for routing outbound traffic through Kubernetes Gateways and describes how policy and extension points can be applied for both general egress and AI-specific use cases.

Importantly, it opens up discussion around important questions regarding:

integration with existing Gateway API resources versus creating new ones.
support for policies with varying levels of granularity without relying on known anti-patterns.

…s gateways. Signed-off-by: usize <[email protected]>

…rics tags. Signed-off-by: usize <[email protected]>

linux-foundation-easycla · 2025-11-06T21:44:04Z

The committers listed above are authorized under a signed CLA.

✅ login: usize / name: Morgan Foster (68b36d4, e960e90, f5e2edf, 04cff57, 1481228, 16dece7, 2a8cebc, 361f570, 41313d7, 440cc8b, 52179de, 60f4caf, 6355c1c, 724fda2, 73e75b9, d99dab1, db016d7, fd7009e)

k8s-ci-robot · 2025-11-06T21:44:05Z

Welcome @usize!

It looks like this is your first PR to kubernetes-sigs/wg-ai-gateway 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/wg-ai-gateway has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

usize · 2025-11-06T21:47:52Z

cc @shaneutt @kflynn (since I tried incorporating your feedback directly)

nirrozenbaum · 2025-11-07T06:57:07Z

proposals/10-egress-gateways.md

+    #   name: egress-client-cert
+  extensions:
+  - name: inject-credentials
+    type: CredentialInjector


what is this type referring to?
do you assume a predefined catalog of extensions?
can I “bring my own” payload processor?

Good question. We probably want to have a set of built in/standard processors with the ability to have (prefixed) implementation specific ones

type is the processor kind here. I think supporting a small catalog of processors would be great, and correct. Users can define their own BYO Processor -- e.g. foo.bar.com/EntityRedactor:v1 -- by conforming to an extension interface.

The interface for extensions will need something like:

Phase(s) it operates on e.g. request-headers

failOpen/Closed (default to closed?)

priority

type specific config schema

The idea I was going with here, was to reuse the approach that filters use on HTTPRoute, but without the rule match (since the Backend policy should impact all traffic going to the backend and not depend on routing decisions).

nirrozenbaum · 2025-11-07T06:58:33Z

proposals/10-egress-gateways.md

+### Conflict Resolution
+When multiple policies influence the same request:
+- **Specificity precedence**: Route > Backend > Gateway.
+- **Same-level ties**: Implementations MUST use a deterministic tie-break (e.g., lexical name order) and surface status indicating the conflict.


I think this should be rephrased.
current phrasing leaves the tie breaking question to the specific gateway implementation.
we need to define deterministic order which will apply to all implementations.

I know in Istio, we pick the oldest policy first to bias towards stability. Is it really a requirement to force all implementations to use the same mechanism? Is that feasible?

I think deterministic order should be defined one way or another, otherwise switching between different Gateways might break expected order.

not talking about the mechanism, only about what is the expected result.

otherwise switching between different Gateways might break expected order.

IMO, switching between Gateway implementations should not be a core design goal of our APIs. In my experience, this is a far more complicated process than most users ever want to take on. I don't feel super strongly, but I am wary about imposing these requirements on implementations w.r.t the tie-breaker

nirrozenbaum · 2025-11-07T10:50:47Z

proposals/10-egress-gateways.md

+
+## Observability Considerations
+
+- Implementations SHOULD expose metrics tagged by `{gateway, route, backend, namespace, serviceAccount}` and surface conditions (e.g., `Accepted`, `Programmed`, `Degraded`).


learning from past mistakes - I think we should phrase things we believe in as MUST.
phrasing as SHOULD may or may not be implemented, so it doesn’t say a lot.

SHOULD seems appropriate for metrics IMO, but +1 on a MUST for status

nirrozenbaum · 2025-11-07T10:55:44Z

proposals/10-egress-gateways.md

+
+## Next Steps
+
+1. Decide on Gateway resource approach (reuse vs. new EgressGateway type)


we should reuse as much as we can when possible.
this should probably be stated clearly.

nirrozenbaum · 2025-11-07T10:57:13Z

proposals/10-egress-gateways.md

+## Next Steps
+
+1. Decide on Gateway resource approach (reuse vs. new EgressGateway type)
+2. Define Backend resource schema with embedded policy rules


I assume embedded policy rules - you mean to state the policy (like rate limit), in the CR?
what about use cases where the payload processing requires custom logic that cannot be expressed declaratively?

I'd felt a bit fuzzy about having a catalog of policies versus embedding some policy directly into the CR. As per our discussion above, I've changed the proposal to suggest maintaining a catalog of policies that can be extended via extensionRef (like filters on HTTPRoute).

nirrozenbaum · 2025-11-07T10:58:32Z

proposals/10-egress-gateways.md

+1. Decide on Gateway resource approach (reuse vs. new EgressGateway type)
+2. Define Backend resource schema with embedded policy rules
+3. Specify filter extension points for payload processing
+4. Align with multi-cluster and agentic networking proposals


completely agree that SIG MC should be involved. having said that, I think it belongs to phase 2.
phase 1 is being able to call an external service while staying within the scope of a single cluster.

keithmattix · 2025-11-07T17:38:55Z

proposals/10-egress-gateways.md

+  extensions:
+  - name: inject-credentials
+    type: CredentialInjector
+    phase: request-headers   # request-headers|request-body|connect|backend-request|backend-response|response-body|response-headers


I think we need to flesh out phases a bit more, especially in the security context. For example, some payload processing (most? all?) should probably not be done after the auth step and the request is coming from a trusted peer or rate-limiting is applied (to prevent malicious or untrusted requests). How does an implementation think about that?

keithmattix · 2025-11-07T17:41:10Z

proposals/10-egress-gateways.md

+
+Option B implies defining equivalents of parentRefs, listeners, and route attachment; this is a significant fork from Gateway API and should be justified by clear need for an egress specific spec.
+
+**Recommendation needed**: Feedback requested on whether the semantics justify a new resource or if Gateway reuse is sufficient.


I'm a +1 on continuing to use Gateway. It's a standard resource that's familiar to users and understood by implementations

keithmattix · 2025-11-07T17:42:56Z

proposals/10-egress-gateways.md

+      hostname: api.openai.com
+      port: 443
+  tls:
+    mode: SIMPLE            # SIMPLE | MUTUAL


Should borrow from Gateway here for implementation specific TLS modes

keithmattix · 2025-11-07T17:43:24Z

proposals/10-egress-gateways.md

+      port: 443
+  tls:
+    mode: SIMPLE            # SIMPLE | MUTUAL
+    serverName: api.openai.com


nit: SNI may be more ubiquitous but don't feel strongly

keithmattix · 2025-11-07T17:45:43Z

proposals/10-egress-gateways.md

+    config:
+      requestsPerMinute: 1000
+```
+Alternatively, policies MAY be separate CRDs (e.g., `BackendTLSPolicy`, `EgressPolicy`) with `spec.targetRef: Backend`, avoiding schema growth on `Backend`.


I definitely see the schema growth issue...does something like Envoy's typed config model help out a bit? Give implementations a way to dynamically instantiate a policy based on well-known type (urls?)?

keithmattix · 2025-11-07T17:47:15Z

proposals/10-egress-gateways.md

+Client traffic flows through the egress gateway directly to an external endpoint (FQDN or IP). The gateway applies policies and routing logic before forwarding to the destination.
+
+### Parent Mode
+Client traffic flows through a local egress gateway to an upstream gateway before reaching the final endpoint. This enables gateway chaining for multi-cluster or multi-zone topologies. The local egress gateway treats the parent as a single upstream. Local retries are limited to establishing the parent connection. Request-level retries are performed by the parent. Implementations MUST prevent retry loops across gateways.


More details are going to be needed here I think, especially when it comes to communication between the gateway and the client, best practices for ensuring traffic goes through the gateway etc

keithmattix · 2025-11-12T04:07:46Z

proposals/10-egress-gateways.md

 When multiple policies influence the same request:
 - **Specificity precedence**: Route > Backend > Gateway.
- **Same-level ties**: Implementations MUST use a deterministic tie-break (e.g., lexical name order) and surface status indicating the conflict.
+- **Same-level ties**: Implementations MUST use a deterministic lexical name order tie-break and surface status indicating the conflict.


If we're going to be prescriptive on tie-breaker, I think taking the oldest resource is an approach that biases more towards cluster stability. You'll never have a stable system become disrupted by a new, conflicting resource. Granted, I'm biased because Istio does this (less work for me 😄 ), but I figured I'd mention it

Sorry about that. I re-read your original comment thread and saw that I'd missed that. I'm fine with this. Lexical name order was just the first thing I glommed onto.

After thinking about it, I'm leaning toward specifying a tie-break because now is our best opportunity to do it IMO. Trying to do it later, after a few implementations spring up, would be more painful.

Signed-off-by: usize <[email protected]>

…tations. Signed-off-by: usize <[email protected]>

Signed-off-by: usize <[email protected]>

…s a proven record of stability. Signed-off-by: usize <[email protected]>

Signed-off-by: usize <[email protected]>

shaneutt

Sorry for the late review, Kubecon week was last week.

This is a very thoughtful first pass at how we might implement egress. I have a few comments asking for some additional provisions regarding other paths we might take, other considerations we need to work through as we move forward, but once those are accounted for this seems like a great next step.

/approve

shaneutt · 2025-11-18T13:16:49Z

proposals/10-egress-gateways.md

-> highly focused sections as much as possible to help make things easier to
-> read and review. Long, unbroken walls of code and YAML in this document are
-> not advisable as that may increase the time it takes to review.
+1. Resource model using Gateway + HTTPRoute with a Backend for destinations (Service or FQDN).


There are other ways to implement this (for instance, Linkerd allows for using Gateway, but also attaching to the mesh network as a parentRef to configure different kinds of egress) that we're aware of. I think starting with this is good, but we'll need to leave an open door for other resource models.

shaneutt · 2025-11-18T13:18:10Z

proposals/10-egress-gateways.md

+- Introduce dedicated `EgressGateway` resource type
+- Enables egress-specific fields (e.g., global CIDR allow-lists) without policy attachment overhead
+- Clearer separation of ingress vs egress concerns
+


I would add another Alternatives Considered here for the Mesh resource (experimental, currently) as we know that Linkerd at least already does something like this, allowing egress from the sidecars, as opposed to the GW.

shaneutt · 2025-11-18T13:19:56Z

proposals/10-egress-gateways.md

+    failOpen: true
+    config:
+      requestsPerMinute: 1000
+```


I'm inclined to not fuss over this API right now, rather: it would be nice if we could put together a working prototype to test with and inform our decisions about how this API should work.

proposals/10-egress-gateways.md

shaneutt · 2025-11-18T13:21:15Z

proposals/10-egress-gateways.md

+
+Additional processors may be defined. They MUST declare the following fields:
+
+- phase: one of {request-headers, request-body, connect, backend-request, backend-response, response-headers, response-body} 


shaneutt · 2025-11-18T13:22:12Z

proposals/10-egress-gateways.md

+- phase: one of {request-headers, request-body, connect, backend-request, backend-response, response-headers, response-body} 
+- priority: integer. (Lower runs first within the same phase).
+- failOpen: boolean. Default false (closed).
+- preAuth: boolean. Default false. (trusted-peer context unavailable before authorization)


Good callout. More to do to figure out how this is going to work ofc, but very important callout.

shaneutt · 2025-11-18T13:26:10Z

proposals/10-egress-gateways.md

+  extensions:
+  - name: pii-detector
+    type: acme.example.com/PIIDetector:v1
+    phase: request-body
+    priority: 20
+    failOpen: false
+    preAuth: true
+    config:
+      modelRef: pii-detect-small
+      redactionStyle: delete
+      confidenceThreshold: 0.7
+      maxBodyBytes: 2097152


I'm not certain yet whether we want to add these extensions/filters/policies at the Backend level, as it seems that a pii-detector could be applied in an egress, ingress, or mesh context (in theory), so it seems more natural that these would apply to the HTTPRoute? 🤔

I think we can play with this, but before we merge let's add a comment pointing out the alternatives that we need to consider still.

I didn't put a great deal of effort into the example use case. More-so focusing on the way it would look to add a filter. I'd like to brainstorm some good Backend specific cases.

shaneutt · 2025-11-18T13:29:10Z

proposals/10-egress-gateways.md

+1. Define Backend resource schema.
+2. Specify default Backend policies e.g. CredentialInjector and QoSController.
+3. Specify filter extension points for payload processing
+4. Align with multi-cluster and agentic networking proposals


Depending on who's feeling froggy, I could see us saying we want to prototype this a bit as a next step.

I've proposed setting aside time for myself to do just that as a part of planning for ${MY_JOB}. 😁

k8s-ci-robot · 2025-11-18T13:29:39Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: shaneutt, usize

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [shaneutt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

'Filter' is a more standard term, which matches the proposed approach. Co-authored-by: Shane Utt <[email protected]> Signed-off-by: usize <[email protected]>

…arifications Signed-off-by: usize <[email protected]>

proposals/10-egress-gateways.md

nirrozenbaum · 2025-11-19T13:14:15Z

proposals/10-egress-gateways.md

+Controllers MUST publish the set of supported processor kinds and versions for a GatewayClass via `GatewayClass.status.parametersRef` or an implementation-specific status e.g. `GatewayClass.status.supportedExtensionKinds`.
+


what if the list is VERY long?
e.g., do you still expect to see it in status if there are 1k supported processors?

Based on wg meeting:

Maybe we should reference an external source of truth instead of trying to keep the whole catalog in a status.

Users can also configure a pointer to their own external catalogs in this way.

but -

External link can also add complexity for users via indirection.

Maybe status could link to a ConfigMap (probably easy to prototype and likely durable)

nirrozenbaum · 2025-11-19T13:16:51Z

proposals/10-egress-gateways.md

+
+Additional processors may be defined. They MUST declare the following fields:
+
+- phase: one of {request-headers, request-body, connect, backend-request, backend-response, response-headers, response-body}


does it make sense to add more details on these phases?
what does each phase means? when does it happen?

wg meeting notes:

for early stage design / proof of concept, maybe we should be less strict about phases.

we should gather feedback from Gateway API and potential users before defining it.

Co-authored-by: Nir Rozenbaum <[email protected]>

sjtal · 2025-11-20T19:36:07Z

proposals/10-egress-gateways.md

+### Parent Mode
+Client traffic flows through a local egress gateway to an upstream gateway before reaching the final endpoint. This enables gateway chaining for multi-cluster or multi-zone topologies. The local egress gateway treats the parent as a single upstream. Local retries are limited to establishing the parent connection. Request-level retries are performed by the parent.
+
+Operators MUST use network policy or sidecar/egress proxy configuration to deny direct egress from workloads and force all outbound traffic to the Gateway.


Does this mean application pods need to be egress gateway-aware? (in lieu of a service mesh/sidecar approach?)

It does not. The expectation is that without a service mesh operators will configure NetworkPolicy or CNI routing to route traffic through the gateway without workloads needing to be aware of it.

usize · 2025-11-20T19:40:42Z

proposals/10-egress-gateways.md

+- phase: one of {request-headers, request-body, connect, backend-request, backend-response, response-headers, response-body}
+- priority: integer. (Lower runs first within the same phase).
+- failOpen: boolean. Default false (closed).
+- preAuth: boolean. Default false. (trusted-peer context unavailable before authorization)


usize · 2025-11-20T21:01:34Z

proposals/10-egress-gateways.md

+  name: acme-piidetector-v1-schema
+  namespace: gateway-system
+data:
+  schema.json: |


We need to make it clear that we can support complicated dynamic use cases: e.g. pattern matching beyond what can be describe by a regular expression.

DamianSawicki

This PR describes egress gateway as a reverse proxy with static Backends. Another approach is a dynamic forward proxy, and we see a huge demand for it. Since the filename and the Why? section are general, I'd suggest splitting How? into subsections corresponding to different models, with the proposals from the present PR fitting into something like Reverse Proxy.

haiyanmeng · 2025-11-21T20:50:34Z

proposals/10-egress-gateways.md

+    fqdn:
+      hostname: api.openai.com
+      port: 443
+  tls:


Why not use https://gateway-api.sigs.k8s.io/reference/spec/#backendtlspolicy?

I'm open to using BackendTLSPolicy here.

I avoided it in the initial proposal because I’m not yet sure what it looks like to apply BackendTLSPolicy where backends are primarily intended to be external FQDNs rather than in-cluster Services.

That is, as of today, to use BackendTLSPolicy for an external FQDN we'd need to represent the FQDN via the creation of a synthetic Service. Since we're proposing the addition of a new Backend type, it seemed useful to try to avoid re-introducing that synthetic Service pattern.

The semantics may line up with minimal changes, but we need to investigate further.

I’ll add a note that we may want to reuse or align with BackendTLSPolicy once the shape of the egress Backend resource stabilizes.

nirrozenbaum

@usize @shaneutt
as I was telling in the last call, I have mixed feelings around this PR.
TLDR - This PR is mixing both egress gateway and payload processing.

more details:
In our WG we currently identified two main use cases that are of interest.

egress gateway - ideally we would like to be able to use HttpRoute (or alike) to route traffic to a service outside of the cluster.
Payload Processors as part of our request flow, ideally also using some Gateway level objects.

This PR is mixing both, which makes the proposal much more complex and also not very easy to implement.

The ideal is to have both to work using one intuitive solution, but for initial PoC and start to collect feedback I think we should separate concerns.
That is - we should try to implement (or in this PR, to specify the How) only for egress use case, without getting into Payload Processing. then we should try to implement a PoC (quick a dirty) and go with that to Gateway API meetings to collect feedback.

each of the use cases is big by itself and deserves a separate discussion.

usize · 2025-11-23T17:46:03Z

TLDR - This PR is mixing both egress gateway and payload processing.

@nirrozenbaum looking at the comments here, yes, I agree. I've tried to put a bit too much into this PR. Payload processing already has its own proposal. Some of this might fit better there, or in some other proposal that bridges payload processing and egress as a singular focus.

How about this. I'm going to trim it down and simplify in the direction you're suggesting (removing details around payload processing). I'll keep the feedback I've gotten so far, and start toward building a simple PoC.

That way we can generate a little forward momentum here without risking needing to backtrack all of it later.

nirrozenbaum · 2025-11-23T18:18:17Z

TLDR - This PR is mixing both egress gateway and payload processing.

@nirrozenbaum looking at the comments here, yes, I agree. I've tried to put a bit too much into this PR. Payload processing already has its own proposal. Some of this might fit better there, or in some other proposal that bridges payload processing and egress as a singular focus.

How about this. I'm going to trim it down and simplify in the direction you're suggesting (removing details around payload processing). I'll keep the feedback I've gotten so far, and start toward building a simple PoC.

That way we can generate a little forward momentum here without risking needing to backtrack all of it later.

SGTM!

usize added 2 commits November 6, 2025 13:19

docs: Begin laying the groundwork for a 'how' section regarding egres…

1481228

…s gateways. Signed-off-by: usize <[email protected]>

Improve Backend sample, clarify language and enumerate additional met…

6355c1c

…rics tags. Signed-off-by: usize <[email protected]>

k8s-ci-robot requested review from keithmattix and nirrozenbaum November 6, 2025 21:44

usize changed the title ~~Egress gateways how proposal~~ docs: Begin laying the groundwork for a 'how' section regarding egress gateways. Nov 6, 2025

nirrozenbaum reviewed Nov 7, 2025

View reviewed changes

keithmattix reviewed Nov 7, 2025

View reviewed changes

keithmattix reviewed Nov 12, 2025

View reviewed changes

usize mentioned this pull request Nov 12, 2025

Propose Tool Authorization API kubernetes-sigs/kube-agentic-networking#8

Open

usize added 9 commits November 13, 2025 20:18

Prefer re-use of existing Gateway API resources.

60f4caf

Signed-off-by: usize <[email protected]>

Clarify backend policy implementation and phase order.

04cff57

Signed-off-by: usize <[email protected]>

Specify that tie-breaks should use lexical name order across implemen…

361f570

…tations. Signed-off-by: usize <[email protected]>

Response body should be processed after headers.

db016d7

Signed-off-by: usize <[email protected]>

Align next steps with proposed backend policy design.

16dece7

Signed-off-by: usize <[email protected]>

Align next steps with proposed Gateway API alignment.

73e75b9

Signed-off-by: usize <[email protected]>

Make observability guidelines into a MUST.

41313d7

Signed-off-by: usize <[email protected]>

Specify a tie-breaker based on Istio's existing approach, since it ha…

52179de

…s a proven record of stability. Signed-off-by: usize <[email protected]>

Clean up processor and Backend versioning and namespaces.

440cc8b

Signed-off-by: usize <[email protected]>

usize added 2 commits November 13, 2025 20:18

Clarify that a new status field may be added.

fd7009e

Signed-off-by: usize <[email protected]>

Add examples of processor extension schema definition and advertising.

d99dab1

Signed-off-by: usize <[email protected]>

usize force-pushed the egress-gateways-how-proposal branch from 0646815 to d99dab1 Compare November 14, 2025 04:19

shaneutt approved these changes Nov 18, 2025

View reviewed changes

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 18, 2025

shaneutt requested review from keithmattix, kflynn, kfswain and nirrozenbaum November 18, 2025 13:39

usize and others added 2 commits November 18, 2025 11:37

Clarify terminology to match existing implementation

f5e2edf

'Filter' is a more standard term, which matches the proposed approach. Co-authored-by: Shane Utt <[email protected]> Signed-off-by: usize <[email protected]>

Refine egress gateway proposal with mesh alternative, cleanup, and cl…

2a8cebc

…arifications Signed-off-by: usize <[email protected]>

usize force-pushed the egress-gateways-how-proposal branch from 18c0800 to 2a8cebc Compare November 18, 2025 19:37

usize requested a review from shaneutt November 18, 2025 19:41

nirrozenbaum reviewed Nov 19, 2025

View reviewed changes

proposals/10-egress-gateways.md Outdated Show resolved Hide resolved

nirrozenbaum reviewed Nov 19, 2025

View reviewed changes

proposals/10-egress-gateways.md Outdated Show resolved Hide resolved

nirrozenbaum reviewed Nov 19, 2025

View reviewed changes

usize and others added 2 commits November 19, 2025 08:10

Grammar nit

68b36d4

Co-authored-by: Nir Rozenbaum <[email protected]>

Grammar nit

e960e90

Co-authored-by: Nir Rozenbaum <[email protected]>

sjtal reviewed Nov 20, 2025

View reviewed changes

usize commented Nov 20, 2025

View reviewed changes

shaneutt requested review from nirrozenbaum and sjtal November 21, 2025 14:11

DamianSawicki suggested changes Nov 21, 2025

View reviewed changes

haiyanmeng reviewed Nov 21, 2025

View reviewed changes

nirrozenbaum reviewed Nov 23, 2025

View reviewed changes


		## Observability Considerations

		- Implementations SHOULD expose metrics tagged by `{gateway, route, backend, namespace, serviceAccount}` and surface conditions (e.g., `Accepted`, `Programmed`, `Degraded`).


		## Next Steps

		1. Decide on Gateway resource approach (reuse vs. new EgressGateway type)


		Option B implies defining equivalents of parentRefs, listeners, and route attachment; this is a significant fork from Gateway API and should be justified by clear need for an egress specific spec.

		Recommendation needed: Feedback requested on whether the semantics justify a new resource or if Gateway reuse is sufficient.


		Additional processors may be defined. They MUST declare the following fields:

		- phase: one of {request-headers, request-body, connect, backend-request, backend-response, response-headers, response-body}

		Controllers MUST publish the set of supported processor kinds and versions for a GatewayClass via `GatewayClass.status.parametersRef` or an implementation-specific status e.g. `GatewayClass.status.supportedExtensionKinds`.

docs: Begin laying the groundwork for a 'how' section regarding egress gateways. #16

Are you sure you want to change the base?

docs: Begin laying the groundwork for a 'how' section regarding egress gateways. #16

Conversation

usize commented Nov 6, 2025

Uh oh!

linux-foundation-easycla bot commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

k8s-ci-robot commented Nov 6, 2025

Uh oh!

usize commented Nov 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nirrozenbaum Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shaneutt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

usize Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

linux-foundation-easycla bot commented Nov 6, 2025 •

edited

Loading

nirrozenbaum Nov 7, 2025 •

edited

Loading

usize Nov 18, 2025 •

edited

Loading

usize Nov 18, 2025 •

edited

Loading

usize Nov 20, 2025 •

edited

Loading

usize Nov 21, 2025 •

edited

Loading