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

r/service: Add external_traffic_policy to spec #59

Merged

Conversation

phamann
Copy link
Contributor

@phamann phamann commented Aug 25, 2017

This adds the externalTrafficPolicy property to the spec schema on the Service resource.

By default k8s obscures the source IP from packets replacing it with the node IP. However certain applications require source IP preservation. This behaviour is managed via the externalTrafficPolicy. More info here: https://kubernetes.io/docs/tutorials/services/source-ip/

Until recently we got around the lack of this property by using an internal k8s annotation to apply the behaviour using service.metadata.annotations[0]. However, #50 (and the 1.0.0 release) broke this by treating internal annotations as invalid. Using the spec.externalTrafficPolicy is the preferred method anyway hence this PR.

@@ -136,6 +136,9 @@ func expandServiceSpec(l []interface{}) v1.ServiceSpec {
if v, ok := in["external_name"].(string); ok {
obj.ExternalName = v
}
if v, ok := in["external_traffic_policy"].(string); ok {
obj.ExternalName = v
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this corrrect - obj.ExternalName ?
Shouldn't that be something like obj.ExternalTrafficPolicy ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll also need to modify flattenServiceSpec similarly.

@radeksimko radeksimko changed the title r/Service add external_traffic_policy to spec r/service: Add external_traffic_policy to spec Aug 29, 2017
Copy link
Member

@radeksimko radeksimko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @phamann
thanks for the contribution.

Except what @sl1pm4t and I mentioned we'll need to upgrade vendored K8S to 1.7 as this field was introduced in that version. I planned to do it anyway - just FYI that this is a blocker. I'll hopefully get to it this week.

After vendor upgrade is done you'd just rebase your PR and run acceptance tests to see if everything's working correctly.

@@ -136,6 +136,9 @@ func expandServiceSpec(l []interface{}) v1.ServiceSpec {
if v, ok := in["external_name"].(string); ok {
obj.ExternalName = v
}
if v, ok := in["external_traffic_policy"].(string); ok {
obj.ExternalName = v
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll also need to modify flattenServiceSpec similarly.

@phamann
Copy link
Contributor Author

phamann commented Aug 30, 2017

Thanks for the review. I've now updated/added all of the correct references within flattenServiceSpec(), expandServiceSpec(), and patchServiceSpec() in 6bccc7c.

The build is now failing (correctly) due to the vendored K8S not having the the field. As @radeksimko suggested, I'll wait until the upgrade has been done and then re-run.

@phamann
Copy link
Contributor Author

phamann commented Oct 3, 2017

@radeksimko Any update on when you will upgrade the vendored K8S to 1.7? To resolve the issues with this PR?

@sl1pm4t
Copy link
Contributor

sl1pm4t commented Oct 29, 2017

@phamann I created a PR #80 that bumps the vendored k8s client code to v1.7.
Do you want to try rebase this PR on mine to see if the build is successful?

@nicknovitski
Copy link

Since #80 has been merged, it seems this is due to be rebased.

@phamann phamann force-pushed the b-service-external-traffic-policy branch 3 times, most recently from d6aedbf to f169008 Compare April 3, 2018 13:16
@phamann
Copy link
Contributor Author

phamann commented Apr 3, 2018

@radeksimko Apologies for neglecting this this, we had the provider version pinned as a temporary resolution to this problem internally. Needing some other features in the latest release reminded me of this PR.

I've now rebased with master and the tests are all passing 😄

@phamann
Copy link
Contributor Author

phamann commented Jun 21, 2018

Any update on this @radeksimko? It still has the waiting-response label even though I have rebased and fixed issues, which may be why you haven't reviewed again?

@jhoblitt
Copy link
Contributor

I just smacked into this as well: Error: module.pkgroot.kubernetes_service.ssl_proxy: spec.0: invalid or unknown key: externalTrafficPolicy -- it would be great to see this feature merged.

@codercr
Copy link

codercr commented Jan 14, 2019

This is good but should default to the Kubernetes default of Cluster. The user should set to Local when they choose not to use default behavior.

@radeksimko, what else is needed to get this in? This is a very important feature.

@ghost ghost removed the waiting-response label Jan 14, 2019
@yacut
Copy link

yacut commented Feb 19, 2019

@phamann @radeksimko any update on this?

@ulm0
Copy link

ulm0 commented Apr 15, 2019

Hi, guys. any update on this? i need this field to deploy nginx ingress controller with terraform.

Copy link

@roidelapluie roidelapluie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@annaGo
Copy link

annaGo commented Apr 30, 2019

I need this field as well, going to pass on terraform and use kubectl :(

@markodkrstic
Copy link

@radeksimko this is a crucial element to deploy nginx ingress controller with terraform as previously mentioned. is there any timeline on this?

@zioproto
Copy link

I rebased this PR on top of the origin master and I pushed the branch here:
https://github.com/zioproto/terraform-provider-kubernetes/tree/PR-59
@phamann could you check if the rebase is OK for you and push the changes to this PR ?
thanks

@zioproto
Copy link

@phamann if my rebase looks correct, to solve the git stuff, you could do like this:

git remote add zioproto https://github.com/zioproto/terraform-provider-kubernetes
git fetch --all
git checkout b-service-external-traffic-policy
git reset --hard zioproto/PR-59
git push -f origin b-service-external-traffic-policy

This will refresh the current PR59 with the rebased version I proposed.
Let me know if you are still interested in getting this merged, otherwise I will propose a new PR.
Thanks !! :)

"external_traffic_policy": {
Type: schema.TypeString,
Description: "Denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. `Local` preserves the client source IP and avoids a second hop for LoadBalancer and Nodeport type services, but risks potentially imbalanced traffic spreading. `Cluster` obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading. More info: https://kubernetes.io/docs/tutorials/services/source-ip/",
Optional: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two possible values for this field: "Local" and "Cluster".
It'd be nice to have validation in place to express this.

Suggested change
Optional: true,
Optional: true,
ValidateFunc: validation.StringInSlice([]string{"Local", "Cluster"}, false),

@alexsomesan alexsomesan force-pushed the b-service-external-traffic-policy branch from 2ef8764 to df911a9 Compare May 20, 2019 16:40
@ghost ghost added size/S and removed size/XS labels May 22, 2019
Copy link
Member

@alexsomesan alexsomesan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI passes. LGTM.

@alexsomesan alexsomesan merged commit 5e11ec4 into hashicorp:master May 22, 2019
@regner
Copy link

regner commented May 22, 2019

Thanks for your work on this everyone. Really looking forward to taking advantage of it.

@ghost ghost locked and limited conversation to collaborators Apr 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.