Since this is a container service port anyways, "insecure" is a bit of
a red herring. There's no real security relevance to the incoming port
numbers for the NFS server pod.
This lets us get rid of the examples/nfs/exporter Docker build
(@jsafrane's personal image).
This ensures nfs-common is installed on GCE, and provides a more
functional explanation/example. I launched two replication controllers
so that there were busybox pods to poke around at the NFS volume, and
so that the later wget actually works (the original example would have
to work on the node, or need some other access to the container
network). After switching to two controllers, it actually makes more
sense to use PV claims, and it's probably a configuration that makes
more sense for indirection for NFS anyways.
- add appropriate server containers into contrib/for-tests/volumes-tester
- the tests are off by default (they need kubelet --allow_privileged=True)
- enable by 'go run hack/e2e.go ... --ginkgo.focus=Volume'
- add glusterfs tools to list of installed packages on each node
While running through this example the Dockerfile wouldn't build, upon closer inspection the entrypoint was not being copied into the container, and it was not executable.
Update docs and example for NFS Plugin
Modified the wording around how many Volumes exist
Cleaned up the text around the NFS Pod description
Fixed Spelling mistake on read-only
* If you want to test this out when an actual NFS export a good place
to start is by running the NFS server in a container:
docker run -d --name nfs --privileged cpuguy83/nfs-server /tmp
More detail can be found here:
https://github.com/cpuguy83/docker-nfs-server
Zach Loafman