Hi, Ran into an interesting "issue" (quotes, because I'm not sure what to expect and absolutely possible that I'm pulling an armature hour type deal) with Kubic. After starting my test cluster at home I noticed that `kured` pods are on ImagePullBackOff and checking registry-o-o the requested version (1.6.1) in the manifest is missing for amd64. My question: - updates of pods should happen via transactional-updates (as it seems to be a package in /usr/share/k8s-yaml/ that holds these manifests) - or kubicctl should do this (I think kubicctl should only handle the k8s upgrades in the cluster with `salt`, I can be wrong) - or it is the users responsibility to keep the pods up-to-date in their preferred manner? Have the feeling that the last option is the winner, but would feel a lot better if someone would clarify this. -- Br, A.
Hi,
Ran into an interesting "issue" (quotes, because I'm not sure what to expect and absolutely possible that I'm pulling an armature hour type deal) with Kubic.
After starting my test cluster at home I noticed that `kured` pods are on ImagePullBackOff and checking registry-o-o the requested version (1.6.1) in the manifest is missing for amd64. My question: - updates of pods should happen via transactional-updates (as it seems to be a package in /usr/share/k8s-yaml/ that holds these manifests)
So it seems that it provided by `kured-k8s-yaml` and it is also updated to 1.9.1 in the official repos so chances are big, that I have a broken `t-u`on my hand. So user error either way...
Hi, On Tue, Jan 25, Attila Pinter wrote:
Hi,
Ran into an interesting "issue" (quotes, because I'm not sure what to expect and absolutely possible that I'm pulling an armature hour type deal) with Kubic. After starting my test cluster at home I noticed that `kured` pods are on ImagePullBackOff and checking registry-o-o the requested version (1.6.1) in the manifest is missing for amd64. My question: - updates of pods should happen via transactional-updates (as it seems to be a package in /usr/share/k8s-yaml/ that holds these manifests)
transactional-update only updates packages, no kubernetes workload. It cannot do that, as it has no credentials to do so and even if, would not know anything about the cluster to do it. Beside automatic update of a k8s cluster would be a really bad idea, since the tools have no clue about your workload and which changes they need to work with the new k8s version.
- or kubicctl should do this (I think kubicctl should only handle the k8s upgrades in the cluster with `salt`, I can be wrong)
kubicctl will upgrade your k8s cluster, but you have to plan, schedule and do it yourself. See above, it's for this tools not possible to do it automatically due to the fast move and big changes of new k8s versions. So from time to time plan to run kubicctl to upgrade your k8s cluster.
- or it is the users responsibility to keep the pods up-to-date in their preferred manner?
Correct. Thorsten
Have the feeling that the last option is the winner, but would feel a lot better if someone would clarify this.
-- Br, A.
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
On Tuesday, January 25th, 2022 at 2:19 PM, Thorsten Kukuk
Hi,
On Tue, Jan 25, Attila Pinter wrote:
Hi,
Ran into an interesting "issue" (quotes, because I'm not sure what to expect and absolutely possible that I'm pulling an armature hour type deal) with Kubic.
After starting my test cluster at home I noticed that `kured` pods are on ImagePullBackOff and checking registry-o-o the requested version (1.6.1) in the manifest is missing for amd64. My question: - updates of pods should happen via transactional-updates (as it seems to be a package in /usr/share/k8s-yaml/ that holds these manifests)
transactional-update only updates packages, no kubernetes workload. It
cannot do that, as it has no credentials to do so and even if, would not
know anything about the cluster to do it.
Beside automatic update of a k8s cluster would be a really bad idea,
since the tools have no clue about your workload and which changes they
need to work with the new k8s version.
- or kubicctl should do this (I think kubicctl should only handle the k8s upgrades in the cluster with `salt`, I can be wrong)
kubicctl will upgrade your k8s cluster, but you have to plan, schedule
and do it yourself. See above, it's for this tools not possible to do it
automatically due to the fast move and big changes of new k8s versions.
So from time to time plan to run kubicctl to upgrade your k8s cluster.
- or it is the users responsibility to keep the pods up-to-date in their preferred manner?
Correct.
Thorsten
Have the feeling that the last option is the winner, but would feel a lot better if someone would clarify this.
--
Br,
A.
Thorsten Kukuk, Distinguished Engineer, Senior Architect
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
Super, thanks for the explanation Thorsten, greatly appreciated. After I fixed `t-u` to update the system and did a `kubicctl upgrade` the pods enter into a healthy state. Was a massive user error, but learnt something again ^_^ Much love, A.
participants (2)
-
Attila Pinter
-
Thorsten Kukuk