Gardener

Appearance

Edit this page Report an issue
Was this page helpful?

Gardener DNS Extension for Cloudflare ​

Build

Project Gardener implements the automated management and operation of Kubernetes clusters as a service. Its main principle is to leverage Kubernetes concepts for all of its tasks.

Gardener supports external controllers for provider-specific behavior, as described in GEP-1.

This controller implements Gardener's extension contract for the Cloudflare provider.

An example for a ControllerRegistration resource that can be used to register this controller to Gardener can be found here.

Please find more information regarding the extensibility concepts and a detailed proposal here.

Supported Kubernetes versions ​

Compatibility follows the Gardener dependency in go.mod. See Gardener's supported shoot Kubernetes versions for the current list. The local test target and API reference generation both use Kubernetes 1.37; these settings do not define the full range of supported shoot versions.

How to start using or developing this extension controller locally ​

Run make start to start the controller locally.

Static code checks and tests can be executed by running make verify. We are using Go modules for Golang package dependency management and Ginkgo/Gomega for testing.

Releases ​

Release Please uses its Go strategy to maintain a release pull request on main, updating CHANGELOG.md and .release-please-manifest.json from Conventional Commits. Use fix: for bug fixes, feat: for features, and ! or a BREAKING CHANGE: footer for breaking changes. Before version 1.0, breaking changes bump the minor version.

Merge the release pull request to create the next v* tag and GitHub release. The release workflow checks out that tag, builds and uploads binaries with GoReleaser while preserving the Release Please notes, and publishes the versioned container image and Helm chart to GHCR. Separately, the build workflow publishes a snapshot image and chart after tests pass on pushes to main.

Enable Allow GitHub Actions to create and approve pull requests in the repository's Actions settings. To run CI automatically on release pull requests, configure the RELEASE_PLEASE_TOKEN Actions secret with a token that can write repository contents, issues, and pull requests. Without that secret, the workflow uses GITHUB_TOKEN; GitHub does not automatically trigger CI for pull requests it creates, so release PR checks must be triggered manually.

Feedback and Support ​

Feedback and contributions are always welcome. Please report bugs or suggestions as GitHub issues or join our Slack channel #gardener (please invite yourself to the Kubernetes workspace here).

Learn more! ​

Please find further resources about out project here:

Last updated: