hypothesis: The old userspace proxier would internally retry connections. The
new one does not. When this test comes up, the firewall might not yet be open or
something is causing a long delay and a timeout. I can't repro this failure
locally, so I am shooting in the dark. It's sort of plausible.
evidence: I can SSH into the jenkins master that is hung and I can see the hung
curl. I can run that curl by hand and it works. I can see that my shell is in
the same netns as that hung curl.
This adds a very basic Zeppelin image that works with the existing
Spark example. As can be seen from the documentation, it has a couple
of warts:
* It requires kubectl port-forward (which is unstable across long
periods of time, at least for me, on this app, bug incoming). See
* I needed to roll my own container (none of the existing containers
exactly matched needs, or even built anymore against modern Zeppelin
master, and the rest of the example is Spark 1.5).
The image itself is *huge*. One of the further refinements we need to
look at is how to possibly strip the Maven build for this container
down to just the interpreters we care about, because the deps here
are frankly ridiculous.
This might be a case where, if possible, we might want to open an
upstream request to build things dynamically, then use something like
probably the cut the image down considerably. (This might already be
possible, need to poke at whether you can late-bind interpreters
later.)
Adds an example using DaemonSets to distribute the NewRelic worker onto all nodes in a k8s cluster.
Signed-off-by: Christian Stewart <christian@paral.in>
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.
* Pod -> ReplicationController, which also forced me to hack around
hostname issue on the master. (Spark master sees the incoming slave
request to spark-master and assumes it's not meant for it, since it's
name is spark-master-controller-abcdef.)
* Remove service env dependencies (depend on DNS instead).
* JSON -> YAML.
* Add GCS connector.
* Make example do something actually useful: A familiar example to
anyone at Google, implement wordcount of all of Shakespeare's works.
* Fix a minor service connection issue in the gluster example.
Matthew Farrellee