You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is very handy to be able to store the default cluster DNS name so
that I can fire up and teardown clusters easily without losing that
setting. You can think of this as a default value for the
`start --dns-domain <val>` flag, but only when starting a new cluster.
In my particular case, I would like to set my default cluster dna domain
to a subdomain under a domain that I control. E.g.
`cluster.wt.user.dev.example.com`. I want to do this to make it easier
to manage TLS certs for my dev cluster.
For context, the `start --dns-domain <val>` flag works like this:
If you fire up a new cluster with that flag, you will get a new cluster
with the domain name base. If you start an existing cluster, the
config will be updated to the new domain name base and then started.
This config will work a little differently. The change implements a
config that will only affect newly started cluster. Here are some
examples to show that difference:
Newly started cluster example:
```
$ minikube config set DefaultClusterDNSDomain cluster2.local
$ minikube start
...
```
Stop and starting the cluster with `--dns-domain` flag:
```
$ minikube stop
...
$ minikub start --dns-domain cluster3.local
...
```
Stopping and starting a new cluster with a non-default domain name and
without the `--dns-domain` flag:
```
$ minikube stop
...
$ minikub start
...
```
The reason for this behavior is that I am not configuring the name of a
cluster. That is a cluster configuration option. I am setting the
default for that.
If I manually overrode the name of a cluster when started previously, I
don't want a default option to override my cluster configuration.
Before:
User cannot cannot change the default DNS domain name for a cluster
to something other than cluster.local.
On cluster creation/start:
If a user runs `minikube start` without a `--dnsDomain` flag, the
cluster will have the dns domain "cluster.local". A cluster setting
is persisted.
If a user runs 'minikube start --dnsDomain cluster.example.com`, the
cluster will hae the dns domain "cluster.example.com". A cluster
setting is persisted.
On cluster restart:
If a user run `minikube start`, the cluster's existing dns domain
(pulled from the persisted cluster config) dns domain will be used.
If a user runs `minikube start --dnsDomain cluster.example.com`, the
cluster's persisted dns name will be updated to the new name and the
cluster will be started with the new domain ("cluster.example.com").
Example command sequence:
```
$ minikube start --dnsDomain=cluster.example.com
# cluster now has dns domain "cluster.example.com"
$ minikube delete
$ minikube start
# cluster now has dns domain "cluster.local"
```
After:
The behavior of the minikube start flag `--dns-domain` does not
change at all. When the new configuration value is not set, all of the
behaviors from the "Before" section above will not change.
User can set the default cluster domain name to whatever they want
via the config option DefaultClusterDNSDomain. E.g.:
`minikube config set DefaultClusterDNSDomain cluster.wt.users.dev.example.com`
Since the case with no configuration is the same as before, here is a
description of what happens only with the new configuration set like
above.
On cluster creation/start:
If a user runs `minikube start` without a `--dnsDomain` flag, the
cluster will have the dns domain "cluster.wt.users.dev.example.com".
A cluster setting is persisted. This is the only thing that changes
with the configuration option set.
If a user runs 'minikube start --dnsDomain cluster.example.com`, the
cluster will hae the dns domain "cluster.example.com". A cluster
setting is persisted.
On cluster restart:
If a user run `minikube start`, the cluster's existing dns domain
(pulled from the persisted cluster config not from the new config)
dns domain will be used.
If a user runs `minikube start --dnsDomain cluster.example.com`, the
cluster's persisted dns name will be updated to the new name and the
cluster will be started with the new domain ("cluster.example.com").
Notice that the only case that changes with the new setting defined is
the case of starting a new cluster. Setting the config will change the
behavior of the "Before -> Example command sequence" section as
described:
Example command sequence:
```
$ minikube config set DefaultClusterDNSDomain cluster.wt.users.dev.example.com
$ minikube start --dnsDomain=cluster.example.com
# cluster now has dns domain "cluster.example.com"
$ minikube delete
$ minikube start
# cluster now has dns domain "cluster.wt.users.dev.example.com"
```
The important piece here is that I can now change the default
dnsDomain so that I don't have to specify it explicitly. This is
useful when I am starting and deleting a single cluster where I want
the top-level domain default to be a subdomain of a domain I control.
startCmd.Flags().String(featureGates, "", "A set of key=value pairs that describe feature gates for alpha/experimental features.")
224
-
startCmd.Flags().String(dnsDomain, constants.ClusterDNSDomain, "The cluster dns domain name used in the Kubernetes cluster")
224
+
startCmd.Flags().String(dnsDomain, constants.DefaultClusterDNSDomain, "The cluster dns domain name used in the Kubernetes cluster")
225
225
startCmd.Flags().Int(apiServerPort, constants.APIServerPort, "The apiserver listening port")
226
226
startCmd.Flags().String(apiServerName, constants.APIServerName, "The authoritative apiserver hostname for apiserver certificates and connectivity. This can be used if you want to make the apiserver available from outside the machine")
227
227
startCmd.Flags().StringSliceVar(&apiServerNames, "apiserver-names", nil, "A set of apiserver names which are used in the generated certificate for kubernetes. This can be used if you want to make the apiserver available from outside the machine")
0 commit comments