Access the Console
Once Lightbend Console is installed, you’ll need to setup external access for the appropriate users. There are many options to expose the Console during development and production:
-
For clusters in a production environment, Ingress is the recommended approach. Because Ingress configuration is highly dependent on your existing distributed environment and requires careful security consideration, it is beyond the scope of this document. However, the Ingress section below provides an example of how to refer to the Lightbend Console in a
.yaml
file. -
For development environments with local clusters, Console access is much simpler: For Minikube, you can use the built in
NodePort
to access it locally and the Kubernetes documentation describes many other ways for for accessing aService
directly.
Minikube
For Minikube, accessing the Console is straightforward. If you installed with the --set exposeServices=NodePort
option, you can access the Console using:
minikube service expose-es-console -n lightbend
This should open your browser to something like: http://192.168.99.100:30080/cluster
. In some cases, the IP address might be different.
Minishift & OpenShift
To access Lightbend Console when using OpenShift or Minishift, expose the console-server service. OpenShift creates a route for the service. Use the following command to expose the service and get the route. (The value of ${CONSOLE_NAMESPACE}
is usually lightbend
):
oc project ${CONSOLE_NAMESPACE}
oc expose service console-server
oc get routes
For example, with the sample output below, you can access the Console at: http://console-server-lightbend.192.168.99.102.nip.io/cluster
console-server console-server-lightbend.192.168.99.102.nip.io console-server 8080 None
Ingress
Ingress
is the recommended production-ready mechanism for external access into a Kubernetes cluster. Ingress
setup is dependent on the environment and Ingress
controller installed.
Setting up an Ingress
controller is beyond the scope of this document, please see the official documentation.
Be especially careful in cloud environments where installing a basic Ingress
may expose the service to the internet by default.
The Helm chart for the Lightbend Console provides a Kubernetes service called console-server
that you can expose with Ingress. The following yaml
file provides an example:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: es-console-ingress
namespace: lightbend
spec:
backend:
serviceName: console-server
servicePort: 80
Do not use any target rewrite configuration with your ingress. For example, if using an nginx
ingress, do not configure it with an nginx.ingress.kubernetes.io/rewrite-target
annotation.
If your ingress adds a path component to the URI, you should set the esConsoleURL
flag when installing with lbc.py
. For example, if the URL to your cluster is http://my.service.io
and your ingress adds a /somepath
path component for access to the console service, then you should install with
--set esConsoleURL="http://my.service.io/somepath"
This makes sure Prometheus links in the Console will work.
Development access
Kubernetes provides a few different mechanisms for external access of services that don’t require setting up Ingress
.
kubectl port-forward
The port forwarding mechanism in kubectl can be used for ad-hoc access. It will perform significantly better than kubectl proxy
, but requires at least Kubernetes 1.10.
kubectl -n lightbend port-forward svc/console-server 5000:80
Then you can access Lightbend Console on http://127.0.0.1:5000
.
kubectl proxy
A simple approach that works across all versions of Kubernetes is to use kubectl proxy
to setup a local reverse-proxy into the cluster:
kubectl proxy
Then you can access Lightbend Console at something like: http://127.0.0.1:8001/api/v1/namespaces/<lightbend>/services/console-server:http/proxy/
, by replacing lightbend
with the namespace you installed it into.
The main drawback of this approach is performance. It proxies every call between your browser and the Console via the Kubernetes apiserver. This puts extra load on the apiserver and can make the browser experience quite slow. But it’s an easy way to get started quick.
LoadBalancer service
For environments that support it (generally any cloud provider, such as AWS or GCP), you can setup a LoadBalancer Service. Create the service using kubectl expose
in the namespace where Lightbend Console is installed (lightbend
by default):
kubectl expose deployment es-console -n lightbend --type=LoadBalancer --name=access-es-console
To discover the external IP, list the service:
$ kubectl get services -n lightbend access-es-console
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
access-es-console ClusterIP 10.3.245.137 104.198.205.71 8080/TCP 54s
In this example, the Lightbend Console would be accessible at http://104.198.205.71:8080
.
NodePort service
In environments that don’t support LoadBalancer
, you can expose the Service
via a port on every single Kubernetes node. This is called a NodePort
.
This only works if the node firewall allows access to the node port range.
Create the service using kubectl
:
kubectl expose deployment es-console -n lightbend --type=NodePort --name=access-es-console
To discover the node port, list the service:
$ kubectl get services -n lightbend access-es-console
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
access-es-console NodePort 10.109.189.117 <none> 8080:32536/TCP 8s
In this case, the node port is 32536
. Next, you need to find a node IP to use:
$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
node-1 Ready node 43d v1.10.0 10.5.5.5 Buildroot 2018.05 4.15.0 docker://17.12.1-ce
node-2 Ready node 43d v1.10.0 10.5.5.6 Buildroot 2018.05 4.15.0 docker://17.12.1-ce
You can pick any node’s EXTERNAL-IP
.
So the Lightbend Console would be accessible at http://10.5.5.5:32536
.