58cca5c14a
The openstack-helm docs currently state that the openstack-helm dev team will work with Helm with regards to facilitating job upgrades. This is misleading in that we do not directly contribute to Helm and currently provide methods for charts to run jobs for an upgrade for instances where images are updated, the job is deleted and re-ran. Change-Id: If04367b6563ed36c3b3cde7a9cd4425b6795505f
72 lines
2.8 KiB
ReStructuredText
72 lines
2.8 KiB
ReStructuredText
Upgrades and Reconfiguration
|
|
----------------------------
|
|
|
|
The OpenStack-Helm project assumes all upgrades will be done through
|
|
Helm. This includes handling several different resource types. First,
|
|
changes to the Helm chart templates themselves are handled. Second, all
|
|
of the resources layered on top of the container image, such as
|
|
``ConfigMaps`` which includes both scripts and configuration files, are
|
|
updated during an upgrade. Finally, any image references will result in
|
|
rolling updates of containers, replacing them with the updating image.
|
|
|
|
As Helm stands today, several issues exist when you update images within
|
|
charts that might have been used by jobs that already ran to completion
|
|
or are still in flight. An example of where this behavior would be
|
|
desirable is when an updated db\_sync image has updated to point from
|
|
one openstack release to another. In this case, the operator will likely
|
|
want a db\_sync job, which was already run and completed during site
|
|
installation, to run again with the updated image to bring the schema
|
|
inline with the Newton release.
|
|
|
|
The OpenStack-Helm project also implements annotations across all chart
|
|
configmaps so that changing resources inside containers, such as
|
|
configuration files, triggers a Kubernetes rolling update. This means
|
|
that those resources can be updated without deleting and redeploying the
|
|
service and can be treated like any other upgrade, such as a container
|
|
image change.
|
|
|
|
Note: Rolling update values can conflict with values defined in each
|
|
service's PodDisruptionBudget. See
|
|
`here <https://docs.openstack.org/openstack-helm/latest/devref/pod-disruption-budgets.html>`_
|
|
for more information.
|
|
|
|
This is accomplished with the following annotation:
|
|
|
|
::
|
|
|
|
...
|
|
annotations:
|
|
configmap-bin-hash: {{ tuple "configmap-bin.yaml" . | include "helm-toolkit.utils.hash" }}
|
|
configmap-etc-hash: {{ tuple "configmap-etc.yaml" . | include "helm-toolkit.utils.hash" }}
|
|
|
|
The ``hash`` function defined in the ``helm-toolkit`` chart ensures that
|
|
any change to any file referenced by configmap-bin.yaml or
|
|
configmap-etc.yaml results in a new hash, which will then trigger a
|
|
rolling update.
|
|
|
|
All ``Deployment`` chart components are outfitted by default
|
|
with rolling update strategies:
|
|
|
|
::
|
|
|
|
# Source: keystone/templates/deployment-api.yaml
|
|
spec:
|
|
replicas: {{ .Values.pod.replicas.api }}
|
|
{{ tuple $envAll | include "helm-toolkit.snippets.kubernetes_upgrades_deployment" | indent 2 }
|
|
|
|
In ``values.yaml`` in each chart, the same defaults are supplied in every
|
|
chart, which allows the operator to override at upgrade or deployment
|
|
time.
|
|
|
|
::
|
|
|
|
pod:
|
|
lifecycle:
|
|
upgrades:
|
|
deployments:
|
|
revision_history: 3
|
|
pod_replacement_strategy: RollingUpdate
|
|
rolling_update:
|
|
max_unavailable: 1
|
|
max_surge: 3
|