tknaup

With Kubernetes v1.24, non-expiring service account tokens are no longer auto-generated. This blog post highlights what this means in practice, and what to do if you rely on non-expiring service account tokens.

Co-founder of Mesosphere/D2iQ here.

Mesos started as a research project at Berkeley in 2009 and was originally focused on cluster computing frameworks like Hadoop. From the paper: "We present Mesos, a platform for sharing commodity clusters between multiple diverse cluster computing frameworks, such as Hadoop and MPI." It actually predates YARN by a few years. But, it very quickly (in 2010) saw production use at Twitter as the foundation for Twitter's custom PaaS which was later open sourced as Apache Aurora.

Marathon's main use case was actually for running microservice application in containers, which is why it has some advanced features around managing groups of containerized apps and their dependencies. The "meta-framework" use case for launching custom frameworks was also important but basically just needs Marathon to keep a container alive. Mesosphere never made Marathon proprietary. The full code is still OSS here: https://github.com/mesosphere/marathon/ Our commercial product DC/OS just added advanced workflows through a UI on top, and better integration with the rest of the components around Mesos.

ML is a relatively young field, and decades behind Software Engineering in terms of best practices for running production systems. CI/CD massively improved the innovation cycle time and quality of production software, and I believe it is key for building robust production ML systems as well. CML looks like a really easy to use product for bringing CI/CD to ML projects.

The new package is here: http://universe.dcos.io/#/package/beta-hdfs/version/latest

Mesosphere co-founder here.

You're correct in that GCP runs k8s in VMs, DC/OS doesn't. What's similar is that there's a resource manager underneath - Borg for GCP, Mesos for DC/OS. They serve similar purposes like resource management, isolation, and operating the services on top.

Mesosphere co-founder here.

This is correct: "DC/OS is better for running stateful services and then you can use K8 to run your stateless services"

Data services run directly on DC/OS via application-aware schedulers. They have the operational logic for how to bring up say a Cassandra cluster correctly, how to upgrade it to a new version without breaking it, change config, scale up, etc. All things you usually have to figure out yourself. When you run k8s on DC/OS you get these same benefits.

disclosure: I'm a founder of Mesosphere.

For most people k8s (like any other distributed system) is pretty hard to operate and wrap their head around. The goal of DC/OS is to make building and operating distributed systems easy. Mesos is pretty different from k8s. It doesn't have an API for microservice developers for example, instead it has low level primitives similar to an operating system kernel, on which you can build any software. We recently launched an SDK to make that even easier, along with a bunch of open source and commercial software that uses it, for example Cassandra/Datastax, Kafka/Confluent, Redis, Elastic, Couchbase, Alluxio. So DC/OS ends up looking a lot more like an entire cloud platform like GCP, which offers managed k8s, a managed database (BigTable), machine learning and so on. Under the hood it all runs on Google's proprietary Borg, which has some similarities with Mesos (Google is a sponsor of the lab where Mesos was created).

(Mesosphere co-founder here)

Running workload-specific schedulers like Kubernetes on Mesos is one of its fundamental ideas. From the paper:

"It seems clear that new cluster computing frameworks will continue to emerge, and that no framework will be optimal for all applications. Therefore, organizations will want to run multiple frameworks in the same cluster, picking the best one for each application."

https://people.csail.mit.edu/matei/papers/2011/nsdi_mesos.pd...

My favorite part is that moving Siri to Mesos actually had a noticeable impact on Siri's response time. It didn't just make the lives of Apple engineers easier but improved the product as well. For every one of the more than 700 million iPhone users worldwide.

self-serve machine learning and analytics is a really cool use case.

The new features are really exciting. Disk quota isolation is important to pave the way for stateful workloads, and with the upcoming work on stateful primitives (https://issues.apache.org/jira/browse/MESOS-2018) it will be easy to run things like databases and filesystems.

The service discovery metadata and labels allow more control over the visibility and naming of tasks. Mesos DNS (https://github.com/mesosphere/mesos-dns) will get support shortly.

Finally the modules also got some additions: hooks and anonymous modules, which can be used to add arbitrary extensions to Mesos.

Exciting release!

They are simpler but keep it mind all the other things you get from running on Mesos, like provisioning your services, having your services restarted when they crash, workload migration when machines fail, bin-packing so you don't waste resources, etc.

That's right, it's really just a plain ol DNS server that happens to read its records from Mesos.

It's the actor library at the core of Mesos (and a many other things). It's what makes it scale to 10,000s of nodes, and probably more. It's just nobody was able to test it on more nodes without breaking the bank.

The nice thing about running it on mesos is you can share the same machines with other big data apps like Hadoop or spark and don't have to provision separate machines.

This part is super important for Rocket support in Mesos and other things that run containers.

This would be another blog post by itself. In short: build a fat jar with maven, package with arx, run with runit.

Most projects use Junit and Easymock.

Dropwizard wasn't around yet when we built our first service.

I'm not referencing any particular framework, but Rails is an example. Recently the Rails team has done a lot to modularize it too though.

Assuming you use InnoDB, is your innodb_buffer_pool_size big enough to hold your data (or a significant amount of it)? It's by far the most important setting to get speedy reads, which form 95% of the queries in our case. When you did the testing, did you warm up the RDS instance before, for example by running a number of common queries? It naturally takes a while after booting until MySQL can make efficient use of caches and buffers.

I'm not sure if instance-local storage will give you better performance compared to EBS. From the EBS page: "The latency and throughput of Amazon EBS volumes is designed to be significantly better than the Amazon EC2 instance stores in nearly all cases."

There is a problem with the recovery approach you described: as far as I know you can't use an EBS snapshot to populate local storage on a new instance, so you would be forced to use EBS for the new master. Promoting the slave to be the new master would be the better approach, with less downtime and data loss, provided that MySQL replication didn't break unnoticed.

- Tobi