For more than five years, DC/OS has enabled some of the largest, most sophisticated enterprises in the world to achieve unparalleled levels of efficiency, reliability, and scalability from their IT infrastructure. But now it is time to pass the torch to a new generation of technology: the D2iQ Kubernetes Platform (DKP). Why? Kubernetes has now achieved a level of capability that only DC/OS could formerly provide and is now evolving and improving far faster (as is true of its supporting ecosystem). That’s why we have chosen to sunset DC/OS, with an end-of-life date of October 31, 2021. With DKP, our customers get the same benefits provided by DC/OS and more, as well as access to the most impressive pace of innovation the technology world has ever seen. This was not an easy decision to make, but we are dedicated to enabling our customers to accelerate their digital transformations, so they can increase the velocity and responsiveness of their organizations to an ever-more challenging future. And the best way to do that right now is with DKP.
Feb 06, 2015
Dario Rexin
D2iQ
On behalf of the Marathon contributors, we are pleased to announce the availability of Marathon version 0.8.0. Alongside a number of small feature additions, this release focuses on improving the overall performance and stability of Marathon. Below is an overview of the most important feature additions. For a complete overview see the release notes on GitHub.
Deployments can now be stopped
Prior to the 0.7.x series when an app was launched with Marathon, the scheduler would just try to scale it to the expected number of instances. In 0.7.0 we introduced deployments whereby Marathon would monitor the process and visualize the progress of a deployment in the UI. If a deployment didn't finish - e.g. because the apps didn't become healthy or there was not enough capacity in the cluster - there is the ability in versions of Marathon 0.7.x and later to rollback to an older version of the deployment that is known to work. However, sometimes you might just want to cancel a deployment rather than initiate a rollback, so in 0.8.0 we added the ability to cancel a deployment. Be mindful when you cancel a deployment, as the apps affected by the cancelation will stay in the faulty state.
Apps can now have labels
Attaching metadata to apps can be useful to expose additional information to other services, so we added the ability to place labels on apps (for example, you could label apps "staging" and "production" to mark services by their position in the pipeline). The soon to be released Mesos 0.22.0 will also add labels to tasks and the Marathon team will add support for task labels as well with a minor update.
UI now shows the latest state in case of connection loss
Prior to 0.8.0 the web UI would show an error message when it could not fetch the status of an app, but you could not see the app's last known state. In Marathon 0.8.0, we've extended the UI so that it also shows the last known state.
maximumOverCapacity in upgradeStrategy
When you deploy an app, you usually want to keep a certain number of instances alive to process the incoming requests and for that we have the minimumHealthCapacity. In addition to minimumHealthCapacity which makes sure that a given number of instances will always be healthy during a deployment, we've added a new setting, maximumOverCapacity, which allows Marathon to exceed the app's number of instances quota during deployment by the specified factor. Provided you have extra capacity in your cluster maximumOverCapacity can make for faster and more robust deployments because it gives Marathon the ability to ensure all the new instances become healthy before killing the old ones
New endpoint /v2/leader
A new endpoint has been added that allows users to retrieve the current leader by sending a GET, or force the current leader to abdicate its leadership and start a new election by sending a DELETE.
Docker parameters can have multiple values
The representation of Docker parameters in the app JSON has changed to allow for multiple values for a given parameter name.
Optimized task queueing
With the new optimized task queuing behaviour in Marathon it is possible to enqueue huge numbers of tasks without performance degradation.
New option maxLaunchDelay
In addition to the backOffSeconds and backOffFactor it is now possible to configure the maximumLaunchDelay which before had been hard coded to 1 hour.
