Support ipFamilyPolicy and ipFamilies fields in Helm Chart

[jaehnri]

What this PR does / why we need it:

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Which issue/s this PR fixes

fixes #6622

How Has This Been Tested?

I've changed the values.yaml to use ipFamilyPolicy: "PreferDualStack" and made sure it reflected in the ingress-nginx-controller service.
I couldn't check whether ingress-nginx actually works with IPv6 because I have no cluster configured with this family. Would be glad if someone could help me with this.

Testing if it applies when I use ipFamilyPolicy: "PreferDualStack"

$ git remote -v
origin  [email protected]:jaehnri/ingress-nginx.git (fetch)
origin  [email protected]:jaehnri/ingress-nginx.git (push)

$ pwd
.../ingress-nginx

$ ls
bin    Changelog.md  cloudbuild.yaml  code-of-conduct.md  deploy  go.mod  hack    internal  Makefile    OWNERS          README.md   rootfs             SECURITY.md  TAG   version
build  charts        cmd              CONTRIBUTING.md     docs    go.sum  images  LICENSE   mkdocs.yml  OWNERS_ALIASES  RELEASE.md  SECURITY_CONTACTS  stable.txt   test

$ cat charts/ingress-nginx/values.yaml | grep 'ipFamilyPolicy:'
    ipFamilyPolicy: "PreferDualStack"

$ make dev-env
...

$ kubectl config current-context
kind-ingress-nginx-dev

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.4", GitCommit:"3cce4a82b44f032d0cd1a1790e6d2f5a55d20aae", GitTreeState:"clean", BuildDate:"2021-08-13T15:45:10Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-21T01:11:42Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

$ kubectl get svc ingress-nginx-controller -n ingress-nginx -o yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/component":"controller","app.kubernetes.io/instance":"ingress-nginx","app.kubernetes.io/managed-by":"Helm","app.kubernetes.io/name":"ingress-nginx","app.kubernetes.io/version":"1.0.0","helm.sh/chart":"ingress-nginx-4.1.0"},"name":"ingress-nginx-controller","namespace":"ingress-nginx"},"spec":{"ipFamilies":["IPv4"],"ipFamilyPolicy":"PreferDualStack","ports":[{"appProtocol":"http","name":"http","port":80,"protocol":"TCP","targetPort":"http"},{"appProtocol":"https","name":"https","port":443,"protocol":"TCP","targetPort":"https"}],"selector":{"app.kubernetes.io/component":"controller","app.kubernetes.io/instance":"ingress-nginx","app.kubernetes.io/name":"ingress-nginx"},"type":"NodePort"}}
  creationTimestamp: "2021-09-17T03:05:11Z"
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/version: 1.0.0
    helm.sh/chart: ingress-nginx-4.1.0
  name: ingress-nginx-controller
  namespace: ingress-nginx
  resourceVersion: "356"
  uid: 2f3fbc1f-70ad-4c16-89d9-161fb59b39ce
spec:
  clusterIP: 10.96.209.96
  clusterIPs:
  - 10.96.209.96
  externalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: PreferDualStack
  ports:
  - appProtocol: http
    name: http
    nodePort: 31589
    port: 80
    protocol: TCP
    targetPort: http
  - appProtocol: https
    name: https
    nodePort: 31652
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

Testing if it applies when I use ipFamilyPolicy: "RequireDualStack"

$ git remote -v
origin  [email protected]:jaehnri/ingress-nginx.git (fetch)
origin  [email protected]:jaehnri/ingress-nginx.git (push)

$ pwd
.../ingress-nginx

$ ls
bin    Changelog.md  cloudbuild.yaml  code-of-conduct.md  deploy  go.mod  hack    internal  Makefile    OWNERS          README.md   rootfs             SECURITY.md  TAG   version
build  charts        cmd              CONTRIBUTING.md     docs    go.sum  images  LICENSE   mkdocs.yml  OWNERS_ALIASES  RELEASE.md  SECURITY_CONTACTS  stable.txt   test

$ cat charts/ingress-nginx/values.yaml | grep 'ipFamilyPolicy:'
    ipFamilyPolicy: "RequireDualStack"

$ make dev-env
...
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
The Service "ingress-nginx-controller" is invalid: 
* spec.ipFamilyPolicy: Invalid value: "RequireDualStack": Cluster is not configured for dual stack services
* spec.ipFamilies[1]: Invalid value: []string(nil): ipfamily IPv6 is not configured on cluster

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added tests to cover my changes.
• All new and existing tests passed.

[k8s-ci-robot]

@jaehnri: This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[k8s-ci-robot]

Welcome @jaehnri!

It looks like this is your first PR to kubernetes/ingress-nginx 🎉. 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/ingress-nginx 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. 😃

[k8s-ci-robot]

Hi @jaehnri. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[cpanato]

please drop the version bumps, we will make a release with other things together

[jaehnri]

please drop the version bumps, we will make a release with other things together

Should I also drop the CHANGELOG change too, then? Is it filled in automatically in a later release step?

[rikatz]

/ok-to-test

[rikatz]

/lgtm
/approve
Thanks

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jaehnri, rikatz

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

The pull request process is described here

Needs approval from an approver in each of these files:

• charts/ingress-nginx/OWNERS [rikatz]

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

[lukeplausin]

Hi everyone, while upgrading to chart version 4.0.6 I'm having issues because of the defaults in values.yaml relating to the ipFamilyPolicy and ipFamilies settings of the service. They are not supported by my controller yet (aws load balancer controller), so the service fails to sync. In case anyone else has this problem it can be fixed by setting this in the values.yaml override:

controller:
  service:
    ## Represents the dual-stack-ness requested or required by this Service. Possible values are
    ## SingleStack, PreferDualStack or RequireDualStack.
    ## The ipFamilies and clusterIPs fields depend on the value of this field.
    ## Ref: https://kubernetes.io/docs/concepts/services-networking/dual-stack/
    ipFamilyPolicy: "" # "SingleStack" # Explicitly set to none/null/empty until this field is supported by the AWS load balancer controller.

    ## List of IP families (e.g. IPv4, IPv6) assigned to the service. This field is usually assigned automatically
    ## based on cluster configuration and the ipFamilyPolicy field.
    ## Ref: https://kubernetes.io/docs/concepts/services-networking/dual-stack/
    ipFamilies: [] # Explicitly set to none/null/empty until this field is supported by the AWS load balancer controller.
      # - IPv4

I think it was a bad idea to set the ipFamilyPolicy and ipFamilies in the default configuration as this chart is now broken by default for a lot of users.

[jaehnri]

Hey, @lukeplausin, thank you for your feedback.
We should probably comment out these two fields in order to avoid these compatibility issues.
Would you mind opening a PR fixing it? If not, I'll do it.
Again, thank you!

[longwuyuan]

Hi @lukeplausin @jaehnri

% helm show values ingress-nginx/ingress-nginx   | grep -i famil
    # The ipFamilies and clusterIPs fields depend on the value of this field.
    ipFamilyPolicy: "SingleStack"
    # -- List of IP families (e.g. IPv4, IPv6) assigned to the service. This field is usually assigned automatically
    # based on cluster configuration and the ipFamilyPolicy field.
    ipFamilies:
[~] 
% helm show values ingress-nginx/ingress-nginx --version 3.40.0 | grep -i famil
[~] 
%