-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update port names for Services for istio compliance #170
Conversation
8b39c05
to
76e43f8
Compare
@@ -175,7 +175,7 @@ metadata: | |||
{{- include "retool.telemetry.labels" . | nindent 4 }} | |||
spec: | |||
ports: | |||
- name: statsd-udp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not needed, but just doing for consistency
Non-TCP based protocols, such as UDP, are not proxied. These protocols will continue to function as normal, without any interception by the Istio proxy but cannot be used in proxy-only components such as ingress or egress gateways.
https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/
afbeef3
to
289018a
Compare
289018a
to
f52c53a
Compare
*/}} | ||
{{- define "retool.multiplayer.name" -}} | ||
{{ template "retool.fullname" . }}-multiplayer-ws | ||
{{- end -}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was using this originally to name ports, but port names can be max 15 characters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO it could just be multiplayer-ws
as port name, since it will already be on a Service object which has the retool.fullname namespace in its own name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the service portName just had to have http- prefix, but will just keep as is for consistency
and then you can have "retool.name" be longer than 15 chars i suppose 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OH I thought this was still being used as port name, but didn't realize you stopped for that reason. good good.
6349293
to
f0798a9
Compare
@@ -241,7 +241,7 @@ spec: | |||
{{- end }} | |||
ports: | |||
- containerPort: {{ .Values.service.internalPort }} | |||
name: {{ template "retool.name" . }} | |||
name: http-server | |||
protocol: TCP | |||
{{- if .Values.livenessProbe.enabled }} | |||
livenessProbe: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no service defined here - attempted to add, but wasn't able to get it to compile template w/out error 👀
@@ -198,7 +198,7 @@ spec: | |||
- name: membership | |||
containerPort: {{ include (printf "temporal.%s.membershipPort" $service) $ }} | |||
protocol: TCP | |||
- name: metrics | |||
- name: http-metrics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't think we need this since this is the pod's port
protocol: TCP | ||
name: metrics | ||
name: http-metrics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would change this if also change above comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does changing it complicate anything? I was wondering the same, but OTOH I don't have the change if only for consistency of naming scheme, if it doesn't hurt anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe a very minor downtime if service port changes before new pod comes up?
but yeah agree if we make them consistent we should do for all (e.g. the two ports defined above)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh right, we're using a named targetPort here. good point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually I think technically, if this causes minor downtime, it's downtime either way, since we have to update targetPort
to match the pod's new port name which comes from the Deployment template. we could choose to or not to update name
here on the Service object to match purely for consistency, but I don't think that would have any downtime since the Service port number (port
here) doesn't change. I think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems like the ports that only need naming are on service and pod
https://istio.io/v1.0/docs/setup/kubernetes/spec-requirements/
I think will stick with the current changes then 👍
@alexlo03 Re-visiting this, I think it should work istio compliance requirements? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I think this is a better/cleaner/clearer approach 🙏
I do not know what the upgrade looks like for existing deployments - renaming a port "should be a no-op" but IDK for sure.
Addresses #144, alternate to #151
Addresses: #155, alternate to #156
Lighter weight approach than #154
https://istio.io/v1.0/docs/setup/kubernetes/spec-requirements/
https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/, could also use appProtocol if prefix in names is not desirable.
Tested in internal (balloon) instances.
(also fixes #155)