OpenstackLCM

Rationale

  • Create a Kubernetes Operator able to orchestrate draining traffic, upgrading, testing, traffic rollout…
  • The main lesson learned from this POC is the ability to use the helm rendering to provide a unified way of delivering scripts onto a platform and at runtime selectively decide which part of the chart to render according to the state of the service which lifecycle may not match exactly the lifecycle of a helm chart (i.e install, upgrade, rollback, delete).
The Argo team published since an new subproject to argoproj called argo-rollout which seems really promising. Currently rely on replacing the standard StatefulSet by an Argo Rollout deployement object

Lessons Learned

Multi facet charts

  • TBD

Traffic Draining

  • TBD

ScaleUp / ScaleDown

  • TBD

Documentation

Associated GIT Repos

Build oslc-operator

Build

git clone -b kube15 https://github.com/keleustes/oslc-operator.git
make

Branches

  • master supports kubernetes 1.14.x and helm 2.13.x
  • kube15 supports kubernetes 1.15.x and helm 2.14.x

    LifeCycle

    Openstack Service Lifecycle

    Schema

    Rationale

    1. Some transitions from one phase/stage to the other are autonomous:
      • Start to test if install successful)
      • xxx
    2. Some transitions from one phase/stage to the other but be triggered by Ops.
      • For instance, the traffic will not be drained from a site unless Ops needs to perform operations:
      • xxx
    3. Some of the lifecyle can be applied to one slice/shard of the a service. This is what happens during a blue-green update.
      • xxx
      • xxx

    SW & Data Handling

    Schema

    FlowCharts

    Greenfield Deployment

    Schema

    Rationale

    1. Ops Team need to deploy a new service.
    2. If the service is unhealty, it gets removed.
    3. If the service is healty, it reaches the operational.

    Brownfield Change

    Schema

    Rationale

    1. Ops Team need to:

      • Use Case 1: remove a service.
      • Use Case 2: update a service.
      • Use Case 3: rollback a service.

    2. Once the traffic is drain:

      • Use Case 1: the service is removed.
      • Use Case 2: the service is updated.
      • Use Case 3: the service is rollback.

    3. Once the update/rollback is performed, the traffic is rollout.

      Oslc CRD

      LifeCycle Modelisation

      Design

      Oslc CRD

      The CRD Oslc definition is available here:

      1. Its Spec which is update through kubectl: Spec
      2. Its Status which is updated by the operator and accessible through kubectl describe: Status
      3. Its definition made out of the two above components: Definition
      4. The yaml version of the CRD: Yaml

      Oslc Controller

      TBD

      SubResources

      The current PhaseCRD are currently standalone CRDs. This provides control to the phase-controller on those objects. At one point we will have to weight if we need to keep those CRDs or simply consider the Phase as nodes of an Argo Workflow.

      Phase CRD

      Phase Modelisation

      Design

      Phase CRD

      The CRD Phase definition is available here:

      1. Its Spec which is update through kubectl: Spec
      2. Its Status which is updated by the operator and accessible through kubectl describe: Status
      3. Its definition made out of the two above components: Definition
      4. The yaml version of the CRD: Yaml

      Phase Controller

      The current POC created one CRD per phase. Most of the attributes of those CRDs are common. At one point we will have to weight the pros and cons of having only one PhaseCRD or one TestPhaseCRD, TrafficRolloutCRD.