2019-12-19 02:02:26 +00:00
|
|
|
---
|
2020-04-07 18:55:19 +00:00
|
|
|
layout: docs
|
2020-09-01 15:14:13 +00:00
|
|
|
page_title: Upgrade
|
|
|
|
|
sidebar_title: Upgrade
|
|
|
|
|
description: Upgrade Consul on Kubernetes
|
2019-12-19 02:02:26 +00:00
|
|
|
---
|
|
|
|
|
|
2020-09-01 15:14:13 +00:00
|
|
|
# Upgrade Consul on Kubernetes
|
2019-12-19 02:02:26 +00:00
|
|
|
|
|
|
|
|
To upgrade Consul on Kubernetes, we follow the same pattern as
|
2020-04-09 23:46:54 +00:00
|
|
|
[generally upgrading Consul](/docs/upgrading), except we can use
|
2019-12-19 02:02:26 +00:00
|
|
|
the Helm chart to step through a rolling deploy. It is important to understand
|
2020-04-09 23:46:54 +00:00
|
|
|
how to [generally upgrade Consul](/docs/upgrading) before reading this
|
2019-12-19 02:02:26 +00:00
|
|
|
section.
|
|
|
|
|
|
|
|
|
|
Upgrading Consul on Kubernetes will follow the same pattern: each server
|
|
|
|
|
will be updated one-by-one. After that is successful, the clients will
|
|
|
|
|
be updated in batches.
|
|
|
|
|
|
|
|
|
|
## Upgrading Consul Servers
|
|
|
|
|
|
|
|
|
|
To initiate the upgrade, change the `server.image` value to the
|
|
|
|
|
desired Consul version. For illustrative purposes, the example below will
|
2020-01-22 03:29:55 +00:00
|
|
|
use `consul:123.456`. Also, set the `server.updatePartition` value
|
2019-12-19 02:02:26 +00:00
|
|
|
_equal to the number of server replicas_:
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
server:
|
2020-04-06 20:27:35 +00:00
|
|
|
image: 'consul:123.456'
|
2019-12-19 02:02:26 +00:00
|
|
|
replicas: 3
|
|
|
|
|
updatePartition: 3
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The `updatePartition` value controls how many instances of the server
|
|
|
|
|
cluster are updated. Only instances with an index _greater than_ the
|
|
|
|
|
`updatePartition` value are updated (zero-indexed). Therefore, by setting
|
|
|
|
|
it equal to replicas, none should update yet.
|
|
|
|
|
|
|
|
|
|
Next, run the upgrade. You should run this with `--dry-run` first to verify
|
|
|
|
|
the changes that will be sent to the Kubernetes cluster.
|
|
|
|
|
|
2020-05-19 18:32:38 +00:00
|
|
|
```shell-session
|
2019-12-19 02:02:26 +00:00
|
|
|
$ helm upgrade consul ./
|
|
|
|
|
...
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
This should cause no changes (although the resource will be updated). If
|
|
|
|
|
everything is stable, begin by decreasing the `updatePartition` value by one,
|
|
|
|
|
and running `helm upgrade` again. This should cause the first Consul server
|
|
|
|
|
to be stopped and restarted with the new image.
|
|
|
|
|
|
|
|
|
|
Wait until the Consul server cluster is healthy again (30s to a few minutes)
|
|
|
|
|
then decrease `updatePartition` and upgrade again. Continue until
|
|
|
|
|
`updatePartition` is `0`. At this point, you may remove the
|
|
|
|
|
`updatePartition` configuration. Your server upgrade is complete.
|
|
|
|
|
|
|
|
|
|
## Upgrading Consul Clients
|
|
|
|
|
|
|
|
|
|
With the servers upgraded, it is time to upgrade the clients. To upgrade
|
|
|
|
|
the clients, set the `client.image` value to the desired Consul version.
|
|
|
|
|
Then, run `helm upgrade`. This will upgrade the clients in batches, waiting
|
|
|
|
|
until the clients come up healthy before continuing.
|
2020-01-22 03:29:55 +00:00
|
|
|
|
|
|
|
|
## Configuring TLS on an Existing Cluster
|
|
|
|
|
|
|
|
|
|
If you already have a Consul cluster deployed on Kubernetes and
|
|
|
|
|
would like to turn on TLS for internal Consul communication,
|
|
|
|
|
please see
|
2020-04-28 18:11:26 +00:00
|
|
|
[Configuring TLS on an Existing Cluster](/docs/k8s/operations/tls-on-existing-cluster).
|
