SovereignCloudStack / cluster-stacks

Definition of Cluster Stacks based on the ClusterAPI ClusterClass feature
https://scs.community/
Apache License 2.0
7 stars 6 forks source link

Evaluate the use of a general purpose Image #102

Open mxmxchere opened 1 month ago

mxmxchere commented 1 month ago

As capi images will not be mandatory on SCS-clouds, capo can not rely on the existence of them. Instead, one flavor on SCS is actually mandatory (Ubuntu 22.04). That means, that every capo can rely on the existence of this image. The task of this issue is to evaluate how much of an effort it is to use such a general purpose image and use it as the base-images for cluster-api workload-cluster nodes.

berendt commented 1 month ago

I rather wonder why Ubuntu 22.04 is manadory when CAPI, for example, is not. What if I am a CSP who has a partnership with RedHat or SUSE and don't want to offer a Canonical product on my cloud? I think it would be better to discuss why a single image of Canonical is mandatory and whether it should not also be marked as non-mandatory.

mxmxchere commented 1 month ago

This issue is about dealing with a general purpose image whose availability is guaranteed by the standard (currently Ubuntu 22.04). A better place to debate which images should be mandatory is here. Anyways, i would welcome Debian as (commercial) vendor-neutral image.

Also, the capi-images are mostly ubuntu as far as i know. So it is not completely distinct from being a canonical product.

To have no mandatory image at all would circumvent SCS's unique selling point. With the guarantee of images/flavors/behaviors i can theoretically have peace of mind applying my cloud resources here today and on another CSP tomorrow. Having no mandatory image or flavor or common behavior that SCS stands for makes the SCS-label useless. I then have to check for everything and alter my resources when i migrate to another cloud.

mxmxchere commented 1 month ago
    preKubeadmCommands:
      - sysctl -w net.ipv4.ip_forward=1
      - curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
      - curl -fsSL https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/cri-o-apt-keyring.gpg
      - echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /" | tee /etc/apt/sources.list.d/kubernetes.list
      - echo "deb [signed-by=/etc/apt/keyrings/cri-o-apt-keyring.gpg] https://pkgs.k8s.io/addons:/cri-o:/prerelease:/main/deb/ /" | tee /etc/apt/sources.list.d/cri-o.list
      - apt-get update -y
      - apt-get install -y  cri-o kubelet kubeadm
      - modprobe br_netfilter
      - echo "br_netfilter" >> /etc/modules
      - systemctl enable crio --now

seems to be enough to use Ubuntu 22.04 out of the box, i did not make any time-measurements, but it does not feel to provision slower than the CAPI images.

artificial-intelligence commented 1 month ago

sysctl -w net.ipv4.ip_forward=1

I don't know if it's needed, but as you persisted all other commands on the system, let me point out, that this command does not persist the sysctl setting but only changes it for the currently running kernel.

mxmxchere commented 1 month ago

Good point, thanks for highlighting it :)