-
Notifications
You must be signed in to change notification settings - Fork 26
Added network policies and customizable node ports #24
Conversation
Hi @vitalyfilatov, Thanks! We'll update the master branch in a few days (for the new version). Once we do, I'll take a deeper look 🙂 |
- port: 8008 | ||
protocol: TCP | ||
to: | ||
- podSelector: |
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.
The agent-services pod should also be able to access the fileserver.
Also, what about access to various other services (possibly external?) - the agent services pod might be running management tasks that communicate with various external services...
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.
Hi Jake,
I didn't notice connections from agent-services to fileserver on my installation. Maybe because I just deployed it and it is actively used yet. We use kube-iptables-tailer to see dropped packets between k8s pods and it didn't show any dropped packets between agent-services and fileserver, that's why I didn't add a network policy for this.
So, the following connection is required, right?
From: agent-services
To: fileserver:8081
If, yes, I will create one more network policy for the connection above.
As for access to various other services - I have no a complete list of all the required connections. If they (connections) arise - I'd add network policies for all of them.
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.
Well, it's:
- apiserver -> elastic
- apiserver -> mongodb
- apiserver -> redis
- webserver -> apiserver
- webserver -> fileserver
- agent-services -> apiserver
- agent-services -> fileserver
And in the future, possibly:
- webserver -> agent-services (future)
- fileserver -> apiserver
- fileserver -> redis
- port: 8008 | ||
protocol: TCP | ||
to: | ||
- podSelector: |
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.
The webserver also acts as a reverse proxy for the fileserver (and in the future might also act as a reverse proxy to the agent services service)
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.
Sorry, I didn't catch what you mean here, could you please clarify? I'm not a profi in ClearML, I just deployed it once.
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.
Sure :) What I meant was that the webserver service (specifically the nginx it runs) can also redirect requests to the fileserver or to the agent services.
@@ -9,7 +9,7 @@ spec: | |||
ports: | |||
- port: {{ .Values.apiserver.service.port }} | |||
targetPort: {{ .Values.apiserver.service.port }} | |||
nodePort: 30008 | |||
nodePort: {{ .Values.apiserver.service.nodePort }} |
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 might be mistaken, but I don't see these in the values...?
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.
Right, I didn't push my values.yaml, should I?
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.
Well, as a rule - it you reference it, you should commit it as well :)
@vitalyfilatov another comment - can we have this somehow controllable from the values? Since this imposes restrictions, and since we might add features in the future that will require the apiserver, for example, to communicate with various external hosts (as specified by a user), I think this feature should be optional |
Due to certain specific of my k8s cluster deployment I kindly ask to introduce the following changes in the cloud-ready Helm chart: