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
- Usage
- Publishing
- Using the static binary bundles directly
- Uninstall the static binary bundles
- CRI-O bundles as OCI artifacts
- More to read
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).
Note
This list may contain yet-to-be-released versions of CRI-O. See CRI-O releases for the latest stable release.
isv:cri-o:stable: Stable Packages (Umbrella)isv:cri-o:stable:v1.35:v1.35.ztags (Stable)isv:cri-o:stable:v1.35:build:v1.35.ztags (Builder)
isv:cri-o:stable:v1.34:v1.34.ztags (Stable)isv:cri-o:stable:v1.34:build:v1.34.ztags (Builder)
isv:cri-o:stable:v1.33:v1.33.ztags (Stable)isv:cri-o:stable:v1.33:build:v1.33.ztags (Builder)
isv:cri-o:stable:v1.32:v1.32.ztags (Stable)isv:cri-o:stable:v1.32:build:v1.32.ztags (Builder)
- End of life:
isv:cri-o:stable:v1.31:v1.31.ztags (Stable)isv:cri-o:stable:v1.31:build:v1.31.ztags (Builder)
isv:cri-o:stable:v1.30:v1.30.ztags (Stable)isv:cri-o:stable:v1.30:build:v1.30.ztags (Builder)
isv:cri-o:stable:v1.29:v1.29.ztags (Stable)isv:cri-o:stable:v1.29:build:v1.29.ztags (Builder)
isv:cri-o:stable:v1.28:v1.28.ztags (Stable)isv:cri-o:stable:v1.28:build:v1.28.ztags (Builder)
isv:cri-o:prerelease: Prerelease Packages (Umbrella)isv:cri-o:prerelease:main:mainbranch (Prerelease)isv:cri-o:prerelease:main:build:mainbranch (Builder)
isv:cri-o:prerelease:v1.35:release-1.35branch (Prerelease)isv:cri-o:prerelease:v1.35:build:release-1.35branch (Builder)
isv:cri-o:prerelease:v1.34:release-1.34branch (Prerelease)isv:cri-o:prerelease:v1.34:build:release-1.34branch (Builder)
isv:cri-o:prerelease:v1.33:release-1.33branch (Prerelease)isv:cri-o:prerelease:v1.33:build:release-1.33branch (Builder)
isv:cri-o:prerelease:v1.32:release-1.32branch (Prerelease)isv:cri-o:prerelease:v1.32:build:release-1.32branch (Builder)
- End of life:
isv:cri-o:prerelease:v1.31:release-1.31branch (Prerelease)isv:cri-o:prerelease:v1.31:build:release-1.31branch (Builder)
isv:cri-o:prerelease:v1.30:release-1.30branch (Prerelease)isv:cri-o:prerelease:v1.30:build:release-1.30branch (Builder)
isv:cri-o:prerelease:v1.29:release-1.29branch (Prerelease)isv:cri-o:prerelease:v1.29:build:release-1.29branch (Builder)
isv:cri-o:prerelease:v1.28:release-1.28branch (Prerelease)isv:cri-o:prerelease:v1.28:build:release-1.28branch (Builder)
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.
KUBERNETES_VERSION=v1.34
CRIO_VERSION=v1.34cat <<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
EOFcat <<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
EOFdnf install -y container-selinuxdnf install -y cri-o kubelet kubeadm kubectlCRI-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.conflistThe bridge plugin is suitable for single-node clusters in CI and testing environments. Different CNI plugins are recommended to use CRI-O in production.
systemctl start crio.serviceswapoff -a
modprobe br_netfilter
sysctl -w net.ipv4.ip_forward=1
kubeadm initapt-get update
apt-get install -y software-properties-common curlcurl -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.listcurl -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.listapt-get update
apt-get install -y cri-o kubelet kubeadm kubectlsystemctl start crio.serviceswapoff -a
modprobe br_netfilter
sysctl -w net.ipv4.ip_forward=1
kubeadm initThe 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:
- 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.
- Push the bundle and spec file into the
corresponding
buildproject. - Wait for the OBS builders to finish.
- Run package installation and usage tests for Kubernetes and available architectures for various Distributions.
- Publish the packages into the top level project.
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 | bashThe 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 arm64It 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.34.0The 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
> curl https://raw.githubusercontent.com/cri-o/packaging/main/get | bash -s -- -uThe 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:
-
latest,main: References the latest available commit on the CRI-Omainbranch, for example: -
A specific tag:
-
A certain commit in long and short (7 characters) format:
-
The latest minor version, release branch or development version:
-
The architecture derivates of the above:
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)
…The following resources are great to understand the motivation behind the latest
deb and rpm packaging efforts within the CRI-O and Kubernetes community:
-
CRI-O is moving towards pkgs.k8s.io:
https://k8s.io/blog/2023/10/10/cri-o-community-package-infrastructure
-
Kubernetes Legacy Package Repositories Will Be Frozen On September 13, 2023:
https://kubernetes.io/blog/2023/08/31/legacy-package-repository-deprecation/
-
pkgs.k8s.io: Introducing Kubernetes Community-Owned Package Repositories:
https://kubernetes.io/blog/2023/08/15/pkgs-k8s-io-introduction/
-
Installing Kubernetes via
kubeadm: