Skip to content
New issue

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

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

Already on GitHub? # 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 &&.

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

Successfully merging a pull request may close this issue.

2 participants