Refactoring the networkProfile configuration #48
Replies: 4 comments
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
The |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The current state of the API, nowadays, is the following.
Proposals
All of these fields are mandatory, although I'd say there's a standard for them.
port
: value 6443serviceCidr
: widely used10.96.0.0/16
podCidr
: widely used10.244.0.0/16
dnsServiceIPs
: widely used10.96.0.10
With that said, I think these could be easily used as default values, leaving the cluster administrator to specify overrides.
spec.networkProfile.domain
and renaming it tocertSANs
We know that Kamaji could be exposed in several ways, from dynamic Load Balancer to bare IP or Ingress resources.
In the latter case, we already support the required hostname to perform host matching, as well as generate the certificate required for it.
However, it some circumstances we could have a LoadBalancer reachable through a DNS, and suddenly, by a hostname that is not reported in any Kubernetes primitive.
With that said, we could add the new array of strings named
certSANs
with the following default values:localhost
127.0.0.1
0.0.0.0
With such option, an operator can easily add an arbitrary hostname, without worrying on the IP address or Ingress hostname used to expose the Tenant Control Plane since it's already covered by Kamaji.
Beta Was this translation helpful? Give feedback.
All reactions