Skip to main content
Expose a Kubernetes Load Balancer. expose kubernetes opens a public ingress to a Load Balancer. The provided service needs to be up and running. For example, it can be created with nsc kubectl expose within an ephemeral instance. The exposed endpoint is encrypted with TLS and secured with Namespace authentication, so whoever has access to the workspace where the ephemeral environment was created in, will also have access to the endpoint. Note: Only HTTP services can currently be exposed.

​
Usage

​
Example

In the example below, we first create an ephemeral instance, start nginx with kubectl run, create a Load Balancer with kubectl expose and then expose it using nsc expose kubernetes.
1

Create an ephemeral instance

Create an ephemeral instance and note its ID:
Output
2

Start nginx

Start nginx within the created instance:
Output
3

Create a load balancer

Expose the nginx pod through a Kubernetes load balancer:
Output
4

Expose port 80

Expose port 80 using nsc expose kubernetes:
Output
5

Visit the exposed endpoint

Visit https://nginx-foobar-072higp5dg0bg.fra1.namespaced.app in your browser and use your Namespace credentials for authentication.

​
Options

​
—namespace <namespace>

Specifies the namespace of the exposed Load Balancer. This option is required.

​
—service <service>

Specifies the name of the exposed Load Balancer. This option is required.

​
—name <name>

Set the name of the exposed ingress. By default, ingress names will be generated by Namespace.

​
—port <port>

In case there are multiple ports exported by the Load Balancer, use this flag to select the port to expose.

​
—output, -o <type>

Specifies the output format. Supported options are json and plain. By default, plain output format is used.

​
—wait

Wait until the provided service has a valid ingress to expose.

​
—ingress <rules>

Specify additional rules per ingress. The following effects can be set per route:
  • noauth: Disables authentication on the route.
Rules are defined by specifying method, path regex, using one of the following schemes:
  • <effect>: Applies effect to any method or path.
  • <path_regex>:<effect>: Applies effect to paths that match path_regex (the full path without the query is using for matching.).
  • <method>[,<method>,...]:<path_regex>:<effect>: In addition to matching path, also matches against the HTTP method used.

​
—wildcard

Expose the service load balancer under a wildcard ingress. The hosting instance needs to be configured to support wildcard ingresses.
Last modified on August 20, 2026