5 ms·

Kubernetes != virtualization Some virtualization use cases can be solved with kubernetes, but many things an enterprise runs do not work at all in the kube par

by hueving 10y ago

Kubernetes != virtualization Some virtualization use cases can be solved with kubernetes, but many things an enterprise runs do not work at all in the kube paradigm. The majority of applications are pets (i.e. stateful) and many applications run on Windows or have some other kernel requirements that mismatch the baremetal kubelet. If you think Kubernetes 'absolutely takes over the more complex cloud installations', you're living in an echo chamber of 12 factor apps that doesn't line up with the majority of what I've seen in big enterprise cloud workloads. Case in point: Walmart has one of the largest openstack deployments in the world.

maloney 10y ago
Have you checked out pet sets[1]? The last couple of kube releases have introduced some really nice work to help with these cases [1]http://kubernetes.io/docs/user-guide/petset/ http://kubernetes.io/docs/user-guide/petset/
- tmzt 10y ago
  Does this fit in with hyperkube in some way? Can you see 'pods' that are really complete VM's which may or may not include OCI containers on them. For instance, would a complete Windows Server instance fit the Pet Set concept in the scheduler?
  - 101km 10y ago
    Nothing to do with hyperkube. PetSets are simply ordinally ordered container collections instead of randomly ordered. The usual concept in Kubernetes is that a container has a name like 'thing-randomsuffix4242'. It is pushing you towards making your pods stateless and not precious so the failure handing logic is simple. If it is blown away for whatever reason can easily be replaced by the scheduler and 'thing-randomsuffix242b' is never far away. With a predictable ordering you can actually make assumptions you otherwise couldn't. For example, perhaps you want the convention that 'thing-predictable1' is the master and 'thing-rpredictable{2,3}' are the slaves.
  - sandGorgon 10y ago
    hyperkube is just a repackaging of all the different packages of k8s as a single binary. so rather than 'kubectl -v', you will run 'hyperkube kubectl -v'
    - tmzt 10y ago
      Closer to minikube then? That was not at all clear to me from reading the site, where it seemed to be discussing a kubelet on an OS on bare metal or hypervisor, but not managing containers.
- paultyng 10y ago
  For development environments we are running MSSQL (yes that MSSQL, unclustered though as there is no SAN emulation of course), Elasticsearch, Mongo, Kafka, Zookeeper, Redis, Memcached, all in Kubernetes (mostly as Pet Sets) and looking to possibly do this in prod once we are happy with it. The story for state in Kubernetes is improving rapidly. Edit: You can find Helm charts here: https://github.com/kubernetes/charts/tree/master/incubator https://github.com/kubernetes/charts/tree/master/incubator
majewsky 10y ago
We (SAP's internal cloud platform) are running OpenStack on Kubernetes. In particular, I'm working on containerizing Swift, which presents its unique set of challenges, but is progressing well regardless. We had a talk at the OpenStack Summit about how we do OpenStack on Kubernetes, if you're interested: https://www.openstack.org/videos/video/cisco-containerization-of-openstack-services-at-cisco-and-sap-to-gain-operational-advantage https://www.openstack.org/videos/video/cisco-containerizatio...

by hueving 10y ago

maloney 10y ago

Have you checked out pet sets[1]? The last couple of kube releases have introduced some really nice work to help with these cases [1]http://kubernetes.io/docs/user-guide/petset/ http://kubernetes.io/docs/user-guide/petset/

tmzt 10y ago
Does this fit in with hyperkube in some way? Can you see 'pods' that are really complete VM's which may or may not include OCI containers on them. For instance, would a complete Windows Server instance fit the Pet Set concept in the scheduler?
- 101km 10y ago
  Nothing to do with hyperkube. PetSets are simply ordinally ordered container collections instead of randomly ordered. The usual concept in Kubernetes is that a container has a name like 'thing-randomsuffix4242'. It is pushing you towards making your pods stateless and not precious so the failure handing logic is simple. If it is blown away for whatever reason can easily be replaced by the scheduler and 'thing-randomsuffix242b' is never far away. With a predictable ordering you can actually make assumptions you otherwise couldn't. For example, perhaps you want the convention that 'thing-predictable1' is the master and 'thing-rpredictable{2,3}' are the slaves.
- sandGorgon 10y ago
  hyperkube is just a repackaging of all the different packages of k8s as a single binary. so rather than 'kubectl -v', you will run 'hyperkube kubectl -v'
  - tmzt 10y ago
    Closer to minikube then? That was not at all clear to me from reading the site, where it seemed to be discussing a kubelet on an OS on bare metal or hypervisor, but not managing containers.
paultyng 10y ago
For development environments we are running MSSQL (yes that MSSQL, unclustered though as there is no SAN emulation of course), Elasticsearch, Mongo, Kafka, Zookeeper, Redis, Memcached, all in Kubernetes (mostly as Pet Sets) and looking to possibly do this in prod once we are happy with it. The story for state in Kubernetes is improving rapidly. Edit: You can find Helm charts here: https://github.com/kubernetes/charts/tree/master/incubator https://github.com/kubernetes/charts/tree/master/incubator

majewsky 10y ago

We (SAP's internal cloud platform) are running OpenStack on Kubernetes. In particular, I'm working on containerizing Swift, which presents its unique set of challenges, but is progressing well regardless. We had a talk at the OpenStack Summit about how we do OpenStack on Kubernetes, if you're interested: https://www.openstack.org/videos/video/cisco-containerization-of-openstack-services-at-cisco-and-sap-to-gain-operational-advantage https://www.openstack.org/videos/video/cisco-containerizatio...