feat: add schema ContainerPort and Route, to expose Service Container #16
Conversation
healthjyk
changed the title
| ---------- | ||
| port: int, default is 80, required. | ||
| The available port on the container. | ||
| accessMode: "Internal" | "Exposed", default is "Internal", required. |
There was a problem hiding this comment.
Generally, we consider Internal / Internet and exposed / unexposed as two different expressions of network type. Combining Internal and Exposed together sounds a little awkward. Any suggestions? @ffforest
There was a problem hiding this comment.
"Internal" and "Exposed" are take a reference of Acorn, ref: acorn ports
There was a problem hiding this comment.
I do agree they should be two sets of configurations. However, combining them into one is still reasonable in the sense that it describes the range to expose the container/port: Pod(Internal), Cluster(Exposed), Intranet, Internet.
Also I don't think this should be a container-port level configuration. That's too much details for the user to consider compared to "whether my application needs to be exposed to other applications".
There are corner cases like when a container has multiple ports, and some need to be exposed while some don't. But we should draw the line somewhere instead of trying to cater to every single edge case.
We have a few options here (there are probably problems with implementation details in each one):
1.We keep this as a container-port-level configuration and let user decide. My suggestion is to change this to a bool named exposed if we consider Internet/Intranet a separate question.
2.We consider this a container-level configuration. This introduces some constraints but it's easier to configure and understand.
3.We consider this an app configuration.
4.We can decide for the user (and eliminate this field) that for each container port defined, we will always expose it via a Kubernetes Service.
There was a problem hiding this comment.
I prefer to combine network/container_port and service/container_port together to reduce the user's cognitive load, as demonstrated by Acorn.
| pathType?: "Exact" | "Prefix" | ||
|
|
||
| # The backend container accessPort. | ||
| containerAccessPort: int |
There was a problem hiding this comment.
Can we simplify this field as accessPort like the naming in the ContainerPort? Are there any other kinds of access ports?
There was a problem hiding this comment.
This is my first design. If use accessPort, is there any confusing question? Does Route only serve container?
There was a problem hiding this comment.
According to my understanding, both route and container_port are designed for service or service containers. There is no other kind of accessPort used without a container.
What type of PR is this?
/kind feature
What this PR does / why we need it:
Add Schema ContainerPort and Route which belong to network, so that the Service Container can be accessed within and outside the cluster.
Special notes for your reviewer:
ContainerPort and Route aims to the TYPICAL scenario of exposing service within and outside cluster. Not all the Kubernetes Service types and CSP loadBalancers are supported.
The the most significant feature of ContainerPort and Route is concise, which provides out of box experience(OOBE).
Task a great reference of acorn Network.