cri-o
/
packaging
mirror of https://github.com/cri-o/packaging.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
CRI-O deb and rpm packages.
537 Commits 1 Branch 0 Tags 893 KiB
Shell 92.6%
Makefile 6.4%
Dockerfile 1%
Go to file
openshift-merge-bot[bot] 7779065c2a
Merge pull request #283 from saschagrunert/cri-tools 
Update cri-tools to v1.34.0
 		2025-08-21 12:10:06 +00:00
.github Bump actions/checkout from 4.2.2 to 5.0.0 2025-08-12 12:13:17 +00:00
scripts Fix osc permission error 2025-06-03 12:44:20 +00:00
templates/latest Update cri-tools to v1.34.0 2025-08-21 10:02:43 +02:00
test Switch to centos 10 2025-08-19 10:48:54 +02:00
.gitignore Move get script into this repository 2023-10-19 17:29:56 +02:00
CONTRIBUTING.md Add `CONTRIBUTING.md` 2024-05-16 16:09:38 +02:00
LICENSE Initial commit 2023-09-18 14:34:08 -04:00
Makefile Update shfmt to v3.11.0 2025-03-06 09:11:45 +01:00
OWNERS Sync OWNERS and add PR template 2023-09-28 10:37:22 +02:00
OWNERS_ALIASES Add @bitoku as reviewer 2025-07-02 17:12:44 +00:00
README.md Close issue #267 2025-08-14 15:40:11 +03:00
dependencies.yaml Update cri-tools to v1.34.0 2025-08-21 10:02:43 +02:00
get Close issue #267 2025-08-14 15:40:11 +03:00

README.md

CRI-O Packaging

Publish package OBS workflow Schedule workflow Test workflow

The intention of this project is to encapsulate CRI-O's packaging efforts into a dedicated repository, following official Kubernetes guidelines by using the openSUSE Build Service (OBS).

Project Layout

CRI-O uses the same basic layout in OBS as Kubernetes project isv:kubernetes, but lives in a dedicated umbrella project called isv:cri-o.

This project contains a bunch of other subprojects.

[!CAUTION] We switched from https://pkgs.k8s.io/addons:/cri-o to a new subproject https://download.opensuse.org/repositories/isv:/cri-o to work independently from the pkgs.k8s.io CDN. Please switch over if you haven't already (see the examples below).

Stable Versions

Prereleases

The prerelease projects are mainly used for release-x.y branches as well as the main branch of CRI-O. The stable projects are used for tagged releases. The build projects are the builders for each project to be published, while the main repositories for them are on top. For example, the builder project for main is:

  • isv:cri-o:prerelease:main:build

But end-users will consume:

  • isv:cri-o:prerelease:main

All packages are based on the static binary bundles provided by the CRI-O CI.

Usage

Available Streams

Stable

v1.34 v1.33 v1.32 v1.31

Deprecated

v1.30 v1.29 v1.28

Prerelease

main release-1.34 release-1.33 release-1.32 release-1.31

Deprecated

release-1.30 release-1.29 release-1.28

Define the Kubernetes version and used CRI-O stream

KUBERNETES_VERSION=v1.33
CRIO_VERSION=v1.33

Distributions using rpm packages

Add the Kubernetes repository

cat <<EOF | tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/rpm/repodata/repomd.xml.key
EOF

Add the CRI-O repository

cat <<EOF | tee /etc/yum.repos.d/cri-o.repo
[cri-o]
name=CRI-O
baseurl=https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/rpm/
enabled=1
gpgcheck=1
gpgkey=https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/rpm/repodata/repomd.xml.key
EOF

Install package dependencies from the official repositories

dnf install -y container-selinux

Install the packages

dnf install -y cri-o kubelet kubeadm kubectl

Configure a Container Network Interface (CNI) plugin

CRI-O is capable of working with different CNI plugins, which may require a custom configuration. The CRI-O package ships a default IPv4 and IPv6 (dual stack) configuration for the bridge plugin, which is disabled by default. The configuration can be enabled by renaming the disabled configuration file in /etc/cni/net.d:

mv /etc/cni/net.d/10-crio-bridge.conflist.disabled /etc/cni/net.d/10-crio-bridge.conflist

The bridge plugin is suitable for single-node clusters in CI and testing environments. Different CNI plugins are recommended to use CRI-O in production.

Start CRI-O

systemctl start crio.service

Bootstrap a cluster

swapoff -a
modprobe br_netfilter
sysctl -w net.ipv4.ip_forward=1

kubeadm init

Distributions using deb packages

Install the dependencies for adding repositories

apt-get update
apt-get install -y software-properties-common curl

Add the Kubernetes repository

curl -fsSL https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/Release.key |
    gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/ /" |
    tee /etc/apt/sources.list.d/kubernetes.list

Add the CRI-O repository

curl -fsSL https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/Release.key |
    gpg --dearmor -o /etc/apt/keyrings/cri-o-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/cri-o-apt-keyring.gpg] https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/ /" |
    tee /etc/apt/sources.list.d/cri-o.list

Install the packages

apt-get update
apt-get install -y cri-o kubelet kubeadm kubectl

Start CRI-O

systemctl start crio.service

Bootstrap a cluster

swapoff -a
modprobe br_netfilter
sysctl -w net.ipv4.ip_forward=1

kubeadm init

Publishing

The obs GitHub action workflow can be used to manually trigger release for a CRI-O tag, a release-x.y branch or main. There is a daily cron scheduled for release branches, but it is also possible to trigger the package creation at a certain point in time. The obs pipeline will:

  1. Build a static binary bundle which contains all necessary files. 1 Upload the bundle to the CNCF Google Cloud Storage Bucket as well as the GitHub container image registry as OCI artifacts.
  2. Push the bundle and spec file into the corresponding build project.
  3. Wait for the OBS builders to finish.
  4. Run package installation and usage tests for Kubernetes and available architectures for various Distributions.
  5. Publish the packages into the top level project.

Using the static binary bundles directly

We always recommend to use deb and rpm packages over the static binary bundle, but for some reason packages may not be a good fit. Every run in the obs GitHub workflow will publish a static binary bundle on our Google Cloud Storage Bucket, which contains all necessary binaries and configurations.

This means that the latest available CRI-O main commit can be installed via our convenience script:

> curl https://raw.githubusercontent.com/cri-o/packaging/main/get | bash

The script automatically verifies the uploaded sigstore signatures as well, if the local system has cosign available in its $PATH. The same applies to the SPDX based bill of materials (SBOM), which gets automatically verified if the bom tool is in $PATH.

Besides amd64, we also support the arm64, ppc64le and s390x bit architectures. This can be selected via the script, too:

curl https://raw.githubusercontent.com/cri-o/packaging/main/get | bash -s -- -a arm64

It is also possible to select a specific git SHA or tag by:

curl https://raw.githubusercontent.com/cri-o/packaging/main/get | bash -s -- -t v1.33.0

The above script resolves to the download URL of the static binary bundle tarball matching the format:

https://storage.googleapis.com/cri-o/artifacts/cri-o.$ARCH.$REV.tar.gz

Where $ARCH can be amd64, arm64, ppc64le or s390x and $REV can be any git SHA or tag.

We also provide a Software Bill of Materials (SBOM) in the SPDX format for each bundle. The SBOM is available at the same URL like the bundle itself, but suffixed with .spdx:

https://storage.googleapis.com/cri-o/artifacts/cri-o.$ARCH.$REV.tar.gz.spdx

Uninstall the static binary bundles

> curl https://raw.githubusercontent.com/cri-o/packaging/main/get | bash -s -- -u

CRI-O bundles as OCI artifacts

The obs GitHub action workflow publishes OCI artifacts within GitHub container image registry. This means that the whole bundle can be retrieved by consuming the OCI artifacts from tools like Podman or ORAS. All artifacts are pushed as multi-architecture OCI image indexes, which means that the corresponding tool can download the right architecture on the target platform immediately. The following tags are available:

All artifacts are annotated by corresponding metadata to allow proper identification:

> oras manifest fetch ghcr.io/cri-o/bundle:main | jq .annotations
{
  "org.cncf.cri-o.branch": "main",
  "org.cncf.cri-o.commit": "2fe75a93f6526cf5c649476692cdecfc982e13e8",
  "org.cncf.cri-o.project": "main",
  "org.cncf.cri-o.version": "v1.33.0-dev",
  "org.opencontainers.image.created": "2025-05-06T01:37:13Z"
}

The artifacts are also signed by sigstore:

> cosign verify \
        --certificate-identity https://github.com/cri-o/packaging/.github/workflows/obs.yml@refs/heads/main \
        --certificate-oidc-issuer https://token.actions.githubusercontent.com \
        ghcr.io/cri-o/bundle:main

…

The corresponding Software Bill of Materials (SBOM) is attached to the related artifact:

> oras discover --platform linux/amd64 ghcr.io/cri-o/bundle:main

ghcr.io/cri-o/bundle@sha256:71c6fbca2330d73faeda5632bc8e1f137ecefc0faee644013009fd3104db146b
└── application/vnd.cncf.spdx.file.v1
    └── sha256:ca4ca75e9999997e5ab753bd606f81115678f67891611906d9a0ecfad42dfe07
        └── [annotations]
            ├── org.cncf.cri-o.project: main
            ├── org.cncf.cri-o.version: v1.33.0-dev
            ├── org.opencontainers.image.created: "2025-04-25T01:37:00Z"
            ├── org.cncf.cri-o.branch: main
            └── org.cncf.cri-o.commit: 17ac08c0c9976930f7d66896307bf46249223b1c

> oras pull $(oras discover --platform linux/amd64 --format json ghcr.io/cri-o/bundle:main | jq -r .referrers[0].reference)
…

More to read

The following resources are great to understand the motivation behind the latest deb and rpm packaging efforts within the CRI-O and Kubernetes community: