Use "servicename.namespace" as address for the NFS server

[EmielBruijntjes]

Hello,

Maybe I do not understand the reason for using the service IP address in the PersistentVolume, but it does not seem to be a very reliable setup. This was also mentioned in issue #79. These IP addresses happen to change every now and then, leaving the PersistentVolume in a useless state. In this pull request I modified the code a bit to use "servicename.namespace" as the server address. I have the feeling that that makes more sense and is better for reliable use in production environments.

I also added some comments next to the lines that sursprised me a bit while working on this. For example why the provisioner hands out pod ips or node ips as server addresses, because those addresses are not so reliable either. And I wondered why the provisioner picks up the responsibility for checking the correctness of the service. Those are however just comments and I did not modify the code any further.

I am new to Kubernetes and this is the first time that I touched any Go code. So my apologies for anything stupid that I did. In that case I am happy to receive feedback to improve my work.

Thanks,

Emiel

[k8s-ci-robot]

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.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please log a ticket with the Linux Foundation Helpdesk: https://support.linuxfoundation.org/
• Should you encounter any issues with the Linux Foundation Helpdesk, send a message to the backup e-mail support address at: [email protected]

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. I understand the commands that are listed here.

[k8s-ci-robot]

Welcome @EmielBruijntjes!

It looks like this is your first PR to kubernetes-sigs/nfs-ganesha-server-and-external-provisioner 🎉. 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/nfs-ganesha-server-and-external-provisioner 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:

[linux-foundation-easycla[bot]]

The committers are authorized under a signed CLA.

• :white_check_mark: Emiel Bruijntjes (6b9045ffbe7cc0deb24135c709781ec771f0b3ed, 044238d0e6b12ec209698a935efc61ebe47d44e8, 2a0d9c2d8588134329211f7860486b210858f266, 53baf825898b8c7192ea1e2c3e84ab24e61505f2)

[EmielBruijntjes]

/assign @ashishranjan738

BTW I don't understand what the pending check is, is this your approval?

[EmielBruijntjes]

I learned some new things. Turns out that the "servicename.namespace" name does not by default exist on all possible clusters. So I changed the code a bit. The default behavior (to use IP addresses) has not been changed, but I did add some comments to explain the reasoning behind this. At the same time, the -server-hostname parameter can now also be used to start the nfs-provisioner with a custom hostname if it runs inside the cluster. This allows users who do support the servicename.namespace DNS on the nodes to run this software without IP address based NFS mounts.

By the way: I would appreciate some human interaction to see if I am on the right track here.

[kmova]

/ok-to-test

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[EmielBruijntjes]

/remove-lifecycle stale

[kvaps]

Hi @EmielBruijntjes, many thanks for your contribution

Maybe I do not understand the reason for using the service IP address in the PersistentVolume, but it does not seem to be a very reliable setup

I know about this problem, but IP address of the kubernetes service can be changed only in case of recreating service object.

This allows users who do support the servicename.namespace DNS on the nodes to run this software without IP address based NFS mounts.

Does it really work? Can you tell more about your environment? The kubelet is using host network while mounting nfs share, in many clusters it has no access to kubernetes DNS server.

[EmielBruijntjes]

Hi @EmielBruijntjes, many thanks for your contribution

Maybe I do not understand the reason for using the service IP address in the PersistentVolume, but it does not seem to be a very reliable setup

I know about this problem, but IP address of the kubernetes service can be changed only in case of recreating service object.

You are right, but at the same time there is this saying that one should treat servers (and other things) like cattle, not pets - which is one of the reasons why people use Kubernetes. So if there is an issue with a pod, deployment, service, ingress, etc, etc - the natural first reaction for many sysadmins/devops is to kill/remove/recreate/restart/etc such things -- and if that doesn't work to try something else. So it would be better if this NFS provisioner would also survive service-recreation.

This allows users who do support the servicename.namespace DNS on the nodes to run this software without IP address based NFS mounts.

Does it really work? Can you tell more about your environment? The kubelet is using host network while mounting nfs share, in many clusters it has no access to kubernetes DNS server.

We do indeed have an unfamiliar setup. In a normal cluster the CoreDNS pods are configured to fall back to the Node /etc/resolv.conf file, which then refers to upstream DNS servers (1.1.1.1 or so). We turned that around: the CoreDNS server fallbacks to 1.1.1.1, and the resolv.conf on the nodes point to 10.96.0.10 (the CoreDNS facility). The effect of this is that you can then also use 'cluster.local' domains on the nodes. To make sure that the nodes also have access to DNS during startup (when the kubelet process is not yet running) we added a secondary 'nameserver' line that does refer to the global DNS. But this secondary nameserver is only used when 10.96.0.10 is not accessible (thus only during boot).

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: EmielBruijntjes Once this PR has been reviewed and has the lgtm label, please ask for approval from ashishranjan738 by writing /assign @ashishranjan738 in a comment. For more information see:The Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale