The Thanos query nodes have the same interface as Prometheus itself, including the web UI (with a few small changes), so you can just use the same Prometheus plugin pointed at Thanos.
Thank you for that answer, it's helpful. We've also been considering Calico but it seems like a fair bit of work and the project's pretty overdue as it is.
The trick with flanneld on our other hosts is that AFAICT there's no way to run flanneld as purely a "grab routes and install them" without having it get a totally unnecessary (and completely unused) subnet lease.
I have considered just writing a quicky daemon that will do just the work of syncing routes without getting a lease (or trying to modify flanneld to do so).
The service in this case is memcache with a bunch of mcrouter pods in front of it to handle failure and cold cache warming. I still need to get traffic to the mcrouter instances and that's where I'm running into the bottleneck.
Anyone working on K8s at Box or I guess anywhere else that has deployed it partially feel free to answer this, but:
How do you handle gatewaying traffic into Kubernetes from non-K8s services? I've been trying to get a basic cluster out the door with one of our most stateless services, but I'm having a having a hard time just getting the traffic into it.
The mechanism I'm using is having a dedicated K8s nodes that don't run pods hold onto a floating IP to act as gateway routers into k8s. They run kube-proxy and flannel so they can get to the rest of things, but ksoftirqd processes are maxing CPU cores on relatively recent CPUs trying to handle about 2Gbps of traffic (2Mpps) which is a bit below the traffic level the non-k8s version of the service is handling. netfilter runs in softirq context, so I figure that's where the problem is.
Are you using Calico+BGP to get routes out to the other hosts? What about kube-proxy?
Not the parent poster, but needing GPU isn't necessarily the same as having UI. You can use GPU for a variety of general purpose math (Example: mining bitcoins, or doing stuff like Folding@Home), or for offline rendering.
I can't find a news story about the incident I'm thinking of, but there are SEC regulations about the release of information to investors. You basically have to try to ensure that they all get the same data at the same time.
ING Direct implemented read-only credentials for Mint, after fighting with them about access for months. (ING kept blocking Mint, and then Mint would find a way around it.)
I used a Norwegian friend's Spotify account for a bit, and I'm now using rdio. I don't see any significant difference between them, other than the client, which ... eh? Rdio works in my web browser, and it works on my phone. That's pretty much all I care about.
The only advantage an actual app could have is responding to my hardware play/pause/next buttons, I think.
I got an invite a few months ago and tried it out. It was pretty amazingly rough for how long they'd been working on it. I did check out the source and was... not impressed.
I'll agree to some extent about the consistency, but I don't think that the "fork and go" mentality makes stability any worse.
I mean, as it is, I see segfaults and whatnot regularly in the canonical, distro-released versions of Apache. Major software releases all the time with bugs that could potentially be a show-stopper. My experience hasn't shown this to be any worse with non-canonical sources. Sometimes it's better.
Further, I like to think of the sysadmin's job as fostering business continuity. While uptime is a primary indicator of this, I think it's lower in priority than say, losing a crapload of customer data. If I have to shut a site down for an hour to prevent losing all transactions for the previous 24 hours or something, then it's not a terribly difficult choice. (Having to make this choice at all, of course, means you should be engineering something better. But we don't have the luxury of infinite time.)
And having all the uptime in the world won't help you if your engineers can't do their jobs effectively because the tools you give them are insufficient. Sometimes the best option is to suck it up and try that patch.
It's a delicate balancing act, and I'm not by any means advocating running all your software out of unofficial repos. Sometimes you gotta make that call, though. And if I'm looking at github at all, it's probably because a package doesn't already exist, or because I need a fix for one specific bug.
If I wanted something like this I'd probably just reach for pampy and use pattern matching. Which still isn't "Monadic".