We are proud to present STUNner v0.18.0, the second stable release candidate of the STUNner Kubernetes media gateway for WebRTC from l7mp.io.
Major changes include the conversion of all STUNner components and CLI utilities to the managed dataplane mode and the new config discovery API, the removal of the ConfigMap that used to hold the running dataplane config, the removal of the legacy dataplane mode, plus the usual assortment of fixes and documentation updates. STUNner is now in soft-freeze state: only fixes, refactors, and documentation updates will be accepted in the master branch until we release v1.
News
Complete config discovery service support
In the ancient days of STUNner, the way the control plane was configuring the dataplane was somewhat complicated. The operator rendered the config into a ConfigMap, which was then mapped into the file-system of the stunnerd pods that actively watched the file for updates. The rest of ancillary STUNner tools, including the auth-service or turncat, also used this ConfigMap as ground-truth. This config interface served us well for the few initial releases, and it also had the useful side-effect that the dataplane config was always available at a convenient place, which greatly simplified debugging. The negative side was that, due to certain Kubernetes limitations beyond our control, config updates were very slow to propagate to the dataplane, so much so that we had to package a separate config-watcher sidecar container next to stunnerd to speed up the process. This alone was larger than stunnerd itself. Even worse, the ConfigMap exposed the TURN authentication credentials in plain text, which raised rightful concerns for our security-savvy users.
To remedy this, we have initiated the transition to a new HTTP-based config API that we call the STUNner Config Discovery Service (CDS) during the v0.15.0 development cycle. This API allows fast access to STUNner dataplane configuration via the CDS server exposed by the gateway operator. The operator creates the stunnerd pods, bootstrapping each with its own address as the CDS server, and from this point stunnerd pods load their configuration via CDS autonomously. This is the main idea in the managed dataplane mode that we made default in the last release.
However, some components, like the STUNner authentication service, and CLI utilities like stunnerctl and turncat, still used the ConfigMap to learn the dataplane config. In this release all these tools have been rewritten to use CDS, eliminating the last remaining restriction originating in the old legacy dataplane mode.
Removal of the dataplane ConfigMaps
Since the ConfigMap that holds dataplane configs is no longer needed, it has been removed in this release. From now on, the "official" way to load/watch/debug dataplane configs is via the stunnerctl tool. For those of you who can't, or don't want to, download a separate utility just to interact with STUNner configs, we still maintain the old shell script, but it has been renamed to stunnerctl.sh. Certain workarounds involving manual port-forwarding and curl are also available for those who favor minimalistic solutions, see the stunnerctl manual for details.
Remote dataplane status reporting
The rewritten stunnerctl tool gained further useful features. The main purpose is still loading and watching running dataplane configs (stunnerctl config). However, from this release the tool can also query the status of the stunnerd pods per each Gateway (stunnerctl status), and it can also be used to quickly generate TURN credentials and full ICE server configurations for testing a STUNner deployment (stunnerctl auth). See the user manual for the details.
Full support for arm64 builds
From this release, we are officially providing build artifacts for the arm64 port of STUNner. Of course, the usual amd64 images are also available. If you are testing STUNner on your M1/M2 MacBook or running STUNner on any arm64 platform, you no longer have to build STUNner images yourself: our Helm charts should download and install the proper container images automatically.
Commits
Dataplane and utilities
doc: Add docs for CDS client
feat: Add turncat binaries as release assets (#115)
feat: Report deleted configs in stunnerctl
feat: Implement a status sub-command in stunnerctl
feat: Implement a basic auth-service client in stunnerctl
fix: Fix turncat build on Windows (#111)
fix: Restore credentials after config env substitution, fix #102
refactor: Rewrite config discovery in strict OpenAPI mode
refactor: Rewrite stunnerctl and turncat to use the CDS API, fix #81
test: Run CDS client-server tests on a random port
Gateway operator
feat: Define a label for the CDS Service for discoveribility
fix: Fix CDS server address parsing
fix: Generate only a single CDS config update per render round
fix: Make sure CDS server is reachable with API server port-forward
fix: Move CDS service label defs to STUNner
fix: Remove dataplane ConfigMap, fixes #43
fix: Update service-port for existing Services on Gateway reconcile
test: Implement config watchers using CDS in integration tests
Authentication service
refactor: Rewrite using the CDS API
chore: Upgrade to STUNner API v1
Enjoy STUNner and don't forget to support us!