ContainerPort protocol is a key field, which makes it required for server-side apply

[bouk]

Hi,

I was playing around with server-side apply and hit into a problem. Say I have a pod like this (very reduced case of course):

# pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test 
    ports:
    - containerPort: 1234

If I run kubectl apply -f pod.yml --server-side I get the following error:

Error from server: failed to create typed patch object: .spec.containers[name="test"].ports: element 0: associative list with keys has an element that omits key field "protocol"

This is unexpected, because ContainerPort specifies the protocol as an optional field, which defaults to TCP. I traced this error back to this repository, so I figured this is where it could be resolved.

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:18:23Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-16T01:01:59Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

[bouk]

I think keeping this restriction in will hamper the adoption of server-side applies greatly, for example the ingress-nginx config also misses the 'protocol' ports in its config: https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/provider/cloud-generic.yaml

cc @lavalamp

[apelisse]

Thanks @bouk, we're aware of this bug and we do want to fix it, thanks.

We have #83 that partially fixes it (still trying to figure out the best solution).

/assign @jennybuckley

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.

[apelisse]

/reopen

We care about this more than ever.

[k8s-ci-robot]

@apelisse: Reopened this issue.

In response to this:

/reopen

We care about this more than ever.

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/test-infra repository.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.

[bouk]

/reopen

[k8s-ci-robot]

@bouk: 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/test-infra repository.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.

[bouk]

/reopen

[k8s-ci-robot]

@bouk: 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/test-infra repository.

[bouk]

/remove-lifecycle rotten

[apelisse]

/remove-lifecycle rotten

[rocketraman]

Despite kubernetes/ingress-nginx#4791, the nginx controller still does not specify the protocol in all its configurations, so this still prevents --server-side from being used. See for example: https://github.com/kubernetes/ingress-nginx/blob/master/charts/ingress-nginx/templates/controller-service-webhook.yaml.

[apelisse]

Should be fixed in 1.20!

[codablock]

As I've deployed my first 1.20.2 cluster today, I retried server-side applying a Service without the protocol field being set and I still have the same issue. @apelisse Do you have a link to the PR that fixed this in 1.20?

[liggitt]

this was narrowly fixed for container port in 1.20. the service port default is addressed in master in kubernetes/kubernetes@dab5112

[apelisse]

the service port default is addressed in master in kubernetes/kubernetes@dab5112

@liggitt What do you think about backporting this to 1.20?