From what I understand, Kubernetes/Mesosphere is a cluster manager and Docker Swarm is an orchestration tool. I am trying to understand how they are different? Is Docker Swarm analogous to the POSIX API in the Docker world while Kubernetes/Mesosphere are different implementations? Or are they different layers?
Disclosure: I'm a lead engineer on Kubernetes
Kubernetes is a cluster orchestration system inspired by the container orchestration that runs at Google. Built by many of the same engineers who built that system. It was designed from the ground up to be an environment for building distributed applications from containers. It includes primitives for replication and service discovery as core primitives, where-as such things are added via frameworks in Mesos. The primary goal of Kubernetes is a system for building, running and managing distributed systems.
Swarm is an effort by Docker to extend the existing Docker API to make a cluster of machines look like a single Docker API. Fundamentally, our experience at Google and elsewhere indicates that the node API is insufficient for a cluster API. You can see a bunch of discussion on this here: https://github.com/docker/docker/pull/8859 and here: https://github.com/docker/docker/issues/8781
Swarm is a very simple add-on to Docker. It currently does not provide all the features of Kubernetes. It is currently hard to predict how the ecosystem of these tools will play out, it's possible that Kubernetes will make use of Swarm.
Related
I am new to devops. I want to install jenkins. So out of all options available to install jenkins provided in official documentation which one should I use. I am zeroed on docker or kubernetes. So parameters I am looking for decision are below.
portability - can be installed on any major os or cloud provider.
minimal changes to move to production.
Kubernetes is a container orchestrator that may use Docker as its container runtime. So, they are quite different things—essentially, different levels of abstraction.
You could theoretically run an application at both of these abstraction levels. Here's a comparison:
Docker
You can run an application as a Docker container on any machine that has Docker installed (i.e. any OS or cloud provider instance that supports Docker). However, you would need to implement any operations-related features that are relevant for production, such as health checks, replication, load balancing, etc. yourself.
Kubernetes
Running an application on Kubernetes requires a Kubernetes cluster. You can run a Kubernetes cluster either on-premises, in the cloud, or use a managed Kubernetes service (such as Amazon EKS, Google GKE, or Azure AKS). The big advantage of Kubernetes is that it provides all the production-relevant features mentioned above (health checks, replication, load balancing, etc.) as part of the platform. So, you don't need to implement them yourself but just use the primitives that Kubernetes provides to you.
Regarding your two requirements, Kubernetes provides both of them, while using Docker alone does not provide easy production-readiness (requirement 2). So, if you're opting for production stability, setting up a Kubernetes cluster is certainly worth the effort.
I am evaluating Kubernetes (with Docker containers, not Kubernetes) and Docker Swarm and could use your input.
If I'm looking at 3 (8.76 hours) or 4 (52 min) 9's reliability in a server farm that is < 100 servers, would Kubernetes be overkill due to its complexity? Would Docker Swarm suffice?
Docker swarm will be able to meet your requirements. I recommend you start with Docker swarm as it is robust and very straightforward to use for anyone who has used Docker before.
For a Docker user, there are many new concepts that you need to learn to be able to use Kubernetes. Moreover, setting up Kubernetes on premise without using a preconfigured cloud platform is not straightforward
On the other hand, Kubernetes is more flexible and extensible. Kubernetes is older than Docker swarm and the community for kubernetes community is really big.
It really depends on your real needs, Kubernetes or Swarm orchestrators are not silver bullets. To take real advantage from the container technology, the applications have to be properly designed. A design guideline for these cloud native apps are the Twelve Factor app principles made by Heroku.
In case you want to scale and achieve global scaling, Kubernetes is a great framework to run distributed apps at scale. In case you have a lot of Java apps, maybe containerized traditional applications then Swarm is a best option.
The business requirements can drive you to make the right choice.
Hope this helps!
I read on Rancher Official Page
Rancher is an open source software platform that enables organizations
to run containers in production. With Rancher, organizations no longer
have to build a container services platform from scratch using a
distinct set of open source technologies. Rancher supplies the entire
software stack needed to manage containers in production.
Base on this description, I think Rancher is a container orchestration like docker-compose. But as I read on same page:
Many users choose to run containerized applications using a container
orchestration and scheduling framework. Rancher includes a
distribution of all popular container orchestration and scheduling
frameworks today, including Docker Swarm, Kubernetes, and Mesos.
This paragraph makes me think Rancher is not a container orchestration but something that controls those thing. Please tell me what is the difference between Rancher and other container orchestration.
[Rancher Labs employee]
Basically we are unopinionated about what orchestration system you want to use. Rancher contains our own container orchestration system called Cattle, which has a full UI, API, and supports YAML syntax that matches docker-compose plus additional things not available in compose.
Obviously we like our own but are aware that other choices exist in the ecosystem and many people want to use them. And managing their installations is not a trivial task... so Rancher contains (Cattle) templates for Kubernetes, Mesos, and Swarm.
When you create an environment you choose an orchestration system, and if you pick e.g. K8s we use Cattle to orchestrate the installation and configuration of K8s, plus integrating other Rancher services like access controls, load balancing, etc. You can then use the standard tools like kubectl, their API, or we have a fairly complete custom UI for K8s built-in.
I came across this article http://www.networkworld.com/article/3100383/cloud-computing/the-worlds-of-openstack-and-containers-are-colliding.html. It talks about openstack running atop kubernetes. What does that actually mean? Going by what they do, openstack is more lower level (IAAS) compared to kubernetes (between IAAS and PAAS), as per my understanding.
There are many ways containers and OpenStack are being mixed. The article you quoted refers to a new-ish approach of running OpenStack servers inside containers. The advantage is for maintainability and scalability. Basically, kubernetes is in charge of orchestrating the various pieces that make an OpenStack service, instead of the more general approach of installing OpenStack services on bare metal or VM (see TripleO).
Recently some alternatives for running docker containers or even the app container have developed.
I know that there is rkt from coreos (https://coreos.com/blog/rocket/) and triton from joyent (https://www.joyent.com/)
How do these two approaches compare?
Edit
Maybe I should re-phrase my question after these good comments from # Lakatos Gyula
How does Triton compare to coreos or kubernetes for running docker-containers at scale?
So in a way, this is an apples to oranges to grapes comparison. CoreOS is an operating system, Kubernetes is open source container orchestration software, and Triton is a PaaS.
So CoreOS, it's a minimal operating system with a focus on security. I've been using this in production for several months now at work, haven't found a reason to not like it yet. It does not have a package manager, but it comes preinstalled with both rkt and Docker. You can run both docker and rkt just fine on there. It also comes with Etcd, which is a distributed key-value store, and it happens that kubernetes is backed by it. It also comes with Flannel which is a networking program for networking between containers and machines in your cluster. CoreOS also ships with Fleet, which you can think of like a distributed version of systemd, which systemd is CoreOS' init system. And as of recently, CoreOS ships with Kubernetes itself.
Kubernetes is a container orchestration software that is made up of a few main components. There are masters, which use the APIServer, controller and scheduler to manage the cluster. And there are nodes which use the "kubelet" and kube-proxy". Through these components, Kubernetes schedules and manages where to run your containers on your cluster. As of v1.1 Kubernetes also can auto-scale your containers. I also have been using this in production as long as I have been using CoreOS, and the two go together very well.
Triton is Joyent's Paas for Docker. Think of it like Joyent's traditional service, but instead of BSD jails (similar concept to Linux containers) and at one point Solaris Zones (could be wrong on that one, that was just something I heard from word of mouth), you're using Docker containers. This does abstract away a lot of the work you'd have to do with setting up CoreOS and Kubernetes, that said there are services that'll do the same and use kubernetes under the hood. Now I haven't used Triton like I have used Kubernetes and CoreOS, but it definitely seems to be quite well engineered.
Ultimately, I'd say it's about your needs. Do you need flexibility and visibility, then something like CoreOS makes sense, particularly with Kubernetes. If you want that abstracted away and have these things handled for you, I'd say Triton makes sense.