|
| 1 | +# DNS Service Configuration |
| 2 | + |
| 3 | +The _PlatformService DNS_ requires configuration in form of a custom resource that is registered during the `init` step of the operator. |
| 4 | +The `DNSServiceConfig` resource is cluster-scoped and must have the same name as the PlatformService it is meant for. |
| 5 | + |
| 6 | +```yaml |
| 7 | +apiVersion: dns.openmcp.cloud/v1alpha1 |
| 8 | +kind: DNSServiceConfig |
| 9 | +metadata: |
| 10 | + name: dns |
| 11 | + namespace: openmcp-system |
| 12 | +spec: |
| 13 | + externalDNSSource: |
| 14 | + chartName: charts/external-dns # path to the external-dns helm chart within the chosen repository |
| 15 | + git: |
| 16 | + url: https://github.com/kubernetes-sigs/external-dns |
| 17 | + interval: 1h |
| 18 | + ref: |
| 19 | + tag: v0.18.0 |
| 20 | + |
| 21 | + externalDNSForPurposes: |
| 22 | + - name: my-identifier # optional, for logging purposes only |
| 23 | + purposeSelector: |
| 24 | + and: |
| 25 | + - or: |
| 26 | + - name: foo |
| 27 | + - name: bar |
| 28 | + - name: asdf |
| 29 | + helmValues: |
| 30 | + foo: bar |
| 31 | + asdf: qwer |
| 32 | +``` |
| 33 | +
|
| 34 | +#### Helm Chart Source |
| 35 | +
|
| 36 | +`spec.externalDNSSource` is required and describes where to find the helm chart for the [external-dns](https://github.com/kubernetes-sigs/external-dns) controller. Next to `chartName`, it has to contain exactly one of either `git`, `helm` or `oci`. The content of this field will then be used as `spec` for a Flux [`GitRepository`](https://fluxcd.io/flux/components/source/gitrepositories/), [`HelmRepository`](https://fluxcd.io/flux/components/source/helmrepositories/), or [`OCIRepository`](https://fluxcd.io/flux/components/source/ocirepositories/), respectively. |
| 37 | + |
| 38 | +While the `HelmRepository` spec already contains a reference to a branch or tag, for `helm` and `oci`, the desired version can be specified by appending it to `chartName` with an `@` as separator, e.g. `chartName: charts/[email protected]`. The version is otherwise assumed to be `latest`. |
| 39 | + |
| 40 | +#### Purpose Mapping |
| 41 | + |
| 42 | +`spec.externalDNSForPurposes` maps purpose selectors to helm values for the external-dns deployment. Its `name` is optional and just used for better log and error messages. |
| 43 | + |
| 44 | +`helmValues` contains the values to be passed into the helm release. They are simply forwarded, but a few keywords are replaced with specific values: |
| 45 | +- `<provider.name>` resolves to the name of the `PlatformService`. |
| 46 | +- `<provider.namespace>` resolves to the namespace the operator pod is running in. |
| 47 | +- `<environment>` resolves to the PlatformService's environment. |
| 48 | +- `<cluster.name>` resolves to the name of the `Cluster` resource the deployment belongs to. |
| 49 | +- `<cluster.namespace>` resolves to the namespace of the `Cluster` resource the deployment belongs to. |
| 50 | + |
| 51 | +The `purposeSelector` defines which `Cluster` resources should get the `external-dns` deployment. Because a `Cluster` can have multiple purposes, a simple mapping from a purpose to the configuration would not suffice. Therefore, the `purposeSelector` field is a recursive struct that allows to specify complex purpose selectors. Exactly one of the allowed fields `name`, `and`, `or`, and `not` must be set: |
| 52 | +- The `name` field takes a string. If set, the selector matches if the shoot purposes contain the purpose with the given name. |
| 53 | +- `not` takes a purpose selector and negates its result. |
| 54 | +- `and` takes a list of purpose selectors and matches only if all of them match. |
| 55 | +- Similarly, `or` also takes a list of purpose selectors, but matches if at least one of them matches. |
| 56 | +- An empty purpose selector always matches. |
| 57 | + |
| 58 | +> It is not validated that only one of the mentioned fields is set. If multiple ones are set, only one of them will be evaluated and the rest will be ignored. |
| 59 | + |
| 60 | +Whenever a `Cluster` is reconciled, the selectors are applied in the order they are specified in. The first mapping where the selector matches decides the configuration with which `external-dns` is deployed. If no selector matches, `external-dns` is not deployed on the respective `Cluster`. |
| 61 | + |
| 62 | +##### Examples |
| 63 | + |
| 64 | +Here are a few examples for purpose selectors and what they match: |
| 65 | + |
| 66 | +###### Example 1 |
| 67 | +```yaml |
| 68 | +purposeSelector: |
| 69 | + name: foo |
| 70 | +``` |
| 71 | +Probably the most common use cases: Matches every `Cluster` where `spec.purposes` contains `foo`. |
| 72 | + |
| 73 | +###### Example 2 |
| 74 | +```yaml |
| 75 | +purposeSelector: {} |
| 76 | +``` |
| 77 | +Matches all `Cluster` resources. |
| 78 | + |
| 79 | +###### Example 3 |
| 80 | +```yaml |
| 81 | +purposeSelector: |
| 82 | + and: |
| 83 | + - or: |
| 84 | + - name: foo |
| 85 | + - name: bar |
| 86 | + - not: |
| 87 | + and: |
| 88 | + - name: foo |
| 89 | + - name: bar |
| 90 | +``` |
| 91 | +Basically an `XOR`, matches all `Cluster`s that have either `foo` or `bar` among their purposes, but not both of them. |
| 92 | + |
| 93 | +###### Example 4 |
| 94 | +```yaml |
| 95 | +purposeSelector: |
| 96 | + not: |
| 97 | + name: foo |
| 98 | +``` |
| 99 | +Matches all `Cluster` resources that do not have `foo` in their purpose list. |
0 commit comments