Add a KEP for supporting AllPorts services. #2611

prameshj · 2021-04-08T16:10:19Z

No description provided.

k8s-ci-robot · 2021-04-08T16:10:29Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: prameshj
To complete the pull request process, please assign caseydavenport after the PR has been reviewed.
You can assign the PR to them by writing /assign @caseydavenport in a comment when ready.

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

Needs approval from an approver in each of these files:

keps/sig-network/OWNERS

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

rikatz · 2021-04-08T16:25:11Z

/cc

keps/sig-network/2610-allports-services/README.md

keps/sig-network/2610-allports-services/kep.yaml

keps/sig-network/2610-allports-services/README.md

jayunit100 · 2021-04-09T16:13:42Z

keps/sig-network/2610-allports-services/README.md

+
+### Goals
+
+* Allow users to optionally expose the entire port range via a Service (of Type LoadBalancer or ClusterIP).


@uablrek ~ can you comment on the kproxy supportability for this ? re: ipvs/iptables/nftables/...

That iptables/ipvs doesn't support port-ranges is not entirely true, but they can not re-map ports in a range, like with an offset. The ports are unchanged.
From ipvsadm(8) man page;

-A, --add-service Add a virtual service. A service address is uniquely defined by a triplet: IP address, port number, and protocol. Alternatively, a virtual service may be defined by a firewall-mark.

As you can see you must use firewall-mark to load-balance a range or an entire ip. The rule to set the fwmark is done by ip(6)tables and can specify port-ranges and protocol (or not).

In this case a single fwmark can be used to cover all services. If we allowed arbitrary ranges, we'd quickly run out of marks. Unless I misunderstand how they are used?

Hmm, I may be wildly, totally wrong. Looking at docs and playing around with ipvsadm it's more restrictive than I thought.

As far as I can see, there is no way to say "forward all ports" without making the vserver "persistent" (which seems to be roughly about client affinity). I don't think we want that, but I am not an IPVS expert. It has a timeout arg which has a floor of 1 second. Does that make it better?

If IPVS can't implement whole-IP, what do we do with this? Is it dead? Can we spin it as strictly optional?

@andrewsykim ICYMI

How about defining allPorts service as fwmark-service? That doesn't appear to make it a persistent service. iptables rules will set the packet mark.

If we used the --tcp-service/--udp-service option with the persistent behavior, this might be desirable based on use-case? If the clients are going to use a random port to reach the service, it is probably ok to send packets to the same service port to the same backend?

true.. managing the mask can be messy, since we would also need to deal with conflicting mark values used by other components (Calico, other networking addons).

I missed that the persistent feature is 3-tuple, not 5.

I think the port forwarding behavior might be do-able with ipvs using ipsets, but I would need to play around with it a bit to be sure.

I think a larger problem with IPVS could be regarding it's "bind-all" behavior (kubernetes/kubernetes#72236), where a all ports Service will conflict with a real host port. Long standing issue that we need to address, but have not come up with a good path forward yet.

Services of type allPorts don't have node ports. So it is primarily

ClusterIP:port which will be dnated to pod:port

ExternalIP:port which will be dnated to pod:port

loadbalancers with no nodeports? those are a thing with #1864

There should just be a few allPorts services in a cluster, say max 16 (a small confugurable number?), and if fwmark is used only for those it should be managable. It is also a per-node resource so kube-proxy can manage them locally, e.g re-read after re-start. See also #2611 (comment).

uablrek · 2021-04-10T09:21:51Z

I would like to see a valid use-case for ClusterIP.

I have not developed SIP apps for many years and never RTP but I from contacts with SIP app developers it seem they always use headless services because they need control over the clients.

If all-ip services can be limited to type:LoadBalancer and headless service as described in kubernetes/kubernetes#23864 (comment) it will simplify in very many ways. I estimate I can implement it myself for ipvs in ~100mh (e2e tests excluded) with a feature-gate in a way that would leave the existing implementation intact. Just avoiding the API change would save considerable time.

The stake-holders should not be asked "do you want all-ip services for ClusterIP?" since the answer would be "yes" (why not), but something like; "are you prepared to delay all-ip service services for ~1y at least, most likely pushed to kube-proxy v2 (which is under way), to get ClusterIP support?"

uablrek · 2021-04-10T09:34:46Z

For ipvs firewall-marks (fwmark) must be used #2611 (comment). I have made a test (without K8s). I share it below for the discussion.

Setup;

ipvsadm -A -f 1 -s rr
ipvsadm -A -f 1 -6 -s rr
ipvsadm -a -f 1 -r 192.168.1.1:0 -m
ipvsadm -a -f 1 -6 -r [1000::1:192.168.1.1]:0 -m
# (repeat for all real servers)
iptables -t mangle -A PREROUTING -i eth2 -d 10.0.0.0/24 -j MARK --set-mark 1
ip6tables -t mangle -A PREROUTING -i eth2 -d 1000::/120 -j MARK --set-mark 1

Port ranges, protocol etc. are defined with iptables with all possibilities iptables provides.

Status after 100 connects;

$ ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
FWM  1 rr
  -> 192.168.1.1:0                Masq    1      0          25        
  -> 192.168.1.2:0                Masq    1      0          25        
  -> 192.168.1.3:0                Masq    1      0          25        
  -> 192.168.1.4:0                Masq    1      0          25        
FWM  1 IPv6 rr
  -> [1000::1:c0a8:101]:0         Masq    1      0          25        
  -> [1000::1:c0a8:102]:0         Masq    1      0          25        
  -> [1000::1:c0a8:103]:0         Masq    1      0          25        
  -> [1000::1:c0a8:104]:0         Masq    1      0          25

Fwmark becomes a resource that must be handled by kube-proxy. However, it is a node-local resource and I see no reason to centralize allocation (as with ipam), it would only complicate things.

keps/sig-network/2610-allports-services/README.md

danwinship · 2021-04-08T18:49:38Z

keps/sig-network/2610-allports-services/README.md

+The proposal here is to introduce an “allPorts” boolean field to the [servicePort API.](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.20/#serviceport-v1-core)
+This field is introduced within ServicePort rather than ServiceSpec, because a ServicePort entry is needed to infer the protocol.
+
+This field will be supported for Service Type=ClusterIP and ServiceType=LoadBalancer. This is not applicable to ExternalName services. NodePort services are not supported.


This is kind of weird given that LoadBalancer services are normally a superset of NodePort... and in particular, with "AWS-style" LoadBalancers, the LB rewrites packets from lb-ip:port to node-ip:port. I guess that means you have to do "GCP-style" LoadBalancers (where the LB delivers packets to the node still addressed to the LB IP) for allPorts services, even if you do "AWS-style" for normal services... (This may mean that some clouds can't support allPorts?)

At any rate, saying that allPorts LoadBalancer services are not also NodePort services may be an API break...

At any rate, saying that allPorts LoadBalancer services are not also NodePort services may be an API break...

I think we burnt that bridge here https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/1864-disable-lb-node-ports

keps/sig-network/2610-allports-services/README.md

prameshj · 2021-04-14T00:01:19Z

I would like to see a valid use-case for ClusterIP.

I have not developed SIP apps for many years and never RTP but I from contacts with SIP app developers it seem they always use headless services because they need control over the clients.

If all-ip services can be limited to type:LoadBalancer and headless service as described in kubernetes/kubernetes#23864 (comment) it will simplify in very many ways. I estimate I can implement it myself for ipvs in ~100mh (e2e tests excluded) with a feature-gate in a way that would leave the existing implementation intact. Just avoiding the API change would save considerable time.

The stake-holders should not be asked "do you want all-ip services for ClusterIP?" since the answer would be "yes" (why not), but something like; "are you prepared to delay all-ip service services for ~1y at least, most likely pushed to kube-proxy v2 (which is under way), to get ClusterIP support?"

Thanks @uablrek . This would still require an API validation change to allow LoadBalancer + ClusterIP: None, but no need for any change to ports validation. After this, allPorts LoadBalancer services will not necessarily be valid ClusterIP services. @danwinship Would that be a breaking change?

uablrek · 2021-04-14T03:51:40Z

Even more narrow; type:LoadBalancer + clusterIP:None + no ports.

danwinship · 2021-04-18T21:19:52Z

@danwinship Would that be a breaking change?

In some cases in the API, it's OK to loosen validation and allow cases that were previously forbidden. But even that can run into problems if there are clients that need to be able to understand all objects of a given type. So, eg, in the case of Services, any change to LoadBalancer behavior that might cause existing external cloud provider implementations to do the wrong thing (or crash!) should probably be considered breaking.

It might work better to add a new WholeIPLoadBalancer type rather than trying to figure out a way to use LoadBalancer plus weird signalling via other fields. (Hopefully existing cloud providers / third-party proxy implementations should just ignore services of types they don't recognize...)

It's possible that we won't be able to add all-ports/whole-IP to v1.Service in a clean way, and we might have to think about doing it in terms of some new API like Gateway instead.

uablrek · 2021-04-19T04:06:15Z

any change to LoadBalancer behavior that might cause existing external cloud provider implementations to do the wrong thing (or crash!) should probably be considered breaking.

Then to limit allIP services to headless services would be safe since cloud providers would sort them out for now anyway?

prameshj · 2021-04-22T19:25:30Z

any change to LoadBalancer behavior that might cause existing external cloud provider implementations to do the wrong thing (or crash!) should probably be considered breaking.

Then to limit allIP services to headless services would be safe since cloud providers would sort them out for now anyway?

I will add this topic to the next sig-network meeting for discussion.

keps/sig-network/2610-allports-services/README.md

andrewsykim

Need to double-check this, but there could be an issue with IPVS regarding its current "bind-all" behavior (kubernetes/kubernetes#72236), where an all ports Service will conflict with a real host port bindings. Long-standing issue that we need to address, but have not come up with a good path forward yet.

andrewsykim · 2021-05-10T15:23:25Z

keps/sig-network/2610-allports-services/README.md

+
+### Goals
+
+* Allow users to optionally expose the entire port range via a Service (of Type LoadBalancer or ClusterIP).


I think the port forwarding behavior might be do-able with ipvs using ipsets, but I would need to play around with it a bit to be sure.

I think a larger problem with IPVS could be regarding it's "bind-all" behavior (kubernetes/kubernetes#72236), where a all ports Service will conflict with a real host port. Long standing issue that we need to address, but have not come up with a good path forward yet.

keps/sig-network/2610-allports-services/README.md

thockin · 2021-05-10T22:15:52Z

FTR: This is exceedingly unlikely to make 1.22 - too many open issues

howardjohn · 2021-05-17T23:35:50Z

keps/sig-network/2610-allports-services/README.md

+Items marked with (R) are required *prior to targeting to a milestone / release*.
+
+- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
+- [ ] (R) KEP approvers have approved the KEP status as `implementable`


Can we look into how implementable this is by common networking implementations? CNIs (calico, cilium, etc), service meshes (linkerd, istio), and load balancer implementations (GKE/AWS, metallb, etc) are all things that could plausible have a very hard time supporting this.

As an Istio maintainer, I can tell you this would be a challenge to implement for us.

Thanks for raising this @howardjohn. I would like to get more clarity on the use-cases for the AllPorts feature to figure out the actual proposal here and revisit this.

We now have a somewhat fleshed out proposal - I have marked this as an "Open question" so we can iterate after merging this initial PR.

prameshj · 2021-09-02T21:22:59Z

/assign @thockin @aojea @khenidak @uablrek for review/lgtm.

wojtek-t · 2021-09-03T06:39:10Z

keps/sig-network/2610-allports-services/kep.yaml

+approvers:
+  - "@thockin"
+prr-approvers:
+  - "@johnbelamaric"


please reassign to me - John seem to be overloaded this cycle.

Also - you will need to fill in the necessary PRR questions for alpha (not sure if you want to do that in this PRR or in a once that will move it move implementable.

Thanks Wojciech. I have reassigned to you.. This will not be targeting alpha in 1.23, most likely the next release.

OK - then I will get back to it after feature freeze.

Addressed review comments. Refactored to include new allPorts field as the proposal. Added an "open questions" section. Updated note about ipvs clusterip.

uablrek · 2021-09-23T16:42:03Z

I have used the simplified setup proposed by @aojea in #2611 (comment) as example in a proposed blog post about kpng; kubernetes/website#29783

k8s-triage-robot · 2021-12-22T17:30:36Z

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 · 2022-01-21T17:32:57Z

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

uablrek · 2022-03-05T08:13:42Z

I suggest to close this KEP and implement all-ip services off-tree as a custom load-balancer with kpng as indicated in https://kubernetes.io/blog/2021/10/18/use-kpng-to-write-specialized-kube-proxiers/

The ClusterIP thing complicated things as I pointed out in #2611 (comment);

The stake-holders should not be asked "do you want all-ip services for ClusterIP?" since the answer would be "yes" (why not), but something like; "are you prepared to delay all-ip service services for ~1y at least, most likely pushed to kube-proxy v2 (which is under way), to get ClusterIP support?"

And here we are almost a year later and the progress on this feature is basically halted.

Considering the interrest and 👍 's in kubernetes/kubernetes#23864 this is a highly wanted feature. However to please everybody, like Istio and nodePort-only clusters (AWS) will stall implementation forever.

IMHO it's better to write a custom proxier that would be useful for the wast majority of users.

Perhaps as a project in K8s network plumbing wg.

k8s-triage-robot · 2022-06-03T09:40:48Z

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 · 2022-07-03T09:53:10Z

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

sftim

Some thoughts

sftim · 2022-07-11T15:19:08Z

keps/sig-network/2610-allports-services/README.md

+Setting this field will be supported for:
+
+* ServiceType=ClusterIP
+* ServiceType=LoadBalancer


How will this work with cloud load balancers that only forward to an assigned port and / or only listen on an assigned port?

sftim · 2022-07-11T15:20:11Z

keps/sig-network/2610-allports-services/README.md

+  b) kube-proxy iptables rules DNAT it to one of the backend pod IPs - p.q.r.s (pod1)
+
+  c) request is received on pod1 with source IP - 1.2.3.4 and destination p.q.r.s:8888


This is assuming TCP, but we should be explicit.

sftim · 2022-07-11T15:20:41Z

keps/sig-network/2610-allports-services/README.md

+1) How should IPVS implementation be handled?
+Options are to a) use iptables for DNAT b) use ipvs rules that results in same 5-tuple requests being sent to the same backend pod. c) create allPorts services as "fwmark-service" and assign a unique mark for each of them.
+
+2) Identfy how Service Mesh(Istio)/Calico/MetalLB can support AllPorts.


Can I have a UDP all-ports Service and a TCP all-ports Service on the same ClusterIP?

sftim · 2022-07-11T15:21:54Z

keps/sig-network/2610-allports-services/README.md

+* To verify that default behavior of `allPorts` does not break any existing e2e tests.
+* Test setting `allPorts` on a new Service and connecting to the service VIP on a few different ports.
+* Test setting `allPorts` on an existing Service and connecting to the service VIP on a few different ports.
+* Test unsetting `allPorts` on a service and specifying a single port allows traffic only for that port.
+* Test setting `allPorts` explicitly to false.


We should test with multiple protocol families, not just TCP.

sftim · 2022-07-11T15:24:06Z

keps/sig-network/2610-allports-services/README.md

+## Motivation
+
+There are several applications like SIP/RTP/Gaming servers that need a lot(1000+) of ports to run multiple calls or media streams.
+Currently the only option is to specify every port in the Service Spec. A request for port ranges in Services has been open in https://github.com/kubernetes/kubernetes/issues/23864. Implementing port ranges are challenging since iptables/ipvs do not support remapping port ranges. Also, in order to specify several non-contiguous port ranges, the user will have to expose the entire valid port range. Hence, this proposal to set a single field in order to expose the entire port range and implement the service clients and endpoints accordingly.


I think nftables can do this remapping. If that's right, another way to view the restriction is that kube-proxy doesn't come with a way to access that remapping (due to accessing netfilter via the older iptables API).

k8s-triage-robot · 2022-08-10T16:06:35Z

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 · 2022-08-10T16:06:57Z

@k8s-triage-robot: Closed this PR.

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.

briantopping · 2022-08-12T13:55:56Z

/reopen

k8s-ci-robot · 2022-08-12T13:56:14Z

@briantopping: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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.

cresta-dongzhao · 2023-08-12T17:30:15Z

keps/sig-network/2610-allports-services/README.md

+
+There are several applications like SIP/RTP/Gaming servers that need a lot(1000+) of ports to run multiple calls or media streams.
+Currently the only option is to specify every port in the Service Spec. A request for port ranges in Services has been open in https://github.com/kubernetes/kubernetes/issues/23864. Implementing port ranges are challenging since iptables/ipvs do not support remapping port ranges. Also, in order to specify several non-contiguous port ranges, the user will have to expose the entire valid port range. Hence, this proposal to set a single field in order to expose the entire port range and implement the service clients and endpoints accordingly.
+[A survey](https://docs.google.com/forms/d/1FOOG2ZoQsnJLYAjnhEtSPYmUULWFNe88iXR7gtFcP7g/edit) was sent out to collect the use-cases for AllPorts support - [results.](http://tiny.cc/allportsslides)


This link is not reachable anymore.

neshkeev · 2024-01-03T11:23:17Z

Is there any progress on the topic? Will Services ever allow to open a range of ports at once?

thockin · 2024-01-24T01:20:56Z

There has not been progress. IIRC the main sticking points for "all ports" are:

The best way to express "all ports" would be to define no Ports[] entries or Ports[].Port = 0, but that's a breaking change, from a certain POV (I think we could get past this)
IPVS does not have a clear way to implement this feature
Service Mesh support seems suspect

It may be better to define this in the L4 Gateway model.

k8s-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Apr 8, 2021

k8s-ci-robot requested review from caseydavenport and thockin April 8, 2021 16:10

k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Apr 8, 2021

This was referenced Apr 8, 2021

Support port ranges or whole IPs in services kubernetes/kubernetes#23864

Open

Support AllPorts for k8s services #2610

Closed

k8s-ci-robot requested a review from rikatz April 8, 2021 16:25

aojea reviewed Apr 8, 2021

View reviewed changes

keps/sig-network/2610-allports-services/README.md Show resolved Hide resolved

aojea reviewed Apr 8, 2021

View reviewed changes

keps/sig-network/2610-allports-services/kep.yaml Show resolved Hide resolved

aojea reviewed Apr 8, 2021

View reviewed changes

keps/sig-network/2610-allports-services/README.md Show resolved Hide resolved

jayunit100 reviewed Apr 9, 2021

View reviewed changes

danwinship reviewed Apr 12, 2021

View reviewed changes

prameshj force-pushed the allports branch from f3bcf38 to 3da8d9e Compare April 13, 2021 23:55

prameshj force-pushed the allports branch from 3da8d9e to 468860e Compare April 15, 2021 19:53

aojea reviewed May 10, 2021

View reviewed changes

keps/sig-network/2610-allports-services/README.md Outdated Show resolved Hide resolved

aojea reviewed May 10, 2021

View reviewed changes

keps/sig-network/2610-allports-services/README.md Show resolved Hide resolved

andrewsykim reviewed May 10, 2021

View reviewed changes

howardjohn reviewed May 17, 2021

View reviewed changes

prameshj force-pushed the allports branch from 4a783d8 to c554211 Compare August 27, 2021 14:47

wojtek-t reviewed Sep 3, 2021

View reviewed changes

Add a KEP for supporting AllPorts services.

e6ebd9d

Addressed review comments. Refactored to include new allPorts field as the proposal. Added an "open questions" section. Updated note about ipvs clusterip.

prameshj force-pushed the allports branch from c554211 to e6ebd9d Compare September 8, 2021 00:35

wojtek-t self-assigned this Sep 8, 2021

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 22, 2021

k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jan 21, 2022

thockin removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Jan 21, 2022

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 3, 2022

k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jul 3, 2022

sftim reviewed Jul 11, 2022

View reviewed changes

k8s-ci-robot closed this Aug 10, 2022

uablrek mentioned this pull request Jan 31, 2023

Allow type LoadBalancer for Headless service for specialized proxiers kubernetes/kubernetes#115429

Closed

cresta-dongzhao reviewed Aug 12, 2023

View reviewed changes

andrewsykim mentioned this pull request May 8, 2024

[Feature] Support Istio ray-project/kuberay#1005

Closed

2 tasks


		### Goals

		* Allow users to optionally expose the entire port range via a Service (of Type LoadBalancer or ClusterIP).

		b) kube-proxy iptables rules DNAT it to one of the backend pod IPs - p.q.r.s (pod1)

		c) request is received on pod1 with source IP - 1.2.3.4 and destination p.q.r.s:8888

Add a KEP for supporting AllPorts services. #2611

Add a KEP for supporting AllPorts services. #2611

Conversation

prameshj commented Apr 8, 2021

k8s-ci-robot commented Apr 8, 2021

rikatz commented Apr 8, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uablrek Aug 6, 2021 • edited Loading

Choose a reason for hiding this comment

uablrek commented Apr 10, 2021

uablrek commented Apr 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prameshj commented Apr 14, 2021

uablrek commented Apr 14, 2021

danwinship commented Apr 18, 2021

uablrek commented Apr 19, 2021

prameshj commented Apr 22, 2021

andrewsykim left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thockin commented May 10, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

prameshj commented Sep 2, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

uablrek commented Sep 23, 2021

k8s-triage-robot commented Dec 22, 2021

k8s-triage-robot commented Jan 21, 2022

uablrek commented Mar 5, 2022 • edited Loading

k8s-triage-robot commented Jun 3, 2022

k8s-triage-robot commented Jul 3, 2022

sftim left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

k8s-triage-robot commented Aug 10, 2022

k8s-ci-robot commented Aug 10, 2022

briantopping commented Aug 12, 2022

k8s-ci-robot commented Aug 12, 2022

cresta-dongzhao Aug 12, 2023 • edited Loading

Choose a reason for hiding this comment

neshkeev commented Jan 3, 2024

thockin commented Jan 24, 2024

uablrek Aug 6, 2021 •

edited

Loading

uablrek commented Apr 10, 2021 •

edited

Loading

uablrek commented Mar 5, 2022 •

edited

Loading

cresta-dongzhao Aug 12, 2023 •

edited

Loading