Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty cluster after applying changed connection method #815

Closed
secustor opened this issue Jan 3, 2025 · 1 comment · Fixed by #816
Closed

Empty cluster after applying changed connection method #815

secustor opened this issue Jan 3, 2025 · 1 comment · Fixed by #816

Comments

@secustor
Copy link
Contributor

secustor commented Jan 3, 2025

I have encountered some unexpected behavior while upgrading my single node K0s cluster from v1.30.7+k0s.0 --> v1.31.3+k0s.0 using k0sctl ( v0.21.0 ).

Steps to reproduce:

  • Install single node cluster using localhost connection type
  • Modify cluster content e.g. add a new deployment
  • Run the same configuration from another host using ssh or openSSH.
  • The cluster will be empty at that point except the extensions
  • This behavior is revertible by simply running the original localhost config from the server

I would be interested in supplying a patch or doc.
As this is reproducible on my side, I can also provide further logs if necessary.

Thanks!

Config diff when overwriting a localhost setup cluster with openSSH:

apiVersion: k0s.k0sproject.io/v1beta1
kind: ClusterConfig
metadata:
  name: k0s
spec:
  api:
    externalAddress: myHost.example.com
    sans:
-    - 127.0.0.1
    - 192.168.178.81
-  storage:
-    etcd:
-      peerAddress: 192.168.178.81

So my current assumption is that the installation flips between kine and etcd.

Used configs "Original" config run from `myHost`:
apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: k0s-cluster
spec:
  hosts:
    - localhost:
        enabled: true
      role: single
      installFlags:
        - "--labels openebs.io/nodeid=myHost"
  k0s:
    version: v1.31.3+k0s.0
    dynamicConfig: false
    config:
      apiVersion: k0s.k0sproject.io/v1beta1
      kind: ClusterConfig
      metadata:
        name: k0s
      spec: { } # shortened 

changed config run from my workstation:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: k0s-cluster
spec:
  hosts:
    - role: single
      openSSH:
        address: 192.168.178.81
      installFlags:
        - "--labels openebs.io/nodeid=myHost"
  k0s:
    version: v1.31.3+k0s.0
    dynamicConfig: false
    config:
      apiVersion: k0s.k0sproject.io/v1beta1
      kind: ClusterConfig
      metadata:
        name: k0s
      spec: { } # shortened 

The logs are not showing anything relevant from my perspective.

Logs

SSH run which lead to the empty cluster:

INFO ==> Running phase: Connect to hosts
INFO [OpenSSH] 192.168.178.81: connected
INFO ==> Running phase: Detect host operating systems
INFO [OpenSSH] 192.168.178.81: is running Ubuntu 24.04.1 LTS
INFO ==> Running phase: Acquire exclusive host lock
INFO ==> Running phase: Prepare hosts
INFO ==> Running phase: Gather host facts
INFO [OpenSSH] 192.168.178.81: using myHost as hostname
INFO [OpenSSH] 192.168.178.81: discovered enp1s0f1 as private interface
INFO ==> Running phase: Validate hosts
INFO ==> Running phase: Gather k0s facts
INFO [OpenSSH] 192.168.178.81: found existing configuration
INFO [OpenSSH] 192.168.178.81: is running k0s single version v1.30.7+k0s.0
WARN [OpenSSH] 192.168.178.81: k0s will be upgraded
INFO ==> Running phase: Validate facts
INFO ==> Running phase: Download k0s on hosts
INFO [OpenSSH] 192.168.178.81: downloading k0s v1.31.3+k0s.0
INFO [OpenSSH] 192.168.178.81: validating configuration
INFO ==> Running phase: Configure k0s
INFO [OpenSSH] 192.168.178.81: installing new configuration
INFO ==> Running phase: Upgrade controllers
INFO [OpenSSH] 192.168.178.81: starting upgrade
INFO [OpenSSH] 192.168.178.81: waiting for the k0s service to start
INFO ==> Running phase: Release exclusive host lock
INFO ==> Running phase: Disconnect from hosts
INFO ==> Finished in 1m41s
INFO k0s cluster version v1.31.3+k0s.0 is now installed
INFO Tip: To access the cluster you can now fetch the admin kubeconfig using:
INFO      k0sctl kubeconfig --config k0s/config.yaml

Localhost run which fixed the issue:

INFO ==> Running phase: Connect to hosts
INFO [local] localhost: connected
INFO ==> Running phase: Detect host operating systems
INFO [local] localhost: is running Ubuntu 24.04.1 LTS
INFO ==> Running phase: Acquire exclusive host lock
INFO ==> Running phase: Prepare hosts
INFO ==> Running phase: Gather host facts
INFO [local] localhost: using myHost as hostname
INFO [local] localhost: discovered enp1s0f1 as private interface
INFO [local] localhost: discovered 192.168.178.81 as private address
INFO ==> Running phase: Validate hosts
INFO ==> Running phase: Gather k0s facts
INFO [local] localhost: found existing configuration
INFO [local] localhost: is running k0s single version v1.31.3+k0s.0
INFO ==> Running phase: Validate facts
INFO [local] localhost: validating configuration
INFO ==> Running phase: Configure k0s
INFO [local] localhost: installing new configuration
INFO [local] localhost: restarting k0s service
INFO [local] localhost: waiting for k0s service to start
INFO ==> Running phase: Release exclusive host lock
INFO ==> Running phase: Disconnect from hosts
INFO ==> Finished in 7s
INFO k0s cluster version v1.31.3+k0s.0 is now installed
INFO Tip: To access the cluster you can now fetch the admin kubeconfig using:
INFO      k0sctl kubeconfig --config k0s/config.yaml
@kke
Copy link
Contributor

kke commented Jan 7, 2025

single should always produce a kine cluster. There may be some bug that adds the etcd peer address in some cases even if the role is single. 🤔

Possibly this one here

if cfg.Dig("spec", "storage", "etcd", "peerAddress") != nil || h.PrivateAddress != "" {
cfg.DigMapping("spec", "storage", "etcd")["peerAddress"] = addr
}

I think that || should probably be &&.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants