Run hyper converged in GKE 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.
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 thespec.template.metadata.annotationssection of your StatefulSet object. - Use volume placement strategy to place volumes on specific nodes.