Skip to content

Latest commit

 

History

History
177 lines (119 loc) · 7.46 KB

MAIN.release-notes.adoc

File metadata and controls

177 lines (119 loc) · 7.46 KB
Raw

{productname} {productversion} Release Notes

Warning
 !!! This is a preview release. Not to be distributed outside of SUSE !!!
Warning
 This software is not ready for production use.
Note
 The released version is {productname} {productversion}

Supported Platforms

This release supports deployment on

  • {soc} 8

  • VMWare ESXi {vmware_version}

  • Bare metal

Changes To Base OS

Base Operating System Is Now {slsa} 15 SP1

The previous version used a minimal OS image called MicroOS. {productname} {productmajor} uses standard {sls} 15 SP1 as the base platform OS. {productname} can be installed as an extension on top of that. Because {slsa} 15 is designed to address both cloud-native and legacy workloads, these changes make it easier for customers who want to modernize their infrastructure by moving existing workloads to a {kube} framework.

Transactional updates are available as a technical preview but {productname} {productmajor} will initially ship without the transactional-update mechanism enabled. The regular zypper workflow allows use of interruption-free node reboot. The {slsa} update process should help customers integrate a Kubernetes platform into their existing operational infrastructure more easily, nevertheless transactional updates are still the preferred process for some customers, which is why we provide both options.

Software Now Shipped As Packages Instead Of Disk Image

In the previous version, the deployment of the software was done by downloading and installing a disk image with a pre-baked version of the product. In {productname} {productmajor}, the software is distributed as RPM packages from an extension module in {sle} 15 SP1. This adaptation towards containers and {sls} mainly gives customers more deployment flexibility.

More Containerized Components

We moved more of the components into containers, namely all the control plane components: etcd, kube-apiserver, kube-controller-manager, and kube-scheduler. The only pieces that are now running uncontainerized are CRI-O, kubelet and kubeadm.

New Deployment Methods

We are using a combination of skuba (custom wrapper around kubeadm) and HashiCorp Terraform to deploy {productname} machines and clusters. We provide Terraform state examples that you can modify to roll out clusters.

Deployment on bare metal using AutoYaST has now also been tested and documented: https://susedoc.github.io/doc-caasp/beta/caasp-deployment/single-html/#_deployment_on_bare_metal

Note
 You must roll out a load balancer manually, this is currently not possible by using terraform. Find an example of a possible load balancer configuration based on {sle} 15 SP1 and nginx in the {productname} Deployment Guide: https://susedoc.github.io/doc-caasp/beta/caasp-deployment/single-html/#_load_balancer

Updates Using Kured

Updates are implemented with skuba-update, that makes use of the kured tool and the SLE package manager. This is implemented in the skuba-update tool which glues zypper and the kured tool (https://github.com/weaveworks/kured). Kured (KUbernetes REboot Daemon) is a Kubernetes daemonset that performs safe automatic node reboots when the need to do so is indicated by the package management system of the underlying OS. Automatic updates can be manually disabled and configured: https://susedoc.github.io/doc-caasp/beta/caasp-admin/single-html/#_cluster_updates

Changes To Kubernetes Stack

Updated Kubernetes

{productname} {productversion} ships with {kube} {kube_version}. This latest version mainly contains enhancements to core {kube} APIs: CustomResourceDefinitions Pruning, -Defaulting and -OpenAPI Publishing. cluster life cycle stability and usability has been enhanced (kubeadm init and kubeadm join can now be used to configure and deploy an HA control plane) and new functionality of the Container Storage Interface (volume cloning) is available. Read up about the details of the new features of {kube} {kube_version} here: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#115-whats-new

CRI-O Replaces Docker

{productname} now uses CRI-O {crio_version} as the default container runtime. CRI-O is a container runtime interface based on the OCI standard technology. The choice of CRI-O allows us to pursue our open-source agenda better than competing technologies.

CRI-O’s simplified architecture is tailored explicitly for {kube} and has a reduced footprint but also guarantees full compatibility with existing customer images thanks to its adherence to OCI standards. Other than Docker, CRI-O allows to update the container runtime without stopping workloads; providing improved flexibility and maintainabilitty to all {productname} users.

We will strive to maintain {productname}'s compatibility with the Docker Engine in the future.

Cilium Replaces Flannel

{productname} now uses Cilium {cilium_version} as the Container Networking Interface enabling networking policy support.

Centralized logging

The deployment of a Centralized Logging node is now supported for the purpose of aggregating logs from all the nodes in the kubernetes cluster. Centralized Logging forwards system and Kubernetes cluster logs to a specified external logging service, specifically the Rsyslog server, using Kubernetes Metadata Module - mmkubernetes.

Obsolete Components

Salt

Orchestration of the cluster no longer relies on Salt. Orchestration is instead achieved with kubeadm and skuba.

Admin Node / Velum

The Admin Node is no longer necessary. The cluster will now be controlled by the master nodes and through API with skuba on the local workstation. This also means the Velum dashboard is no longer available.

Known Issues

Updating from Beta 4 to Beta 5

Due to an internal change in the architecture, this update requires a manual step. This step does not cause any service interruption and can be run simultaneously on several nodes.

To safely update from skuba version 0.7.1 to 0.8.1, SSH to each of the nodes and run the following:

sudo zypper in -y patterns-caasp-Node-1.15 -patterns-caasp-Node

Layer 7 Policies in Cilium

The current implementation of Cilium in {productname} does not support Layer 7 policies!

Renaming caaspctl to skuba

The caaspctl tool has been renamed from its working title to skuba with the release of {productname} Beta 3.

Other Known Issues: