openyurtio
/
kruise
mirror of https://github.com/openkruise/kruise.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
kruise/docs/roadmap/2019-Q3.md

3.0 KiB
Raw Blame History

Kruise 2019 Q3 Roadmap

By the end of October, we plan to enhance the existing workload controllers with new features based on our original development plan and the feedbacks from the users. We also plan to release a few new workload controllers!

Terminology

M# represents the milestone starting from M1. Each milestone corresponds to a three-four weeks release cycle. M1 is expected to be released by the end of July 2019.

Enhancements

SidecarSet

  • [M1] Rolling Upgrade: Support rolling upgrading the sidecar containers for matched Pods if the sidecar container image is the only updated component, i.e., the upgrade can be done via "InPlaceUpgrade" strategy. In other cases where Pod recreation is needed, SidecarSet will not proactively delete the affecting Pods. Instead, it "lazily" relies on user to trigger Pod workload upgrade to recreate the Pods. The new version of sidecar containers will be injected during Pod creation. The rolling upgrade is done in a sequential manner, which means MaxUnavailable is equal to one.

  • [M1] Paused Rollout: User can pause the current rollout process to avoid potential conflicts with other controllers by setting the Paused flag. The rollout can be resumed by setting Paused to false.

  • [M2] Selective Upgrade: An upgrade Pod selector is added. The new sidecar container version will only be applied to the Pods that match the upgrade selector.

  • [M2] Parallel Upgrade: Support MaxUnavailable feature, which allows upgrading sidecar containers for multiple Pods simultaneously.

Advanced StatefulSet

  • [M1] Paused Rollout: If the StatefulSet rollout takes a long time due to large number of replicas, a Paused flag is introduced to allow user to pause the current rollout process. The rollout can be resumed by setting the Paused flag to false.

  • [M2] Auto Remediation: When creating new Pods in scaling or rollout workflow, it is possible that a created Pod cannot reach Ready state due to certain node problems. For example, node misconfiguration may cause constant failures on pulling images or starting the containers. AutoRemediation flag enables controller to delete a stuck pending Pod, and create an SchedPatch CRD which injects a Pod-to-node anti-affinity rule for all new Pods created by this controller.

  • [M2] Condition Report: Leverage the StatefulSetConditionType API to report the StatefulSet condition based on the scaling or roll out results.

New Controller

SchedPatch

  • [M2] This controller implements a Pod creation mutating webhook that adds auxiliary scheduling rules for Pods created by a target workload. The purpose is to change the Pod specification without modifying the target workload's Pod template, hence avoiding rolling out all existing Pods, in order to accommodate the new scheduling requirements. The auxiliary scheduling rules specified in the CRD include affinity, tolerations and node selectors. The CRD status reports the changed Pods for record.

-- TBD --