feat: kgateway emitter

[puertomontt]

What type of PR is this?

/kind feature

depends on #305

What this PR does / why we need it:

Add kgateway emitter.

Which issue(s) this PR fixes:

Fixes #260

Does this PR introduce a user-facing change?:

Add kgateway emitter

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: puertomontt
Once this PR has been reviewed and has the lgtm label, please assign youngnick for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @puertomontt. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

[Stevenjin8]

/ok-to-test

[Stevenjin8]

We've got integration tests in work, so we can probably do those tests here.

[Stevenjin8]

Seems good, going to wait until @kkk777-7 PR merges first and #294

[Stevenjin8]

@puertomontt could you add yourself to the owners file and agree to

ingress2gateway/docs/emitters.md

Lines 61 to 83 in 2802595

	## Governance and Maintainability
	To ensure long-term stability, we list clear expectations for Gateway API implementations that wish to have custom emitters in ingress2gateway.
	* All code that serves a single vendor or implementation ("third-party code") MUST have nominated contacts for security that will respond within at most 3 business days, if we find security issues.
	* All third-party code MUST live in individual directories/modules, with `CODEOWNERS` indicating who is responsible for reviewing that code.
	* Reviews and issues about third-party code MUST be triaged and responded to within 30 days.
	Furthermore, the codeowners of third-party emitters MUST commit to the following responsibilities:
	* Update the third-party emitters to keep up with upstream Gateway API changes within 60 days of a new Gateway API release.
	* Ensure that the output of third-party emitters matches the scope defined below within 60 days of a new Gateway API release.
	Not keeping up with these responsibilities will trigger a removal process for the affected third-party emitters which is as follows:
	* In the next minor release, the emitters will be marked as deprecated, triggering a warning to users.
	* The emitters will be removed in the following minor release or within 30 days, whichever comes later.
	* During this time, ingress2gateway maintainers will reach out to the codeowners with two emails spaced one week apart, notifying them of the impending removal as well as a GitHub issue.
	A codeowner can stop the removal process if they demonstrate commitment to the above policy as decided by the maintainers.
	Existing providers will be exempted from these policies, but may not be fully integrated into the provider/emitter model.

[Stevenjin8]

@puertomontt Also, it would be nice to add some e2e tests, but we can have that in another PR (sooner rather than later hopefully)

[k8s-ci-robot]

The OWNERS file contains untrusted users, which makes it INVALID. The following users are mentioned in OWNERS file(s) but are untrusted for the following reasons. One way to make the user trusted is to add them as members of the kubernetes-sigs org. You can then trigger verification by writing /verify-owners in a comment.

• puertomontt
  • User is not a member of the org. Satisfy at least one of these conditions to make the user trusted.