تخطَّ إلى المحتوى

Write resource manifests

هذا المحتوى غير متوفر بلغتك بعد.

Each manifest describes desired state for one resource. metadata.name identifies it, metadata.namespace selects its scope when supported, and spec contains kind-specific data.

Prefer xcsh export <KIND> <NAME> -f exported.yaml for an existing resource. For a new resource, start from a repository example tied to the current catalog. Remove server-managed fields before reuse.

Use one resource per YAML document, stable names, and explicit namespaces. Run xcsh validate -f manifests/ -R so nested files are included intentionally.

Start from the catalog schema for the exact kind and keep one resource per manifest while learning. Set metadata, namespace, and required specification fields explicitly; omit server-owned status and identifiers. Run local validation before any command that contacts the tenant, then run a live diff in the selected context. A clean local parse does not prove authorization, existence, or a safe remote change.