159-scheduler-simulator-operator

KEP-159: Scheduler Simulator Operator

Summary

A new custom resource to represent a simulator itself and a custom controller to manage it will be introduced.

Motivation

With this, we can easily create/use the simulator as sandbox for the simulator by creating the Simulator custom resource.

This feature also makes it easier to handle simulators from other CRD or controllers. They can gets the information for the simulator easily by accessint the Simulator resource.

Goals

• Users can define simulators via Simulator resources.
• The controller will manage(create, edit, delete) simulators.

Non-Goals

Create new Simulator from Web UI. (may be implemented in the future, but out of scope of this proposal.)

Proposal

Implementation design details

Required prior knowledge

The current simulator is built in a single binary: the binary contains kube-apiserver, kube-scheduler and the simulator backend (which provides the web UI specific feature.)

And, the simulator can be configured via environment variables.

Simulator CRD

The CRD Simulator will be applied to kube-apiserver in user's cluster. (not to simulator's kube-apiserver.)

It will create the Pod for the simulator in the same namespace.

type Simulator struct {
  metav1.TypeMeta 
  metav1.ObjectMeta // namespaced.

  Spec SimulatorSpec
  Status SimulatorStatus
}

// SimulatorSpec has the spec for the simulator.
// All fields can be updated, but a Pod will be restarted.
//
// Note that all data stored in "etcd" container will be removed if you don't specify Volume in "etcd" container.
// Or, you can use an external etcd with EtcdURL.
type SimulatorSpec struct {
  // KubeAPIServerPort indicates the kube-apiserver’s port which the simulator has internally.
  // (The each simulator has own kube-apiserver internally.)
  // This field's value will be added to a "simulator" container's env as "KUBE_API_PORT".
  KubeAPIServerPort            int 
  // SimulatorServerPort indicates the port for the simulator’s endpoint.
  // This field's value will be added to a "simulator" container's env as "PORT".
  SimulatorServerPort          int 
  // KubeSchedulerConfigurationPath indicates the path to configuration for the scheduler. 
  // The Simulator has the scheduler internally and you can configure it with this configuration.
  // This field's value will be added to a "simulator" container's env as "KUBE_SCHEDULER_CONFIG_PATH".
  // optional
  KubeSchedulerConfigurationPath   string
  // EtcdURL indicates the URL of etcd used in kube-apiserver.
  // If this field is empty, the Pod created by this Simulator resource will have the etcd container.
  // This field's value will be added to a "simulator" container's env as "KUBE_SCHEDULER_SIMULATOR_ETCD_URL".
  // optional
  EtcdURL *string
  // CORSAllowedOriginList indicates the AllowedOriginList for CORS. 
  // This is applied to kube-apiserver and simulator server.
  // This field's value will be added to a "simulator" container's env as "CORS_ALLOWED_ORIGIN_LIST".
  // optional.
  CORSAllowedOriginList        []string
  // Image should be the image of simulator.
  // You can use your customized simulator here, but the simulator container created by this image should follow these things:
  // - can be configured by the same environment variables. 
  // - (will add other requirements if any)
  Image                        string
  // Describes the pod that will be created.
  // This Pod should create the simulator.
  //
  // The system will add the container named "simulator" that: 
  // - run the simulator created by image specified in Image field,
  // - have Ports for kube-apiserver and the simulator endpoint,
  // - have environment variables to configure the simulator.
  // 
  // And if the EtcdURL field is empty, the system will add the container named "etcd" for kube-apiserver.
  // 
  // You can overwrite those container spec by defining containers that have the same name, "simulator" or "etcd".
  // 
  // When PodTemplate has the container(s) named "simulator" or "etcd" and the field is different from the container spec generated by other fields in SimulatorSpec,
  // container(s) definition in PodTemplate takes precedence.
  PodTemplate *corev1.PodTemplateSpec 
}

type SimulatorStatus struct {
  Phase SimulatorPhase

  // A human readable message indicating details about why the simulator is in this phase.
  // optional
  Message *string 

  // KubeAPIServerURL is the url to access the kube-apiserver in the simulator.
  KubeAPIServerURL string
}

type SimulatorPhase string
const (
  // SimulatorPending means the simulator is waiting for the controller to start to creating the Pod for this Simulator resource.
  SimulatorPending SimulatorPhase = "Pending"
  // SimulatorCreating means the simulator is being creating. 
  SimulatorCreating SimulatorPhase = "Creating"
  // SimulatorAvailable means the simulator is available.
  SimulatorAvailable SimulatorPhase = "Available"
)

Alternatives