Run Hyper Converged Using Stork

Hyper-convergence

When a pod runs on the same host as its volume, it is known as convergence or hyper-convergence. Because this configuration reduces the network overhead of an application, performance is typically better.

Using scheduler convergence

The recommended method to run your pods hyperconverged is to use Stork.

Once you have installed Stork, the webhook controller is enabled by default and will use Stork as the scheduler. If you have disabled webhook-controller with the flag, all you need to do is add schedulerName: stork in your application specs. Stork will then ensure that the nodes with data for a volume get prioritized when pods are being scheduled.

note

On Amazon EKS with hybrid nodes, the Stork admission webhook can set the scheduler automatically only when the on-premises pod network is routable from the virtual private cloud (VPC). If the pod network is not routable, keep Stork on the on-premises nodes and add schedulerName: stork to each workload that requires Stork scheduling. Hyperconvergence then works as described in this topic. For more information, see Configure hyperconvergence for workloads.

For example, this is how you would specify the scheduler name in a MySQL deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  replicas: 1
  template:
    metadata:
      labels:
        app: mysql
        version: "1"
    spec:
      schedulerName: stork
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-data

note

• To enforce strict pod hyperconvergence with respect to all its PVC replicas, include stork.libopenstorage.org/preferLocalNodeOnly: "true" in the spec.template.metadata.annotations section of your StatefulSet object.
• Use volume placement strategy to place volumes on specific nodes.

Disabling scheduler convergence

You can disable Stork's hyperconverged pod prioritization with the stork.libopenstorage.org/disableHyperconvergence: "true" pod annotation.

note

For sharedv4 volumes, when disableHyperconvergence is enabled, Portworx ignores Stork's node score logic, and all input nodes are scored equally. Also, the StorageClass parameters listed below are ignored.

• stork.libopenstorage.org/preferRemoteNodeOnly
• stork.libopenstorage.org/preferRemoteNode