We are proud to present STUNner v0.17.0, the new release of the STUNner Kubernetes media gateway for WebRTC from l7mp.io. Major changes include the stabilization of the managed dataplane mode, which also becomes the default from this release, upgrading the Gateway API and STUNner config API to v1, the rewriting of the STUNner dataplane API over OpenAPI, fixing the handling of clusters in Prometheus metrics reporting, port-range filtering support, and the usual assortment of fixes and documentation updates.
This release marks the first candidate for the upcoming stable release. STUNner now enters into a soft-freeze state: only fixes, refactors, and documentation updates will be applied in the master branch until we release v1.
News
Upgrade to Gateway API and STUNner API v1
The Kubernetes Gateway API used by STUNner to define the TURN services exposed to clients has gone GA recently. In preparation for the upcoming v1 release, STUNner's internal dataplane API, the wire protocol used by the gateway operator to configure the dataplane, has also been upgraded to v1.
This release therefore will again require smaller changes in your STUNner configs to track the moving API targets.
- Gateway and GatewayClass API resources have to be updated from v1beta1 to v1. The old v1alpha2 and v1beta1 versions are still accepted, but silently upgraded to v1 by Kubernetes.
- UDPRoutes remain at v1alpha2, but the backend port has been made mandatory upstream. To remove the confusion around the handling of ports, we have forked the official UDPRoute API to provide STUNner's own UDPRoute API that does not require backend ports but is otherwise fully compatible with the official API. To use it, rename the API group in your UDPRoute resources from
gateway.networking.k8s.io/v1alpha2tostunner.l7mp.io/v1. The standard v1alpha2 URPRoutes are still accepted, but don't forget that the backend port is now mandatory. - STUNner's GatewayConfig, Dataplane, and StaticService APIs have moved from v1alpha1 to v1. The old v1alpha1 resources are still accepted but they will be silently upgraded to v1. Since there were some minor incompatible changes between v1alpha1 and v1 it is recommended to double-check the upgrade, especially if you are using non-standard metrics reporting and health-checking settings.
Managed mode: default
In the last release we introduced the managed dataplane mode to simplify the provisioning of STUNner dataplane pods. In the managed mode the gateway operator automatically maintains a separate dataplane per each Gateway (i.e., a separate stunnerd Deployment), plus the usual LoadBalancer service to expose it to clients.
With this release managed mode has become the default. Legacy mode is still supported, but it is officially deprecated we will be removed in v1. Please make sure you properly upgrade STUNner, otherwise you may end up with a dysfunctional deployment.
Commits
chore: Introduce a rate-limited logger
chore: Introduce STUNner dataplane config API v1
chore: Refactor Service label/annotation setting
chore: Set default dataplane mode to "managed"
feat: Fork the UDPRoute API from Gateway API v1
feature: Per-cluster port range filtering
feature: Implement port range filtering on peer connections
fix: GatewayConfigs now print the Dataplane on kubectl-get
fix: Handle existing load balancer class (#41, #104)
fix: No longer set spec.externalIPs on LB Services
fix: Nonzero replica-count in Dataplane.spec no longer prevents autoscaling
fix: Open health-check service-port for LB Services only
fix: Properly remove managed resources on the invalidation pipeline
fix: Rewrite public address/port search, fix l7mp/stunner-auth-service#3
fix: Unbreak legacy config file watcher
refactor: Complete CDS server rewrite
refactor: Re-implement CDS API over OpenAPI
refactor: Steamline command line argument parsing
refactor: Upgrade STUNner Gateway API to v1
refactor: Upgrade to Gateway API v1
Enjoy STUNner and don't forget to support us!