Service targetPort guidance when customizing service's port #4068
Conversation
Added notes on changing service ports and potential disruptions.
✅ Vale Linting ResultsNo issues found on modified lines! |
eedugon
changed the title
eedugon
changed the title
| When you change the `clusterIP` setting of the service, ECK will delete and re-create the service as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
| When you change the `clusterIP` setting of the service, ECK deletes and re-creates the service, as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
|
|
||
| If you change the service’s `port`, set `targetPort` to the container’s default listening port. Otherwise, Kubernetes uses the same value for both, resulting in failed connections. For reference, default ports are `9200` for the {{es}} HTTP interface, and `5601` for {{kib}}. |
There was a problem hiding this comment.
We could also include a list of reference default ports, like:
- 9200 for ES HTTP
- 9300 for ES Transport
- 9443 for ES RCS (Remote cluster server)
- 5601 for Kibana
But I didn't want to make the note too big. Port 9300 is mentioned in the transport specific doc, and 9443 will be mentioned in the relevant docs.
There was a problem hiding this comment.
We also have other services, like Fleet on port 8220, Maps on 8080... So I was wondering if we should say "For example, ..." instead? (definitely not a strong opinion, feel free to ignore)
There was a problem hiding this comment.
I like "for example" - this makes me wonder if we have some sort of central resource we can link to for all of these ports though 🤔
| When you change the `clusterIP` setting of the service, ECK will delete and re-create the service as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
| When you change the `clusterIP` setting of the service, ECK deletes and re-creates the service, as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
|
|
||
| If you change the service’s `port`, set `targetPort` to the container’s default listening port. Otherwise, Kubernetes uses the same value for both, resulting in failed connections. For reference, default ports are `9200` for the {{es}} HTTP interface, and `5601` for {{kib}}. |
There was a problem hiding this comment.
We also have other services, like Fleet on port 8220, Maps on 8080... So I was wondering if we should say "For example, ..." instead? (definitely not a strong opinion, feel free to ignore)
shainaraskas
left a comment
shainaraskas
left a comment
There was a problem hiding this comment.
couple little thoughts, otherwise lgtm
| When you change the `clusterIP` setting of the service, ECK deletes and re-creates the service, as `clusterIP` is an immutable field. This causes a short network disruption, but it should not affect existing connections as the transport module uses long-lived TCP connections. | ||
|
|
||
| If you change the service’s `port`, set `targetPort` to `9300`, which is the default {{es}} transport interface port. Otherwise, Kubernetes uses the same value for both, resulting in failed connections. |
There was a problem hiding this comment.
consider adding bullets here, or making this stacked notes. when I read the first paragraph of a note, I make the assumption that the second paragraph is related to the first. one of these methods will help people to understand that these are two notes that are not related
| When you change the `clusterIP` setting of the service, ECK will delete and re-create the service as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
| When you change the `clusterIP` setting of the service, ECK deletes and re-creates the service, as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
|
|
||
| If you change the service’s `port`, set `targetPort` to the container’s default listening port. Otherwise, Kubernetes uses the same value for both, resulting in failed connections. For reference, default ports are `9200` for the {{es}} HTTP interface, and `5601` for {{kib}}. |
There was a problem hiding this comment.
I like "for example" - this makes me wonder if we have some sort of central resource we can link to for all of these ports though 🤔
| When you change the `clusterIP` setting of the service, ECK will delete and re-create the service as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
| When you change the `clusterIP` setting of the service, ECK deletes and re-creates the service, as `clusterIP` is an immutable field. Depending on your client implementation, this might result in a short disruption until the service DNS entries refresh to point to the new endpoints. | ||
|
|
||
| If you change the service’s `port`, set `targetPort` to the container’s default listening port. Otherwise, Kubernetes uses the same value for both, resulting in failed connections. For reference, default ports are `9200` for the {{es}} HTTP interface, and `5601` for {{kib}}. |
There was a problem hiding this comment.
same note about overloading the warning (use bullets or split the notes)
Added notes on changing service ports and potential disruptions.
Addresses elastic/cloud-on-k8s#7198