Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove knowledge of pod cluster CIDR from iptables rules #2450

Closed
4 tasks
shekhar-rajak opened this issue Feb 7, 2021 · 5 comments
Closed
4 tasks

Remove knowledge of pod cluster CIDR from iptables rules #2450

shekhar-rajak opened this issue Feb 7, 2021 · 5 comments
Labels
sig/network Categorizes an issue or PR as relevant to SIG Network.

Comments

@shekhar-rajak
Copy link
Member

shekhar-rajak commented Feb 7, 2021

Enhancement Description

  • One-line enhancement description (can be used as a release note):

Remove knowledge of pod cluster CIDR from iptables rules

  • Kubernetes Enhancement Proposal:
The iptables implementation of kube-proxy today references the cluster CIDR for pods in three places for the following reasons.

   1. [Masquerade off cluster traffic to services by node IP](https://github.com/kubernetes/kubernetes/blob/v1.17.0/pkg/proxy/iptables/proxier.go#L965-L970)
   2. [Redirecting pods traffic to external loadbalancer VIP to cluster IP](https://github.com/kubernetes/kubernetes/blob/v1.17.0/pkg/proxy/iptables/proxier.go#L1327-L1339)
   3. [Accepting traffic after first packet, after being accepted by kubernetes rules](https://github.com/kubernetes/kubernetes/blob/v1.17.0/pkg/proxy/iptables/proxier.go#L1468-L1490)

In addition, the ipvs implementation also references it in two places for similar purposes

   1. [Masquerade off cluster traffic to services by node IP](https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/proxier.go#L1649-L1654)
   2. [Accepting traffic after first packet, after being accepted by kubernetes](https://github.com/kubernetes/kubernetes/blob/master/pkg/proxy/ipvs/proxier.go#L1726-L1745)

This enhancement proposes ways to achieve similar goals without tracking the pod cluster CIDR to do so.

  • Discussion Link:
  • Primary contact (assignee): @satyasm
  • Responsible SIGs: sig-network
  • Enhancement target (which target equals to which milestone):
    • Alpha release target (x.y):
    • Beta release target (x.y):
    • Stable release target (x.y):
  • Alpha
    • KEP (k/enhancements) update PR(s):
    • Code (k/k) update PR(s):
    • Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

@shekhar-rajak
Copy link
Member Author

shekhar-rajak commented Feb 7, 2021

Migrating all the old template keps to new template : #2446

@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Feb 7, 2021
@kikisdeliveryservice kikisdeliveryservice added the sig/network Categorizes an issue or PR as relevant to SIG Network. label Feb 11, 2021
@k8s-ci-robot k8s-ci-robot removed the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Feb 11, 2021
@thockin
Copy link
Member

thockin commented Apr 30, 2021

Implemented

@thockin thockin closed this as completed Apr 30, 2021
@sftim
Copy link
Contributor

sftim commented Jun 25, 2021

It looks like KEP from this issue is being linked to deprecating use of the podCIDR field in the Node resource: kubernetes/kubernetes#57130

Have I got that right?

@aojea
Copy link
Member

aojea commented Jun 25, 2021

Have I got that right?

This removes kube-proxy dependency, that is one step towards deprecating it, however, it seems the field is "happily" used by CNI and other projects in the ecosystem

@sftim
Copy link
Contributor

sftim commented Jun 25, 2021

Maybe the field deprecation should have its own KEP?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/network Categorizes an issue or PR as relevant to SIG Network.
Projects
None yet
Development

No branches or pull requests

6 participants