Skip to content

Improve documentation of samples #303

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

Merged
merged 3 commits into from
Jan 15, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions samples/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# Sample AppWrappers

This directory contains a number of example yamls showing how to wrap
different Pod-creating Kubernetes resources in an AppWrapper.
AppWrappers can be used to wrap one or more instances of
any Kubernetes Kind that uses `PodSpecTemplate` to define its Pods.
An AppWrapper must contain at least one such Pod-creating resource in addition
to zero or more non-Pod-creating resources.

An AppWrapper contains a`components` array containing the wrapped resources.
Each component has two main pieces: a `template` that defines the wrapped resource
and a `podSets` array that gives the `replicas` and `path` within the template
for each `PodSpecTemplate`. For correct operation of the AppWrapper, it is
required that the provided `path` and `replicas` information correctly represent
the Pod creating behavior of the wrapped resource. For resources that do not
created Pods (eg `Services` or `Secrets`) `podSets` should be empty and thus omitted.

To simplify the user experience, for a selection of commonly-used Kubernetes
resource Kinds, the AppWrapper controller can automatically infer the `podSets`
array if it is not provided. For these same Kinds, the AppWrapper controller
will validate that any explicitly provided `podSet` entries do in fact match the
definitions in `template`.
The current set of automatically inferred Kinds is:
+ v1 Pod
+ apps/v1 Deployment
+ apps/v1 StatefulSet
+ batch/v1 Job
+ kubeflow.org/v1 PyTorchJob
+ ray.io/v1 RayCluster
+ ray.io/v1 RayJob

In all of the examples, if `podSets` inference is supported for the wrapped Kind,
then `podSets` is omitted from the sample yaml.
44 changes: 44 additions & 0 deletions samples/wrapped-leader-worker-set.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
apiVersion: workload.codeflare.dev/v1beta2
kind: AppWrapper
metadata:
name: sample-lws
labels:
kueue.x-k8s.io/queue-name: default-queue
spec:
components:
- podSets:
- path: "template.spec.leaderWorkerTemplate.leaderTemplate"
replicas: 2
- path: "template.spec.leaderWorkerTemplate.workerTemplate"
replicas: 3
template:
apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
name: nginx-leaderworkerset
labels:
app: nginx
spec:
replicas: 2
leaderWorkerTemplate:
leaderTemplate:
spec:
containers:
- name: nginx-leader
image: registry.k8s.io/nginx-slim:0.27
resources:
requests:
cpu: "100m"
ports:
- containerPort: 80
size: 3
workerTemplate:
spec:
containers:
- name: nginx-worker
image: nginx:1.14.2
resources:
requests:
cpu: "200m"
ports:
- containerPort: 80
Loading