Skip to content

Latest commit

 

History

History
113 lines (83 loc) · 6.73 KB

README.md

File metadata and controls

113 lines (83 loc) · 6.73 KB
Raw

kubernetes-configuration

This repository holds the API definitions for Kong's Kubernetes configuration.

👷 🚧 This is currently a work in progress which is heavily based on Kong's Ingress Controller CRDs Before KIC starts using these CRDs this repo should contain only additive, non-breaking changes on top of KIC's types.

Repository structure

  • api/ directory contains Go types that are the source for generating
    • pkg/clientset: Go clientsets for users who want to interact with Kong's Kubernetes configuration in Go
  • config/crd: Kubernetes CRDs for all supported channels
  • test/ directory contains Go tests
    • test/crdsvalidation directory contains Go tests which perform operations against a live Kubernetes cluster, testing CEL rules set on API types
    • test/unit directory contains Go unit tests for generated Go types
  • docs/ directory contains generated API reference markdown files

Channels

This repository supports multiple channels of CRDs. Each channel is an independent collection of CRDs that is meant to be used by a designated product or project. Manifests for each channel are stored in a separate directory under config/crd/<channel> (each has a generated kustomize.yaml file as well).

The following channels are supported:

A single CRD can be included in multiple channels. See available custom markers for more details.

Install CRDs

In order to install the CRDs from this repo, you can use the following command, replacing <channel> with one of the supported channel names.

kustomize build github.com/kong/kubernetes-configuration/config/crd/<channel> | kubectl apply -f -

For example, to install the CRDs for the Kong Ingress Controller, you can run:

kustomize build github.com/kong/kubernetes-configuration/config/crd/ingress-controller | kubectl apply -f -

Generate code

In order to run code generation in this repo you can use make generate.

Adding new CRDs

When you add a new CRD make sure to

  • Annotate the CRD with +kong:channels marker to specify the channels that the CRD should be published to.
  • Add unit tests in test/unit
  • Add CRD validation tests in test/crdsvalidation
  • If you want GetItems() []T helper to be generated for your type, add it to supported type list.
  • If this CRD is meant to have Konnect helpers functions generated for it, add it in supported type list.
  • Annotate the CRD and any new type it depends on with the right markers to make sure it will be included in the generated documentation. See [available markers](#Available custom markers).

How to release?

Currently, in order to make a new release/tag available for users to use is to create a new tag and push it to the repository.

Available custom markers

Name Applies to Meaning
+kong:channels Types Any root object type annotated with this marker will be included in a CRD channel passed as a marker value (e.g. +kong:channels=ingress-controller;gateway-operator will include the CRD both in ingress-controller and gateway-operator channels).
+apireference:kgo:exclude Fields Any field annotated with this marker will be excluded from the KGO's generated CRDs reference.
+apireference:kgo:include Types Any type annotated with this marker will be included in the KGO's generated CRDs reference.
+apireference:kic:exclude Fields Any type annotated with this marker will be excluded from the KIC's generated CRDs reference.
+apireference:kic:include Types Any type annotated with this marker will be included in the KIC's generated CRDs reference.

Why do we need separate markers for API reference and channels?

Channels are used to group CRDs into logical sets that are meant to be used by a specific product or project. API reference markers are used to control which types and fields are included in the generated API reference documentation. While the channels are enough to be defined on a root object type, the API reference markers need to be defined on each type or field that should be included/excluded in the generated API reference documentation.

Currently, we don't have a way to automatically generate API reference documentation based only on channels, so we need separate markers for this purpose.