Closed bjoernrost closed 3 years ago
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.
It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
Welcome @bjoernrost!
It looks like this is your first PR to kubernetes-sigs/ip-masq-agent 🎉. 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/ip-masq-agent 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. :smiley:
I signed it
/assign @bowei
@bowei @MrHohn do you have an estimate on when you will be able to review this PR? And in the meantime, is there anything that I can do to help this move along?
Sorry for the huge delay. I found this to be an interesting use case. I saw a similar use case where a customer wanted to set up 1:1 NAT rule for each pod, which was trickier and we ended up not having a good solution.
Though I do wonder how to use this in practice - wouldn't it invalidate other traffic that is not supposed to be go through the static/LB IP? ip-masq-agent is usually deployed as a daemonset - do we expect outbound traffic from the entire cluster to be SNAT to a static IP? Or is it deploying the agent only to specific nodes to special case them?
Also there are some cases we SNAT to the node IP when bouncing packets from outside to the backend pod that runs on another node. I wonder it this would break those cases.. e.g.:
client -> LB -> node1 -(SNAT to node1 IP)-> node2 -> pod
Adding @varunmar @freehan for inputs as well :) /cc @freehan @varunmar
@MrHohn: GitHub didn't allow me to request PR reviews from the following users: freehan, varunmar.
Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.
Multiple nodes using the same SNAT ip would break external networking for everything but very edge cases. I built this for and tested with single-node "clusters" in mind. I had naively assumed that when using multiple nodes one could have a dedicated LB for each node and set the SNAT ip to the assigned LB. However, that would require two more pieces: 1 - a way to set a different value for the SNAT ip on each node 2 - a mechanism to map a static LB IP to a node and also to manage and create additional LBs as a cluster scales
The second one is a biggie and if/when someone builds that they could likely just add the little bit of iptables logic to that thing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
Some minor comments, otherwise LGTM
@varunmar
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: bjoernrost To complete the pull request process, please ask for approval from bowei after the PR has been reviewed.
The full list of commands accepted by this bot can be found here.
/remove-lifecycle rotten
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closed this PR.
Adds an optional parameter "SnatTarget". When set to an ip address, ip-masq-agent will create an SNAT rule instead of MASQUERADE for outbound traffic. This fixes #56