Fixes in style and more on CDK (#5292)
* Fixes in style and more on CDK * Addressing review comments
This commit is contained in:
Konstantinos Tsakalozos
committed by
Steve Perry
Steve Perry
parent
2b57c44a26
commit
e4fd3f81a8
@@ -9,29 +9,54 @@ This page will outline how to manage and execute a Kubernetes upgrade.
|
||||
{% capture prerequisites %}
|
||||
This page assumes you have a working deployed cluster.
|
||||
|
||||
## Assumptions
|
||||
**Warning:** You should always back up all your data before attempting an upgrade.
|
||||
Don't forget to include the workload inside your cluster!
|
||||
Refer to the [backup documentation](/docs/getting-started-guides/ubuntu/backups).
|
||||
{: .warning}
|
||||
|
||||
You should always back up all your data before attempting an upgrade. Don't forget to include the workload inside your cluster! Refer to the [backup documentation](/docs/getting-started-guides/ubuntu/backups).
|
||||
{% endcapture %}
|
||||
|
||||
{% capture steps %}
|
||||
## Preparing for an Upgrade
|
||||
## Patch kubernetes upgrades eg 1.7.0 -> 1.7.1
|
||||
|
||||
See if upgrades are available. The Kubernetes charms are updated bi-monthly and mentioned in the Kubernetes release notes. Important operational considerations and change in behaviour will always be documented in the release notes.
|
||||
Clusters are transparently upgraded to the latest Kubernetes patch release.
|
||||
To be clear, a cluster deployed using the 1.7/stable channel
|
||||
will transparently receive unattended upgrades for the 1.7.X Kubernetes
|
||||
releases.
|
||||
The upgrade causes no disruption to the operation of the cluster and requires
|
||||
no intervention from a cluster administrator.
|
||||
Each patch release is evaluated by the
|
||||
Canonical Kubernetes Distribution team.
|
||||
Once a patch release passes internal testing and is deemed safe for upgrade,
|
||||
it is packaged in snap format and pushed to the stable channel.
|
||||
|
||||
You can use `juju status` to see if an upgrade is available. There will either be an upgrade to kubernetes or etcd, or both.
|
||||
|
||||
# Upgrade etcd
|
||||
## Upgrading a minor Kubernetes release eg 1.7.1 -> 1.8.0
|
||||
|
||||
Backing up etcd requires an export and snapshot, refer to the [backup documentation](/docs/getting-started-guides/ubuntu/backups) to create a snapshot. After the snapshot upgrade the etcd service with:
|
||||
|
||||
The Kubernetes charms follow the Kubernetes releases. Please consult
|
||||
your support plan on the upgrade frequency. Important operational considerations
|
||||
and changes in behaviour will always be documented in the release notes.
|
||||
|
||||
You can use `juju status` to see if an upgrade is available.
|
||||
There may be an upgrade available for kubernetes, ectd, or both.
|
||||
|
||||
### Upgrade etcd
|
||||
|
||||
Backing up etcd requires an export and snapshot, refer to the
|
||||
[backup documentation](/docs/getting-started-guides/ubuntu/backups) to create a snapshot.
|
||||
After the snapshot upgrade the etcd service with:
|
||||
|
||||
juju upgrade-charm etcd
|
||||
|
||||
This will handle upgrades between minor versions of etcd. Major upgrades from etcd 2.x to 3.x are currently unsupported. Instead, data will be run in etcdv2 stores over the etcdv3 api.
|
||||
This will handle upgrades between minor versions of etcd. Major upgrades from
|
||||
etcd 2.x to 3.x are currently unsupported. Instead, data will be run in etcdv2 stores over the etcdv3 api.
|
||||
|
||||
# Upgrade Kubernetes
|
||||
### Upgrade Kubernetes
|
||||
|
||||
The Kubernetes Charms use snap channels to drive payloads. The channels are defined by `X.Y/channel` where `X.Y` is the `major.minor` release of Kubernetes (e.g. 1.6) and `channel` is one of the four following channels:
|
||||
The Kubernetes Charms use snap channels to drive payloads.
|
||||
The channels are defined by `X.Y/channel` where `X.Y` is the `major.minor` release
|
||||
of Kubernetes (e.g. 1.6) and `channel` is one of the four following channels:
|
||||
|
||||
| Channel name | Description |
|
||||
| ------------------- | ------------ |
|
||||
@@ -40,15 +65,19 @@ The Kubernetes Charms use snap channels to drive payloads. The channels are defi
|
||||
| beta | Latest alpha or beta of Kubernetes for that minor release |
|
||||
| edge | Nightly builds of that minor release of Kubernetes |
|
||||
|
||||
If a release isn't available, the next highest channel is used. For example, 1.6/beta will load `/candidate` or `/stable` depending on availability of release. Development versions of Kubernetes are available in that minor releases edge channel. There is no guarantee that edge or master will work with the current charms.
|
||||
If a release isn't available, the next highest channel is used.
|
||||
For example, 1.6/beta will load `/candidate` or `/stable` depending on availability of release.
|
||||
Development versions of Kubernetes are available in the edge channel for each minor release.
|
||||
There is no guarantee that edge snaps will work with the current charms.
|
||||
|
||||
## Master Upgrades
|
||||
### Master Upgrades
|
||||
|
||||
First you need to upgrade the masters:
|
||||
|
||||
juju upgrade-charm kubernetes-master
|
||||
|
||||
NOTE: Always upgrade the masters before the workers.
|
||||
**Node:** Always upgrade the masters before the workers.
|
||||
{: .note}
|
||||
|
||||
Once the latest charm is deployed, the channel for Kubernetes can be selected by issuing the following:
|
||||
|
||||
@@ -57,13 +86,17 @@ Once the latest charm is deployed, the channel for Kubernetes can be selected by
|
||||
Where `x` is the minor version of Kubernetes. For example, `1.6/stable`. See above for Channel definitions
|
||||
|
||||
|
||||
## Worker Upgrades
|
||||
### Worker Upgrades
|
||||
|
||||
Two methods of upgrading workers are supported. [Blue/Green Deployment](http://martinfowler.com/bliki/BlueGreenDeployment.html) and upgrade-in-place. Both methods are provided for operational flexibility and both are supported and tested. Blue/Green will require more hardware up front than inplace, but is a safer upgrade route.
|
||||
Two methods of upgrading workers are supported.
|
||||
[Blue/Green Deployment](http://martinfowler.com/bliki/BlueGreenDeployment.html)
|
||||
and upgrade-in-place. Both methods are provided for operational flexibility and both
|
||||
are supported and tested. Blue/Green will require more hardware up front than in-place,
|
||||
but is a safer upgrade route.
|
||||
|
||||
## Blue/Green Upgrade
|
||||
#### Blue/green worker upgrade
|
||||
|
||||
Given the following deployment, where the workers are named kubernetes-alpha.
|
||||
Given a deployment where the workers are named kubernetes-alpha.
|
||||
|
||||
Deploy new worker(s):
|
||||
|
||||
@@ -81,42 +114,40 @@ Tear down old workers with:
|
||||
|
||||
juju remove-application kubernetes-alpha
|
||||
|
||||
## In place worker upgrade
|
||||
#### In place worker upgrade
|
||||
|
||||
juju upgrade-charm kubernetes-worker
|
||||
juju config kubernetes-worker channel=1.x/stable
|
||||
|
||||
Where `x` is the minor version of Kubernetes. For example, `1.6/stable`. See above for Channel definitions. Once you've configured kubernetes-worker with the appropriate channel, run the upgrade action on each worker:
|
||||
Where `x` is the minor version of Kubernetes. For example, `1.6/stable`.
|
||||
See above for Channel definitions. Once you've configured kubernetes-worker with the appropriate channel,
|
||||
run the upgrade action on each worker:
|
||||
|
||||
juju run-action kubernetes-worker/0 upgrade
|
||||
juju run-action kubernetes-worker/1 upgrade
|
||||
...
|
||||
|
||||
# Verify upgrade
|
||||
### Verify upgrade
|
||||
|
||||
`kubectl version` should return the newer version.
|
||||
|
||||
It is recommended to rerun a [cluster validation](/docs/getting-started-guides/ubuntu/validation) to ensure that the cluster upgrade has successfully completed.
|
||||
It is recommended to rerun a [cluster validation](/docs/getting-started-guides/ubuntu/validation)
|
||||
to ensure that the cluster upgrade has successfully completed.
|
||||
|
||||
# Upgrade Flannel
|
||||
### Upgrade Flannel
|
||||
|
||||
Upgrading flannel can be done at any time, it is independent of Kubernetes upgrades. Be advised that networking is interrupted during the upgrade. You can initiate a flannel upgrade:
|
||||
Upgrading flannel can be done at any time, it is independent of Kubernetes upgrades.
|
||||
Be advised that networking is interrupted during the upgrade. You can initiate a flannel upgrade:
|
||||
|
||||
juju upgrade-charm flannel
|
||||
|
||||
# Upgrade easyrsa
|
||||
### Upgrade easyrsa
|
||||
|
||||
Upgrading easyrsa can be done at any time, it is independent of Kubernetes upgrades. Upgrading easyrsa should result in zero downtime as it is not a running service:
|
||||
Upgrading easyrsa can be done at any time, it is independent of Kubernetes upgrades.
|
||||
Upgrading easyrsa should result in zero downtime as it is not a running service:
|
||||
|
||||
juju upgrade-charm easyrsa
|
||||
|
||||
## Rolling back etcd
|
||||
|
||||
At this time rolling back etcd is unsupported.
|
||||
|
||||
## Rolling back Kubernetes
|
||||
|
||||
At this time rolling back Kubernetes is unsupported.
|
||||
{% endcapture %}
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
Reference in New Issue
Block a user