Access the Couchbase Server User Interface

    +
    Connect to the Couchbase Server user interface.

    The Couchbase user interface (UI) provides a rich environment for cluster management, debugging and application development. Access to the UI varies based on your chosen network architecture.

    Kubernetes ingress resources are not supported as they are neither fully featured nor generic across platforms. It is highly recommended that one of the methods outlined below be used for correct functionality as no technical support will be provided.

    Port Forwarding

    The standard way to connect to a Couchbase UI is through port-forwarding. In order to forward a Couchbase Server pod, list the pods belonging to the cluster you wish to connect to:

    $ kubectl get pods -l couchbase_cluster=cb-example (1)
    NAME              READY   STATUS    RESTARTS   AGE
    cb-example-0000   1/1     Running   0          69m
    cb-example-0001   1/1     Running   0          68m
    cb-example-0002   1/1     Running   0          68m
    1 Replace cb-example with the cluster name you require.

    If you are using multi-dimensional scaling then you will need to specify the subset of pods to use. Versions of Couchbase Server before version 6.5.0 require you to connect to a node that is running the service you are trying to access. This can be achieved by providing a second filter to specify the service you require (data, index, query, search, eventing or analytics):

    $ kubectl get pods -l couchbase_cluster=cb-example,couchbase_service_query=enabled (1)
    NAME              READY   STATUS    RESTARTS   AGE
    cb-example-0000   1/1     Running   0          73m
    cb-example-0001   1/1     Running   0          72m
    cb-example-0002   1/1     Running   0          72m
    1 Replace query with the service you require.

    To port forward to a chosen pod use the following command:

    $ kubectl port-forward cb-example-0000 8091
    Forwarding from 127.0.0.1:8091 -> 8091
    Forwarding from [::1]:8091 -> 8091

    You can then connect to http://localhost:8091 to access the UI.

    If you must connect over TLS then forward port 18091 and use the address https://localhost:18091. Ensure your cluster administrator has provided a CA certificate to be installed into your browser’s trust store. If certificate based authentication is used, then ensure you have installed your client certificate/key into your browser too. As you are connecting to localhost it is also important that your cluster administrator has added the localhost subject alternative address name into the cluster TLS certificate.

    DNS Based Addressing

    If you are using the public networking with External DNS network configuration then DNS based addressing can be used. When using public networking the Couchbase administrative service is exposed as a load balancer service in order to provide resilient connectivity for clients. This same service provides access to the UI.

    The connection string is determined by the spec.networking.dns.domain cluster parameter. The connection string is in the form https://console.${dns-domain}. Given the DNS domain my-cluster.acme.org, to connect to the cluster using TLS use the connection string https://console.my-cluster.acme.org:18091.

    Configuring an Ingress

    A Kubernetes ingress can be used to expose the Couchbase administrative console to a network external to the Kubernetes cluster. Ingresses are not managed by the Operator because the required configuration is not generic, however the configuration for your specific provider can be summarized as:

    • Enable cookie based client session affinity.

    Couchbase administrative console cookies are valid only for the pod you authenticated against. Client affinity ensures the ingress routes all requests for a session to the same pod each time.

    An illustrative example for NGINX would look like:

    apiVersion: networking.k8s.io
    kind: Ingress
    metadata:
      name: my-ingress
      annotations:
        nginx.ingress.kubernetes.io/affinity: cookie (1)
        nginx.ingress.kubernetes.io/affinity-mode: persistent
      spec:
        rules:
        - http: (2)
            paths:
            - path: / (3)
              pathType: Prefix
              backend:
                service:
                  name: my-cluster (4)
                  port:
                    number: 8091 (5)
    1 The ingress is annotated with affinity — this enables client affinity — and affinity-mode — this ensures each client session is routed to the same backend pod.
    2 A rule is created for all virtual hosts using the HTTP service.
    3 A path of / and a type of Prefix means that any HTTP path will match this rule.
    4 The service name references a service within the namespace the ingress is created in. The Operator will create a headless service by default for every cluster — in order to create DNS entries — and can be used as the backend service for the ingress. The service will be named the same as a Couchbase cluster resource.
    5 The port is the backend port to connect to. In this instance the ingress is plain text HTTP, so 8091.

    Use TLS to secure your ingresses on the public internet, otherwise your login credentials will be visible in plain text and can be snooped by an attacker. Your ingress provider may support backend TLS encryption, providing end-to-end security — use port 18091 on the backend. When using ingresses to access Couchbase, you cannot use client certificate authentication — use a load balancer service to expose the console instead.