We were lucky enough in December 2014 to join the group of teams who use CoreOS stack and Kubernetes on their way to become next generation of cloud infrastructure. It has been almost one year so I'd like to provide a article series about our experience with the whole stack.
The distributed computing is one of most challenging disciplines in the computer science. Why is that? Because of an asynchronicity in the form of remote calls among distributed components. There are no locks like in your favorite languages. However, there are remote calls with no guarantees of any response or in any time.
It's pretty challenging to provide high-available application, with no downtime during updates, crashes. The application which scales according to the needs. The application with guarantees any data consistency.
What are typical questions and considerations when you start to build such app?
Here is a link to the whole series.
The Motivation
You usually want to model your business domain, provide useful APIs, break your application into pieces, services, and so on. Well, it's your work.The distributed computing is one of most challenging disciplines in the computer science. Why is that? Because of an asynchronicity in the form of remote calls among distributed components. There are no locks like in your favorite languages. However, there are remote calls with no guarantees of any response or in any time.
It's pretty challenging to provide high-available application, with no downtime during updates, crashes. The application which scales according to the needs. The application with guarantees any data consistency.
What are typical questions and considerations when you start to build such app?
- how can I run exactly 3 instances of a service in my app?
- how can I detect that some instance failed?
- how can I run a new replica instead of dead one?
- what if there are more than 3 instances because the dead replica was not so much dead and it's now back in the cluster?
- what if there are two replicas - dead one and new one - which process same part of the data?
- how can I guarantee that all replicas can see the same configuration?
- where can service B discover a link to running service A?
- where can service B discover new instance of service A because the first one failed?
- how can I install all that mess to one operating system?
CoreOS stack and Kubernates provide well tested but tiny platform for your cluster/cloud infrastructure. You can focus on your business not on the infrastructure.
Components
Here is a diagram how all tools fits together:
- CoreOS :It's just very simple linux distribution prepared for cluster/cloud deployment.
- Fleet is responsible for running units (services) on remote nodes
- Etcd is distributed key value store using Raft consensus. The purpose is to store the configuration in namespaces. I've already wrote some articles about etcd
- Flannel allows to provide private networking among nodes - or docker container in this case
- Kubernetes uses all tools together to provide cluster management. You can describe your application via kubernetes descriptors and use kubectl or REST API to run, scale or fail-over your app. Obviously in cooperation with the application. One can say that it's PaaS for dockerized application. And (s)he would be right.
What should I read to become more familiar with all these?
- look into the documentation for the CoreOS
- there are tons of topics in the latest doc, cluster setup, installation, cloud configs etc.
- fleet documentation
- etcd docs
- flannel does (private) networking
- here is nice description of all components together
- watch videos from Kubernetes launch
- try to understand and learn how to manage systemd
- journalctl can show you log messages for every unit (process) managed by systemd
If you would have only 30 minutes check out this video:
What's next?
I'd like to write article series about our experience with CoreOS and Kubernetes. I'd like to deal with the installation in next article.Here is a link to the whole series.
Comments