If it isn't good, why?
In another words, what's the different from original Kubernetes?
IMO using Kubernetes with Rancher is a great idea. I'm managing the rancher instances at my company and we'll move from Cattle to Kubernetes for several reasons:
Kubernetes
- Now widely used
- Open source
- Big companies supports its development
- RANCHER 2.0 WILL BE BUILT FOR KUBERNETES FIRST
I strongly recommand you to use Kubernetes if you plan to use Rancher.
Related
I'm planning to deploy a small Kubernetes cluster (3x 32GB Nodes). I'm not experienced with K8S and I need to come up with some kind of resilient SQL database setup and CockroachDB seems like a great choice.
I wonder if it's possible to relatively easy deploy a configuration, where some CockroachDB instances (nodes?) are living inside the K8S cluster, but at the same time some other instances live outside the K8S cluster (2 on-premise VMs). All those CockroachDB would need to be considered a single CockroachDB cluster. It might be also worth noting that Kubernetes would be hosted in the cloud (eg. Linode).
By relatively easy I mean:
simplish to deploy
requiring little maintenance
Yes, it's straight forward to do a multi-cloud deployment of CRDB. This is one of the great advantages of cockroachdb. Simply run the cockroach start command on each of the VMs/pods running cockroachdb and they will form a cluster.
See this blog post/tutorial for more info: https://www.cockroachlabs.com/blog/multi-cloud-deployment/
I have 2 namespaces in my kubernetes cluster: development and production. I'm currently adding a third namespace: staging.
I'm NOT using terraform with which this task would have been supposedly simpler.
I'm looking for solutions within the GCP ecosystem to provision a workload in the staging namespace with all the environment variables and configurations of the development namespace.
Please check my answer to similar question here. Unfortunately there is no ready solution for that within GCP, especially if you want to migrate workload from the existing cluster between different namespaces. However you can use for that purpose Heptio Velero. It's nicely described in this article.
I am trying to install kubernetes on Self-hosted production environment running on Ubuntu 16.04. I am not able to find any helpful guide to setup production grade kubernetes master and connect worked nodes to it.
any help is much appreciated.
you can use the kubespray to self Host production environment.
https://github.com/kubernetes-incubator/kubespray
Depends on what you understand by saying "self-host". The most people think it's about deploying kubernetes in the own environment.
If you want to compare different approaches to deploy k8s in a custom environment, refer to this article which covers a bunch of options suitable for that.
If you are interested in how to set up an HA Kubernetes cluster using kubeadm, refer to this article.
However, in kubernetes, there is a different definition of "self-hosted". It means running kubernetes itself as a workload in kubernetes. If you are interested in a real self-hosted approach (on a custom environment), refer to this article
Hope this helps
You can use typhoon which can be used to provision an HA kubernetes cluster.
Here is a sample configuration which I used to bring up my own home cluster.
A few advantages of typhoon are that you have the option of choosing your choice of a cloud provider for provisioning your infrastructure, which is done using terraform and the fact that it gives you upstream k8s is a big plus too.
Internally, it uses bootkube to bring up the temporary control plane, which would consist of
api-server
controller-manager
scheduler
and then when we have the temporary control plane object, we inject the objects to the API server to have our k8s cluster.
Have a look at this kubecon talk given by CoreOS which explains how this is working.
I'm trying to dig into Rancher, and was wondering if having Rancher plugged in with Kubernetes has any additional benefits over Cattle which is Rancher's in home orchestration framework. So far, I haven't been able to figure out why someone would opt for Rancher with Kubernetes. Does it only help ease out the initial setup of Kubernetes? How do these options differ from a stand alone setup of Kubernetes ?
There is now a very good answer to this. Rancher just moved 100% into Kubernetes by announcing Rancher 2.0: http://rancher.com/announcing-rancher-2-0/. It does not use Cattle anymore.
After 1+ year of using Rancher + Cattle and Kubernetes in production simultaneously, I can share some personal observations, but first let me share some thoughts on Kubernetes vs Rancher + Cattle:
Kubernetes is astonishingly flexible and designed to be extendable. There are two pillars on which Kubernetes cluster stands - kube-apiserver as a main unit and etcd as a storage. Other basic components are vital for a cluster, but they were designed to use kube-apiserver's API as any Kubernetes extension should. You can design your cluster the way you need, use different network providers, authentication/authorization services, volume providers and substitute almost every component in cluster - and if configured correctly your extended Kubernetes cluster will be more stable than basic Cattle cluster in almost any case, not speaking of Cattle extensions.
Kubernetes has a lot of useful out-of-the-box features for persisting your data, keeping your data secret and control access to it. This is important part, rancher-nfs is quite fragile, moreover, NFS-storage is the only more or less stable option you have in Cattle to keep volumes, not mentioning local storage.
Kubernetes is an overkill for non-frequent deployments and development in a small team. No doubts, Cattle has been created as a simple clone of Kubernetes and has inherited its basic concepts of namespaces, pods, scheduling, etc., yet making it very easy to deploy and maintain a cluster, making it useful for developers with no understanding of containerisation and networking. Due to its simplicity it became pretty unusable for heavy and dynamically changing production projects.
Kubernetes community is growing fast, being supported by cloud providers and by uncountable number of open-source project and startups, so it's wiser to learn Kubernetes than Cattle, which is one foot in grave now.
And finally - Cattle is unstable, very unstable. Especially if you plan to use it with bare metal. Believe me, you don't want to use Cattle in production.
And speaking about Rancher + Kubernetes tied together - it's a very nice combination, Rancher web UI makes Kubernetes concepts simpler in a good way, cluster maintenance and provisioning become much easier, but there's always some "buts": Rancher 2.0 is very unstable, too, bugs make it unusable for production now. Can't say anything about Rancher 1.x + Kubernetes.
In our experience,
Cattle is just a toy. It's just suit for development or some small environment. If you used Cattle in PROD, you will know what I say.
But Rancher is far more concise and simple than k8s.
So I'm looking forward to the Rancher 2.0,
Rancher 2.0 is a complete container management platform built on Kubernetes
rancher v2 is more complicated as ks8 is complicated but its contain great features to manage containers ,for pros and cons between cattle rancher v1 and ks8 rancher v2 here some of most important differences :
1- rancher v1 cattle is more like docker-compose than modern orchestration tools and lack of support new storage drivers or real high available loadbalancer approach like ingress in ks8.
2- rancher v1 have great community catalogs that make create of high available services lots more easy but its kind of tricky to resolve problems that can happen.
3 - rancher v2 support community catalogs and helm but need more contribution to become stable and great as v1 was but k8s instead is completely stable and using kubectl to manage pods and resources is easy.
my opinion is use rancher v2 if you want to start docker orchestration , ks8 have great cli tools but when you need upgrade container or change configuration rancher web gui can help effectively.
Kubernetes 1.2:
How do you bootstrap a second master for an HA configuration?
Can you use kube-up?
The HA doc doesn't really get into that:
https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/admin/high-availability.md
Thanks
There aren't any automated scripts (like kube-up.sh) checked into the Kubernetes github repository that will create an HA cluster; you will need to understand the intricacies of building a cluster (many of which are described in the Creating a Custom Cluster from Scratch guide) and build an HA cluster from scratch or modify a "normal" cluster to make it into an HA configuration.
If you are interested in helping contribute to developing better tools for HA masters, you can join the Kubernetes High Availability special interest group.
kops (https://github.com/kubernetes/kops) is able to provision HA Kubernetes with multiple masters: https://github.com/kubernetes/kops/blob/master/docs/commands.md#other-interesting-modes
AFAIK some more upcoming work is being done in k8s 1.5 and 1.6
Some other platforms based on kubernetes supports multiple masters.
For example, Openshift origin support setup cluster with multiple masters and on load balance.
However, Openshift built some customized solutions into kubernetes. Currently k8s couldn't be decoupled from Openshift gracefully.
Personally speaking, I also prefer multiple masters configuration for HA.