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

Evaluate the use of a general purpose Image #102

Open
mxmxchere opened this issue Jun 5, 2024 · 5 comments
Open

Evaluate the use of a general purpose Image #102

mxmxchere opened this issue Jun 5, 2024 · 5 comments

Comments

@mxmxchere
Copy link
Contributor

mxmxchere commented Jun 5, 2024

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
Copy link
Member

berendt commented Jun 5, 2024

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
Copy link
Contributor Author

mxmxchere commented Jun 5, 2024

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
Copy link
Contributor Author

    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

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
Copy link
Contributor Author

Good point, thanks for highlighting it :)

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

No branches or pull requests

3 participants