Update:
So I think I answered my own question here. In a Master maxscale configuration it would be appropriate to use statefulset as they all share the same maxscae.cnf file. Statefulset allows the increase/decrease of replica count in the cluster and its perfect for this purpose. The replicasets all pin to one service detailed below:
Maxscale Cluster service service.yaml:
Note: This service is for metallb which will pin the VIP. I believe Kubevip will be slightly different (something Ill look into once I get kubevip in our environment)
apiVersion: v1
kind: Service
metadata:
name: {{ include "maxscale-helm.fullname" . }}
labels:
{{- include "maxscale-helm.labels" . | nindent 4 }}
spec:
type: {{ .Values.service.type }}
ports:
- name: mariadb
port: {{ .Values.service.mariadbProtocolPort }}
targetPort: 3306
protocol: TCP
- name: maxscale-webgui
port: {{ .Values.service.maxscaleWebGuiPort }}
targetPort: 8989
protocol: TCP
selector:
app: maxscale-cluster # reference that all maxscales in statefulset will use
Heres my current deployment. My org cannot deploy kube-vip at the moment until later on. So for now I am using Metallb to host a VIP. Metallb works well for failover but I suspect it is not service loadbalancing in the same way kube-vip does.
Note: Im using custom helm charts I've made but hopefully the above diagram properly depicts whats going on.
What are your thoughts? Are my assumptions correct?
@4evercoding It is great you are sharing your experiences....helps all of us learn from what you are seeing. I believe all of your assumptions are correct here. Using statefulsets, you should have the ability to scale the number of MaxScale instances up or down based on demand. It will also allow maintaining a consistent configuration across replicas.
Your use of MetalLB as a stopgap until you can deploy Kube-VIP should work well. Both MetalLB and Kube-VIP can provide the VIP for high availability, but they operate slightly differently as you know:
- MetalLB acts as a LoadBalancer in environments where external load balancers are not natively available (like bare metal clusters). It can assign external IP addresses (VIPs) to services and ensure that traffic reaches the correct node in the cluster.
- Kube-VIP, on the other hand, can offer a similar LoadBalancer functionality but is also capable of providing virtual IP management directly on top of Kubernetes, often used for Kubernetes control plane high availability as I noted in the video you referenced.