Workloads¶
Running things inside a cluster you own.
Your cluster is conformant Kubernetes and you are cluster-admin in it, so most of what you know already applies and is documented upstream rather than here.
Four things are specific to this platform, and they are the ones that will otherwise cost you an afternoon:
Persistent Storage — one StorageClass, a volume that is not on your node, and a quota that refuses you at kubectl apply rather than leaving a claim Pending.
Exposing Workloads — a LoadBalancer Service needs two fields and an address granted to your Environment. Without them it waits forever, silently.
Deploying Applications — what your cluster already ships with, how it differs from a managed cloud cluster, and delivering add-ons across several clusters at once.
Requesting a GPU: attaching a whitelisted GPU or PCI device to a worker, and what changes about it once one is attached.
The one distinction to keep straight¶
You work in two places, with two credentials, and confusing them is the most common source of "that command does nothing".
| Credential | Objects | |
|---|---|---|
| Your Environment, on the under cluster | Whatever your platform team gave you | Cluster, EipClaim, ClusterBackup, ResourceQuota |
| Your cluster | Its own kubeconfig, from a Secret in the Environment |
Deployment, PersistentVolumeClaim, Service, VolumeSnapshot |
Your quota, your addresses and your clusters live in the first. Everything you run lives in the second. Pages here say which one a command belongs to whenever it is not obvious.