All the Deckhouse components will be restarted during the update from the Deckhouse 1.33
Component version updates
- Kubernetes Control Plane: `1.23.7`, `1.22.10`, `1.21.13`
- cert-manager: `1.8.2`
- Ingress controller: `0.49.3`
- CoreDNS: `1.9.3`
Important update notes
- **All Deckhouse components will be restarted** including control-plane, ingress-nginx.
- The `ru-central1-c` **Yandex.cloud** zone was [deprecated](https://cloud.yandex.com/en/docs/overview/concepts/ru-central1-c-deprecation).
For new clusters NAT-instance will be created in `ru-central1-a` zone. For old instances you should add to `withNATInstance.natInstanceInternalAddress` (you can get address from Yandex.Cloud console)
and `withNATInstance.internalSubnetID` (you can get address using command `kubectl -n d8-system exec -it deploy/deckhouse -- deckhouse-controller module values cloud-provider-yandex -o json | jq -r '.cloudProviderYandex.internal.providerDiscoveryData.zoneToSubnetIdMap["ru-central1-c"]'`) to prevent NAT-instance recreation during a converge process.
Major changes
- The base container images used to build Deckhouse components have been updated to address known security issues (CVEs).
- New VMware vSphere and OpenStack-based clusters use the [cni-cilium](https://deckhouse.io/en/documentation/latest/modules/021-cni-cilium/) module by default (no change for existing clusters).
- A [dashboard](https://user-images.githubusercontent.com/32434187/175541471-2a09d908-9baa-4421-bfb2-fc82ba64efa9.png) that contains information about deprecated versions of APIs used in the cluster has been added.
- It is now possible to use the manually deployed Alertmanager for notifications (this one is relevant for Community Editions).
- New NAT instances in Yandex.Cloud are now provisioned in the `ru-central-1a` availability zone since the `ru-central1-c` availability zone has been decommissioned. Please note that you have to update the existing NAT instances [manually](https://github.com/deckhouse/deckhouse/blob/main/CHANGELOG/CHANGELOG-v1.34.md#know-before-update).
- A [command](https://deckhouse.io/en/documentation/latest/modules/020-deckhouse/usage.html#collect-debug-info) to collect debugging information has been added to Deckhouse. Providing this information to the Deckhouse team can significantly speed up troubleshooting.
- The log-shipper module now allows you to configure the [topology](https://deckhouse.io/en/documentation/latest/modules/460-log-shipper/#deployment-topologies) for sending logs. The following types are supported:
- *Distributed* — agents send logs directly to a repository (e.g., Loki or Elasticsearch-based one). This option is simpler, but it may require additional resources on the nodes for complex data manipulations;
- *Centralized* — logs are sent to an aggregator (such as Logstash or Vector). This option consumes less node resources and has a higher overall speed. Aggregators do all data processing.
See [CHANGELOG v1.34](https://github.com/deckhouse/deckhouse/blob/main/CHANGELOG/CHANGELOG-v1.34.md) for more details.