Custom resources in the platform
What are custom resources
In Kubernetes custom resources (CRD) allow you to expand the object model due to their types: on top of the basic Pod, Service, Deployment, etc., the platform can add its own entities with the necessary fields and controllers.
The Shturval platform is entirely built on operators and custom resources: almost all operations in the GUI (creating a cluster, changing the configuration of nodes, installing services, assigning rights) ultimately come down to creating or changing the CRD, and the operators bring the actual state of the cluster to the one described in them.
Platform specific custom resources
Below are the main custom resources in the *.shturval.tech API groups that are used in the platform.
API group auth.shturval.tech
In the management cluster.
| Resource | Purpose | Where is it used in GUI | Documentation |
|---|---|---|---|
AuthOidcClient (authoidcclient) | Clients of the platform’s internal authentication service (backend, frontend, Argo CD, Grafana, etc.) using OIDC | When switching via SSO to an external service | Custom IAM Resources |
User (user) | Local users stored in the platform | Access control → users | Local Administrator Password Management |
Kubectl example for auth.shturval.tech
kubectl get authoidcclient -A
API group node.shturval.tech
In the management cluster and client cluster.
| Resource | Purpose | Where is it used in GUI | Documentation |
|---|---|---|---|
NodeConfigItem (nodeconfigitem) | Node configuration template: NTP, sysctl, packages, registries, systemd units, etc.; applied by node selector | Administration → Node Configuration (list and NCI cards) | Node Configuration (NCI), NCI Object (NodeConfigItem), Module shturval-node-config |
NodeConfig (nodeconfig) | Summary of actual node-specific configuration collected from all applicable NCIs, with application status | Tabs and status blocks on the site page | NodeConfig (NC), Module shturval-node-config |
Kubectl example for node.shturval.tech
kubectl get nodeconfigitem
API group cluster.shturval.tech
In the management cluster.
| Resource | Purpose | Where is it used in GUI | Documentation |
|---|---|---|---|
ClusterConfig (clusterconfig) | Actual cluster configuration: API parameters, networks, set of services, links to profiles. Target update version is spec.releaseVersion, node update strategy is spec.update.updateStrategy | Cluster dashboard, configuration editing and updating sections | API for cluster management, Update Kubernetes |
ClusterInfo (clusterinfo) | Summary information about the cluster for dashboards: status, versions, number of nodes, links to monitoring/log sections. Available update versions are status.update.availableUpdates | Cluster dashboard and related monitoring pages | Cluster graphs and dashboards |
ClusterProfile (clusterprofile) | Profile with which the cluster will be deployed: Kubernetes version, networks, logging/monitoring endpoints, default set of services | Cluster creation dialogs, default profile settings | Cluster Profiles |
ClusterUpdateSchedule (clusterupdateschedule) | Deferred update schedule. During the update window it writes the target version to the cluster ClusterConfig | Cluster dashboard → Update block → deferred update settings | Update Kubernetes |
InfrastructureProvider (infrastructureprovider) | Provider instance metadata: VM templates and Kubernetes versions (spec.templates), provider subtype (spec.subtype). Credentials are stored on the provider resource | Provider instance page | Preparing the Provider Template |
Kubectl example for cluster.shturval.tech
kubectl get clusterprofile -A
kubectl get infrastructureprovider -A
API group ops.shturval.tech
In the management cluster and client cluster.
| Resource | Purpose | Where is it used in GUI | Documentation |
|---|---|---|---|
ShturvalRepoConfig (shturvalrepoconfig) | Helm repositories configuration: URL, protocol, credentials, TLS | Services and repositories → Repositories tab | How to connect your repository |
ShturvalServiceConfig (shturvalserviceconfig) | Configuration of Helm charts (system services): version, control mode, basic customvalues | Services and repositories → Installed services, Service tab; as well as the Custom Resources section | Overview of working with services, System services of the Shturval repository |
ShturvalServicePatch (shturvalservicepatch) | Patch for customvalues system service (Helm release), applied on top of the base SSC; allows you to safely customize services | Tab Applied ShturvalServicePatch on the service page and through Administration → Custom Resources | How to manage CustomValues of services |
Kubectl example for ops.shturval.tech
kubectl get shturvalserviceconfig -A
API group update.shturval.tech
In the management cluster and client cluster.
| Resource | Purpose | Where is it used in GUI | Documentation |
|---|---|---|---|
ShturvalUpdate (shturvalupdate) | Resource for manually triggering cluster upgrades and tracking update status | The “Update” block on the cluster dashboard, section Administration → Custom resources → update.shturval.tech | Startup and update stages |
ShturvalUpdateChannel (shturvalupdatechannel) | Specifying the update channel (only the stable channel stable is available in the platform) | Update settings on the cluster dashboard; section Custom resources | Launch and update stages, Updating a mirror in a closed loop |
ShturvalUpdateSchedule (shturvalupdateschedule) | Schedule for automatic (delayed) cluster update | Setting up an update schedule on the cluster dashboard | Update modes |
Kubectl example for update.shturval.tech (ShturvalUpdateSchedule)
kubectl get shturvalupdateschedule -n shturval-update-system
The move to 2.15 is performed with the resources of this group. After the move to 2.15, the ShturvalUpdate, ShturvalUpdateChannel, and ShturvalUpdateSchedule objects are deleted.
An update from version 2.15 to a newer one is started by resources of the cluster.shturval.tech group: the target version and strategy are in ClusterConfig, the schedule is in ClusterUpdateSchedule, and available versions are in ClusterInfo.
API group permissions.shturval.tech
In the management cluster.
| Resource | Purpose | Where is it used in GUI | Documentation |
|---|---|---|---|
GroupRole (grouprole) | An object to associate a permission set with a user group; determines which Permissions apply to the group and at what level (platform, tenant, cluster, namespace) | Access control → Groups tab and assigning rights to groups | Custom resources for managing access rights, How access rights are assigned |
UserRole (userrole) | Object to associate a permission set with a specific user | Access control → Users tab and assigning rights to users | Custom resources for managing access rights, How access rights are assigned |
Scope (scope) | A set of permission enforcement objects (for example, a platform, a specific tenant, a cluster, or a namespace) | The internal essence of the access control system; displayed through the access tree and rights assignment pages | Permission settings |
Permission (permission) | A set of permissions - platform, clusters, namespaces, Argo CD roles; underlies access sets | Access control → Access manager → access sets | Setting permissions, Custom resources for managing access rights |
| Tenant | Logical combination of entire clusters or namespaces of one or more clusters for access control | Section Tenants and corresponding tabs in Access Control | Tenant Concept |
Kubectl example for permissions.shturval.tech
kubectl get userrole -n shturval-backend
When to use GUI and when to use manifests
- GUI is convenient for typical operations: creating clusters, setting up services, assigning rights, changing node configurations.
- CRD manifests (
kubectl, YAML import) are useful when:- you want to version changes and apply them via GitOps;
- requires access to the full set of resource fields, not all of which are available in the GUI form.
Instructions for importing YAML manifests through the interface: Import.
For all of the listed CRDs, it is recommended to focus on the specialized sections of the documentation (links in the tables above) - they contain YAML examples, restrictions and typical usage scenarios.