You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
***Authors:*** Lior Lieberman (Google), Kobi Levi (independent)
9
9
10
-
Today we are releasing [ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway), a tool that can help you migrate from Ingress to Gateway API. Gateway API is just weeks away from graduating to GA, if you haven't upgraded yet, now's the time to think about it!
10
+
Today we are releasing [ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway), a tool
11
+
that can help you migrate from Ingress to Gateway API. Gateway API is just weeks away from
12
+
graduating to GA, if you haven't upgraded yet, now's the time to think about it!
11
13
12
14
## Background
13
15
14
-
In the ever-evolving world of Kubernetes, networking plays a pivotal role. As more applications are deployed in Kubernetes clusters, effective exposure of these services to clients outside the cluster becomes a critical concern. If you've been working with Kubernetes, you're likely familiar with the [Ingress API], which has been the go-to solution for managing external access to services.
16
+
In the ever-evolving world of Kubernetes, networking plays a pivotal role. As more applications are
17
+
deployed in Kubernetes clusters, effective exposure of these services to clients outside the cluster
18
+
becomes a critical concern. If you've been working with Kubernetes, you're likely familiar with the
19
+
[Ingress API], which has been the go-to solution for managing external access to services.
The Ingress API provides a way to route external traffic to your applications within the cluster, making it an indispensable tool for many Kubernetes users. Ingress has its limitations however, and as applications become more complex and the demands on your Kubernetes clusters increase, these limitations can become bottlenecks.
23
+
The Ingress API provides a way to route external traffic to your applications within the cluster,
24
+
making it an indispensable tool for many Kubernetes users. Ingress has its limitations however, and
25
+
as applications become more complex and the demands on your Kubernetes clusters increase, these
26
+
limitations can become bottlenecks.
19
27
20
28
Some of the limitations are:
21
29
22
-
-**Insufficient common denominator** - by attempting to establish a common denominator for various HTTP proxies, Ingress can only accommodate basic HTTP routing, forcing more features of contemporary proxies like traffic splitting and header matching into provider-specific, non-transferable annotations.
23
-
-**Inadequate permission model** - Ingress spec configures both infrastructure and application configuration in one object. With Ingress, the cluster operator and application developer operate on the same Ingress object without being aware of each other’s roles. This creates an insufficient role-based access control and has high potential for setup errors.
24
-
-**Lack of protocol diversity** - Ingress primarily focuses on HTTP(S) routing and does not provide native support for other protocols, such as TCP, UDP and gRPC. This limitation makes it less suitable for handling non-HTTP workloads.
30
+
-**Insufficient common denominator** - by attempting to establish a common denominator for various
31
+
HTTP proxies, Ingress can only accommodate basic HTTP routing, forcing more features of
32
+
contemporary proxies like traffic splitting and header matching into provider-specific,
33
+
non-transferable annotations.
34
+
-**Inadequate permission model** - Ingress spec configures both infrastructure and application
35
+
configuration in one object. With Ingress, the cluster operator and application developer operate
36
+
on the same Ingress object without being aware of each other’s roles. This creates an insufficient
37
+
role-based access control and has high potential for setup errors.
38
+
-**Lack of protocol diversity** - Ingress primarily focuses on HTTP(S) routing and does not provide
39
+
native support for other protocols, such as TCP, UDP and gRPC. This limitation makes it less
40
+
suitable for handling non-HTTP workloads.
25
41
26
-
To overcome this, Gateway API is designed to provide a more flexible, extensible, and powerful way to manage external traffic to your services.
42
+
## Gateway API
27
43
28
-
Gateway API is just weeks away from a GA release. It provides a standard Kubernetes API for ingress traffic control. It offers extended functionality, improved customization, and greater flexibility. By focusing on modular and expressive API resources, Gateway API makes it possible to describe a wider array of routing configurations and models.
44
+
To overcome this, Gateway API is designed to provide a more flexible, extensible, and powerful way
45
+
to manage external traffic to your services.
29
46
30
-
The transition from Ingress API to Gateway API in Kubernetes is driven by advantages and advanced functionalities that the Gateway API offers, with its foundation built on four core principles: a role-oriented approach, portability, expressiveness and extensibility.
47
+
Gateway API is just weeks away from a GA release. It provides a standard Kubernetes API for ingress
48
+
traffic control. It offers extended functionality, improved customization, and greater flexibility.
49
+
By focusing on modular and expressive API resources, Gateway API makes it possible to describe a
50
+
wider array of routing configurations and models.
31
51
32
-
### A Role-Oriented Approach
33
-
34
-
Gateway API employs a role-oriented approach that aligns with the conventional roles within organizations involved in configuring Kubernetes service networking. This approach enables infrastructure engineers, cluster operators, and application developers to collectively address different aspects of the Gateway API.
35
-
36
-
For instance, infrastructure engineers play a pivotal role in deploying GatewayClasses, cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them, laying the groundwork for robust service networking.
37
-
38
-
Subsequently, cluster operators utilize these GatewayClasses to deploy gateways.
39
-
A Gateway in Kubernetes' Gateway API defines how external traffic can be directed to Services within the cluster, essentially bridging non-Kubernetes sources to Kubernetes-aware destinations.
40
-
It represents a request for a load balancer configuration aligned with a GatewayClass’ specification.
41
-
The Gateway spec may not be exhaustive as some details can be supplied by the GatewayClass controller, ensuring portability.
42
-
Additionally, a Gateway can be linked to multiple Route references to channel specific traffic subsets to designated services.
52
+
The transition from Ingress API to Gateway API in Kubernetes is driven by advantages and advanced
53
+
functionalities that the Gateway API offers, with its foundation built on four core principles: a
54
+
role-oriented approach, portability, expressiveness and extensibility.
43
55
44
-
Lastly, application developers configure route resources (such as HTTPRoutes), to manage configuration (e.g. timeouts, request matching/filter) and Service composition (e.g. path routing to backends)
45
-
Route resources define protocol-specific rules for mapping requests from a Gateway to Kubernetes Services.
46
-
HTTPRoute is for multiplexing HTTP or terminated HTTPS connections.
47
-
It's intended for use in cases where you want to inspect the HTTP stream and use HTTP request data for either routing or modification, for example using HTTP Headers for routing, or modifying them in-flight.
56
+
### A Role-Oriented Approach
48
57
49
-
{{< figure src="gateway-api-resources.svg" caption="Diagram showing the APIs that make up Gateway and how they relate to each other" >}}
58
+
Gateway API employs a role-oriented approach that aligns with the conventional roles within
59
+
organizations involved in configuring Kubernetes service networking. This approach enables
60
+
infrastructure engineers, cluster operators, and application developers to collectively address
61
+
different aspects of the Gateway API.
62
+
63
+
For instance, infrastructure engineers play a pivotal role in deploying GatewayClasses,
64
+
cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived
65
+
from them, laying the groundwork for robust service networking.
66
+
67
+
Subsequently, cluster operators utilize these GatewayClasses to deploy gateways. A Gateway in
68
+
Kubernetes' Gateway API defines how external traffic can be directed to Services within the cluster,
69
+
essentially bridging non-Kubernetes sources to Kubernetes-aware destinations. It represents a
70
+
request for a load balancer configuration aligned with a GatewayClass’ specification. The Gateway
71
+
spec may not be exhaustive as some details can be supplied by the GatewayClass controller, ensuring
72
+
portability. Additionally, a Gateway can be linked to multiple Route references to channel specific
73
+
traffic subsets to designated services.
74
+
75
+
Lastly, application developers configure route resources (such as HTTPRoutes), to manage
76
+
configuration (e.g. timeouts, request matching/filter) and Service composition (e.g. path routing to
77
+
backends) Route resources define protocol-specific rules for mapping requests from a Gateway to
78
+
Kubernetes Services. HTTPRoute is for multiplexing HTTP or terminated HTTPS connections. It's
79
+
intended for use in cases where you want to inspect the HTTP stream and use HTTP request data for
80
+
either routing or modification, for example using HTTP Headers for routing, or modifying them
81
+
in-flight.
82
+
83
+
{{< figure src="gateway-api-resources.svg" caption="Diagram showing the APIs that make up Gateway
84
+
and how they relate to each other" >}}
50
85
51
86
### Portability
52
-
With more than 20 [API implementations](https://gateway-api.sigs.k8s.io/implementations/#implementations), Gateway API is designed to be more portable across different implementations, clusters and environments. It helps reduce Ingress' reliance on non-portable, provider-specific annotations, making your configurations more consistent and easier to manage across multiple clusters.
87
+
With more than 20 [API
88
+
implementations](https://gateway-api.sigs.k8s.io/implementations/#implementations), Gateway API is
89
+
designed to be more portable across different implementations, clusters and environments. It helps
90
+
reduce Ingress' reliance on non-portable, provider-specific annotations, making your configurations
91
+
more consistent and easier to manage across multiple clusters.
53
92
54
-
Gateway API commits to supporting the 5 latest Kubernetes minor versions. That means that Gateway API currently supports Kubernetes 1.24+.
93
+
Gateway API commits to supporting the 5 latest Kubernetes minor versions. That means that Gateway
94
+
API currently supports Kubernetes 1.24+.
55
95
56
96
### Expressiveness
57
-
The Gateway API provides standard, Kubernetes-backed support for a wide range of features, such as header-based matching, traffic splitting, weight-based routing, request mirroring and more. With Ingress, these features need custom provider-specific annotations.
97
+
The Gateway API provides standard, Kubernetes-backed support for a wide range of features, such as
98
+
header-based matching, traffic splitting, weight-based routing, request mirroring and more. With
99
+
Ingress, these features need custom provider-specific annotations.
58
100
59
101
### Extensibility
60
-
Gateway API is designed with extensibility as a core feature. Rather than enforcing a one-size-fits-all model, it offers the flexibility to link custom resources at multiple layers within the API's framework. This layered approach to customization ensures that users can tailor configurations to their specific needs without overwhelming the main structure. By doing so, the Gateway API facilitates more granular and context-sensitive adjustments, allowing for a fine-tuned balance between standardization and adaptability. This becomes particularly valuable in complex cloud-native environments where specific use cases require nuanced configurations.
102
+
Gateway API is designed with extensibility as a core feature. Rather than enforcing a
103
+
one-size-fits-all model, it offers the flexibility to link custom resources at multiple layers
104
+
within the API's framework. This layered approach to customization ensures that users can tailor
105
+
configurations to their specific needs without overwhelming the main structure. By doing so, the
106
+
Gateway API facilitates more granular and context-sensitive adjustments, allowing for a fine-tuned
107
+
balance between standardization and adaptability. This becomes particularly valuable in complex
108
+
cloud-native environments where specific use cases require nuanced configurations.
61
109
62
110
63
111
## Upgrading to Gateway
64
112
65
-
1.[Install a Gateway controller](https://gateway-api.sigs.k8s.io/guides/#installing-a-gateway-controller) OR [install the Gateway API CRDs manually](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api)
113
+
Migrating from Ingress to the Gateway API may seem intimidating, but luckily Kubernetes just
114
+
released a tool to simplify the process.
115
+
[ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway) assists in the migration by
116
+
converting your existing Ingress resources into Gateway API resources. Here is how you can get
117
+
started with Gateway API and using ingress2gateway:
118
+
119
+
1.[Install a Gateway
120
+
controller](https://gateway-api.sigs.k8s.io/guides/#installing-a-gateway-controller) OR [install
121
+
the Gateway API CRDs manually](https://gateway-api.sigs.k8s.io/guides/#installing-gateway-api)
2. install [ingress2gateway](https://github.com/kubernetes-sigs/ingress2gateway) If you have a Go
124
+
development environment locally, you can install `ingress2gateway` with:
68
125
69
126
```
70
-
go install github.com/kubernetes-sigs/ingress2gateway@latest
127
+
go install github.com/kubernetes-sigs/ingress2gateway@v0.1.0
71
128
```
72
-
Provided you have a Go development environment installed, that command installs `ingress2gateway` to `$(go env GOPATH)/bin/ingress2gateway`.
73
129
74
-
Alternatively, you can build it from source by following [Build from source](https://github.com/kubernetes-sigs/ingress2gateway/tree/95b4a0316bac8d28d72b871a210bbc9bd6191eb7#build-from-source)
130
+
This installs `ingress2gateway` to `$(go env GOPATH)/bin/ingress2gateway`.
3. Once the tool is installed, you can use it to convert the ingress resources in your cluster to Gateway API resources.
135
+
3. Once the tool is installed, you can use it to convert the ingress resources in your cluster to
136
+
Gateway API resources.
77
137
78
138
```
79
139
ingress2gateway print
@@ -83,28 +143,39 @@ This above command will:
83
143
84
144
1. Read your Kube config file to extract the cluster credentials and the current active namespace.
85
145
1. Search for ingresses and provider-specific resources in that namespace.
86
-
1. Convert them to Gateway API resources (Currently only Gateways and HTTPRoutes).
87
-
For other options refer run the tool with `-h` or refer to https://github.com/kubernetes-sigs/ingress2gateway#options
146
+
1. Convert them to Gateway API resources (Currently only Gateways and HTTPRoutes). For other options
147
+
refer run the tool with `-h` or refer to https://github.com/kubernetes-sigs/ingress2gateway#options
88
148
89
149
4. Review the converted Gateway API resources, validate them, and then apply them to your cluster.
90
150
91
-
5. Update your DNS to point to the new Gateway.
151
+
5. Send test requests to your Gateway to check that it is working. You could get your gateway
152
+
address using `k get gateway <gateway-name> -n <namespace> -o
153
+
jsonpath='{.status.addresses}{"\n"}'`.
92
154
93
-
Note: make sure you test the newly created gateway before shifting the shifting 100% of the traffic.
155
+
6. Update your DNS to point to the new Gateway.
94
156
95
-
6. Once you've confirmed that no more traffic is going through your Ingress configuration, you can safely delete it.
157
+
7. Once you've confirmed that no more traffic is going through your Ingress configuration, you can
158
+
safely delete it.
96
159
97
160
## Wrapping up
98
-
Achieving reliable, scalable and extensible networking has always been a challenging objective.
99
-
The Gateway API is designed to improve the current Kubernetes networking standards like ingress and/or implementation specific annotations and CRDs.
161
+
Achieving reliable, scalable and extensible networking has always been a challenging objective. The
162
+
Gateway API is designed to improve the current Kubernetes networking standards like ingress and/or
163
+
implementation specific annotations and CRDs.
100
164
101
-
It is a Kubernetes standard API, consistent across different platforms and implementations and most importantly it is future proof. The Gateway API is considered the Ingress’ successor, it has a sub team under SIG Network that actively work on it and manage the ecosystem and it is likely to receive more updates and community support.
165
+
It is a Kubernetes standard API, consistent across different platforms and implementations and most
166
+
importantly it is future proof. The Gateway API is considered the Ingress’ successor, it has a sub
167
+
team under SIG Network that actively work on it and manage the ecosystem and it is likely to receive
168
+
more updates and community support.
102
169
103
-
Ingress2gateway tool helps to ease the migration process for you, converting an existing Ingress object to equivalent objects from Gateway. To make migrations even easier, Ingress2gateway has recently added extensions to enable converting from provider-specific solutions, enabling it to translate implementation-specific CRDs or Ingress annotations to the closest Gateway API equivalent.
170
+
Ingress2gateway tool helps to ease the migration process for you, converting an existing Ingress
171
+
object to equivalent objects from Gateway. To make migrations even easier, Ingress2gateway has
172
+
recently added extensions to enable converting from provider-specific solutions, enabling it to
173
+
translate implementation-specific CRDs or Ingress annotations to the closest Gateway API equivalent.
104
174
105
175
106
176
### Try it out and get involved
107
177
There are many resources to check out and learn more:
108
-
- Get involved with the Ingress2Gateway project on [GitHub](https://github.com/kubernetes-sigs/ingress2gateway)
178
+
- Get involved with the Ingress2Gateway project on
0 commit comments