volcano.sh/volcano@v1.9.0/docs/design/queue/queue-state-management.md (about)

     1  # Queue State Management
     2  
     3  [@sivanzcw](https://github.com/sivanzcw); Oct 17, 2019
     4  
     5  ## Table of Contents
     6  
     7  - [Queue State Management](#queue-state-management)
     8    * [Table of Contents](#table-of-contents)
     9    * [Motivation](#motivation)
    10    * [Function Detail](#function-detail)
    11      + [Data Structure](#data-structure)
    12      + [Queue State](#queue-state)
    13      + [Queue Lifecycle Management](#queue-lifecycle-management)
    14      + [Queue Status Refreshment](#queue-status-refreshment)
    15      + [Queue Placement Restriction](#queue-placement-restriction)
    16      + [Queue State on The Scheduling Process](#queue-state-on-the-scheduling-process)
    17      + [Queue State on `vcctl`](#queue-state-on--vcctl-)
    18  
    19  ## Motivation
    20  
    21  The queue is an object of resource management in the cluster and the cornerstone of resource scheduling, which is
    22  closely related to the allocation of resources and the scheduling of tasks. The resources under the cluster are
    23  allocated according to the `weight` ratio of the queue. The configuration of queue guarantees the number of cluster
    24  resources that tasks can use under the queue and limits the maximum resources that can be used. A single user or
    25  user group is correspond to one or more queues, which is assigned and determined by the administrator. When queues
    26  splitting cluster resources, single queue obtains the resource guarantees and quotas for using resources, so that uses
    27  or user groups under the queue have opportunity to use cluster resources, Simultaneously due to the resource limitation
    28  of queue, the ability of users or user groups to user cluster resources is limited to prevent cluster from being
    29  overwhelmed by a single user to deliver a large number or tasks, thereby ensuring the `multi-tenancy` feature of
    30  scheduling. When task is delivered, it will be placed to a specific queue and pod scheduling will by affected by queue
    31  priority and queue resource status. It is worth mentioning that the resource allocation of queue and limitation of
    32  queue resource can be dynamically adjusted. The queue can flexibly acquire remaining resources under cluster if there
    33  are idle resources, when a queue is busy, and there are idle resources under the cluster, the queue may break the
    34  original resource limit and try to occupy the remaining cluster resources.
    35  
    36  Based on the above description, it can be found that queue is a crucial object in the process of resource scheduling.
    37  There should have a complete guarantee mechanism to ensure the stability of queue without losing the flexibility of
    38  queue. Firstly, the queue should not be deleted arbitrarily, since if the queue is deleted, the unscheduled tasks in
    39  the queue will not be scheduled normally and the resources occupied by running tasks in the queue will not be normally
    40  counted. However, considering the flexibility of resource control, queue should not be forbidden to delete. In addition,
    41  considering the decisive role of queue in resource management, the administrator will control which user or user group
    42  can use cluster resources by controlling queue which also requires queue to provide corresponding capabilities.
    43  
    44  Therefore, we need to provide `State Management` capabilities for queue. Add the state configuration for queue and
    45  adjust capabilities of queue by judging the state of queue, thereby achieving the management of queue lifecycle and
    46  scheduling of tasks under the queue.
    47  
    48  ## Function Detail
    49  
    50  ### Data Structure
    51  
    52  Add `state` to `properties` in `spec` of CRD `queues.scheduling.sigs.dev`. The `state` of queue controller the status
    53  of queue.
    54  
    55  ```go
    56  spec:
    57    properties:
    58      ...
    59  
    60      state:
    61        type: string
    62  
    63      ...
    64  ```
    65  
    66  Add `state` to `properties` in `status` of CRD `queues.scheduling.sigs.dev`. The `state` of queue display the status of
    67  current queue.
    68  
    69  ```go
    70  status:
    71    properties:
    72      ...
    73  
    74      state:
    75        type: string
    76  
    77      ...
    78  ```
    79  ### Queue State
    80  
    81  Valid queue state includes:
    82  
    83  * `Open`, indicates that the queue is available, the queue receives new task delivery
    84  * `Closed`, indicated that the queue is unavailable, the queue will wait for the subordinate tasks to gracefully exit,
    85  which does not mean that the system will actively delete tasks under the queue. However, the queue does not receive new
    86  task delivery
    87  * `Closing`, is a intermediate state between `Open` and `Closed`. When the state of queue is `Open` and there
    88  are tasks running or waiting to be scheduled under the queue. At this time, we try to change the state of queue to
    89  `Closed`. The state of queue will changes to `Closing` firstly and then changes to `Closed` when all the tasks under
    90  the queue exist.
    91  
    92  The ability of queue corresponding to queue state as show in the following table:
    93  
    94  | state     | default | can be set | receive delivery | can be deleted | can be scheduled | deserved resources |
    95  | :-------: | :-----: | :--------: | :--------------: | :------------: |:---------------: | :----------------: |
    96  | `Open`    | Y       | Y          | Y                | N              | Y                | Normal             |
    97  | `Closed`  | N       | Y          | N                | Y              | Y                | Normal             |
    98  | `Closing` | N       | N          | N                | N              | Y                | Normal             |
    99  
   100  * If the state of queue is not specified during the creating of queue, the queue will use default state `Open`
   101  * When creating a new queue, the user can only specify `Open` or `Closed` state for queue
   102  * Only the queue with `Open` state accept new task delivery. the task will be rejected when it is posted to the queue
   103  with `Closed` or `Closing` state
   104  * Only the queue with `Closed` state can be deleted
   105  
   106  ### Queue Lifecycle Management
   107  
   108  In the lifecycle management of queue, we need to guarantee the following three points:
   109  
   110  * When creating a new queue, if the user does not specify a state for queue, we need to specify default `Open` state
   111  for it, If the user specifies a state for queue, the specified state must be a valid value, valid values are `Open`
   112  and `Closed`.
   113  * When upgrading the queue, if state of queue changed, the specified state value must be valid.
   114  * when deleting the queue, only queue with `Closed` status can be deleted successfully. The `status` here is the `state`
   115  under the status of queue, not the `state` under the `spec` of queue.
   116  * `default` queue can not be deleted
   117  
   118  Add `validatingwebhookconfiguration` for queue validation during creating, updating or deleting of queue.
   119  
   120  ```yaml
   121  apiVersion: admissionregistration.k8s.io/v1
   122  kind: ValidatingWebhookConfiguration
   123  metadata:
   124    name: {{ .Release.Name }}-validate-queue
   125  webhooks:
   126    - clientConfig:
   127        caBundle: ""
   128        service:
   129          name: {{ .Release.Name }}-admission-service
   130          namespace: {{ .Release.Namespace }}
   131          path: /queues
   132      failurePolicy: Fail
   133      name: validatequeue.volcano.sh
   134      namespaceSelector: {}
   135      rules:
   136        - apiGroups:
   137            - "scheduling.sigs.dev"
   138          apiVersions:
   139            - "v1alpha2"
   140          operations:
   141            - CREATE
   142            - UPDATE
   143          resources:
   144            - queues
   145  ```
   146  
   147  Add implementation function `AdmitQueues`
   148  
   149  ```go
   150  func AdmitQueues(ar v1beta1.AdmissionReview) *v1beta1.AdmissionResponse {
   151  	...
   152  	queue, err := DecodeQueue(ar.Request.Object, ar.Request.Resource)
   153  	reviewResponse := v1beta1.AdmissionResponse{}
   154  	validateQueue(queue, &reviewResponse)
   155  	...
   156  }
   157  ```
   158  
   159  The above function will complete the following verification:
   160  
   161  * During creating or upgrading queue, verify the validity of the queue state
   162  * During deleting queue, check if queue can be deleted
   163  
   164  We need another `webhook` to set default state value for queue during queue creating, add `mutatingwebhookconfiguration`
   165  and `MutateQueues` function
   166  
   167  ```yaml
   168  apiVersion: admissionregistration.k8s.io/v1
   169  kind: MutatingWebhookConfiguration
   170  metadata:
   171    name: {{ .Release.Name }}-mutate-queue
   172  webhooks:
   173    - clientConfig:
   174        caBundle: ""
   175        service:
   176          name: {{ .Release.Name }}-admission-service
   177          namespace: {{ .Release.Namespace }}
   178          path: /mutating-queues
   179      failurePolicy: Fail
   180      name: mutatequeue.volcano.sh
   181      namespaceSelector: {}
   182      rules:
   183        - apiGroups:
   184            - "scheduling.sigs.dev"
   185          apiVersions:
   186            - "v1alpha2"
   187          operations:
   188            - CREATE
   189          resources:
   190            - queues
   191  ```
   192  
   193  ```go
   194  func MutateQueues(ar v1beta1.AdmissionReview) *v1beta1.AdmissionResponse {
   195  	...
   196  	queue, err := DecodeQueue(ar.Request.Object, ar.Request.Resource)
   197  	reviewResponse := v1beta1.AdmissionResponse{}
   198  	createPatch(queue)
   199  	...
   200  }
   201  ```
   202  
   203  ### Queue Status Refreshment
   204  
   205  When refreshing the status of queue, the `state` value under `spec.properties` and podgroup condition under the queue will be
   206  considered:
   207  
   208  * If the `state` value is empty, the status of queue will be set as `Open`
   209  * If the `state` value is `Open`, then the status of queue will also be `Open`
   210  * If the `state` value is `Closed`, then we need to further consider whether there is a podgroup under the queue. if
   211  there is a podgroup under the queue, the status of the queue will be set as `Closing`, while if there is no podgroup
   212  under the queue, the status of queue will be set as `Closed`.
   213  
   214  ### Queue Placement Restriction
   215  
   216  When creating job, we need to verify the status of queue specified by the job:
   217  
   218  * Allow job to be create, if the job does not specify a queue name
   219  * If the job specifies a queue name and the status of the queue is `Open`, the job is allowed to create
   220  * If the status of queue is not `Open`, the job creation request will be rejected.
   221  
   222  ### Queue State on The Scheduling Process
   223  
   224  The above three states of queue have no effect on the existing scheduling process, for there is no pod under queue with
   225  `Closed` state, while pods under queues with `Open` or `Closing` state should be scheduled normally.
   226  
   227  ### Queue State on `vcctl`
   228  
   229  We need to add support for `queue state management` in `vcctl`, mainly including the following changes:
   230  
   231  * Support for passing state of queue when creating queue
   232  * When getting queue detail or queue list, we need to display the status of the queue
   233  * Provide update function of queue, the function supports updating the `weight` or `state` of queue
   234  * Provide delete function of queue
   235  * Add queue operation interface, add `queue open` `queue close` `queue update` support