Kubernetes and CoreOS looks like a pretty good strategy for deploying in a cloud env. I'd be interested to see how this might work with the Fleet strategy that is part of CoreOS.
fleet is a cluster-level init system with just enough of a scheduler to handle the fault tolerance of higher-level components (i.e. log aggregation, scheduling, etc). In this case, Kubernetes can be thought of as an application-specific scheduler, as it nontrivially places containers in a cluster. Kubernetes can schedule its containers through fleet's APIs and trust fleet to track the overall state of the cluster.
Would that be valuable though? As described now, it appears that kubernetes just replaced fleet, and seems to do work well. What would be arguments to keep fleet under the hood?
Kubernetes is exactly what I've been needing to ease our deployments; combining CoreOS and Kubernetes looks like a dream come true!
I agree, this seems like it has very strong potential. We are going to give it a whirl for sure!
I think this ingredient will change how a big part of the cloud interoperability problem can be approached. Once you only have to manage a few, relatively static set of VMs, and let kubernetes provide both the API and the scheduler for actually running services, it will become easier to just run your stuff on aws, azure and gce.
CoreOS brings to the table the ability to run on bare metal in a manner such that is just as easy to update the underlying OS on metal as it is to re-provision an updated VM in cloud.
Kubernetes will be great for organizing my related containers. It's great to see workflows for running on other platforms besides GCE. I look forward to the rest of the articles in this series.
Cool! the next step would be to make it part of a CoreOS image
so that you can roll out kubernetes updates the CoreOS way.
I wonder if there is an easy way to maintain a customized image of CoreOS.
For the next post I'm thinking about using containers and cloud-config to set up all the Kubernetes components. That would make it easy to do everything the "CoreOS" way.
And please don't forget volume persistency... and maybe sharing those across a couple of containers.
This might get me to split up my containers better, they're getting a little pudgy. Looking forward to part 2 for more in-depth examples with multiple containers.