We’re now completely ready to create a more “advanced” cluster. The main differences from the one created before will be:
Create the file sgcluster-cluster1.yaml
and apply the following YAML file:
apiVersion: stackgres.io/v1
kind: SGCluster
metadata:
namespace: demo
name: cluster
spec:
postgres:
version: 'latest'
instances: 3
sgInstanceProfile: 'size-small'
pods:
persistentVolume:
size: '10Gi'
configurations:
sgPostgresConfig: 'pgconfig1'
sgPoolingConfig: 'poolconfig1'
sgBackupConfig: 'backupconfig1'
distributedLogs:
sgDistributedLogs: 'distributedlogs'
prometheusAutobind: true
nonProductionOptions:
disableClusterPodAntiAffinity: true
and deploy to Kubernetes:
kubectl apply -f sgcluster-cluster1.yaml
You may notice that in this ocassion the pods contain one extra container. This is due to the agent (FluentBit) used to export the logs to the distributed logs server. You can check both from kubectl -n demo get pods --watch
:
$ kubectl -n demo get pods
NAME READY STATUS RESTARTS AGE
distributedlogs-0 3/3 Running 0 3m16s
hol-0 7/7 Running 0 98s
hol-1 7/7 Running 0 72s
as well as kubectl -n demo describe sgcluster cluster
and the Web Console the status of the newly created cluster.
From the Web Console:
While the cluster is being created, you may notice a blip on the distributed logs server, where a container is restarted. This is a normal process, and does only pause temporarily the collection of logs (no logs are lost, since they are buffered on the source pods). This is caused by a re-configuration which requires a container restart.