CAST AI components running on your clusters use predefined service accounts and relevant permissions to be able to perform functions such as, for example, sending data about the cluster state. This section discusses all required service accounts and permissions granted to CAST AI components.
Each CAST AI component installed in your cluster uses a dedicated service account. Such a setup allows you to fine-tune permissions for each component:
» kubectl get serviceAccounts -n castai-agent NAME SECRETS AGE castai-agent 1 46h castai-cluster-controller 1 4h20m castai-evictor 1 4h20m castai-spot-handler 1 4h20m default 1 46h
The CAST AI agent collects cluster operational details (snapshots) and delivers them to the central platform to assess if there is room for optimization. That's why it must get cluster-wide permissions:
|core||Pods, Nodes, ReplicationControllers, PersistentVolumeClaims, PersistentVolumes, Services||get, list, watch|
|apps||Deployments, ReplicaSets, DaemonSets, StatefulSets||get, list, watch|
|storage.k8s.io||StorageClasses, CSInodes||get, list, watch|
|batch||Jobs||get, list, watch|
The CAST AI agent's resource consumption vastly depends on the cluster size. The agent must be able to adjust resource limits proportionally to the size of your cluster. For that purpose, Cluster Proportional Vertical Autoscaler patches the CAST AI agent's deployment with re-estimated limits, which requires the following permission:
|apps||deployments||patch||Used only to patch the castai-agent deployment|
CAST AI's cluster controller component gets installed when your connected cluster moves to Phase 2, in which you can enable managed cost savings:
» kubectl get deployments -n castai-agent NAME READY UP-TO-DATE AVAILABLE AGE castai-agent 1/1 1 1 43h castai-cluster-controller 2/2 2 2 64m castai-evictor 0/0 0 0 64m
The cluster controller operates mostly on the cluster level as it performs operations required to optimize its costs:
|core||Pods, Nodes||get, list|
|core||Nodes||patch, update||Used for node draining and patching.|
|certificates.k8s.io||CertificateSigningRequests||get, list, delete, create||Used for creating a new certificate when adding a node to the cluster.|
|certificates.k8s.io||CertificateSigningRequests/approval||patch, update||Used for creating a new certificate when adding a node to the cluster.|
|certificates.k8s.io||Signers||approve||Applicable only for kubelet.|
|core||Events||list, create, patch|
|rbac.authorization.k8s.io||Roles, ClusterRoles, ClusterRoleBindings||get, patch, update, delete, escalate||Applicable to all CAST AI components.|
|core||Namespace||delete||Applicable only to the CAST AI agent.|
One of the main tasks of the cluster controller is to update CAST AI components. The cluster controller is granted with all permissions in castai-agent namespace necessary for current and future changes.
Additionally, it includes two cluster-wide permissions for managing the RBAC of CAST AI components and the possibility to delete the CAST AI namespace (see above).
When onboarding the cluster to Phase 2 for automated cost optimization, CAST AI installs more components than the cluster controller. One such component is Evictor, which minimizes the number of nodes your cluster uses.
When installed, Evictor handles non-CAST AI pods, so it requires a set to cluster-wide permissions:
|core||Nodes||get, list, watch, patch, update||Used to find a suitable node for eviction.|
|core||Pods||get, list, watch, patch, update, create, delete||List pods to find a suitable node for eviction and delete a stuck pod from the node.|
|apps||ReplicaSets||get||Used to find out if it's safe to evict a pod (it belongs to RS and has replicas).|
|core||Pods/eviction||create||Used for pod eviction.|
|coordination.k8s.io||Leases||*||Used for leader election when there may be a single instance active.|
Updated about 1 month ago