This helper is used in tests and pulls in unnecessary dependency, which should
not be used if kubeadm is to move to staging.
Replace with direct use of the GroupResource type.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
ValidateDNS1123Subdomain is a simple wrapper around IsDNS1123Subdomain, however
it's the only reason for us to pull k8s.io/kubernetes/pkg/apis/core/validation
as a dependency.
To avoid unnecessary dependencies, replace the use of ValidateDNS1123Subdomain
with IsDNS1123Subdomain.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
RBAC construction helpers are part of the Kubernetes internal APIs. As such,
we cannot use them once we move to staging.
Hence, replace their use with manual RBAC rule construction.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
During the control plane joins, sometimes the control plane returns an
expected error when trying to download the `kubeadm-config` ConfigMap.
This is a workaround for this issue until the root cause is completely
identified and fixed.
Ideally, this commit should be reverted in the near future.
kube-controller-manager.
If a service CIDR that overlaps with the cluster CIDR is
specified to kube-controller-manager then kube-controller-
manager will incorrectly allocate node CIDRs that overlap
with the service CIDR. The fix ensure that kubeadm
maps the --service-cidr to --service-cluster-ip-range for use
by kube-controller-manager.
As per docs, --allocate-node-cidrs must be true for
--service-cluster-ip-range to be considered. It does not make
sense for --cluster-cidr to be unspecified but for
--service-cluster-ip-range and --allocate-node-cidrs to be
set, since the purpose of these options is to have the
controller-manager do the per node CIDR allocation. Also
note that --service-cluster-ip-range is passed to the
api-server, so the presence of *just*
--service-cluster-ip-range should not imply that
--allocate-node-cidrs should be true.
Resolves: kubernetes/kubeadm/issues/1591
This fixes possible problems when kubeadm upgrade can't load the
InitConfig properly. Some new code introduced in
https://github.com/kubernetes/kubernetes/pull/75499 is placed between
the loading of the config and the error handling, hiding possible
errors.
This error cannot be ignored (as is the case now), since the cfg ptr.
returned from the configutil function will be nil in the case of an
error.
Signed-off-by: Odin Ugedal <odin@ugedal.com>
The existing logic already creates a proper "tree"
where a CA is always generated before the certs that are signed
by this CA, however the tree is not deterministic.
Always use the default list of certs when generating the
"kubeadm init phase certs" phases. Add a unit test that
makes sure that CA always precede signed certs in the default
lists.
This solves the problem where the help screen for "kubeadm
init" cert sub-phases can have a random order.
TestWatchBasedManager was racing with the default namespace creation.
To fix that flake and to ensure integration tests using a shared etcd
don't accidentally overlap in the future, move the three main tests
using the default namespace to separate namespaces, and have
TestWatchBasedManager create that namespace before it runs.
Make StartTestServer wait for default namespace creation, which will
reduce other flakes until future changes completely remove use of default
namespace.
From a failed integration run:
watch_manager_test.go:66: namespaces "default" not found
watch_manager_test.go:66: namespaces "default" not found
watch_manager_test.go:66: namespaces "default" not found
Similar to --token, do not allow the mixture of --config and
--certificate-key.
If the user has fed a config, it is expected that the certificate
key should also be provided in the config and not from
the command line.
