[doc] 3.5 Deployment on Existing SLES Installation

[savasirez]

3.5 Deployment on Existing SLES Installation

https://documentation.suse.com/suse-caasp/4/single-html/caasp-deployment/#_deployment_on_existing_sles_installation

There is no indication of "removal of swap" before bootstrapping the cluster with skuba.
So it should be written here to disable and remove swap before going forward.

[r0ckarong]

@ereslibre Must swap be disabled on existing SLE systems? From my understanding this installation method would be run in parallel to the existing stuff on those SLE systems that might use swap.

[savasirez]

@ereslibre Must swap be disabled on existing SLE systems? From my understanding this installation method would be run in parallel to the existing stuff on those SLE systems that might use swap.

It must be disabled, because:

1. It fails during skuba init
2. If you just disable and initialize the cluster, cluster fails to start the next time you reboot (swap is re-mounted during boot) with the following error:
   2019-09-24T09:37:22.850213+03:00 caas4master kubelet[2586]: F0924 09:37:22.850089 2586 server.go:273] failed to run Kubelet: Running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/swaps contained: [Filename#011#011#011#011Type#011#011Size#011Used#011Priority /dev/sda3 partition#0114031464#0110#011-1]

Of course I'm talking about the master and worker nodes, not the skuba administration node...

[ereslibre]

Yes, @savasirez is correct, swap must be disabled on the target nodes that will join (or initialize) the cluster. The machine where skuba was called from is not relevant, unless it will form part of the cluster as well.

[r0ckarong]

Yes, @savasirez is correct, swap must be disabled on the target nodes that will join (or initialize) the cluster. The machine where skuba was called from is not relevant, unless it will form part of the cluster as well.

So maybe this was a misunderstanding I had from the beginning. The "existing SLES installation" implied to me that you could re-use any of your existing SLES servers to ALSO become nodes in the CaaSP cluster (and keep running the previous use case on them). From what you state here this is not possible.

@ereslibre Can you please confirm that with "existing SLES" you mean "fully convert an existing SLES machine to exclusively become a cluster node for CaaSP". Then I need to change the wording to make that clear.

[ereslibre]

@ereslibre Can you please confirm that with "existing SLES" you mean "fully convert an existing SLES machine to exclusively become a cluster node for CaaSP". Then I need to change the wording to make that clear.

For creating a cluster you need a machine where you can run:

• skuba cluster init
• skuba node bootstrap

and subsequent skuba node join commands (these commands can be run from anywhere with access to the cluster definition folder, the apiserver and SSH access to the target nodes).

The important part is that skuba cluster init and skuba node bootstrap could be run on any machine with SSH access to the first control plane node. It can be any machine, but it can also be that very same machine that will become a control plane.

My point was, the swap should be removed and disabled on all machines that will become part of the cluster. If you use a laptop to bootstrap the first remote node, it's fine if that laptop has swap, but the target node must not.

[r0ckarong]

My point was, the swap should be removed and disabled on all machines that will become part of the cluster. If you use a laptop to bootstrap the first remote node, it's fine if that laptop has swap, but the target node must not.

I get that but that wasn't my question.

Saying "Install CaaSP on an existing SLES installation" to me (as a user) means:

Hey, I have X amount of webservers already running SLES that are mostly idle. I can just use those as CaaSP nodes as well.

Now we're saying "You must disable swap on the machines that are joining the cluster" which means

Once the machine is part of a CaaSP cluster, no other applications can run there that are not explicitly managed by kubernetes (if they might require swap)

Or am I seeing this wrong?

[savasirez]

My point was, the swap should be removed and disabled on all machines that will become part of the cluster. If you use a laptop to bootstrap the first remote node, it's fine if that laptop has swap, but the target node must not.

I get that but that wasn't my question.

Saying "Install CaaSP on an existing SLES installation" to me (as a user) means:

Hey, I have X amount of webservers already running SLES that are mostly idle. I can just use those as CaaSP nodes as well.

Now we're saying "You must disable swap on the machines that are joining the cluster" which means

Once the machine is part of a CaaSP cluster, no other applications can run there that are not explicitly managed by kubernetes (if they might require swap)

Or am I seeing this wrong?

I believe you are correct, it may be better to insert a disclaimer about this here, what do you think?

[ereslibre]

Once the machine is part of a CaaSP cluster, no other applications can run there that are not explicitly managed by kubernetes (if they might require swap)

+1, yes. In general they won't run applications per-se (that's what Kubernetes is for), but they might want to run some configuration management tools that have an agent (salt, chef...) or other similar applications.

[r0ckarong]

Once the machine is part of a CaaSP cluster, no other applications can run there that are not explicitly managed by kubernetes (if they might require swap)

+1, yes. In general they won't run applications per-se (that's what Kubernetes is for), but they might want to run some configuration management tools that have an agent (salt, chef...) or other similar applications.

OK but again: You can NOT just add general purpose SLES machines to the cluster and expect this to work correctly; right?!

This "you may only run CaaSP on existing machines if they use any of the following things <we don't have that list>" is not really a good way to communicate expectations or requirements.

[r0ckarong]

I believe you are correct, it may be better to insert a disclaimer about this here, what do you think?

That is exactly what I'm trying to clarify here, yes :)

[ereslibre]

OK but again: You can NOT just add general purpose SLES machines to the cluster and expect this to work correctly; right?!

You can. As long as they don't have swap.

[ereslibre]

However one thing is what can be done, and other is what we encourage and support.

I can't tell whether we would support a "reused" SLE machine that is running nginx or mariadb at the host level. What I can tell is that we should encourage users to create machines for the sole purpose of joining the Kubernetes cluster. The use cases where they will "reuse" machines is nearly to 0, I would expect at least.

[savasirez]

My impression when reading the part was actually this :

1. I have vms which are new, and since I'm using Proxmox as hypervisor, I could not go with vm instructions.
2. I don't want to get into autoyast configs, so I could not use bare metal instructions.
3. That left me with the only choice of "installation on existing systems". So I thought it was there for structures like mine...

[r0ckarong]

@kkaempf @qnetter Are we aiming at using "existing SLES (as in running other applications" as cluster nodes or can I reword these instructions to explicitly exclude that scenario?

[kkaempf]

"existing SLES (as in running other applications)"

I wouldn't want to support such a scenario. CaaSP nodes should be dedicated to CaaSP and not run other applications/services.

[r0ckarong]

OK I will rewrite this section to make that clear and that "existing SLES" only means "SLES that was installed without CaaSP at the time".

[savasirez]

"existing SLES (as in running other applications)"

I wouldn't want to support such a scenario. CaaSP nodes should be dedicated to CaaSP and not run other applications/services.

+1

[r0ckarong]

Looks like a real world case of this misunderstanding is documented here: https://bugzilla.suse.com/show_bug.cgi?id=1152354

[r0ckarong]

fe58e85