Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.29 upgrade notes #834

Merged
merged 11 commits into from
Feb 29, 2024
47 changes: 43 additions & 4 deletions pages/k8s/1.29/release-notes.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ toc: False
---
# 1.29

### February 23, 2024 - `charmed-kubernetes --channel 1.29/stable`
### February 12, 2024 - `charmed-kubernetes --channel 1.29/stable`

The release bundle can also be [downloaded here](https://raw.githubusercontent.com/charmed-kubernetes/bundle/main/releases/1.29/bundle.yaml).

Expand All @@ -24,8 +24,8 @@ The release bundle can also be [downloaded here](https://raw.githubusercontent.c
### Charmed Operator Framework (Ops)

We're pleased to announce the completion of the Charmed Kubernetes refactor that began
last year. Charms have moved from the `reactive` and `pod-spec` styles to the `ops`
framework in order to enable access to common charm libraries, gain better Juju support,
last year. Core charms have moved from the `reactive` and `pod-spec` styles to the `ops`
framework. This shift aims to enable access to common charm libraries, gain better Juju support,
and provide a more consistent charming experience for community engagement.

### Out of the box monitoring enhancements
Expand All @@ -38,6 +38,20 @@ observability tools.
This release expands our COS integration so that it includes rich monitoring for the
control plane and worker node components of Charmed Kubernetes.

### Ceph CSI

Ceph CSI resource management has been decoupled from the `kubernetes-control-plane`
charm. All new deployments should leverage the [ceph-csi][] charm for Ceph storage
provisioning, including support for CephFS. See the [updated documentation][ceph] for
details on deploying Charmed Kubernetes with Ceph support.

### OpenStack integration

OpenStack capabilities (including cinder storage and cloud provider) have been decoupled
from the `kubernetes-control-plane` charm. All new deployments should leverage the new
`openstack-integrator`, `openstack-controller-manager`, and `cinder-csi` charms. See the
[updated documentation][openstack] for more details.

### NVIDIA GPU Operator

The new [nvidia-gpu-operator][] charm simplifies the management of NVIDIA GPU resources
Expand Down Expand Up @@ -73,7 +87,29 @@ support and is offered as an alternative to the default Calico CNI.
All bug fixes and other feature updates in this release can be found at
[the launchpad milestone page for 1.29](https://launchpad.net/charmed-kubernetes/+milestone/1.29).

## Known Issues
<a id='notes-issues'> </a>

## Notes and Known Issues

### Integration gaps

While Charmed Kubernetes core charms have been rewritten in the `ops` framework, some
integrations with other charms in the Juju ecosystem are not available in this release.
If your deployment depends on the following, we recommend remaining on Charmed Kubernetes
1.28 until compatible support is provided in a subsequent release:

- AWS IAM authentication: [aws-iam](https://charmhub.io/aws-iam)
- Keystone authentication: [keystone](https://charmhub.io/keystone)
- Vault storage: [vault](https://charmhub.io/vault)

### Cloud integrators

Direct integration between `[aws|azure|gcp|openstack]-integrator` charms and
`kubernetes-control-plane` has been removed in this release. The recommended method for
enabling native cloud features is to use the respective out-of-tree cloud provider
charms. See the cloud-specific documentation for details.

### Bugs

A list of known bugs scheduled to be fixed in the first maintenance release can be found
on the [1.29+ck1 milestone page](https://launchpad.net/charmed-kubernetes/+milestone/1.29+ck1).
Expand All @@ -93,6 +129,9 @@ relevant sections of the [upstream release notes][upstream-changelog-1.29].
<!--LINKS-->

[rel]: /kubernetes/docs/release-notes
[ceph-csi]: https://charmhub.io/ceph-csi?channel=1.29/stable
[ceph]: /kubernetes/docs/ceph
[openstack]: /kubernetes/openstack-integration
[nvidia-gpu-operator]: https://charmhub.io/nvidia-gpu-operator?channel=1.29/stable
[gpu-workers]: /kubernetes/docs/gpu-workers
[install-local]: /kubernetes/docs/install-local
Expand Down
46 changes: 26 additions & 20 deletions pages/k8s/1.29/upgrading.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,9 +13,18 @@ layout: [base, ubuntu-com]
toc: False
---

<div class="p-notification--caution is-inline">
<div markdown="1" class="p-notification__content">
<span class="p-notification__title">Caution:</span>
<p class="p-notification__message">This release includes topology changes and new best practices for integrating <strong>Charmed Kubernetes</strong> with other Juju ecosystem solutions. Be sure to read and understand the *What's new* section of the <a href="/kubernetes/docs/1.29/release-notes">1.29 release notes</a> prior to upgrading your cluster.<br/>
<br/>
Additionally, some features from previous <strong>Charmed Kubernetes</strong> releases are not yet available in this release. If you rely on a component identified as an *Integration gap* in the <a href="/kubernetes/docs/1.29/release-notes#notes-issues">Notes and Known Issues</a> section of the release notes, remain on release 1.28 (or earlier) and do not upgrade to 1.29 at this time.</p>
</div>
</div>

It is recommended that you keep your **Kubernetes** deployment updated to the latest available stable version. You should also update the other applications which make up **Charmed Kubernetes**. Keeping up to date ensures you have the latest bug-fixes and security patches for smooth operation of your cluster.

You can check the latest release version on the [Kubernetes release page on GitHub][k8s-release].
New minor versions of **Kubernetes** are set to release three times per year. You can check the latest release version on the [Kubernetes release page on GitHub][k8s-release].
kwmonroe marked this conversation as resolved.
Show resolved Hide resolved

<div class="p-notification--information is-inline">
<div markdown="1" class="p-notification__content">
Expand Down Expand Up @@ -52,7 +61,7 @@ You should also make sure:
- Your Juju client and controller/models are running the same, stable version of Juju (see the [Juju docs][juju-controller-upgrade]).
- You read the [Upgrade notes][notes] to see if any caveats apply to the versions you are upgrading to/from.
- You read the [Release notes][release-notes] for the version you are upgrading to, which will alert you to any important changes to the operation of your cluster.
- You read the [Upstream release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#deprecation) for details of deprecation notices and API changes for Kubernetes 1.29 which may impact your workloads.
- You read the [Upstream release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#deprecation) for details of Kubernetes deprecation notices and API changes that may impact your workloads.

It is also important to understand that **Charmed Kubernetes** will only upgrade,
and migrate if necessary, components relating specifically to elements of
Expand All @@ -68,7 +77,7 @@ deprecated APIs.
</div>
</div>

## Upgrading the Machine's Series (required for machines currently running 18.04(Bionic))
## Upgrading the series (required for machines currently running Ubuntu 18.04)

All of the charms support [upgrading machine series via Juju](https://juju.is/docs/juju/manage-machines#heading--upgrade-a-machine).
As each machine is upgraded, the applications on that machine will be stopped and the unit will
Expand All @@ -84,12 +93,13 @@ outside of the cycle of new releases of Kubernetes.

This includes:

- calico or other CNI
- coredns
- easyrsa
- etcd
- flannel, calico or other CNI

Note that this may include other applications which you may have installed, such as
Elasticsearch, Prometheus, Nagios, Helm, etc.
Ceph, Docker Registry, MetalLB, Volcano, etc.

<a id='upgrading-containerd'> </a>

Expand Down Expand Up @@ -117,15 +127,16 @@ juju refresh etcd --channel=1.29/stable
To upgrade **etcd** itself, you will need to set the **etcd** charm channel config.

To determine the correct channel, go to the
[releases section of the bundle repository][bundle-repo] page and check the relevant
**Charmed Kubernetes** bundle. Within the bundle, you should see which channel
the **etcd** charm is configured to use.
[releases section of the bundle repository](https://github.com/charmed-kubernetes/bundle/tree/main/releases)
and check the relevant **Charmed Kubernetes** bundle. Within the bundle, you will see
which channel the **etcd** charm is configured to use.

Once you know the correct channel, set the **etcd** charm's channel config:

```bash
juju config etcd channel=3.4/stable
```

### Upgrading MetalLB (if used)

Previous versions of Charmed Kubernetes adopted a two charm approach for MetalLB. These were deployed in a K8s model with the suggested name `metallb-system`.
Expand Down Expand Up @@ -171,18 +182,18 @@ juju refresh easyrsa --channel=1.29/stable
```

Any other infrastructure charms should be upgraded in a similar way. For
example, if you are using the flannel CNI:
example, if you are using the calico CNI:

```bash
juju refresh flannel --channel=1.29/stable
juju refresh calico --channel=1.29/stable
```

<div class="p-notification--caution">
<p markdown="1" class="p-notification__response">
<span class="p-notification__status">Note:</span>
Some services may be briefly interrupted during the upgrade process. Upgrading
your CNI (e.g. flannel) will cause a small amount of network downtime. Upgrading
<strong>easyrsa</strong> will not cause any downtime. The behaviour of other
your CNI (e.g. calico) will cause a small amount of network downtime. Upgrading
easyrsa will not cause any downtime. The behaviour of other
components you have added to your cluster may vary - check individual documentation
for these charms for more information on upgrades.
</p>
Expand All @@ -193,8 +204,8 @@ for these charms for more information on upgrades.
Before you upgrade the **Kubernetes** components, you should be aware of the exact
release you wish to upgrade to.

The **Kubernetes** charms use **snap** _channels_ to manage the version of
**Kubernetes** to use. Channels are explained in more detail in the
The **Kubernetes** charms use snap _channels_ to manage the version of
**Kubernetes** they use. Channels are explained in more detail in the
[official snap documentation][snap-channels], but in terms of **Kubernetes** all you
need to know are the major and minor version numbers and the 'risk-level':

Expand All @@ -205,7 +216,7 @@ need to know are the major and minor version numbers and the 'risk-level':
| beta | Latest alpha/beta of Kubernetes for the specified release |
| edge | Nightly builds of the specified release of Kubernetes |

For most use cases, it is strongly recommended to use the 'stable' version of charms.
For most use cases, it is strongly recommended to use the _stable_ charm versions.

### Upgrading the **kube-api-loadbalancer**

Expand All @@ -222,11 +233,6 @@ that of NGINX rather than Kubernetes.

### Upgrading the **kubernetes-control-plane** units

**Note**: Older versions of Charmed Kubernetes used `kubernetes-master` as the charm name. This has been updated
to `kubernetes-control-plane`. However, it is not possible to rename a deployed application. If you
originally installed version 1.23 or before, your units will follow the old naming scheme and you should
substitute `kubernetes-control-plane` for `kubernetes-master` in the following commands.

To start upgrading the Kubernetes control plane units, first upgrade the charm:

```bash
Expand Down
Loading
Loading