|
| 1 | +# Sample AppWrappers |
| 2 | + |
| 3 | +This directory contains a number of example yamls showing how to wrap |
| 4 | +different Pod-creating Kubernetes resources in an AppWrapper. |
| 5 | +AppWrappers can be used to wrap one or more instances of |
| 6 | +any Kubernetes Kind that uses `PodSpecTemplate` to define its Pods. |
| 7 | +An AppWrapper must contain at least one such Pod-creating resource in addition |
| 8 | +to zero or more non-Pod-creating resources. |
| 9 | + |
| 10 | +An AppWrapper contains a`components` array containing the wrapped resources. |
| 11 | +Each component has two main pieces: a `template` that defines the wrapped resource |
| 12 | +and a `podSets` array that gives the `replicas` and `path` within the template |
| 13 | +for each `PodSpecTemplate`. For correct operation of the AppWrapper, it is |
| 14 | +required that the provided `path` and `replicas` information correctly represent |
| 15 | +the Pod creating behavior of the wrapped resource. For resources that do not |
| 16 | +created Pods (eg `Services` or `Secrets`) `podSets` should be empty and thus omitted. |
| 17 | + |
| 18 | +To simplify the user experience, for a selection of commonly-used Kubernetes |
| 19 | +resource Kinds, the AppWrapper controller can automatically infer the `podSets` |
| 20 | +array if it is not provided. For these same Kinds, the AppWrapper controller |
| 21 | +will validate that any explicitly provided `podSet` entries do in fact match the |
| 22 | +definitions in `template`. |
| 23 | +The current set of automatically inferred Kinds is: |
| 24 | + + v1 Pod |
| 25 | + + apps/v1 Deployment |
| 26 | + + apps/v1 StatefulSet |
| 27 | + + batch/v1 Job |
| 28 | + + kubeflow.org/v1 PyTorchJob |
| 29 | + + ray.io/v1 RayCluster |
| 30 | + + ray.io/v1 RayJob |
| 31 | + |
| 32 | +In all of the examples, if `podSets` inference is supported for the wrapped Kind, |
| 33 | +then `podSets` is omitted from the sample yaml. |
0 commit comments