istio An open platform to connect, manage, and secure micro-services looks very interesting, but supports only Kubernetes. I couldn't find a roadmap or mention of future support for other container management platforms, specifically Docker Swarm
The project's github site does state the following explicitly:
Istio currently only supports the Kubernetes platform, although we
plan support for additional platforms such as Cloud Foundry, and Mesos
in the near future.
I don't know about the plans for Docker Swarm however I believe it probably would figure in the plans.
The roadmap at https://istio.io/docs/reference/release-roadmap.html shows that VM support is planned for 0.2
You can see that work is happening in the Cloud Foundry world when you see issues such as this.
The docker team indicated recently they are very interested in looking at istio and docker swarm integration so stay tuned this may happen in the next few quarters before you know it :)
Related
I'm using docker on a bare metal server. I'm pretty happy with docker-compose to configure and setup applications.
Still some features are missing, like configuration management and monitoring maybe there are other solutions to solve this issues but I'm a bit overwhelmed by the feature set of Kubernetes and can't judge if it would help me here.
I'm also open for recommendations to solve the requirements separately:
Configuration / Secret management
Monitoring of my docker hostes applications (e.g. having some kind of dashboard)
Remot container control (SSH is okay with only one Server)
Being ready to scale my environment (based on multiple different Dockerized applications) to more than one server in future - already thinking about networking/service discovery issues with a pure docker-compose setup
I'm sure Kubernetes covers some of these features, but I have the feeling that it's too much focused on Cloud platforms where Machines are created on the fly (since I only have at most few bare metal Servers)
I hope the questions scope is not too broad, else please use the comment section and help me to narrow down the question.
Thanks.
I think the Kubernetes is absolutely much your requests and it is what you need.
Let's start one by one.
I have the feeling that it's too much focused on Cloud platforms where Machines are created on the fly (since I only have at most few bare metal Servers)
No, it is not focused on Clouds. Kubernates can be installed almost on any bare-metal platform (include ARM) and have many tools and instructions which can help you to do it. Also, it is easy to deploy it on your local PC using Minikube, which will prepare local cluster for you within VMs or right in your OS (only for Linux).
Configuration / Secret management
Kubernates has a powerful configuration and management based on special objects which can be attached to your containers. You can read more about configuration management in that article.
Moreover, some tools like Helm can provide you more automation and range of preconfigured applications, which you can install using a single command. And you can prepare your own charts for it.
Monitoring of my docker hostes applications (e.g. having some kind of dashboard)
Kubernetes has its own dashboard where you can get many kinds of information: current applications status, configuration, statistics and many more. Also, Kubernetes has great integration with Heapster which can be used with Grafana for powerful visualization of almost anything.
Remot container control (SSH is okay with only one Server)
Kubernetes controlling tool kubectl can get logs and connect to containers in the cluster without any problems. As an example, to connect a container "myapp" you just need to call kubectl exec -it myapp sh, and you will get sh session in the container. Also, you can connect to any application inside your cluster using kubectl proxy command, which will forward a port you need to your PC.
Being ready to scale my environment (based on multiple different Dockerized applications) to more than one server in future - already thinking about networking/service discovery issues with a pure docker-compose setup
Kubernetes can be scaled up to thousands of nodes. Or can have only one. It is your choice. Independent of a cluster size, you will get production-grade networking, service discovery and load balancing.
So, do not afraid, just try to use it locally with Minikube. It will make many of operation tasks more simple, not more complex.
I'm interested in getting started with Kubernetes, but my needs are simple and it does not look simple. I have a number of containerized applications that I deploy to container servers. I use nginx as a reverse proxy to expose these applications.
As far as I can tell, Kubernetes is meant to simplify management of setups like this. But I'm not sure the setup investment is worth it, given that I only realistically need one instance of each app running.
What is the simplest reasonable Kubernetes setup that I can deploy a few containerized applications to?
EDIT: If I start using Kubernetes, it will be using only on-site servers. The applications in question are ones I’ve developed for my employer, who requires that everything stays on-site.
On developers machine; you should use minikube.
On Azure / Google / Amazon ..etc; you should use managed kubernetes services
On Prem you should deploy kubernetes with on your own setup.
3.1. https://github.com/kelseyhightower/kubernetes-the-hard-way
3.2. with kubeadm
3.3 with ansible scripts like kubespray
If you choose kubeadm installation,while you are upgrading kubernetes cluster, again you should use kubeadm again. Best way to deploy on prem is using kubeadm, kube-spray or automating it with Pivotal's Bosh scripts
As you want to get started with Kubernetes, I assume that you want to set-up for your local development, I think that minikube is a best candidate for this purpose. You can also take a look at interactive tutorials from official Kubernetes website, I find it very helpful.
Take a look at this opinionated cluster setup k8s-snowflake and deploy it somewhere like Azure, or Google Compute.
It's a great exercise to figure out how kubernetes clusters work at a low level, but when you're ready to go to production, take a look at Google's Container Engine or AWS Elastic Container Engine. These ease the management of clusters immensely and exposes all the other benefits of the cloud platform to your kubernetes workloads.
Well according to previous answers you should start with minikube on your machine.
Regarding the futher dev/test/staging/prod deployment it depends. There are a couple of solutions:
use clusters provided by Google, Azure or AWS (AWS EKS is not ready yet - https://aws.amazon.com/eks/)
the hard way - setup own cluster or EC2 machines or similar
use tools like Rancher - some additional abstration over k8s for easy start, from version 2.0 k8s will be default mechanism orchiestration for Rancher
Update 31-01-2018:
regarding the hard way - there are of course some tools which helps with that approach like helm
The Kubernetes docs provide an excellent page to choose between the different options to setup kubernetes. The page is found under Picking the Right Solution.
If you want a simple way for setting a kubernetes cluster on premise, check kubeadm.
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 am interested in installing OpenStack to a couple of physical we have lying around, and then, somehow, deploying CloudFoundry on top of of it, as the PaaS.
I am also interested in playing around with Docker and CoreOS, and see that an integration between OpenStack and CoreOS already exists.
My question: if I have OpenStack/Nova spinning up VMs running CoreOS, and hence be Docker/container-based, will this be compatible with CloudFoundry, or is CloudFoundry somehow incompatible with Docker containers?
Cloud Foundry is installed using a specialised tool called Bosh. It has support for Openstack and I think would require deployment using Ubuntu VMs (open to correction on this point). Cloud Foundry has not integrated Docker yet, that is coming in the next version, google "Cloud Foundry" and "Diego".
maybe I'm not fully understanding here, but I was under the impression
that containers can't just stand on their own. They would require
living inside a VM. So my thinking/hope was that I could use
CloudFoundry to spin up VM instances, and inside those instances,
deploy containers. Thoughts?
Containers are completely standalone, they are a form of lightweight virtualization. Cloud Foundry is a platform for deploying your application. It runs on virtual machines (or physical servers) and instances of your application are compiled and run on the CF hosts within containers. Currently the container tech used by CF is something called Warden. Diego is a new CF component coming in 2015 that will offer Docker support.
then what is the difference between CF Diego and Kubernetes, which
also seems to be about deploying/distributing your container across
pools of nodes? Do they serve different, similar or identical
purposes? In other words, would there be a use case for having both CF
Diego and Kubernetes managing your app deployments, if so, what?
Kubernetes is a Google sponsored project for orchestrating containers across multiple hosts. Cloud Foundry goes further because it also contains features for building and versioning applications that are deployed. It's worth noting that Redhat have a competing PAAS solution called Openshift. The next version (already available in github) has integrated Kubernetes and added in all the missing application build support, making it comparable to what Cloud Foundry offers. Both CF Diego and Openshift V3 are due for delivery sometime in 2015.
Update
I see from your other questions, you're familiar with Camel. You'd be interested in the fabric8 framework which has recently integrated Openshift V3. (Fabric is the upstream project for the JBoss Fuse product)
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.