gatewayapi docs - #317
Conversation
✅ Deploy Preview for metal-stack-io ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
e408dff to
d688f42
Compare
Signed-off-by: Benjamin Ritter <benjamin.ritter@x-cellent.com>
d688f42 to
3bf85bc
Compare
Gerrit91
left a comment
There was a problem hiding this comment.
Thanks for writing this up! Left some comments, which I hope are helpful.
|
|
||
| ### Continued need for an Ingress Controller | ||
|
|
||
| For some vendor dependencies you will still require an ingress controller. Examples of services still relying on Ingress are Gardener and Thanos. As ingress-nginx is EoL we recommend switching to a different Ingress Controller implementation. |
There was a problem hiding this comment.
Gardener does not rely on an ingress controller from third-party.
|
|
||
| ### Familiarize yourself with Gateway API | ||
|
|
||
| Gateway API is more complex than Ingress and consists of multiple different resources and operator personas. The rest of the guide assumes a basic understanding of the `HTTPRoute`, `TCPRoute`, `Gateway`, `GatewayClass`. An introduction can be found [here](https://gateway-api.sigs.k8s.io/docs/introduction/) |
There was a problem hiding this comment.
| Gateway API is more complex than Ingress and consists of multiple different resources and operator personas. The rest of the guide assumes a basic understanding of the `HTTPRoute`, `TCPRoute`, `Gateway`, `GatewayClass`. An introduction can be found [here](https://gateway-api.sigs.k8s.io/docs/introduction/) | |
| Gateway API is more complex than Ingress and consists of multiple different resources and operator personas. The rest of the guide assumes a basic understanding of the `HTTPRoute`, `TCPRoute`, `Gateway`, `GatewayClass`. An introduction can be found [here](https://gateway-api.sigs.k8s.io/docs/introduction/). |
|
|
||
| ### Migrating Components | ||
|
|
||
| ::: warning |
There was a problem hiding this comment.
This block is not properly rendered in docusaurus.
| The old Ingress Controller and new Gateway are going to have different IP addresses. | ||
| ::: | ||
|
|
||
| Deploy the `HTTPRoutes` and `TCPRoutes` for each component using metal-role. *routes and Ingress resources can be deployed at the same time. To switch over a service to the Gateway, change the DNS record of that service from pointing to the Ingress Controller to the Gateway. |
There was a problem hiding this comment.
| Deploy the `HTTPRoutes` and `TCPRoutes` for each component using metal-role. *routes and Ingress resources can be deployed at the same time. To switch over a service to the Gateway, change the DNS record of that service from pointing to the Ingress Controller to the Gateway. | |
| Deploy the `HTTPRoute` and `TCPRoute` resources for each component using metal-role. Note that routes and Ingress resources can be deployed at the same time. To switch over a service to the Gateway, change the DNS record of that service from pointing to the Ingress Controller to the Gateway. |
| - name: metal-control-plane | ||
| sectionName: https | ||
| ``` | ||
|
|
There was a problem hiding this comment.
I was using a gateway resolver for cert-manager to issue certificates and for this scenario I manually copied the existing cert secrets over to the gateway namespace in order to make both services successfully reachable in parallel for a transition time window. Not sure if there is a better solution than that. Otherwise we could just recommend that there will be a short switchover phase where the services are not available until cert-manager was able to solve the DNS challenge for the IP address.
|
|
||
| Check your endpoints are still reachable on their expected host names/IP addresses. The easiest way to do that is to check with metalctl(metal-api)/metalctlv2(metal-apiserver). | ||
|
|
||
| It is also recommended to check if the DNS records really resolve the new Gateway and are not accessed via the old ingress infrastructure. Use `nslookup`/`dig` to check your hostname and make sure they resolve to the same IP address as the Gateway |
There was a problem hiding this comment.
| It is also recommended to check if the DNS records really resolve the new Gateway and are not accessed via the old ingress infrastructure. Use `nslookup`/`dig` to check your hostname and make sure they resolve to the same IP address as the Gateway | |
| It is also recommended to check if the DNS records really resolve the new Gateway and are not accessed via the old ingress infrastructure. Use `nslookup`/`dig` to check your hostname and make sure they resolve to the same IP address as the Gateway. |
Description
TODO
Used AI-Tools ✨