> K8s does not really work that way. It's huge and it's heavy, and it expects every app to be written it's way.
I disagree. Kubernetes is quite lightweight, and its architecture is nicely modular. The core of Kubernetes is just four daemons. You can also deploy most of its processes on Kubernetes, which greatly eases the operational side.
> and it expects every app to be written it's way.
Kubernetes makes zero assumptions about how an app is written, as long as it can run as a Docker (or rkt) image.
It imposes certain requirements, such as that pods are allocated unique IP addresses and share networking between containers, but that doesn't really impact how apps are written.
> K8s is a trojan for Google Cloud
Doubt it very much. For one, the Kubernetes experience on GCloud (GKE) isn't particularly good at all — the "one click" setup uses the same Salt ball of spaghetti that kube-up.sh uses, the upgrade story isn't great, alpha/beta features are disabled, you can't disable privileged containers, ABAC disabled, the only dashboard is the Kubernetes Dashboard app (which is still a toy), and GCloud still doesn't have internal load balancers. Setting it up from scratch is preferable, even on GCE.
Additionally:
* Kubernetes has excellent support for AWS as well as technologies such as Flannel for running on providers with less flexible networking.
* Google makes a lot of effort to help you to set it up on other providers (also see kube-up).
* Projects like Minikube let you run it locally.
If Kubernetes is a "trojan" of anything, it's to improve the containerization situation generally, because this is an application deployment model where they can compete with AWS, which doesn't have a good container story at all (ECS is pretty awful).
The arguably whole reason Google is sponsoring K8S is to promote GCE and GKE. It's their main long term game play vs. AWS (moving the world to containers instead of VMs).
I disagree. Kubernetes is quite lightweight, and its architecture is nicely modular. The core of Kubernetes is just four daemons. You can also deploy most of its processes on Kubernetes, which greatly eases the operational side.
> and it expects every app to be written it's way.
Kubernetes makes zero assumptions about how an app is written, as long as it can run as a Docker (or rkt) image.
It imposes certain requirements, such as that pods are allocated unique IP addresses and share networking between containers, but that doesn't really impact how apps are written.
> K8s is a trojan for Google Cloud
Doubt it very much. For one, the Kubernetes experience on GCloud (GKE) isn't particularly good at all — the "one click" setup uses the same Salt ball of spaghetti that kube-up.sh uses, the upgrade story isn't great, alpha/beta features are disabled, you can't disable privileged containers, ABAC disabled, the only dashboard is the Kubernetes Dashboard app (which is still a toy), and GCloud still doesn't have internal load balancers. Setting it up from scratch is preferable, even on GCE.
Additionally:
* Kubernetes has excellent support for AWS as well as technologies such as Flannel for running on providers with less flexible networking.
* Google makes a lot of effort to help you to set it up on other providers (also see kube-up).
* Projects like Minikube let you run it locally.
If Kubernetes is a "trojan" of anything, it's to improve the containerization situation generally, because this is an application deployment model where they can compete with AWS, which doesn't have a good container story at all (ECS is pretty awful).