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.
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
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
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
couchbaseclusters.spec.networking.dns.domain cluster parameter.
The connection string is in the form
Given the DNS domain
my-cluster.acme.org, to connect to the cluster using TLS use the connection string
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
|2||A rule is created for all virtual hosts using the HTTP service.|
|3||A path of
|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.