Kubernetes was not written for docker clustering alone. It uses a different API, configuration and different YAML definitions. So you can't use the Docker CLI or Docker Compose to define your containers. Everything has to be done from scratch.
Kubernetes was built on top of several years of experience from Google working on containers in production. It's a little opinionated on how containers should work and behave, but if used correctly it can help you achieve fault-tolerant systems.
Almost everything in Kubernetes is designed to handle if parts of it fail or if your service crashed for whatever reason. So it's particularly adapted if you've a cluster (even a very small one).
Kubernetes works very well with modern environments (such as CoreOS or Red Hat Atomc) which offer lightweight computing nodes that you don't have to manage, since they are managed for you.
Kubernetes is currently supported by Google Compute Engine, Rackspace, Microsoft Azure, and vSphere. Work is being done to support Kubernetes on OpenShift and CloudFoundry.
Kubernetes uses labels which are key-value pairs that are attached to objects, usually pods. They are used to specify the characteristics of an object like the version, tier, etc. Labels are used to identify objects or groups of objects according to different characteristics that they may have, for example they can be used to identify all the pods that are included in the backend tier.
Through labels it's easier to do grouping tasks for pods or containers, like moving pods to different groups or assigning them to load-balanced groups.
Windows compatibility rules, the host OS version must match the container base image OS version. Only Windows containers with Windows Server 2019 are supported. Also other restrictions are present.
Because of how opinionated Kubernetes is, it may be necessary to change some things if you decide to use Kubernetes as an orchestration tool in an existing application.
Kubernetes great for beginners who are just starting to work on clustering. It's probably the quickest and easiest way to start experimenting and learning cluster oriented development.
It happens that a Pod needs a manual kick before it runs properly, especially if you're near full utilisation of your machine resources. Sometimes it is just a long delay.
Kubernetes is here to stay. Top tech giants seemt to have agreed to cooperate around the base technology and compete on higher level tools.
Recent CNCF's announcement with Top tech companies (like Google, Red Hat, CoreOS, FathomDB, ZTE Corporation, Huawei, IBM, Microsoft, Fujitsu, and Mirantis.) agreeing to a Kubernetes Certification standard is a major step towards having a dominant cloud agnostic Container Orchestration platform (and no fear or forks in the near-term).
This also means that containers can be launched with a simple docker run command and Swarm will take care of the rest, such as selecting the appropriate host on which to run the container.
Since Docker Swarm is a native Docker tool, it exposes the Docker API, making it possible t integrate it and communicate with other Docker tools (CLI, Compose, Krane, etc.).
Docker Swarm is much more lightweight than alternatives: Kubernetes and Mesosphere. Kubernetes, for instance, is very complex - it downloads and installs half of the web, where Docker Swarm has much, much smaller footprint.
If the Docker API doesn't support something, then you are pretty much out of luck when it comes to Docker Swarm, because it won't be supported by Swarm either.
Being focused on one thing only also has its advantages. For one, Nomad is very simple architecturally. There's only a single binary for both clients and servers, it also does not need any external services for any coordination or storage.
Nomad uses a high-level abstraction of jobs. Jobs are essentially task groups (sets of tasks). Because of this, Nomad allows users to develop and manage complex applications easily, without having to think about the individual containers that make these applications.
While other orchestration tools provide much more than just cluster management and scheduling (they also provide things like secrets management, discovery, monitoring, etc.), Nomad follows the Unix philosophy of doing only one thing and doing it well, providing only cluster management and scheduling.
All that's needed to setup a multi-container application with Compose is a single file configuration file. Finally the application can be spun up with only a single command.
Docker-compose isn't really meant (yet) for distributed deployment, but using it to deploy a website locally for testing is awesome. You could use it, with care (like handling faults), on a single server as well.
While Compose is very good for staging servers, CI and development environments, it's still not ready for production and it's not recommended to be used in production yet.
Great contributions from the co community who build the service stack catalog.
One of them is the "Prometheus" template which deploys a collection of containers for monitoring a platform. It's capable of querying all aspects of your environment with some nice pre-built dashboards.
I love Rancher's UI and feature set, but there's something ironic about a service designed to make it wasy to run k8s clusters, which needs k8s or k3s to run on!
Not working with the newest docker (and composer) versions.! I only use the latest stable or beta (for testing) software on a local machine. Rancher was and is producing a lot of irritating messages or errors.
Not working with the newest docker (and composer) versions.! I only use the latest stable or beta (for testing) software on a local machine. Rancher was and is producing a lot of irritating messages or errors.
Learning to use OpenShift is pretty easy. Most environments can be set up in a few simple steps and for everything else the official documentation and third-party resources are extremely helpful.
Because of its high flexibility and customization power, OpenShift can be used to create specialized tasks for the application being hosted on it. For example, an entire array of dynos (also known as gears) can be dedicated to media transcoding in order to build a custom media converter infrastructure.
OpenShift seems to rely more on written documentation and on the community to solve any problem users may have. The forums and IRC channel are active and very helpful, but the official customer support could be better.
Mesos handles (HA) master or agent failover; Marathon HA can survive scheduler failover; and Marathon automatically restarts failed tasks to maintain the desired number of task instances.