Skip to content

feat(api): Add appProtocol to InferencePool API for gRPC support#2162

Merged
k8s-ci-robot merged 4 commits intokubernetes-sigs:mainfrom
zetxqx:grpcsupapi
Jan 20, 2026
Merged

feat(api): Add appProtocol to InferencePool API for gRPC support#2162
k8s-ci-robot merged 4 commits intokubernetes-sigs:mainfrom
zetxqx:grpcsupapi

Conversation

@zetxqx
Copy link
Copy Markdown
Contributor

@zetxqx zetxqx commented Jan 16, 2026

What type of PR is this?

/kind feature

What this PR does / why we need it:

Add appProtocol field to InferencePool API for further gRPC support.
Also includes the proposal of gRPC support.

Which issue(s) this PR fixes:

Fixes #2164

Does this PR introduce a user-facing change?:

appProtocol field is added to InferencePoolSpec.Port

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 16, 2026
@netlify
Copy link
Copy Markdown

netlify Bot commented Jan 16, 2026

Deploy Preview for gateway-api-inference-extension ready!

Name Link
🔨 Latest commit 8846471
🔍 Latest deploy log https://app.netlify.com/projects/gateway-api-inference-extension/deploys/696e826370724e0008b8c34b
😎 Deploy Preview https://deploy-preview-2162--gateway-api-inference-extension.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Jan 16, 2026
@zetxqx
Copy link
Copy Markdown
Contributor Author

zetxqx commented Jan 16, 2026

The only failure is the CRD validation check.

From the CRD validation failure, it's really just because I added the CEL validation on targetPorts:
image

Thus, we need to force merge by approver for this PR.

/assign @ahg-g

@ahg-g
Copy link
Copy Markdown
Contributor

ahg-g commented Jan 16, 2026

/assign @robscott @danehans

Comment thread api/v1/inferencepool_types.go Outdated
// +kubebuilder:validation:MinItems=1
// +kubebuilder:validation:MaxItems=8
// +kubebuilder:validation:XValidation:message="port number must be unique",rule="self.all(p1, self.exists_one(p2, p1.number==p2.number))"
// +kubebuilder:validation:XValidation:message="all ports must have the same AppProtocol",rule="self.all(p, (has(p.appProtocol) ? p.appProtocol : 'Unset') == (has(self[0].appProtocol) ? self[0].appProtocol : 'Unset'))"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why define it in TargetPort if all ports must share the same protocol? why not define it directly here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, listing the pros and cons below. I feel add a single appProtocol in InferenceSpec is better. So I changed accordingly. PTAL

Option 1. the original change: add appProtocol to Port and create a separate Port for EndPointPicker.

Pros:

  1. more aligned with the structure of servicePort putting Port and AppProtocol at the same level.
  2. give possibility for future mix gRPC and http model support

Cons:

  1. break the goClient backward compatibility
  2. poor user experience, user has to explicitly set all the appProtocol for every ports

Option 2. new solution(the comment here), add appProtocol in parallel with targetPorts.

Pros:

  1. simple change
  2. no breaking change even in go client.
  3. simple user experience

Cons:

  1. a little different from servicePort
  2. don't support mix protocol model servers. But this could be a very rare use cases. and we can always introduce new appProtocol field to Port(as option 1) to override it if necessary.

Comment thread api/v1/inferencepool_types.go
@ahg-g
Copy link
Copy Markdown
Contributor

ahg-g commented Jan 20, 2026

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jan 20, 2026
@k8s-ci-robot
Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahg-g, zetxqx

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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 k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 20, 2026
@ahg-g
Copy link
Copy Markdown
Contributor

ahg-g commented Jan 20, 2026

@danehans @robscott this is not yet released, please take a look, I am approving just to unblock followup PRs.

@k8s-ci-robot k8s-ci-robot merged commit c68dde6 into kubernetes-sigs:main Jan 20, 2026
11 checks passed
RyanRosario pushed a commit to RyanRosario/gateway-api-inference-extension that referenced this pull request Jan 20, 2026
…ernetes-sigs#2162)

* Add appProtocol for gRPC support.

* rename the proposal folder to include pr number.

* move appprotocol out of Port.

* add default.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[gRPC] API Add AppProtocol to InferencePool and introduce EndpointPickerPort

5 participants