Skip to content

Expose Neptune#

This section describes how to expose Neptune from your cluster or VM to the outside.

You have two options:

  1. Use the ingress controller embedded within the Neptune installer.
  2. Provide your own ingress controller.

For more information on ingress controllers, see the Kubernetes documentation .

Parameter         Description Values
ingress_controller Determines whether the installer should deploy an ingress controller, or use an ingress controller already present in the cluster. If you're installing Neptune within a VM or on a fresh cluster, chances are you should go with the default.
  • embedded (default): the installer will install an Nginx ingress controller.
  • provided: the ingress controller will not be installed. It's assumed that you have an ingress controller working in the cluster.
  • provided-aws: a special value applicable to deployments on Amazon EKS clusters. The ingress controller will not be installed and the Neptune services will be deployed in a way compatible with AWS Application Load Balancer.
    • Note: AWS-specific annotations still need to be configured via the ingress_annotations parameter (see Ingress options). Also keep in mind that prior to the installation, your EKS cluster needs to be configured to provision ALBs for ingress resources.1
service_exposition_type Valid only if ingress_controller is set to embedded (the default). Determines the way Neptune's embedded ingress controller is exposed.
  • LoadBalancer: usually the preferred option when running in a cloud environment. It provisions a load balancer that points to Neptune.2
  • NodePort (default): commonly used when deploying Neptune on your own hardware, especially when using the single VM setup. In this case, Neptune will be exposed on port 30080 on every node of your Kubernetes cluster.3

Ingress options#

The options below require some understanding of Kubernetes concepts. You can skip them if you're installing Neptune within a VM and plan to add a separate load balancer to strip TLS.

Parameter        Description
ingress_host Defines a domain at which the ingress controller will listen for requests to Neptune. Translates directly to .spec.rules[].host in Neptune's ingress. Note: If this option is set, Neptune will be available only through this domain.
ingress_annotations Dictionary that translates directly to .metadata.annotations in Neptune's ingress. You can use this option to configure behavior specific to your provided ingress controller, such as forcing an SSL redirect.
ingress_labels Dictionary that translates directly to .metadata.labels in Neptune's ingress. Note: the Neptune installer might add a few labels. In particular, the label names app, chart, release, and heritage are reserved. Setting these will cause the installation to fail.
ingress_tls_secret Name of a secret in the target namespace containing a valid TLS certificate and key for the ingress to use. If defined, the values of ingress_tls_cert and ingress_tls_key are ignored.
ingress_tls_cert, ingress_tls_key Base64-encoded TLS certificate and private key. The installer uses these two values to build a secret and provide it to .spec.tls.secretName in Neptune's ingress.

Configuring body size limit#

Neptune uploads files in chunks of 5 MB by default. Most ingress controllers have a HTTP body size limit (1 MB for Nginx). By default, the ingress_controller parameter is set to embedded and Neptune injects the appropriate annotations to adjust the limit.

If you specify your own value for the parameter (ingress_controller: "provided") in the configuration.yml file, you need to manually add ingress annotations. Otherwise, you might experience 413 HTTP errors while uploading files larger than 1 MB.

Nginx example
ingress_annotations:
  nginx.ingress.kubernetes.io/proxy-body-size: "0"

If using different ingress controllers or load balancers, you may need to add other annotations.

Next steps#

  1. For more information on exposing ingress resources as ALBs, see the AWS docs . ↩

  2. For more information on LoadBalancer services, see the Kubernetes docs . ↩

  3. For more information on NodePort services, see the Kubernetes docs . ↩