Implementation of the Kubernetes Gateway API utilizing Caddy as the underlying web server.
By (ab)using the Caddy Admin API we can dynamically program Caddy with any configuration we want on the fly, without downtime. Instead of requiring sidecar containers or modifying Caddy source-code.
There are two core components, the Controller (this repository) and Caddy (the webserver).
The Controller watches for changes to any Gateway API resources (and referenced resources).
Whenever a watched resource is updated, a reconciliation cycle runs that will collect all the
Gateway API resources for a given Gateway and generate a JSON configuration for Caddy. Once the
configuration is generated, the Controller will find all Caddy pods associated with the Gateway
and send a request to the pod's Caddy Admin API.
Caddy is the webserver running as either a Deployment or DaemonSet. It serves as the ingress point for any Route resources and is where your requests will be processed.
Requires Gateway API v1.0.0 CRDs to be installed on your cluster (some experimental CRDs are supported but are optional)
Support for missing resources is planned but not yet implemented.
The Ingress resource is not supported and support is not planned, sorry.
The following steps assume you already have a Kubernetes cluster setup and configured with core components like networking and DNS.
This repository doesn't contain any CRDs, instead it relies on the standardized Kubernetes Gateway API resources. See https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api for more details.
We recommend installing all Gateway API CRDs, including those that are experimental.
# Install Gateway API CRDs (including those that are experimental)
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/experimental-install.yaml
# Install Gateway API CRDs (only stable resources)
# NOTE: **Do not use this command if you already ran the `experimental-install`**
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yamlTODO: deployment manifests
The Controller requires you to provide your own Caddy instance, later we may provide a CRD that will allow us to automatically deploy and manage Caddy for you, but for now you can use our pre-made deployment templates (or bring your own).
Before deploying Caddy however, there are a few things you need to consider.
- Due to the way we program Caddy, we send an HTTP request to each Caddy pod. If your Caddy instances do not use TLS on the Admin API, any certificates programmed into Caddy will be sent over an unsecure connection and may be visible to malicious actors.
- Enforce strict NetworkPolicies on who can access the Caddy Admin API. Your Caddy instance will likely be exposed to the public internet and exposing the Caddy Admin API is extremely dangerous for security.
TODO: reference deployment templates
Copyright 2024 Matthew Penner
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
This project is in no way affiliated or associated with any of the following listed projects.
Parts of this controller would not be possible without the surrounding Kubernetes community and open-source projects.
I'd like to thank the Cilium maintainers and community contributors for the base logic for the controller implementation, allowing me to focus on Caddy integration rather than Gateway API semantics.
- Modifying a BackendTLSPolicy will not trigger reconciliation of the Gateway.