Version: 0.7

Cluster Plans

What are Cluster Plans?#

Cluster plans provide platform operators the means to shape the options and configuration available for teams to self-serve their environment. You can specify kubernetes versions, node pools and instance types, provider features such as GKE Autorepair and autoscaling, as well as options related to default roles the teams inherit.

# Display a list of all plans in Kore
$ kore get plan
RESOURCE SUMMARY DESCRIPTION KIND AGE
aks-development Provides a development AKS cluster AKS Development Cluster AKS 27d
aks-production Provides a production AKS cluster AKS Production Cluster AKS 27d
eks-development Provides a development cluster within EKS EKS Development Cluster EKS 125d
eks-production Provides a production cluster within EKS EKS Production Cluster EKS 125d
gke-budget-cluster Provides a cheap cluster using pre-emptible nodes, good for testing GKE Budget Cluster GKE 30d
gke-development Provides a development cluster within GKE GKE Development Cluster GKE 133d
gke-production Provides a production cluster within GKE GKE Production Cluster GKE 133d

From the UI navigate to plans via Configure > Cloud > Provider > Cluster Plans. By default, all teams can access all plans, however if you have configured Kore cloud account automation you can restrict this by only including certain plans in the naming rules.

What is the purpose of plans?#

  • Provide sane defaults out of the box.
  • Remove the need for domain knowledge in your teams. They need to consume an environment to deploy their applications and are thinking more in line of staging, dev, production than cluster types.
  • Provide guard rails around the options teams can pick and choose to keep it inline to the organization's requirements.

Once the plans are setup teams can consume them when building their environment, for example:

kore create cluster --plan gke-development <name>

What are plan policies?#

Providing options is great, but teams may need to override from the norm. Plan policies provide the means for platform operators to say certain options can be overridden by the team while others cannot, e.g. you can allow the team to add another node pool, change the machine type, or set the network CIDR permitted to access the API.

$ kore get planpolicy
RESOURCE SUMMARY DESCRIPTION AGE
allow-gke-node-type-changes Allow GKE node type changes 86d
default-aks Default plan policy for AKS clusters This policy defines which plan properties can be edited by default for AKS clusters 27d
default-eks Default plan policy for EKS clusters This policy defines which plan properties can be edited by default for EKS clusters 127d
default-gke Default plan policy for GKE clusters This policy defines which plan properties can be edited by default for GKE clusters 127d
restrict-ip-editing Restrict IP Editing Teams with this policy applied cannot edit IP ranges 86d
$ kore get planpolicy restrict-ip-editing -o yaml
apiVersion: config.kore.appvia.io/v1
kind: PlanPolicy
metadata:
name: restrict-ip-editing
namespace: kore-admin
spec:
description: Teams with this policy applied cannot edit IP ranges
kind: GKE
properties:
- allowUpdate: false
disallowUpdate: true
name: authorizedMasterNetworks
summary: Restrict IP Editing

You can define and edit policies using the UI via Configure > Cloud > Provider > Cluster Policies.

All properties default to read-only, then the default policies which ship with Kore enable editing on a number of fields. You can define additional policies to restrict or widen the fields which teams can edit.

Each policy can be applied to either all teams, or one or more specified teams, allowing you to permit specific teams greater control if needed.

An explicit deny cannot be overridden, so if you set a global deny for a field, you cannot override that for a specific team. Instead, leave it unspecified at the global level (which will make it read-only by default), then create a policy to allow that field to be edited for the team you wish.