From 330a1deeb1f6befa28df67e9eff2f69ad739270c Mon Sep 17 00:00:00 2001 From: craig Date: Thu, 11 Jan 2024 15:34:03 +0000 Subject: [PATCH 1/7] draft dns configuration for gateway API GEP-2627 minor tweaks Update geps/gep-2627/index.md Co-authored-by: Candace Holman Update geps/gep-2627/index.md Co-authored-by: Candace Holman Update geps/gep-2627/index.md Co-authored-by: Candace Holman --- geps/gep-2627/index.md | 50 +++++++++++++++++++++++++++++++++++++ geps/gep-2627/metadata.yaml | 8 ++++++ 2 files changed, 58 insertions(+) create mode 100644 geps/gep-2627/index.md create mode 100644 geps/gep-2627/metadata.yaml diff --git a/geps/gep-2627/index.md b/geps/gep-2627/index.md new file mode 100644 index 0000000000..6cb11bae7f --- /dev/null +++ b/geps/gep-2627/index.md @@ -0,0 +1,50 @@ +# GEP-2627: DNS configuration within Gateway API + +* Issue: [#2627](https://github.com/kubernetes-sigs/gateway-api/issues/2627) +* Status: Provisional + +## TLDR + +For gateway infrastructure to be valuable we need to be able to connect clients to these gateways. A common way to achieve this is to use domain names/hostnames and DNS. Gateways define listeners that can have assigned hostnames or wildcards. The guidelines for DNS configuration are a critical piece of service networking, but this is currently not expressible as part of Gateway API. Instead of leaving this as an exercise for the user to figure out, this proposal attempts to provide options to ease Gateway API operations. + +## Goals +* Allow cluster operators or infrastructure providers to declaratively express which DNS service they want to use with a particular Gateway or Gateway Listener and have that DNS service interacted with via a controller to provision and configure the defined listener hostnames as DNS names and records based on the addresses assigned to the gateway instances. +* Provide a standard CRD-based API as an alternative to the need for "loose" APIs such as annotations. Support an easily extended, standardized, versioned, and status-reporting API. +* Increase portability and supportability across gateway providers and third party implementors, for this type of key configuration + +## Non-Goals + +* Cover more complex DNS routing strategies that come into play for multi-cluster topologies such as round robin, failover, health checks, weighted and geo location with this first pass. Supporting these types of use cases for distributed gateways (e.g., in different regions or multiple gateways for resilience within a region) and offering a form of global load balancing leveraging DNS is a potential future goal. + +## Use Cases + +As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used and limit which domains can be used. + +A a cluster administrator, I would like to have the dns names automatically populated into my specified dns zones as a set of records based on the assigned addresses of my gateways and have the status of the DNS records reported back to me, so that I do not have to undertake external automation or management of this essential task and can leverage existing kube based monitoring tools to know the status of the integration. + +As a cluster administrator, I would like the DNS records to be setup automatically based on the assigned gateways address and if the IP or hostname changes, I would like for the DNS to update automatically to ensure traffic continues to reach my gateway. + +## API + +Initial draft will not offer an API yet until the use cases are agreed. Some thoughts worth thinking about: +- I think it is important that we try to move away from APIs based on annotations which, while convenient, are not a full API and suffer from several limitations. An example: I want to configure a listener with a domain I own that is in a different provider than the domains of the other listeners. I want to add a new option to configure a particular weighting and so on. Soon you end up with a large set of connected annotations that often grow in complexity that really should be expressed as an API. + +- It is also important that this API can be delegated to controllers other than the Gateway provider. This is because there are existing solutions that may want to support whatever API decided upon. It should not **have** to be a gateway provider that has to integrate with many DNS providers. + +## Conformance Details + +(This section describes the names to be used for the feature or +features in conformance tests and profiles. + +These should be `CamelCase` names that specify the feature as +precisely as possible, and are particularly important for +Extended features, since they may be surfaced to users.) + +## Alternatives + +it is possible to use `external-dns` to manage dns based on HTTPRoutes and Gateways https://github.com/kubernetes-sigs/external-dns/blob/7f3c10d65297ec1c4bcc8dd6f88c189b7f3e80d0/docs/tutorials/gateway-api.md. The aim of this GEP is not remove this as an option, but instead provide a common API that could then be leveraged by something like external-dns. + +## References + +(Add any additional document links. Again, we should try to avoid +too much content not in version control to avoid broken links) \ No newline at end of file diff --git a/geps/gep-2627/metadata.yaml b/geps/gep-2627/metadata.yaml new file mode 100644 index 0000000000..31efe0e660 --- /dev/null +++ b/geps/gep-2627/metadata.yaml @@ -0,0 +1,8 @@ +apiVersion: internal.gateway.networking.k8s.io/v1alpha1 +kind: GEPDetails +number: 2627 +name: DNS configuration for Gateway API +status: Experimental +authors: + - maleck13 + \ No newline at end of file From f3c86ee944363dfb802341cfe4ab3b2090114c9f Mon Sep 17 00:00:00 2001 From: craig Date: Fri, 19 Jan 2024 10:02:42 +0000 Subject: [PATCH 2/7] changes post review --- geps/gep-2627/index.md | 21 +++++++++------------ geps/gep-2627/metadata.yaml | 2 +- 2 files changed, 10 insertions(+), 13 deletions(-) diff --git a/geps/gep-2627/index.md b/geps/gep-2627/index.md index 6cb11bae7f..ac7f62cbb9 100644 --- a/geps/gep-2627/index.md +++ b/geps/gep-2627/index.md @@ -8,9 +8,10 @@ For gateway infrastructure to be valuable we need to be able to connect clients to these gateways. A common way to achieve this is to use domain names/hostnames and DNS. Gateways define listeners that can have assigned hostnames or wildcards. The guidelines for DNS configuration are a critical piece of service networking, but this is currently not expressible as part of Gateway API. Instead of leaving this as an exercise for the user to figure out, this proposal attempts to provide options to ease Gateway API operations. ## Goals -* Allow cluster operators or infrastructure providers to declaratively express which DNS service they want to use with a particular Gateway or Gateway Listener and have that DNS service interacted with via a controller to provision and configure the defined listener hostnames as DNS names and records based on the addresses assigned to the gateway instances. -* Provide a standard CRD-based API as an alternative to the need for "loose" APIs such as annotations. Support an easily extended, standardized, versioned, and status-reporting API. -* Increase portability and supportability across gateway providers and third party implementors, for this type of key configuration +* Allow cluster operators to declaratively express which DNS service they want to use with a particular Gateway or Gateway Listener. +* Provide a mechanism to allow the DNS configuration to be delegated to a chosen controller. +* Provide a standard CRD-based API as an alternative to the need for "loose" APIs such as annotations. Support an easily extended, standardized, versioned, and status-reporting API. +* Increase portability and supportability between Gateway API implementations and third party controllers offering DNS integration. ## Non-Goals @@ -20,7 +21,9 @@ For gateway infrastructure to be valuable we need to be able to connect clients As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used and limit which domains can be used. -A a cluster administrator, I would like to have the dns names automatically populated into my specified dns zones as a set of records based on the assigned addresses of my gateways and have the status of the DNS records reported back to me, so that I do not have to undertake external automation or management of this essential task and can leverage existing kube based monitoring tools to know the status of the integration. +As a cluster administrator, I would like to have the DNS names automatically populated into my specified DNS zones as a set of records based on the assigned addresses of my gateways so that I do not have to undertake external automation or management of this essential task. + +As a cluster administrator I would have the status of the DNS records reported back to me, so that I can leverage existing kube based monitoring tools to know the status of the integration. As a cluster administrator, I would like the DNS records to be setup automatically based on the assigned gateways address and if the IP or hostname changes, I would like for the DNS to update automatically to ensure traffic continues to reach my gateway. @@ -33,12 +36,7 @@ Initial draft will not offer an API yet until the use cases are agreed. Some tho ## Conformance Details -(This section describes the names to be used for the feature or -features in conformance tests and profiles. - -These should be `CamelCase` names that specify the feature as -precisely as possible, and are particularly important for -Extended features, since they may be surfaced to users.) +TBD ## Alternatives @@ -46,5 +44,4 @@ it is possible to use `external-dns` to manage dns based on HTTPRoutes and Gatew ## References -(Add any additional document links. Again, we should try to avoid -too much content not in version control to avoid broken links) \ No newline at end of file +TBD \ No newline at end of file diff --git a/geps/gep-2627/metadata.yaml b/geps/gep-2627/metadata.yaml index 31efe0e660..d540d4bbef 100644 --- a/geps/gep-2627/metadata.yaml +++ b/geps/gep-2627/metadata.yaml @@ -2,7 +2,7 @@ apiVersion: internal.gateway.networking.k8s.io/v1alpha1 kind: GEPDetails number: 2627 name: DNS configuration for Gateway API -status: Experimental +status: Provisional authors: - maleck13 \ No newline at end of file From ac54f7ee22b5b845557935b50e2fbeffcb0316f3 Mon Sep 17 00:00:00 2001 From: craig Date: Fri, 8 Mar 2024 12:42:27 +0000 Subject: [PATCH 3/7] rewording --- geps/gep-2627/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/geps/gep-2627/index.md b/geps/gep-2627/index.md index ac7f62cbb9..64940ff146 100644 --- a/geps/gep-2627/index.md +++ b/geps/gep-2627/index.md @@ -10,7 +10,7 @@ For gateway infrastructure to be valuable we need to be able to connect clients ## Goals * Allow cluster operators to declaratively express which DNS service they want to use with a particular Gateway or Gateway Listener. * Provide a mechanism to allow the DNS configuration to be delegated to a chosen controller. -* Provide a standard CRD-based API as an alternative to the need for "loose" APIs such as annotations. Support an easily extended, standardized, versioned, and status-reporting API. +* Provide a standard CRD-based API with expressive status reporting and remove the need for "loose" APIs such as annotations. * Increase portability and supportability between Gateway API implementations and third party controllers offering DNS integration. ## Non-Goals @@ -19,7 +19,7 @@ For gateway infrastructure to be valuable we need to be able to connect clients ## Use Cases -As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used and limit which domains can be used. +As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used. As a cluster administrator, I would like to have the DNS names automatically populated into my specified DNS zones as a set of records based on the assigned addresses of my gateways so that I do not have to undertake external automation or management of this essential task. @@ -32,7 +32,7 @@ As a cluster administrator, I would like the DNS records to be setup automatical Initial draft will not offer an API yet until the use cases are agreed. Some thoughts worth thinking about: - I think it is important that we try to move away from APIs based on annotations which, while convenient, are not a full API and suffer from several limitations. An example: I want to configure a listener with a domain I own that is in a different provider than the domains of the other listeners. I want to add a new option to configure a particular weighting and so on. Soon you end up with a large set of connected annotations that often grow in complexity that really should be expressed as an API. -- It is also important that this API can be delegated to controllers other than the Gateway provider. This is because there are existing solutions that may want to support whatever API decided upon. It should not **have** to be a gateway provider that has to integrate with many DNS providers. +- It is also important that this API can be delegated to controllers other than the Gateway API provider/implementor. This is because there are existing solutions that may want to support whatever API decided upon. It should not **have** to be a gateway provider that has to integrate with many DNS providers. ## Conformance Details From c56f690dd779b21231a6ae54c3c92a8044a84340 Mon Sep 17 00:00:00 2001 From: Craig Brookes Date: Thu, 27 Jun 2024 08:49:25 +0100 Subject: [PATCH 4/7] Update geps/gep-2627/index.md Co-authored-by: Nick Young --- geps/gep-2627/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-2627/index.md b/geps/gep-2627/index.md index 64940ff146..a4124edd8a 100644 --- a/geps/gep-2627/index.md +++ b/geps/gep-2627/index.md @@ -25,7 +25,7 @@ As a cluster administrator, I would like to have the DNS names automatically pop As a cluster administrator I would have the status of the DNS records reported back to me, so that I can leverage existing kube based monitoring tools to know the status of the integration. -As a cluster administrator, I would like the DNS records to be setup automatically based on the assigned gateways address and if the IP or hostname changes, I would like for the DNS to update automatically to ensure traffic continues to reach my gateway. +As a cluster administrator, I would like the DNS records to be updated automatically if the `spec` of assigned gateways changes, whether those changes are for IP address or hostname. ## API From 2f42d0f9d02836ad97b86edc529415eceadf2b83 Mon Sep 17 00:00:00 2001 From: Craig Brookes Date: Thu, 27 Jun 2024 08:59:59 +0100 Subject: [PATCH 5/7] Update geps/gep-2627/index.md Co-authored-by: Nick Young --- geps/gep-2627/index.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/geps/gep-2627/index.md b/geps/gep-2627/index.md index a4124edd8a..34ac77345a 100644 --- a/geps/gep-2627/index.md +++ b/geps/gep-2627/index.md @@ -8,13 +8,16 @@ For gateway infrastructure to be valuable we need to be able to connect clients to these gateways. A common way to achieve this is to use domain names/hostnames and DNS. Gateways define listeners that can have assigned hostnames or wildcards. The guidelines for DNS configuration are a critical piece of service networking, but this is currently not expressible as part of Gateway API. Instead of leaving this as an exercise for the user to figure out, this proposal attempts to provide options to ease Gateway API operations. ## Goals -* Allow cluster operators to declaratively express which DNS service they want to use with a particular Gateway or Gateway Listener. -* Provide a mechanism to allow the DNS configuration to be delegated to a chosen controller. -* Provide a standard CRD-based API with expressive status reporting and remove the need for "loose" APIs such as annotations. +* Provide a way for Gateway API resource owners to mark their resources as relevant for external DNS provisioning +* Ensure that the above method has a way for multiple providers to be present in the cluster and be able to actuate external DNS provisioning requests +* Ensure that any method is based on structured fields and makes the most of `status` on whatever resources are relevant, whether they are existing Gateway API resources or new resources. * Increase portability and supportability between Gateway API implementations and third party controllers offering DNS integration. +* Clarity on the scope of hostnames under management. (This should _not_ be able to be used to affect the standard in-cluster DNS configuration) ## Non-Goals +* Anything to do with configuring in-cluster DNS. This support is for configuration outside the cluster only. +* Ways to define if the Gateway API resources are allowed to request particular hostnames. These choices should be left to the implementations that actually actuate the requests for hostnames. However, `status` flows should be specified so as to make clear if a hostname provisioning request cannot be performed. * Cover more complex DNS routing strategies that come into play for multi-cluster topologies such as round robin, failover, health checks, weighted and geo location with this first pass. Supporting these types of use cases for distributed gateways (e.g., in different regions or multiple gateways for resilience within a region) and offering a form of global load balancing leveraging DNS is a potential future goal. ## Use Cases From 46615d1f27eeb59bb17fd21305412da4ccc313b2 Mon Sep 17 00:00:00 2001 From: Craig Brookes Date: Thu, 27 Jun 2024 09:00:49 +0100 Subject: [PATCH 6/7] Update geps/gep-2627/index.md Co-authored-by: Nick Young --- geps/gep-2627/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-2627/index.md b/geps/gep-2627/index.md index 34ac77345a..fdce6564cd 100644 --- a/geps/gep-2627/index.md +++ b/geps/gep-2627/index.md @@ -22,7 +22,7 @@ For gateway infrastructure to be valuable we need to be able to connect clients ## Use Cases -As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used. +As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which gateways should be used for provisioning DNS records, and, if necessary, which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used. As a cluster administrator, I would like to have the DNS names automatically populated into my specified DNS zones as a set of records based on the assigned addresses of my gateways so that I do not have to undertake external automation or management of this essential task. From 43f18b492b3176d6b58f13e6319a0401cc62b863 Mon Sep 17 00:00:00 2001 From: Craig Brookes Date: Thu, 27 Jun 2024 09:05:14 +0100 Subject: [PATCH 7/7] Update geps/gep-2627/index.md Co-authored-by: Nick Young --- geps/gep-2627/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-2627/index.md b/geps/gep-2627/index.md index fdce6564cd..0d080a4d87 100644 --- a/geps/gep-2627/index.md +++ b/geps/gep-2627/index.md @@ -29,7 +29,7 @@ As a cluster administrator, I would like to have the DNS names automatically pop As a cluster administrator I would have the status of the DNS records reported back to me, so that I can leverage existing kube based monitoring tools to know the status of the integration. As a cluster administrator, I would like the DNS records to be updated automatically if the `spec` of assigned gateways changes, whether those changes are for IP address or hostname. - +As a DNS administrator, I should be able to ensure that only approved External DNS controllers can make changes to DNS zone configuration. (This should in general be taken care of by DNS system <-> External DNS controller interactions like user credentials and operation status responses, but it is important to remember that it needs to happen). ## API Initial draft will not offer an API yet until the use cases are agreed. Some thoughts worth thinking about: