Adding traffic_distribution field

[JaylonmcShan03]

Description

Addresses #2581
This PR introduces the traffic_distribution field to the kubernetes_service_v1 resource. This field, introduced in Kubernetes v1.31 provides a way to influence traffic routing within a Kubernetes Service by specifying a preference for traffic distribution.

• PreferClose: prioritizes routing to topologically closer endpoints for improved performance, cost, or reliability.

Acceptance tests

• Have you added an acceptance test for the functionality being added?
• Have you run the acceptance tests on this branch?

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccXXX'

...
2024-11-21T08:51:03.941-0600 [DEBUG] sdk.helper_resource: Finished TestCase: test_name=TestAccKubernetesServiceV1_trafficDistribution
--- PASS: TestAccKubernetesServiceV1_trafficDistribution (1.44s)
PASS
ok      github.com/hashicorp/terraform-provider-kubernetes/kubernetes   2.238s


jaylon.mcshan@jaylon issue-testing % terraform apply
╷
│ Error: expected spec.0.traffic_distribution to be one of ["PreferClose"], got InvalidValue
│ 
│   with kubernetes_service_v1.test,
│   on main.tf line 68, in resource "kubernetes_service_v1" "test":
│   68:     traffic_distribution = "InvalidValue"
│ 
╵
jaylon.mcshan@jaylon issue-testing % 

Release Note

Release note for CHANGELOG:

...

References

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[arybolovlev]

All in all, great job! 🚀

I have left some cosmetic suggestions. 😊

Thanks for making the test function flexible with the additional attribute, once the Kubernetes team adds more traffic distribution values, it can be reused to add more tests.

[arybolovlev]

I would suggest importing such predefined words from Kubernetes code.

[JaylonmcShan03]

@arybolovlev Wow, that's a clever approach! Would this be considered best practice for the future? Due to the k8s api were to update / expand on the traffic_distrubtion field with additional options, our code would automatically align with those changes?

[arybolovlev]

I would say yes, this is the best practice regarding 'static' values. At least in this case, we can be sure that we validate against the same values that Kubernetes API relies on.

our code would automatically align with those changes?

Unfortunately, no, we will have to either follow up with the changes that the Kubernetes team introduces or wait for end users to report that missing part. Likely, this new feature will be highlighted in the release notes. Another option, with auto code generation, should be resolved as we bump up dependencies.