Support Gateway API extensions (output providers)

[arkodg]

What would you like to be added:

Add the ability to translate provider specific APIs into implementation specific Gateway API extensions (output providers) for fields not currently supported in the Gateway API

Why this is needed:
Adding ability to translate all input provider specific intent without losing any functionality
For e.g. the current ingress-nginx translation only translates a subset of the API (annotations) https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#annotations
Without this feature, its unlikely that the user will migrate to Gateway API until all the input provider features are supported in the Gateway API APIs
If this tool supports the notion of output providers, the input API could be translated to various implementation specific Gateway API extensions

[mlavacca]

Hi @arkodg , thanks for creating this issue! It looks reasonable to me 👍

[arkodg]

cool, I think istio is a good one to start off with and a use case would be to translate existing Istio resources in native istio type to Gateway API + Gateway API extensions defined in istio
we probably need an explicit flag ( e.g. --out-provider=istio) to opt into this
does this sgty @LiorLieberman @howardjohn ?

[LiorLieberman]

Thanks @arkodg.
Can you provide a bit more details?
Like maybe the full example you had in mind for a real scenario where a native Istio resource is translated to GW API resource Plus Extension?

Also I did not fully understand what --out-provider should represent?

[arkodg]

@LiorLieberman here's an example for Istio

Input

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
  namespace: test
spec:
  selector:
    app: istio-ingressgateway
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - test.com
  - port:
      number: 443
      protocol: HTTPS
    hosts:
    - "bookinfo/*.bookinfo.com"
    -  "*"
    tls:
      httpsRedirect: true
      mode: SIMPLE
      # all following tls related fields are ignored as there's no direct mapping to the k8s gateway api
      serverCertificate: /etc/certs/servercert.pem
      privateKey: /etc/certs/privatekey.pem
      credentialName: bookinfo-secret
      caCertificates: /etc/certs/caCertificates
      subjectAltNames: ["v1"]
      verifyCertificateSpki: ["v1"]
      verifyCertificateHash: ["v1"]
      minProtocolVersion: TLSV1_0
      maxProtocolVersion: TLSV1_3
      cipherSuites: ["v1"]
    bind: 1.2.3.4 # is ignored
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-nothing
 namespace: test
spec:
 selector:
   matchLabels:
     app: istio-ingressgateway
     istio: ingressgateway   

Output

piVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: test
spec:
  gatewayClassName: istio
  listeners:
  - name: https-protocol-bookinfo-ns-wildcard.bookinfo.com
    hostname: "*.bookinfo.com"
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
 ---
 apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-nothing
 namespace: test
spec:
  targetRef:
    kind: Gateway
    group: gateway.networking.k8s.io
    name:  my-gateway  

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[mlavacca]

@LiorLieberman here's an example for Istio

Input

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: my-gateway
  namespace: test
spec:
  selector:
    app: istio-ingressgateway
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - test.com
  - port:
      number: 443
      protocol: HTTPS
    hosts:
    - "bookinfo/*.bookinfo.com"
    -  "*"
    tls:
      httpsRedirect: true
      mode: SIMPLE
      # all following tls related fields are ignored as there's no direct mapping to the k8s gateway api
      serverCertificate: /etc/certs/servercert.pem
      privateKey: /etc/certs/privatekey.pem
      credentialName: bookinfo-secret
      caCertificates: /etc/certs/caCertificates
      subjectAltNames: ["v1"]
      verifyCertificateSpki: ["v1"]
      verifyCertificateHash: ["v1"]
      minProtocolVersion: TLSV1_0
      maxProtocolVersion: TLSV1_3
      cipherSuites: ["v1"]
    bind: 1.2.3.4 # is ignored
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-nothing
 namespace: test
spec:
 selector:
   matchLabels:
     app: istio-ingressgateway
     istio: ingressgateway   

Output

piVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: test
spec:
  gatewayClassName: istio
  listeners:
  - name: https-protocol-bookinfo-ns-wildcard.bookinfo.com
    hostname: "*.bookinfo.com"
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
 ---
 apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-nothing
 namespace: test
spec:
  targetRef:
    kind: Gateway
    group: gateway.networking.k8s.io
    name:  my-gateway  

I think this use case can be addressed by #78, but only when reading from files. With it, it will be possible to output all the input resources that do not belong to the set of converted resources. When it comes to reading resources from a cluster, that flag cannot be used as it is now in the PR.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[LiorLieberman]

/reopen

[k8s-ci-robot]

@LiorLieberman: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[LiorLieberman]

/assign @sawsa307

[sawsa307]

/remove-lifecycle rotten

[LiorLieberman]

@sawsa307 as discussed before, support for input and output providers is necessary to close this issue.

[sawsa307]

Yes I think #188 merge automatically triggered this since it said Fixes #125, I'll use a different description next time to tag this issue.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[gcasella]

I would like to make a suggestion here as well.
Instead of the output providing both kind: Gateway and kind: HTTPRoute I would suggest giving the option to only export the Gateway resource or HTTPRoute resource.

This would be useful if users are using a shared listener for example:

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: development-gateway
  namespace: sample-namespace
  annotations: 
    cert-manager.io/cluster-issuer: letsencrypt-staging
spec:
  infrastructure:
    annotations:
      lbipam.cilium.io/ips: 3.3.3.3
  gatewayClassName: cilium
  listeners:
    - name: https
      hostname: "*.example.com"
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-example.com-tls

In my use-case, i have multiple ingress-nginx resources defined, what would be nice is to migrate just the HTTPRoutes to use the Kubernetes GatewayAPI

The binary ingress2gateway works very well for me to print out the HTTPRoute resources from the input provider of ingress-nginx, but it is a bit tedious for me to copy and paste ONLY the HTTPRoute section.

What would be REALLY cool is if there were a way to automatically convert an existing resource from an input provider and then automatically create the new resource required.

These are just my two cents.

[LiorLieberman]

Hi @gcasella, thanks for the idea! Two points;

1. Can you please open a new issue with that? I think its a bit different than this issue
2. I am not quite sure I understood exactly the idea, is it to be able to filter the output of the tool by resource? I think I did not understand the last paragraph when you talked on auto creation.

Thanks!