Restarting snap.kubelet.daemon service results in failed to parse kubelet flag: unknown flag: --container-runtime
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Kubernetes Control Plane Charm |
In Progress
|
Low
|
Kevin W Monroe |
Bug Description
The control plane of my Charmed Kubernetes deployment got blocked because the kubelet service stopped in both nodes.
App Version Status Scale Charm Channel Rev Exposed Message
kubernetes-
kubernetes-worker 1.27.1 waiting 3 kubernetes-worker latest/stable 87 yes Waiting for kubelet to start.
The charm in trying to restart it, but falls into the following error:
$ sudo snap logs kubelet.daemon
2023-04-
2023-04-
2023-04-
2023-04-
2023-04-
2023-04-
2023-04-
2023-04-
2023-04-
2023-04-
$ sudo snap info kubelet
installed: 1.27.1 (2945) 22MB classic,in-cohort
The upstream documentation says:
--container-runtime string Default: remote
The container runtime to use. Possible values: docker, remote. (DEPRECATED: will be removed in 1.27 as the only valid value is 'remote')
--cloud-provider string
The provider for cloud services. Set to empty string for running with no cloud provider. If set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used). (DEPRECATED: will be removed in 1.24 or later, in favor of removing cloud provider code from Kubelet.)
https:/
The kubelet args looks like this in the snap:
$ cat /var/snap/
--kubeconfig=
To try, I sshed into the kubernetes-
$ sudo snap restart kubelet.daemon
But the charm will overwrite the snap config and restart it again falling in the same error.
summary: |
Restarting snap.kubelet.daemon service results in failed to parse - kubelet flag: unknown flag: --container-runtim + kubelet flag: unknown flag: --container-runtime |
description: | updated |
From mattermost, 1.26 charms were tracking 'latest/stable' snaps. Those snaps were refreshed last week with the 1.27 GA. Installed snaps will automatically refresh; deployed charms will not. It's recommended to use a named track for both charm and snap channel config to keep them in-sync.
Two options:
- configure the charms to use 1.26/stable snaps vs latest/stable
- upgrade the charms to 1.27/stable which are compatible with 1.27/stable snaps