{"id":20840295,"url":"https://github.com/kong/kubernetes-configuration","last_synced_at":"2025-05-08T21:44:36.330Z","repository":{"id":247776669,"uuid":"826802981","full_name":"Kong/kubernetes-configuration","owner":"Kong","description":null,"archived":false,"fork":false,"pushed_at":"2025-05-02T09:28:34.000Z","size":2654,"stargazers_count":6,"open_issues_count":18,"forks_count":2,"subscribers_count":8,"default_branch":"main","last_synced_at":"2025-05-03T21:30:30.178Z","etag":null,"topics":["crd","kubernetes","team-k8s"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Kong.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":null,"support":".github/supported_k8s_node_images.yaml","governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2024-07-10T12:08:07.000Z","updated_at":"2025-04-29T10:22:16.000Z","dependencies_parsed_at":"2024-10-28T09:55:47.497Z","dependency_job_id":"8bfd8c2e-1a36-4594-9ef7-7aad030baec6","html_url":"https://github.com/Kong/kubernetes-configuration","commit_stats":null,"previous_names":["kong/kubernetes-configuration"],"tags_count":65,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Kong%2Fkubernetes-configuration","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Kong%2Fkubernetes-configuration/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Kong%2Fkubernetes-configuration/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Kong%2Fkubernetes-configuration/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Kong","download_url":"https://codeload.github.com/Kong/kubernetes-configuration/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253154177,"owners_count":21862471,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["crd","kubernetes","team-k8s"],"created_at":"2024-11-18T01:15:52.602Z","updated_at":"2025-05-08T21:44:36.314Z","avatar_url":"https://github.com/Kong.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# kubernetes-configuration\n\nThis repository holds the API definitions for Kong's Kubernetes configuration.\n\n## Repository structure\n\n- [`api/`][api] directory contains Go types that are the source for generating\n  - [`pkg/clientset`][clientset]: Go clientsets for users who want to interact\n    with Kong's Kubernetes configuration in Go\n- [`config/crd`][crd]: Kubernetes CRDs for all supported [channels]\n- [`test/`][test] directory contains Go tests\n  - [`test/crdsvalidation`][testcrdsvalidation] directory contains Go tests which\n    perform operations against a live Kubernetes cluster, testing [CEL][cel] rules\n    set on API types\n  - [`test/unit`][testunit] directory contains Go unit tests for generated Go types\n- [`docs/`][docs] directory contains generated API reference markdown files\n\n[api]: ./api/\n[clientset]: ./pkg/clientset/\n[crd]: ./config/crd\n[docs]: ./docs/\n[test]: ./test/\n[testcrdsvalidation]: ./test/crdsvalidation\n[testunit]: ./test/unit\n[cel]: https://kubernetes.io/docs/reference/using-api/cel/\n[channels]: #channels\n\n## Channels\n\nThis repository supports multiple _channels_ of CRDs. Each channel is an independent collection\nof CRDs that is meant to be used by a designated product or project. Manifests for each channel\nare stored in a separate directory under `config/crd/\u003cchannel\u003e` (each has a generated `kustomize.yaml` file as well).\n\nThe following channels are supported:\n- `ingress-controller` - CRDs for [Kong Ingress Controller][kic]\n- `ingress-controller-incubator` - experimental CRDs for [Kong Ingress Controller][kic]\n- `gateway-operator` - CRDs for [Kong Gateway Operator][kgo]\n\nA single CRD can be included in multiple channels. See [available custom markers](#available-custom-markers) for more details.\n\n[kic]: https://github.com/kong/kubernetes-ingress-controller\n[kgo]: https://github.com/kong/gateway-operator\n\n## Install CRDs\n\nIn order to install the CRDs from this repo, you can use the following command, replacing \n`\u003cchannel\u003e` with one of the supported [channel names](#channels).\n\n```terminal\nkustomize build github.com/kong/kubernetes-configuration/config/crd/\u003cchannel\u003e | kubectl apply -f -\n```\n\nOptionally you can specify the `ref` to use via the `?ref=\u003ctag\u003e` query parameter.\n\nFor example, to install the CRDs for the Kong Ingress Controller, you can run:\n\n```terminal\nkustomize build github.com/kong/kubernetes-configuration/config/crd/ingress-controller | kubectl apply -f -\n```\n\nTo install the CRDs from kubernetes-configuration v1.2.0 tag for the Kong Gateway Operator, you can run:\n\n```terminal\nkustomize build github.com/kong/kubernetes-configuration/config/crd/gateway-operator\\?ref=v1.2.0 | kubectl apply --server-side -f -\n```\n\n## Generate code\n\nIn order to run code generation in this repo you can use `make generate`.\n\n## Adding new CRDs\n\nWhen you add a new CRD make sure to\n\n- Annotate the CRD with `+kong:channels` marker to specify the channels that the CRD should be published to.\n- Add unit tests in [`test/unit`][testunit]\n- Add CRD validation tests in [`test/crdsvalidation`][testcrdsvalidation]\n- If you want `GetItems() []T` helper to be generated for your type,\n  add it to [supported type list][apitypes_funcs_gen_list].\n- If this CRD is meant to have Konnect helpers functions generated for it,\n  add it in [supported type list][apitypes_funcs_gen].\n- Annotate the CRD and any new type it depends on with the right markers to make sure it will be included \n  in the generated documentation. See [available markers](#Available custom markers).\n\n[crd_kustomization]: ./config/crd/kustomization.yaml\n[apitypes_funcs_gen]: ./scripts/apitypes-funcs/supportedtypes.go\n[apitypes_funcs_gen_list]: ./scripts/apitypes-funcs/supportedtypes.go#L112-114\n\n## How to release?\n\nReleases are driven by changes in the [`VERSION`](./VERSION) file.\nThis file contains 2 lines:\n\n- The first line is the version number (e.g. `1.0.0`).\n- The second line indicates if the version should be marked as latest or not\n  (e.g. `latest` for latest, anything else is not marked as latest).\n\nTo release a new version:\n\n- Pick a new version.\n- Make sure a changelog is updated with the new version, the release date, and all the changes.\n- Update the [`VERSION`](./VERSION) file with said version and whether the version should be marked as latest.\n  This can be done in a separate PR or along with the PR that introduces the changes.\n\nThe [`release_on_version_change.yaml`][release_on_change_workflow]\nworkflow will be triggered when a commit changing the `VERSION` file is pushed to the `main` branch.\nReleases created with this approach will be marked as latest\n\n[release_on_change_workflow]: .github/workflows/release_on_version_change.yaml\n\n## Available custom markers\n\n| Name                        | Applies to | Meaning                                                                                                                                                                                                                                                                |\n|-----------------------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `+kong:channels`            | Types      | Any root object type annotated with this marker will be included in a [CRD channel](#channels) 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). |\n| `+apireference:kgo:exclude` | Fields     | Any field annotated with this marker will be excluded from the [KGO's generated CRDs reference][kgo-crd-ref].                                                                                                                                                          |\n| `+apireference:kgo:include` | Types      | Any type annotated with this marker will be included in the [KGO's generated CRDs reference][kgo-crd-ref].                                                                                                                                                             |\n| `+apireference:kic:exclude` | Fields     | Any type annotated with this marker will be excluded from the [KIC's generated CRDs reference][kic-crd-ref].                                                                                                                                                           |\n| `+apireference:kic:include` | Types      | Any type annotated with this marker will be included in the [KIC's generated CRDs reference][kic-crd-ref].                                                                                                                                                             |\n\n### Why do we need separate markers for API reference and channels?\n\nChannels are used to group CRDs into logical sets that are meant to be used by a specific product or project.\nAPI reference markers are used to control which types and fields are included in the generated API reference documentation.\nWhile the channels are enough to be defined on a root object type, the API reference markers need to be defined on\neach type or field that should be included/excluded in the generated API reference documentation.\n\nCurrently, we don't have a way to automatically generate API reference documentation based only on channels,\nso we need separate markers for this purpose.\n\n[kgo-crd-ref]: https://github.com/Kong/gateway-operator/blob/main/docs/api-reference.md\n[kic-crd-ref]: https://github.com/kong/kubernetes-ingress-controller/blob/main/docs/api-reference.md\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkong%2Fkubernetes-configuration","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkong%2Fkubernetes-configuration","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkong%2Fkubernetes-configuration/lists"}