Note: This project is under active development. During development, we use container images hosted on Quay.io:
- Operator:
quay.io/repository/redhat-user-workloads/kueue-operator-tenant/kueue-operator
- Operand:
quay.io/repository/redhat-user-workloads/kueue-operator-tenant/kueue-0-11
Kueue Operator provides the ability to deploy kueue using different configurations
The Kueue Operator needs CertManager installed to operate correctly
ko version | ocp version | kueue version | k8s version | golang |
---|---|---|---|---|
1.0.0 | 4.19 - 4.20 | 0.11.z | 1.32 | 1.23 |
Kueue releases around 6 times a year. For the latest Openshift version, we will take the latest version that was build with that underlying Kubernetes version.
See Kueue Release for more details on the Kueue release policy.
-
Login into podman and have a repository created.
-
Set OPERATOR_IMAGE to point to your repostory ie export OPERATOR_IMAGE=quay.io/testrepo/kueue-operator:test
-
Build operator image:
make operator-build
-
Push operator image to repository:
make operator-push
-
Set $KUEUE_IMAGE to point to kueue operand image
-
Run
make deploy-cert-manager
to deploy OperatorGroup and Subscription in cert-manager-operator namespace. -
Run
make deploy-ocp
to deploy the operator using the $OPERATOR_IMAGE and $KUEUE_IMAGE for operator and operand, respectively. -
Run
make undeploy-ocp
to remove operator from ocp cluster
-
Login into podman and have a repository created for the operator bundle.
-
Set BUNDLE_IMAGE to point to your repostory and a tag of choice
-
Run
make bundle-generate
to generate the bundle manifests -
Run
make bundle-build
to build thebundle.Dockerfile
. -
Run
make bundle-push
to push the bundle image to your repository. -
Run
make deploy-cert-manager
to deploy OperatorGroup and Subscription in cert-manager-operator namespace. -
Set OPERATOR_NAMESPACE, i.e, "kueue-operator"
-
Run
oc new-project $OPERATOR_NAMESPACE
to create a namespace for the operaotr -
Run
operator-sdk run bundle --namespace $OPERATOR_NAMESPACE ${BUNDLE_IMAGE}
to deploy operator to $OPERATOR_NAMESPACE
-
make
-
oc apply -f deploy/
-
oc apply -f deploy/crd
-
hack/run-locally.sh
-
Optionally run
oc apply -f deploy/examples/job.yaml
apiVersion: kueue.openshift.io/v1
kind: Kueue
metadata:
labels:
app.kubernetes.io/name: kueue-operator
app.kubernetes.io/managed-by: kustomize
name: cluster
namespace: openshift-kueue-operator
spec:
config:
integrations:
frameworks:
- "batch/job"
- Set kubeconfig to point to a OCP cluster
- Set OPERATOR_IMAGE to point to your operator image
- Set KUEUE_IMAGE to point to your kueue image you want to test
- make deploy-cert-manager test-e2e
The Kueue Operator implements an opt-in webhook mechanism to ensure targeted enforcement of Kueue policies. To enable the validating and mutating webhooks for a specific namespace, use the following label:
oc label namespace <namespace> kueue.openshift.io/managed=true
This label instructs the Kueue Operator that the namespace should be managed by its webhook admission controllers. As a result, any Kueue resources within that namespace will be properly validated and mutated.
This project uses a git submodule to track the upstream Kueue repository. The submodule is located in the upstream/kueue
directory and is used to synchronize manifests and configurations.
To update the git submodule to the latest commit:
# Update the submodule to the latest commit on its tracked branch
git submodule update --remote upstream/kueue/src
# Commit the submodule update
git add upstream/kueue/src
git commit -m "Update upstream/kueue submodule"
To change which branch the submodule tracks:
# Navigate to the submodule directory
cd upstream/kueue/src
# Switch to the desired branch
git checkout <branch-name>
# Return to the main repository root
cd ../..
# Update the submodule configuration to track the new branch
git config -f .gitmodules submodule.upstream/kueue.branch <branch-name>
# Update the submodule to the latest commit on the new branch
git submodule update --remote upstream/kueue
# Commit the changes
git add .gitmodules upstream/kueue
git commit -m "Update submodule to track <branch-name> branch"
To configure the submodule to track the main branch:
# Set the submodule to track the main branch
git config -f .gitmodules submodule.upstream/kueue.branch main
# Update to the latest commit on main
git submodule update --remote upstream/kueue
# Commit the configuration change
git add .gitmodules upstream/kueue/src
git commit -m "Configure submodule to track main branch"
After updating the git submodule, you should synchronize the manifests using:
hack/sync_manifests.py --src-dir upstream/kueue/src/config/default/
This command processes the manifests from the submodule and prepares them for use by the operator.
The hack/sync_manifests.py
script is used to synchronize Kueue manifests from upstream releases or local development builds into the operator's bindata directory. This script handles the downloading, processing, and organization of Kueue manifests for operator deployment.
# Sync latest Kueue release
./hack/sync_manifests.py
# Sync specific version
./hack/sync_manifests.py 0.7.1
# Use local kustomize build
./hack/sync_manifests.py --src-dir path/to/kustomize/source
# Specify custom bindata directory
./hack/sync_manifests.py --bindata-dir custom/path
- Automatic Latest Version: Fetches the latest Kueue release from GitHub if no version is specified
- Local Development: Supports building manifests from local kustomize sources using
--src-dir
- OpenShift Integration: Automatically updates namespaces from
kueue-system
toopenshift-kueue-operator
- Webhook Configuration: Updates webhook configurations for OpenShift namespace conventions
- Image Parameterization: Replaces deployment images with
${IMAGE}
placeholder for operator templating - Network Policy Labels: Adds required OpenShift labels for network policies
- Organized Output: Separates manifests into appropriate files (CRDs, ClusterRoles, etc.) in the bindata directory
The script processes the following Kubernetes resources:
- Custom Resource Definitions (CRDs)
- ClusterRoles and ClusterRoleBindings
- Roles and RoleBindings
- Services and ServiceAccounts
- Deployments
- Webhook Configurations (Validating/Mutating)
- API Services