Deploying Distributed Databases and In-Memory Computing Platforms with Kubernetes

Editor's Notes

• #2: Thank you open stack Thanks for coming Good to be in berlin… museum of technology, Konrad Zeus, Z1 programmable computer
• #3: The buzzfeed version: the three tricks you need to install a compute/data grid using Kubernetes… the third will amaze you! But first, let’s define some terms.
• #4: You know what kubernetes is… but what about in-memory compute platforms? We’re going to be talking about Ignite, but there are others that are similar
• #5: Let’s dig down into what that really means and what it means for Kubernetes
• #7: Lots of nodes That all need to be able to find each other Share configuration Non-shared storage (even memory only config not all nodes are fungible, but for persistence for logs, for persistent data) Dynamically add/remove nodes – without affecting the data!
• #9: Traditionally you’d have one or more ”compute” pods (MySQL) plus some fixed disk That would kinda work for Ignite but missing the point Also, scale horizontally… all nodes equal (no master) but in charge of different data… so not equal! But no master means they need to be able to find each other
• #10: Kubernetes already knows about nodes (pods) All we need is a little glue to link them together
• #11: apiVersion: v1kind: Servicemetadata:  name: ignite namespace: ignitespec: type: LoadBalancer ports: - name: rest port: 8080 targetPort: 8080 - name: sql port: 10800 targetPort: 10800 - name: thinclients port: 10900 targetPort: 10900 selector: app: ignite
• #12: <bean class="org.apache.ignite.configuration.IgniteConfiguration"> <property name="discoverySpi"> <bean class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi"> <property name="ipFinder"> <bean class=” org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder"> <!-- Assumed that RBAC is configured for `ignite` namespace. --> <property name="namespace" value="ignite"/> </bean> </property> </bean> </property></bean>
• #13: kubectl create configmap ignite-config --from-file=example-kube.xml
• #15: In-Memory Use Case:  in-memory caches, in-memory data grids, in-memory computations, web-session caching, real-time processing of continuous data streams. 100% on Disk + In-Memory Cache – ideal for HTAP because it doesn’t make sense to store analytical data sets in RAM or raw data for ML/DL models.
• #16: Example here just uses a deployment, you might prefer be explicit about using a ReplicaSet Singleton instance like MySQL (persistent volume, MySQL pod, service) ReplicaSet – “should be used when your application is completely decoupled from the node” “every container is identical and replaceable” (which is true for memory-only but not for persistent) DaemonSet – “should be used when a single copy of your application must be run on all or a subset of nodes in the cluster” Dynamic Volume Provisioning (with Azure for example, using StorageClass) StatefulSet (stable in 1.9, ~ a year ago) Persistent hostname with a unique index Created and deleted in order Singleton instance like MySQL (persistent volume, MySQL pod, service) ReplicaSet – “should be used when your application is completely decoupled from the node” “every container is identical and replaceable” (which is true for memory-only but not for persistent) DaemonSet – “should be used when a single copy of your application must be run on all or a subset of nodes in the cluster” Dynamic Volume Provisioning (with Azure for example, using StorageClass) StatefulSet (stable in 1.9, ~ a year ago) Persistent hostname with a unique index Created and deleted in order apiVersion: extensions/v1beta1 kind: Deployment metadata: name: ignite-cluster spec: replicas: 2 template: metadata: labels: app: ignite spec: containers: - name: ignite-node image: apacheignite/ignite:2.6.0 env: - name: OPTION_LIBS value: ignite-kubernetes - name: CONFIG_URI value: URL_TO_CONFIG ports: ...
• #17: Singleton instance like MySQL (persistent volume, MySQL pod, service) ReplicaSet – “should be used when your application is completely decoupled from the node” “every container is identical and replaceable” (which is true for memory-only but not for persistent) DaemonSet – “should be used when a single copy of your application must be run on all or a subset of nodes in the cluster” Dynamic Volume Provisioning (with Azure for example, using StorageClass) StatefulSet (stable in 1.9, ~ a year ago) Persistent hostname with a unique index Created and deleted in order
• #18: Singleton instance like MySQL (persistent volume, MySQL pod, service) ReplicaSet – “should be used when your application is completely decoupled from the node” “every container is identical and replaceable” (which is true for memory-only but not for persistent) DaemonSet – “should be used when a single copy of your application must be run on all or a subset of nodes in the cluster” Dynamic Volume Provisioning (with Azure for example, using StorageClass) StatefulSet (stable in 1.9, ~ a year ago) Persistent hostname with a unique index Created and deleted in order apiVersion: apps/v1 kind: StatefulSet metadata: name: ignite namespace: ignite spec: selector: matchLabels: app: ignite serviceName: ignite ... volumeMounts: - mountPath: "/data/ignite" name: ignite-storage volumeClaimTemplates: - metadata: name: ignite-storage spec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 1Gi
• #19: kubectl exec -it ignite-0 --namespace=ignite -- /bin/bash cd /opt/ignite/apache-ignite-fabric/bin/ ./control.sh --activate
• #25:   [1] http://globenewswire.com/news-release/2018/07/09/1534470/0/en/The-Apache-Software-Foundation-Announces-Annual-Report-for-2018-Fiscal-Year.html [2] https://blogs.apache.org/foundation/entry/apache-in-2017-by-the 
• #26: Try to get the demo app and slides on the web