kubeadm still generates RSA keys when deploying a node, but also
accepts ECDSA keys if they already exist pregenerated in the
directory specified in --cert-dir.
Add the functionality to support `CreateOrMutateConfigMap` and `MutateConfigMap`.
* `CreateOrMutateConfigMap` will try to create a given ConfigMap object; if this ConfigMap
already exists, a new version of the resource will be retrieved from the server and a
mutator callback will be called on it. Then, an `Update` of the mutated object will be
performed. If there's a conflict during this `Update` operation, retry until no conflict
happens. On every retry the object is refreshed from the server to the latest version.
* `MutateConfigMap` will try to get the latest version of the ConfigMap from the server,
call the mutator callback and then try to `Update` the mutated object. If there's a
conflict during this `Update` operation, retry until no conflict happens. On every retry
the object is refreshed from the server to the latest version.
Add unit tests for `MutateConfigMap`
* One test checks that in case of no conflicts, the update of the
given ConfigMap happens without any issues.
* Another test mimics 5 consecutive CONFLICT responses when updating
the given ConfigMap, whereas the sixth try it will work.
The function certs.NewCACertAndKey() is just a wrapper around
pkiutil.NewCertificateAuthority() which doesn't add any
additional functionality.
Instead use pkiutil.NewCertificateAuthority() directly.
Currently kubeadm produces an error upon parsing multiple
certificates stored in the cluster-info configmap. Yet it
should check all available certificates in a scenario like
CA key rotation.
Check all available CA certs against pinned certificate hashes.
Fixes https://github.com/kubernetes/kubeadm/issues/1399
In the case where newControlPlane is true we don't go through
getNodeRegistration() and initcfg.NodeRegistration.CRISocket is empty.
This forces DetectCRISocket() to be called later on, and if there is more than
one CRI installed on the system, it will error out, while asking for the user
to provide an override for the CRI socket. Even if the user provides an
override, the call to DetectCRISocket() can happen too early and thus ignore it
(while still erroring out).
However, if newControlPlane == true, initcfg.NodeRegistration is not used at
all and it's overwritten later on.
Thus it's necessary to supply some default value, that will avoid the call to
DetectCRISocket() and as initcfg.NodeRegistration is discarded, setting
whatever value here is harmless.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Windows worker nodes run kube-proxy as a Windows service.
In the future the kube-proxy DaemonSet might run on Windows nodes
too, but for now a temporary measure is needed to disable it.
Add a linux node selector in the kube-proxy manifest spec.
We have an existing helper function for this: runtime.SerializerInfoForMediaType()
This is common prep-work for encoding runtime.Objects into JSON/YAML for transmission over the wire or writing to ComponentConfigs.
If the k8s version argument passed to "upgrade plan" is missing
the logic should perform the following actions:
- fetch a "stable" version from the internet.
- if that fails, fallback to the local client version.
Currentely the logic fails because the cfg.KubernetesVersion is
defaulted to the version of the existing cluster, which
then causes an early exit without any ugprade suggestions.
See app/cmd/upgrade/common.go::enforceRequirements():
configutil.FetchInitConfigurationFromCluster(..)
Fix that by passing the explicit user value that can also be "".
This will then make the "offline getter" treat it as an explicit
desired upgrade target.
In the future it might be best to invert this logic:
- if no user k8s version argument is passed - default to the kubeadm
version.
- if labels are passed (e.g. "stable"), fetch a version from the
internet.
Used T.Run API for kubeadm tests in app/phases/*
This should improve testing output and make it more visible
which test is doing what.
Signed-off-by: Ed Bartosh <eduard.bartosh@intel.com>
Under certain circumstances, specially when using an insecure external
etcd cluster (no certificates), or when using external certificates (
no CA key), some keys inside the kubeadm-certs secret data can contain
the key with an empty value on the map.
When downloading certs just ignore those that are blank and inform the
user about it.
* Upload certificates: generate certificates and check that the kubeadm-certs
secret is populated with the expected contents.
* Download certificates: given we have a kubeadm-certs secret, ensure that
keys and certificates are copied on the expected target, and that depending
on the secret nature they have the expected permissions.
The fuzzer test for NodeRegistrationOptions is defaulting the CRISocket member.
This is a left over from the times this member was statically defaulted in the
config. Now that the member is dynamically defaulted, setting CRISocket to foo
can cause issues to get undetected by the fuzzer test with this member.
The resolution is to stop setting CRISocket in the fuzzer test.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
The standalone execution of upload-certs phase does not print
the key that that user should use for the newly uploaded encrypted
secret. Print this key in the upload-certs phase in both
standalone mode or if executed in the standard init workflow.
Make it possible to omit the printing if the user passes
--skip-certificate-key-print.
Also:
- Uppercase string in Printf call in copycerts.go
- Don't use V(1) for the "Skipping phase" message in uploadcerts.go
instead always print a message that the user case use
--experimental-upload-certs. This solves a problem if the user tried
the standalone phase but didn't pass --experimental-upload-certs.
CommonConfiguration is an interface, that aims at abstracting common
configuration of InitConfiguration and JoinConfiguration. It was never widely
used and never got too much functionality attached to it. With recent
developments in the kubeadm config field, it got even more out of touch with
reality and where things are going.
Thus, the only viable solution is to remove it completely.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Add ResetClusterStatusForNode() that clears a certain
control-plane node's APIEndpoint from the ClusterStatus
key in the kubeadm ConfigMap on "kubeadm reset".
Hardcoding a temp path of /tmp/... is not portable and can potentially cause
other issues (such as flakyness) too.
Use TempFile instead.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Certain join phases have flags that are redundant:
- getControlPlanePreparePhaseFlags():
- amend flags (use switch / case)
- add example for the parent command
- rename internal function and sub-phase "manifests"
to "control-plane"
- getControlPlaneJoinPhaseFlags():
- amend flags
- remove MacroCommandLongDescription
- move most unrelated to phases output to klog.V(1)
- rename some prefixes for consistency - e.g.
[kubelet] -> [kubelet-start]
- control-plane-prepare: print details for each generated CP
component manifest.
- uppercase the info text for all "[reset].." lines
- modify the text for one line in reset
Add an extra flag isSecondaryControlPlane to RunInitNodeChecks
which can be used to indicate that the node we are checking is
a secondary control-plane. In such a case we skip some tests
that are already covered by RunJoinNodeChecks and
RunOptionalJoinNodeChecks.
This implements the certificate download for the join process. If certificates
have been uploaded during init (or explicitly on any master node) and the secret
is still present in the cluster, the join process will try to download the secret
data, decrypting it with the provided key in the new `--certificate-key` flag.
The custom sub-set interfaces in init/join phases as a pattern
have isolation benefits - e.g. when a consumer imports these
but we don't want them to be able to call all methods from
the original object that satisfies a complete interface.
On the other hand these sub-set interfaces under phases/init
and phases/join are private.
Expose a couple of new common interfaces:
- InitData from phases/init/data.go
- JoinData from phases/join/data.go
Use these interfaces in init/join phases accordingly instead
of the sub-set interfaces.
Use compile-time type assertion to verify that these
interfaces can be satisfied by init.go's initData and
join.go's joinData.
Add NO-OP objects called testInitData and joinInitData
that can be used for unit testing if embedded.
This fixes the following error:
"error execution phase control-plane-join/etcd:
control-plane-join phase invoked with an invalid data struct"
The problem here is that joinData cannot be type-asserted
to the interface type under controlplanejoin.go (controlPlaneJoinData)
because joinData lacks KubeConfigPath.
Given we use KubeConfigPath in more than one place for join
it makes sense to define define the method and make it return:
kubeadmconstants.GetAdminKubeConfigPath()
This package contains public/private key utilities copied directly from
client-go/util/cert. All imports were updated.
Future PRs will actually refactor the libraries.
Updates #71004
- Rename FindExistingKubeConfig to GetKubeConfigPath
- Cobra supports a DefValue option which can be used
to differentiate between the cases where the user set a flag
and when a flag was unset, while still adding a default value.
Use this in options/generic.go for the kubeconfig flag.
- Remove the GetKubeConfigPath() logic from `reset` and `upgrade`
as these are node level kubeadm commands.
- Default kubeconfig values to "" everywhere where GetKubeConfigPath
is used. This allows to search for existing kubeconfig locations.
The structure `applyFlags` is meant to keep a user's
input from command line and as such should be immutable.
Use either a variable or the validated `InitConfig.KubernetesVersion`
field instead.
Currently kubeadm supports a couple of configuration versions - v1alpha3 and
v1beta1. The former is deprecated, but still supported.
To discourage users from using it and to speedup conversion to newer versions,
we disable the loading of deprecated configurations by all kubeadm
sub-commands, but "kubeadm config migrate".
v1alpha3 is still present and supported at source level, but cannot be used
directly with kubeadm and some of its internal APIs.
The added benefit to this is, that users won't need to lookup for an old
kubeadm binary after upgrade, just because they were stuck with a deprecated
config version for too long.
To achieve this, the following was done:
- ValidateSupportedVersion now has an allowDeprecated boolean parameter, that
controls if the function should return an error upon detecting deprecated
config version. Currently the only deprecated version is v1alpha3.
- ValidateSupportedVersion is made package private, because it's not used
outside of the package anyway.
- BytesToInitConfiguration and LoadJoinConfigurationFromFile are modified to
disallow loading of deprecated kubeadm config versions. An error message,
that points users to kubeadm config migrate is returned.
- MigrateOldConfig is still allowed to load deprecated kubeadm config versions.
- A bunch of tests were fixed to not expect success if v1alpha3 config is
supplied.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Moved all flag code from `staging/src/k8s.io/apiserver/pkg/util/[flag|globalflag]` to `component-base/cli/[flag|globalflag]` except for the term function because of unwanted dependencies.
Currently we maintain the state of the mode of interactiveness
by updating flags.nonInteractiveMode even if the flag hasn't been
set by the user.
Since the computation of the mode is done only once it's easier
and less error prone to calculate the mode in the function
sessionIsInteractive() without mutating any flags.
If /etc/kubeadm/amdin.conf doesn't exist kubeadm reset fails
with the error:
failed to load admin kubeconfig: open /root/.kube/config: no such file or directory
Fixed by properly checking if file exists before using it.
MigrateOldConfigFromFile is a function, whose purpose is to migrate one config
into another. It is working OK for now, but it has some issues:
- It is incredibly inefficient. It can reload and re-parse a single config file
for up to 3 times.
- Because of the reloads, it has to take a file containing the configuration
(not a byte slice as most of the rest config functions). However, it returns
the migrated config in a byte slice (rather asymmetric from the input
method).
- Due to the above points it's difficult to implement a proper interface for
deprecated kubeadm config versions.
To fix the issues of MigrateOldConfigFromFile, the following is done:
- Re-implement the function by removing the calls to file loading package
public APIs and replacing them with newly extracted package private APIs that
do the job with pre-provided input data in the form of
map[GroupVersionKind][]byte.
- Take a byte slice of the input configuration as an argument. This makes the
function input symmetric to its output. Also, it's now renamed to
MigrateOldConfig to represent the change from config file path as an input
to byte slice.
- As a bonus (actually forgotten from a previous change) BytesToInternalConfig
is renamed to the more descriptive BytesToInitConfiguration.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Remove the deprecated `scheduler.alpha.kubernetes.io/critical-pod` pod annotation and use
the `priorityClassName` first class attribute instead, setting all master components to
`system-cluster-critical`.
Add test files that exclude the field in question
under KubeletConfiguration -> evictionHard for non-Linux.
Add runtime abstraction for the test files in initconfiguration_tests.go
The current code logs an error and full blown backtrace if we fail to remove
the containers upon reset. This creates unneeded, huge and rather scary log
message. Fix that by leaving just the error message.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Found using script:
https://gist.github.com/dims/384dea60754042f61d79233603034038
Just run using:
`find . -name .import-restrictions | xargs python ~/junk/sanitize-import-boss.py`
The removed entries are either packages that got moved/renamed/deleted
but are still not cleaned up from .import-restrictions files.
Change-Id: I92c400f74e6f012cc75539311ed4de280e25e918
Currently ConfigFileAndDefaultsToInternalConfig and
FetchConfigFromFileOrCluster are used to default and load InitConfiguration
from file or cluster. These two APIs do a couple of completely separate things
depending on how they were invoked. In the case of
ConfigFileAndDefaultsToInternalConfig, an InitConfiguration could be either
defaulted with external override parameters, or loaded from file.
With FetchConfigFromFileOrCluster an InitConfiguration is either loaded from
file or from the config map in the cluster.
The two share both some functionality, but not enough code. They are also quite
difficult to use and sometimes even error prone.
To solve the issues, the following steps were taken:
- Introduce DefaultedInitConfiguration which returns defaulted version agnostic
InitConfiguration. The function takes InitConfiguration for overriding the
defaults.
- Introduce LoadInitConfigurationFromFile, which loads, converts, validates and
defaults an InitConfiguration from file.
- Introduce FetchInitConfigurationFromCluster that fetches InitConfiguration
from the config map.
- Reduce, when possible, the usage of ConfigFileAndDefaultsToInternalConfig by
replacing it with DefaultedInitConfiguration or LoadInitConfigurationFromFile
invocations.
- Replace all usages of FetchConfigFromFileOrCluster with calls to
LoadInitConfigurationFromFile or FetchInitConfigurationFromCluster.
- Delete FetchConfigFromFileOrCluster as it's no longer used.
- Rename ConfigFileAndDefaultsToInternalConfig to
LoadOrDefaultInitConfiguration in order to better describe what the function
is actually doing.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
systemd is the recommended driver as per the setup of running
the kubelet using systemd as the init system. Add a preflight
check that throws a warning if this isn't the case.
Currently JoinConfigFileAndDefaultsToInternalConfig is doing a couple of
different things depending on its parameters. It:
- loads a versioned JoinConfiguration from an YAML file.
- returns defaulted JoinConfiguration allowing for some overrides.
In order to make code more manageable, the following steps are taken:
- Introduce LoadJoinConfigurationFromFile, which loads a versioned
JoinConfiguration from an YAML file, defaults it (both dynamically and
statically), converts it to internal JoinConfiguration and validates it.
- Introduce DefaultedJoinConfiguration, which returns defaulted (both
dynamically and statically) and verified internal JoinConfiguration.
The possibility of overwriting defaults via versioned JoinConfiguration is
retained.
- Re-implement JoinConfigFileAndDefaultsToInternalConfig to use
LoadJoinConfigurationFromFile and DefaultedJoinConfiguration.
- Replace some calls to JoinConfigFileAndDefaultsToInternalConfig with calls to
either LoadJoinConfigurationFromFile or DefaultedJoinConfiguration where
appropriate.
- Rename JoinConfigFileAndDefaultsToInternalConfig to the more appropriate name
LoadOrDefaultJoinConfiguration.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
DetectUnsupportedVersion is somewhat uncomfortable, complex and inefficient
function to use. It takes an entire YAML document as bytes, splits it up to
byte slices of the different YAML sub-documents and group-version-kinds and
searches through those to detect an unsupported kubeadm config. If such config
is detected, the function returns an error, if it is not (i.e. the normal
function operation) everything done so far is discarded.
This could have been acceptable, if not the fact, that in all cases that this
function is called, the YAML document bytes are split up and an iteration on
GVK map is performed yet again. Hence, we don't need DetectUnsupportedVersion
in its current form as it's inefficient, complex and takes only YAML document
bytes.
This change replaces DetectUnsupportedVersion with ValidateSupportedVersion,
which takes a GroupVersion argument and checks if it is on the list of
unsupported config versions. In that case an error is returned.
ValidateSupportedVersion relies on the caller to read and split the YAML
document and then iterate on its GVK map checking if the particular
GroupVersion is supported or not.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
* Return `nil` instead of a pointer to an empty struct when possible,
before the pointer was introduced the empty struct was required.
* Explicitly accept only one argument maximum for `kubeadm join` as in
`kubeadm join <master>`.
* Accept no arguments for `kubeadm init`.
* Make phases leafs accept arguments, whereas intermediate phases
automatically gets set that they accept no arguments.
For historical reasons InitConfiguration is used almost everywhere in kubeadm
as a carrier of various configuration components such as ClusterConfiguration,
local API server endpoint, node registration settings, etc.
Since v1alpha2, InitConfiguration is meant to be used solely as a way to supply
the kubeadm init configuration from a config file. Its usage outside of this
context is caused by technical dept, it's clunky and requires hacks to fetch a
working InitConfiguration from the cluster (as it's not stored in the config
map in its entirety).
This change is a small step towards removing all unnecessary usages of
InitConfiguration. It reduces its usage by replacing it in some places with
some of the following:
- ClusterConfiguration only.
- APIEndpoint (as local API server endpoint).
- NodeRegistrationOptions only.
- Some combinations of the above types, or if single fields from them are used,
only those field.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Fix a couple of problems related to data used by the phases runners
of `init` and `join`.
1) make `newInitData()` and `newJoinData()` return pointers.
Methods of the data objects returned by these functions should
be able to modify fields in the data objects - e.g.
`func (d initData) Client()`. This allows us to store a state and
not execute the same logic multiple times - e.g. obtaining a client.
A side effect of this change is that the `new...` functions must return
pointers, so that casting the data object in a phase, from
`workflow.RunData` to a locally defined interface, works.
2) Make it possible to pass arguments from a parent command
to a sub-phase with regards to data initialization.
In output of "kubeadm init", there are two strings for meaning of
bootstrap token which are "bootstraptoken" and "bootstrap-token".
This changes `[bootstraptoken]` to `[bootstrap-token]`.
In order to allow for a smoother UX with CRIs different than Docker, we have to
make the --cri-socket command line flag optional when just one CRI is
installed.
This change does that by doing the following:
- Introduce a new runtime function (DetectCRISocket) that will attempt to
detect a CRI socket, or return an appropriate error.
- Default to using the above function if --cri-socket is not specified and
CRISocket in NodeRegistrationOptions is empty.
- Stop static defaulting to DefaultCRISocket. And rename it to
DefaultDockerCRISocket. Its use is now narrowed to "Docker or not"
distinguishment and tests.
- Introduce AddCRISocketFlag function that adds --cri-socket flag to a flagSet.
Use that in all commands, that support --cri-socket.
- Remove the deprecated --cri-socket-path flag from kubeadm config images pull
and deprecate --cri-socket in kubeadm upgrade apply.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
This avoids ending in a wrong cluster state by assuming that the
present certificates will work. It is specially important when we
are growing etcd from 1 member to 2, in which case in case of failure
upon joining etcd will be unavailable.
When the etcd cluster grows we need to explicitly wait for it to be
available. This ensures that we are not implicitly doing this in
following steps when they try to access the apiserver.
It may happen that both the git version and the remote version
are broken/inaccessible. In this case the broken remote version
would be used.
To overcome this situation fall back to the constant CurrentKubernetesVersion.
The alternative could be os.Exit(1).
Also this change fixes Bazel-based unit tests in air-gapped environment.
This is a minor cleanup which helps to make the code of kubeadm a bit
less error-prone by reducing the scope of local variables and
unexporting functions that are not meant to be used outside of their
respective modules.
e2e-node tests may use custom system specs for validating nodes to
conform the specs. The functionality is switched on when the tests
are run with this command:
make SYSTEM_SPEC_NAME=gke test-e2e-node
Currently the command fails with the error:
F1228 16:12:41.568836 34514 e2e_node_suite_test.go:106] Failed to load system spec: open /home/rojkov/go/src/k8s.io/kubernetes/k8s.io/kubernetes/cmd/kubeadm/app/util/system/specs/gke.yaml: no such file or directory
Move the spec file under `test/e2e_node/system/specs` and introduce a single
public constant referring the file to use instead of multiple private constants.
Selfhosting pivoting fails when using --store-certs-in-secrets
as controller-manager fails to start because of missing front-proxy CA
certificate:
unable to load client CA file: unable to load client CA file: open
/etc/kubernetes/pki/front-proxy-ca.crt: no such file or directory
Added required certificate to fix this.
This should fixkubernetes/kubeadm#1281
Modified command line options --authentication-kubeconfig and
--authorization-kubeconfig to point out to the correct location
of the controller-manager.conf
This should fix this controller-manager crash:
failed to get delegated authentication kubeconfig: failed to get
delegated authentication kubeconfig: stat
/etc/kubernetes/controller-manager.conf: no such file or directory
Related issue: kubernetes/kubeadm#1281
Used T.Run API for kubeadm tests in app/phases/selfhosting and
app/phases/update directories
This should improve testing output and make it more visible
which test is doing what.
Selfhosting pivoting fails when using --store-certs-in-secrets
as api-server fails to start because of missing etcd/ca and
apiserver-etcd-client certificates:
F1227 16:01:52.237352 1 storage_decorator.go:57] Unable to create storage backend:
config (&{ /registry [https://127.0.0.1:2379]
/etc/kubernetes/pki/apiserver-etcd-client.key
/etc/kubernetes/pki/apiserver-etcd-client.crt
/etc/kubernetes/pki/etcd/ca.crt true 0xc000884120 <nil> 5m0s 1m0s}),
err (open /etc/kubernetes/pki/apiserver-etcd-client.crt: no such file or directory)
Added required certificates to fix this.
Secret name for etc/ca certifcate has been converted to conform RFC-1123 subdomain
naming conventions to prevent this TLS secret creation failure:
unable to create secret: Secret "etcd/ca" is invalid: metadata.name:
Invalid value: "etcd/ca": a DNS-1123 subdomain must consist of lower
case alphanumeric characters, '-' or '.', and must start and end with an
alphanumeric character (e.g. 'example.com', regex used for validation is
'[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
Related issue: kubernetes/kubeadm#1281
Moved token related flags to constants.
Token related flags refactored into constants.
Moved token related flags to constants.
Used new Consts flags in api's validation
Build deps fix
Moved token related flags to constants.
Used new Consts flags in api's validation
Build deps fix
Lint fix
Lint BUILD
Fixed the following golint warnigns:
- package_validator.go:68:1: receiver name should not be an underscore, omit the name if it is unused
- package_validator.go:89:1: receiver name should be a reflection of its identity; don't use generic names such as "this" or "self"
- package_validator.go:96:1: receiver name should be a reflection of its identity; don't use generic names such as "this" or "self"
- package_validator.go:119:1: receiver name should be a reflection of its identity; don't use generic names such as "this" or "self"
When golint is run against kubeadm it reports severel warnings like
redundant if ...; err != nil check, just return error instead.
Fix the warnings by just returning error.
Replaced hardcoded "v0.12.0" strings with MinimumControlPlaneVersion and
MinimumKubeletVersion global variables.
This should help with a regular release version bumps.
Currently the function `cmd/kubeadm/app/util.validateStableVersion()`
doesn't validate remote versions in the special case when the client
version is empty. This makes the code more difficult to reason about,
because the function may successfully return a string which isn't a valid version.
Move handling the special case outside of the function to the place
where its meaning is more obvious.
Despite we were checking for the kubelet kubeconfig file to be present, the
kubelet first writes this file and then the certificates the kubeconfig file
refers to. This represents a race condition in kubeadm in which when we confirm
that the kubelet's kubeconfig file is present we continue creating a clientset
out of it. However, the clientset creation will ensure that the certificates the
kubeconfig file refers to exist on the filesystem.
To fix this problem, not only wait for the kubelet's kubeconfig file to be
present, but also ensure that we can create a clientset ouf of it on our polling
process, while we wait for the kubelet to have performed the TLS bootstrap.
If we let the hostpath with DirectoryOrCreate to create this directory
it defaults to 0755. A default install should use 0700 for better
security especially if the directory is not present.
Change-Id: Idc0266685895767b0d1c5710c8a4fb704805652f
'kubeadm reset' uses incorrect way of unmounting /var/lib/kubelet
directories. It queries /proc/mounts for /var/lib/kubelet mount point.
If /var/lib/kubelet directory is also mounted it makes 'kubelet reset'
to unmount it too, which is incorrect. It also makes it fail as it
can't unmount /var/lib/kubelet before unmounting mounts inside it.
Fixed by querying /var/lib/kubelet/ instead of /var/lib/kubelet.
This should exclude /var/lib/kubelet from the query results even if
it's mounted.
Fixes: kubernetes/kubeadm#1294
As localApiEndpoint is ignored by json.Unmarshaller this should be
localAPIEndpoint as defined in the json tag of the source code.
Signed-off-by: André Martins <aanm90@gmail.com>
'kubeadm init' silently ignores --node-name and --cri-socket
command line options if --config option is specified.
Implemented setting 'name' and 'criSocket' options from the command
line even if --config command line option is used.
kubeadm config migrate uses AnyConfigFileAndDefaultsToInternal, which can
unmarshal config from file only if InitConfiguration or JoinConfiguration are
present. Even with that in mind, it can only return a singlie config object,
with InitConfiguration taking precendence over JoinConfiguration. Thus, the
following cases were not handled properly, while they were perfectly valid for
kubeadm init/join:
- ClusterConfiguration only file caused kubeadm config migrate to exit with
error.
- Init + Join configurations in the same file caused Init + Cluster
configuration to be produced (ignoring JoinConfiguration). The same is valid
when the combo is Init + Cluster + Join configurations.
- Cluster + Join configuration ignores ClusterConfiguration and only
JoinConfiguration gets migrated.
To fix this, the following is done:
- Introduce MigrateOldConfigFromFile which migrates old config from a file,
while ensuring that all kubeadm originated input config kinds are taken care
of. Add comprehensive unit tests for this.
- Replace the use of AnyConfigFileAndDefaultsToInternal in
kubeadm config migrate with MigrateOldConfigFromFile.
- Remove the no longer used and error prone AnyConfigFileAndDefaultsToInternal.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
'kubeadm join' silently ignores --node-name and --cri-socket
command line options if --config option is specified.
In some cases it's much easier for users to override these parameters
from the command line instead of updating config, especially for
multi-node automatic deployments where only node name should be changed.
Implemented setting 'name' and 'criSocket' options from the command
line even if --config command line option is used.
Bump MinimumControlPlaneVersion and MinimumKubeletVersion to v1.12 and update
any related tests.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Added hostport and host/port parts to the error messages
produced by ParseHostPort API.
This should help users to better identify parsing issues.
Fixes: kubernetes/kubeadm#1159
- make the whole config example actually pass strict verification
(i.e. make the config work with --config)
- add print init-defaults/join defaults
- other small fixes
When 'kubeadm init ...' is used with an IPv6 kubeadm configuration,
kubeadm currently generates an etcd.yaml manifest that uses IP:port
combinatins where the IP is an IPv6 address, but it is not enclosed
in square brackets, e.g.:
- --advertise-client-urls=https://fd00:20::2:2379
For IPv6 advertise addresses, this should be of the form:
- --advertise-client-urls=https://[fd00:20::2]:2379
The lack of brackets around IPv6 addresses in cases like this is
causing failures to bring up IPv6-only clusters with Kubeadm as
described in kubernetes/kubeadm Issues #1212.
This format error is fixed by using net.JoinHostPort() to generate
URLs as shown above.
Fixes kubernetes/kubeadm Issue #1212
ChooseAPIServerBindAddress is silently overriding the requested bind IP
address for the API server if that address is deemed unsuitable. This is
currently done only if the IP is a loopback one (127.0.0.0/8; ::1/128).
It's best to at least issue a warning if such override occurs, so that there
are no surprised users by this.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
The reason for the bump is the new functionality of the
k8s.io/utils/exec package which allows
- to get a hold of the process' std{out,err} as `io.Reader`s
- to `Start` a process and `Wait` for it
This should help on addressing #70890 by allowing to wrap std{out,err}
of the process to be wrapped with a `io.limitedReader`.
It also updates
- k8s.io/kubernetes/pkg/probe/exec.FakeCmd
- k8s.io/kubernetes/pkg/kubelet/prober.execInContainer
- k8s.io/kubernetes/cmd/kubeadm/app/phases/kubelet.fakeCmd
to implement the changed interface.
The dependency on 'k8s.io/utils/pointer' to the new version has also
been bumped in some staging repos:
- apiserver
- kube-controller-manager
- kube-scheduler
The kubelet allows you to set `--pod-infra-container-image`
(also called `PodSandboxImage` in the kubelet config),
which can be a custom location to the "pause" image in the case
of Docker. Other CRIs are not supported.
Set the CLI flag for the Docker case in flags.go using
WriteKubeletDynamicEnvFile().
Since docker 18.09, the ServerVersion field format changed: the `-ce`
or `-ee` suffix disappeared:
- docker 18.06: `18.06.1-ce`
- docker 18.09: `18.09.0`
This was not expected by the docker_validator version regexp, which
assumed newer docker versions ended with `-[a-z]{2}`.
This made the validator return an error, whereas we expect it to
return only a warning (by recognizing it as a newer but not yet
supported docker version).
This commit relax the version regexp to also recognize `18.09.0`.
The docker validator now returns a warning, as tested.
- Move from the old github.com/golang/glog to k8s.io/klog
- klog as explicit InitFlags() so we add them as necessary
- we update the other repositories that we vendor that made a similar
change from glog to klog
* github.com/kubernetes/repo-infra
* k8s.io/gengo/
* k8s.io/kube-openapi/
* github.com/google/cadvisor
- Entirely remove all references to glog
- Fix some tests by explicit InitFlags in their init() methods
Change-Id: I92db545ff36fcec83afe98f550c9e630098b3135
Up until now UnifiedControlPlaneImage existed as a string value as part of the
ClusterConfiguration. This provided an override for the Kubernetes core
component images with a single custom image. It is mostly used to override the
control plane images with the hyperkube image. This saves both bandwith and
disk space on the control plane nodes.
Unfortunately, this specified an entire image string (complete with its prefix,
image name and tag). This disables upgrades of setups that use hyperkube.
Therefore, to enable upgrades on hyperkube setups and to make configuration
more convenient, the UnifiedControlPlaneImage option is replaced with a boolean
option, called UseHyperKubeImage. If set to true, this option replaces the
image name of any Kubernetes core components with hyperkube, thus allowing for
upgrades and respecting the image repository and version, specified in the
ClusterConfiguration.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Create CSR using the mentioned function which also encodes the
type CertificateRequestBlockType.
Without that 'certs renew' is failing with:
'PEM block type must be CERTIFICATE REQUEST'
When node lease feature is enabled, kubelet reports node status to api server
only if there is some change or it didn't report over last report interval.
Added new alpha command to pivot to self hosted
Removed slelfhosting upgrade ability
Added warning message to self hosted pivot
added certs in secrets flag to new selfhosting comand
Until now the control plane timeout was fixed to 4 minutes and users did not
have the ability to change it. This commit allows that timeout to be configured
via the new `timeoutForControlPlane` option in the API server config (itself a
member of the ClusterConfiguration).
The default timeout is still 4 minutes.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Writable was added to HostPathMount in v1alpha1 in order to control if an extra
volume is mounted in read only or writable mode.
Usually, in Kubernetes, this option is referred to as ReadOnly, instead of
Writable and is defaulted to `false`. However, at the time, all extra volumes
to pods were defaulted to read-only. Therefore, to avoid changes to existing
v1alpha1 configs, this option had to be added with reversed meaning.
Hence, it's called `writable`.
Now, with the migration towards v1beta1, we can safely change this to ReadOnly
and get it in sync with the reset of Kubernetes.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
In v1alpha3's, control plane component config options were nested directly into
the ClusterConfiguration structure. This is cluttering the config structure and
makes it hard to maintain. Therefore the control plane config options must be
separated into different substructures in order to graduate the format to beta.
This change does the following:
- Introduces a new structure called ControlPlaneComponent, that contains fields
common to all control plane component types. These are currently extra args
and extra volumes.
- Introduce a new structure called APIServer that contains
ControlPlaneComponent and APIServerCertSANs field (from ClusterConfiguration)
- Replace all API Server, Scheduler and Controller Manager options in
ClusterConfiguration with APIServer, ControllerManager and Scheduler fields
of APIServer and ControlPlaneComponent types.
Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
