Command-Line Interface

The supergloo cli is a command line wrapper for supergloo's REST API.

In order to create a seamless experience, the supergloo cli is interactive by default. However, if you would not like to take advantage of these features, feel free to use the static -s flag and turn them off.

Initializing supergloo

The first step with the CLI is Initializing supergloo in your desired cluster.

supergloo init

The above command will create supergloo-system namespace in your cluster, as well as all of it's related resources.


Installing Meshes

supergloo cli allows for the installation of multiple different meshes from one unified place.

supergloo install [flags]

Flags:

Example usage:

supergloo install --meshtype istio --namespace istio-system

The above command will install istio into the istio-system namespace


Uninstalling Meshes

Uninstalls meshes from the cluster.

supergloo uninstall [flags]

Flags: --all (boolean, optional) uninstalls all installed meshes --meshname (string, required) name of an installed mesh of any type. * --meshtype (string, optional) mesh to uninstall: (istio, consul, linkerd2, appmesh). Rather than supplying the exact name of the mesh like above, this argument takes the mesh type and finds the corresponding mesh to delete.

Example usage:

supergloo uninstall --meshname <name-of-mesh>

Routing Rules

Routing rules control the flow of traffic to and from the application. In addition these rules allow the user to test for resilience. Each rule has specific sources and destinations to allow for more fine-grained targeting of the rules. See here for meshes which currently support this feature.

supergloo create routing-rule [flags] <resource-name>

Persistent flags: --matchers (string, optional) list of comma seperated matchers. eg: ("") -m --mesh (string, required) name of mesh which will be the target for this rule -n --namespace (string, required, default: "default") namespace this rule will be installed into -d --destinations (string, required) destinations for this rule. Each entry consists of an upstream namespace and and upstream name, separated by a colon. eg <namespace:name> --sources (string, required) Sources for this rule. Each entry consists of an upstream namespace and and upstream name, separated by a colon. eg <namespace:name> -f --filename (string, optional) filename containing info to construct route rule. Only yaml supported currently. note: currently this feature supports multiple data formats. Either use the form defined in the routing_rule.proto or one that conforms to the CLI. -s --static (bool, optional, default: false) As stated above. the CLI by default is interactive unless specified via this flag

Notes: * upstreams are found via our discovery system and can be found easily using the following command. It is important to check all namespaces because the user is given the freedom to place these wherever he/she pleases.

kubectl get routingrules.supergloo.solo.io --all-namespaces

Create routing rule functions as the sum total of all of the individual rule commands listed below. create routing-rule allows for the creation of multiple rules simultaneously, either via flags, or via yaml.

Traffic Shifting

Traffic-shifting rules allow for the disbursement of network traffic among a specific set of upstreams based on a set of given weights.

supergloo traffic-shifting [flags] <resource-name>

Flags: --traffic.upstreams (string, optional) upstreams for this rule. Each entry consists of an upstream namespace and and upstream name, separated by a colon. eg <namespace:name> --traffic.weights (string, optional) Comma-separated list of integer weights corresponding to the associated upstream's traffic sharing percentage. Must be the same length as the # of upstreams

Example:

supergloo traffic-shifting ts-rule -s -m <mesh-name> -n <namespace> \
    --destinations <namespace:name> --sources <namespace:name> \
    --traffic.upstreams <namespace:name>, <namespace:name> --traffic.weights 10, 20

Fault Injection

Fault injection rules allow for purposeful semi-random error generation.

supergloo fault-injection [flags] <resource-name>

Flags: --fault.abort.message (string, required) Error message (int for type=http errors, string otherwise). --fault.abort.percent (int, required) Percentage of requests on which the abort will be injected (0-100) --fault.abort.type (string, required) Type of error (http, http2, or grpc) --fault.delay.percent (int , required) Percentage of requests on which the delay will be injected (0-100) --fault.delay.type (string, required) Type of delay (fixed or exponential) --fault.delay.value.seconds (int, required) delay duration (seconds) * --fault.delay.value.nanos (int, required) delay duration (nanoseconds)

Timeout

Timeout rules rules create specific timeouts within a given route.

supergloo timeout [flags] <resource-name>

Flags: --route.timeout.seconds (int, required) timeout duration (seconds) --rout.timeout.nanos (int, required) timeout duration (nanoseconds)

Retries

Retry rules create specific forced retries for the given route(s).

supergloo retries [flags] <resource-name>

Flags: --route.retry.attempt (int, required) number of retries to attempt --route.retry.timeout.seconds (int, required) timeout duration (seconds) * --route.retry.timeout.nanos (int, required) timeout duration (nanoseconds)

Cors Policy

Cors-policy rules updates the CORS settings for the given route(s)

supergloo cors [flags] <resource-name>

Flags: --cors.allow.credentials (bool, required) Indicates whether the caller is allowed to send the actual request (not the preflight) using credentials. Translates to Access-Control-Allow-Credentials header. --cors.allow.headers (string, required) List of HTTP headers that can be used when requesting the resource. Serialized to Access-Control-Allow-Methods header. --cors.allow.methods (string, required) List of HTTP methods allowed to access the resource. The content will be serialized into the Access-Control-Allow-Methods header. --cors.allow.origin (string, required) The list of origins that are allowed to perform CORS requests. The content will be serialized into the Access-Control-Allow-Origin header. Wildcard * will allow all origins. --cors.expose.headers (string, required) A white list of HTTP headers that the browsers are allowed to access. Serialized into Access-Control-Expose-Headers header. --cors.maxage.seconds (int, required) Max age time in seconds. Specifies how long the the results of a preflight request can be cached. Translates to the Access-Control-Max-Age header. * --cors.maxage.nanos (int, required) Max age time in nanoseconds. Specifies how long the the results of a preflight request can be cached. Translates to the Access-Control-Max-Age header.

Mirror

Mirror rules allow for the sending of a duplicate request to the given upstream, in addition the responses to these requests are ignored.

supergloo mirror [flags] <resource-name>

Flags: * --mirror (string, required) Destination upstream (ex: upstream_namespace:upstream_name).

Example:

supergloo mirror m-rule -s --mesh <mesh-name> --namespace <mesh-namespace> \
    --destinations <namespace:name> --sources <namespace:name> \
    --mirror <namespace:name>

The above command creates a new mirror rule

Header Manipulation

Header-manipulation rules allow for the control of request and response headers

supergloo header-manipulation [flags] <resource-name>

Flags: --header.request.append (string, optional) Headers to append to request (ex: h1,v1,h2,v2). --header.request.remove (string, optional) Headers to remove from request (ex: h1,h2). --header.response.append (string, optional) Headers to append to response (ex: h1,v1,h2,v2). --header.response.remove (string, optional) Headers to remove from response (ex: h1,h2).

Example:

supergloo header-manipulation hm-rule -s --mesh <mesh-name> --namespace <mesh-namespace> \
    --destinations <namespace:name> --sources <namespace:name> \
    --header.request.append header-request1,text --header.request.remove header-request2 \
    --header.response.append header-response1,text --header.request.remove header-response2

The above command creates a new header-manipulation rule for the mesh (mesh) in the namespace (namespace). This rule will append the request header [header-request1, text] and remvove the request header header-request2. This rule will then append the response header [header-response1, text] and remove the response header header-response2.


Security

security features: policies mtls * ingress

Policies

Configure security policies for service communication.

supergloo policy [sub-command] [flags] 

Sub-Commands: add apply a policy claer clear all policies * remove remove a single policy

Persistent-Flags: --mesh (string, required) name of mesh to update --namespace (string, required) namespace of mesh to update --destination.name (string, required) name of policy destination upstream --destination.namespace (string, required) namespace of policy destination upstream --source.name (string, required) name of policy source upstream --source.namespace (string, required) namespace of policy source upstream

Add:

Adds a single policy to a given mesh with the specified source and destination

supergloo policy add -s --mesh.name <mesh-name> --mesh.namespace <namespace> \
    --destination.name <upstream-name> --destination.namespace <upstream-namespace> \
    --source.name <upstream-name> --source.namespace <upstream-namespace>

Remove:

Removes a single policy from a given mesh with the specified source and destination.

supergloo policy remove -s --mesh.name <mesh-name> --mesh.namespace <namespace> \
    --destination.name <upstream-name> --destination.namespace <upstream-namespace> \
    --source.name <upstream-name> --source.namespace <upstream-namespace>

Clear:

Clears all policies from a given mesh

supergloo policy remove -s --mesh.name <mesh-name> --mesh.namespace <namespace>

mTLS

Configure mTLS for a given mesh

supergloo mtls [sub-command] [flags] 

Sub-Commands: disable disable mTLS enable enable mTLS * toggle toggle mTLS

Persistent-Flags: --mesh (string, required) name of mesh to update --namespace (string, required) namespace of mesh to update

Example:

supergloo mtls enable -s --mesh.namespace <namespace> --mesh.name <mesh-name>

Fortify Ingress

Configure ingress security parameters

This feature will be available in 2019.


Secrets

supergloo-cli allows for the creation of multiple secret-types in the given cluster

Standard

create a standard secret in a given namespace

supergloo create secret [flags] <secret-name>

Flags: --certchain (string, required) filename of certchain for secret --privatekey (string, required) filename of privatekey for secret --rootca (string, required) filename of rootca for secret --secret.namespace (string, required) namespace in which to store the secret

AWS

Create an AWS secret

supergloo create aws-secret [flags] <secret-name>

Flags: --secret.namespace (string, required) namespace in which to store the secret --access-key (string, required) aws access key * --secret-key (string, required) aws secret key


Get

Fetch supergloo data/CRDs in a readable format

supergloo get <RESOURCE-TYPE> <resource-name> [flags]

This command functions similarly to kubectl get. The first arg is the resource type, and the second (optional) arg is the name of the individual resource.

Sub-Commands: * -r --resources prints a list of available resource types and their corresponding shortcuts

Flags: -n --namespace (string, optional, default: "gloo-system) namespace to search for the corresponding CRD -o --output (string, optional) output format for the data, small table by default (yaml, wide...)