A newer version of this documentation is available.

View Latest

Configure Server Groups

      How to configure server groups to provide high availability across data centers.

      Ensure you have read and understood the server groups concepts and how server group scheduling applies to your cluster.

      Configuring Kubernetes Node Labels

      The Operator does not, and can not, have any prior knowledge of what Kubernetes node resides where. Kubernetes nodes are cluster scoped resources that we do not grant access to for security reasons.

      Most cloud providers will label Kubernetes nodes to describe physical location based on availability zone. You can examine your cluster with the kubectl get nodes command to determine whether labels are already configured for your environment. If labeled, take a note of all availability zones and proceed to the next section.

      If not labeled, Kubernetes nodes must be in order to describe physical failure domains. The labels may map to any desired failure domain e.g. a data center, rack, switch, etc. This can be done with the following command:

      $ kubectl label nodes ip-172-16-0-10 failure-domain.beta.kubernetes.io/zone=us-east-1a

      ip-172-16-0-10 is the Kubernetes node name to apply the label to. The label key must be failure-domain.beta.kubernetes.io/zone. The label value (us-east-1a) can be anything you want.

      Configuring Couchbase Cluster

      When configuring the cluster, you must specify the set of server groups that the Operator is allowed to schedule Couchbase Server pods across. Server group members correspond to Kubernetes failure-domain.beta.kubernetes.io/zone labels. For example:

      apiVersion: couchbase/v2
      kind: CouchbaseCluster
        serverGroups: (1)
        - us-east-1a
        - us-east-1b
        - us-east-1c
        - name: ServerClass1 (2)
        - name: ServerClass2 (3)
            - us-east-1a
            - us-east-1b
      1 spec.serverGroups is a global default that can used by any server class.
      2 This server class does not have spec.servers[].serverGroups defined. When the Operator schedules pods in this class it will default to server groups set with spec.serverGroups.
      3 This server class has spec.servers[].serverGroups defined. When the Operator schedules pods in this class it will override the global defaults set with spec.serverGroups and use spec.servers[].serverGroups instead. This is useful when a server class is sized in a way that cannot be fully balanced across the default set of server groups.

      Server groups are enabled for the cluster if any of the server classes have spec.servers[].serverGroups set, or the global default — spec.serverGroups  — is enabled. It is considered an invalid configuration when server groups is enabled and a server class doesn’t have either an explicit set of server groups or an inherited set of global defaults.

      Server groups are immutable and cannot be modified during the cluster lifetime.