Document Access types in v2

[pwright]

endorsed: local, loadbalancer, nodeport, route
deprecated: ingress-nginx
poorly tested: contour-http-proxy
requires beta features/unstable API: gateway

Controller configurations:
SKUPPER_DEFAULT_ACCESS_TYPE/-default-access-type - drives Site.spec.linkAccess=default and grants server when -grant-server-autoconfigure is set (default)
SKUPPER_ENABLED_ACCESS_TYPES/-enabled-access-types - controls selection of allowable Site.spec.linkAccess values.

[c-kruse]

Additionally access type specific options

• gateway: gateway-class, gateway-domain, gateway-port
• contour-http-proxy: -http-proxy-domain
• ingress-nginx: -ingress-domain

[artem-zinnatullin]

Hi @pwright, @c-kruse!

Does this mean 2.x (and currently latest Skupper 2.1.3) actually support NodePort and other types and not just Service type: LoadBalancer for Kubernetes?

Because CLI clearly says that loadbalancer is the only Kubernetes --link-access-type:

$ skupper site create -h
A site is a place where components of your application are running.
Sites are linked to form application networks.
There can be only one site definition per namespace.

Usage:
  skupper site create <name> [flags]

Examples:
skupper site create my-site --wait configured

Flags:
      --enable-ha                 Configure the site for high availability (EnableHA). EnableHA sites have two active routers
      --enable-link-access        allow access for incoming links from remote sites (default: false)
  -h, --help                      help for create
      --link-access-type string   configure external access for links from remote sites.
                                  Choices: [route|loadbalancer]. Default: On OpenShift, route is the default;
                                  for other Kubernetes flavors, loadbalancer is the default.
      --timeout duration          raise an error if the operation does not complete in the given period of time (expressed in seconds). (default 3m0s)
      --wait string               Wait for the given status before exiting. Choices: configured, ready, none (default "ready")

Global Flags:
  -c, --context string      Set the kubeconfig context
      --kubeconfig string   Path to the kubeconfig file to use
  -n, --namespace string    Set the namespace
  -p, --platform string     Set the platform type to use [kubernetes, podman, docker, linux]


$ skupper version
COMPONENT               VERSION
router                  3.4.2
controller              2.1.3
network-observer        2.1.3
cli                     2.1.3
prometheus              v2.42.0
origin-oauth-proxy      4.14.0

I do see mentions of NodePort and Ingress access types in the code:

• https://github.com/search?q=repo%3Askupperproject%2Fskupper%20nodeport&type=code
• https://github.com/search?q=repo%3Askupperproject%2Fskupper%20ingress&type=code

But the CLI fails to use these types:

skupper site create site-a --link-access-type nodeport --enable-link-access true
only one argument is allowed for this command.
link access type is not valid: value nodeport not allowed. It should be one of this options: [route loadbalancer default]

I thought this was all deprecated for 2.x and only Service type: LoadBalancer left which is a bummer or am I reading this wrong?

[c-kruse]

Hi @artem-zinnatullin

We did bring with us from V1 all of our ingress types - NodePort included. That said, we've spent relatively few cycles outside of the platform default (LoadBalancer + OpenShift Route) and have yet to get to documenting the relevant configuration parameters on the controller - that's this issue.

If you want to use NodePort, the default installs of skupper (the manifests from our release page and helm chart) does not have the option enabled. See -enabled-access-types and -cluster-host options (docker run --rm -ti quay.io/skupper/controller:2.1.3 /app/controller --help.) Customizing the deployment to enable NodePort (for now) would be on you.

As for what options the CLI should expose, I think that is tricky given that any of the access types can be disabled. I do see now that omitting options like nodeport could be interpreted that way - especially for those of us familiar with V1 where everything was CLI driven. That is probably something we should reconsider.