- 03 Nov, 2021 27 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
Now using the SUB feature of VMOD re2. This simplifies and improves the scalability of the matching logic (one subroutine call, rather than an if-elsif sequence that is as long as the number of paths). Will also simplify the implementation of pathType for k8s-1.22.
-
Geoff Simmons authored
This is due at any rate, and in particular the more recent versions of VMOD re2 and selector support the VCL_SUB feature.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
This is necessary even if the controller is otherwise restricted to a namespace. So we add a new ClusterRole to add the RBAC read rights (wath, list and get) unconditionally for any controller instance.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
Verified with the hello world example using kubectl/yaml deployment. The other tests/examples, including all helm deployments, do not work as of this commit, until they are adapted to the new logic for configuring the Ingress class.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
Its two fields are mapped directly to the ttl and ttl_from parameters of VMOD dynamic.
-
Geoff Simmons authored
We now work with Ingress from the API group networking.k8s.io. Ingress in the extensions API group is no longer supported. This entails: - update RBAC grants - update client-go code - update the examples/tests, currently only using helm deployments - changes in the Ingress backend and service fields - for now we only test pathType:ImplementationSpecific, implemented as posix_type re2 matches, which had been the match implementation prior to this change. viking will support the Match and Prefix pathTypes, but in this iteration, it was not necessary to change the code to support the ImplementationSpecific pathType. Examples/tests with kubectl deployments and plain YAML manifests will also be updated in an upcoming iteration.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
In this commit, the code compiles and passes make check. But we currently can't test anything else, because the manifests/charts still use API groups that are obsolete in this k8s version.
-
Geoff Simmons authored
-
- 22 Oct, 2021 2 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
- 20 Sep, 2021 1 commit
-
-
Geoff Simmons authored
Cf. ab85c9bb and c3f7a9a9
-
- 17 Sep, 2021 7 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
The replica scaling test for self-sharding requires the Deployment name "varnish-ingress" for the viking service.
-
Geoff Simmons authored
This is the SNI sent in the client TLS connection to a backend. We use VMOD dynamic for backends represented by an ExternalName Service (likely the common use case for TLS onload). VMOD dynamic does not have the authority field that klarlack makes available for standard backends. But if the host_header field is set for a VMOD dynamic director, the VMOD uses that value for the SNI. So if the BackendConfig authority field is set, we also assign its value to the host_header field. Since BackendConfig also has a separate field for host_header, both of them could be conceivably set to different values. If we find that the two fields are set to non-empty, conflicting values, the controller emits a SyncFatalError, and the BackendConfig is not synced.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
This uses haproxy for TLS connections to IngressBackends, and the via feature of the klarlack implementation of Varnish. See: https://github.com/varnishcache/varnish-cache/pull/3128 Adds the spec.tls object to the BackendConfig CRD, which configures TLS onload for a backend. Limitations: currently only verify:false and the maxConn settings are implemented. Specification of CA certificates and the stick table configuration for haproxy are not yet implemented. Currently TLS onload may be only specified for one backend (no more than one BackendConfig). Adds the CLI option -varnishImpl to the controller. TLS onload is only supported if this option is set to "klarlack". Otherwise, the presence of the tls object in a BackendConfig leads to a SyncFatalError, with a message that it's only supported for klarlack, and the BackendConfig is not synced. If the backend Service specified for TLS onload has type ExternalName, then 3 server instances are configured for the haproxy backend. This value is currently hard-wired, and may be made configurable in a future iteration. For any other Service type, there are as many haproxy server instances as there are Endpoints (Pods) in the k8s cluster. If maxConn is not specified in the BackendConfig, it defaults to 2000 (the haproxy default).
-
Geoff Simmons authored
-
- 03 Sep, 2021 3 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
See c3f7a9a9
-
Nils Goroll authored
-