Transit wants a new storage tier with different disk type and IOPS. Where should those backend flavor settings be expressed for newly provisioned volumes?
Select an answer to reveal the explanation.
Short Explanation
Parameters on a StorageClass are the order form checkboxes—SSD vs HDD, IOPS tier, encrypted or not—that the provisioner hands to the CSI driver. Security contexts, Service load-balancer classes, and namespace labels are different knobs entirely.
Full Explanation
Transit wanting a new storage tier with different disk type and IOPS should express those backend flavor settings in the StorageClass parameters map that the provisioner passes through to the CSI driver. Parameters are the order-form checkboxes—SSD versus HDD, IOPS tier, encrypted or not—interpreted by the named provisioner when new volumes are minted for city workloads.
Pod securityContext.fsGroup adjusts filesystem group ownership inside the container; it does not select cloud disk SKUs. Service loadBalancerClass influences load-balancer implementations for Services, not disk classes. A label on the kube-system Namespace does not globally override CSI volume flavor parameters.
Exam caveat: changing parameters affects newly provisioned volumes; already-bound PVs keep their original backend characteristics. Invalid parameter keys often surface as provisioning failures on the PVC events.
Operational check: define a StorageClass with the desired parameters, provision a test PVC, inspect the cloud console or CSI logs for the created disk type/IOPS, and only then offer the class to transit application teams. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.