AKS

This section of documentation covers the use of the managed Kubernetes Azure service AKS. For information on the installation of StorageOS with vanilla Kubernetes in Azure VMs, please refer to the Kubernetes standard installation procedure.

AKS and StorageOS

AKS deployment of Kubernetes uses Ubuntu by default with an optimized kernel. All versions of Ubuntu with a kernel version later than4.15.0-1029-azure meet the StorageOS prerequisites.

Kubernetes Upgrades

Currently upgrading the Kubernetes version on AKS is not supported. This is because nodes are replaced rather than being upgraded in place. As such manual relocation of data and etcd members is required. We are working with the AKS team to improve the upgrade process to create a better user experience.

Kubernetes with StorageOS

Kubernetes and StorageOS communicate with each other to perform actions such as creation, deletion or mounting of volumes. The CSI (Container Storage Interface) driver is the standard communication method. Using CSI, Kubernetes and StorageOS communicate over a Unix domain socket.

For this platform the only supported setup for communication is CSI.

CSI (Container Storage Interface) Note

CSI is the standard method of communication that enables storage drivers to release on their own schedule. This allows storage vendors to upgrade, update, and enhance their drivers without the need to update Kubernetes source code, or follow Kubernetes release cycles.

CSI is available from Kubernetes 1.9 alpha. CSI is considered GA from Kubernetes 1.13, hence StorageOS recommends the use of CSI. In addition, the StorageOS Cluster Operator handles the configuration of the CSI driver and its complexity by detecting the version of the Kubernetes installed.

Check out the status of the CSI release cycle in relation with Kubernetes in the CSI project page.

CSI communication is fully supported by StorageOS if the cluster is deployed with any supported Linux Distribution.

Docker

Some managed Kubernetes platforms enable the ‘Live-Restore’ Docker feature, enabling containers to continue running while Docker is stopped or upgraded. This feature can cause nodes to hang while shutting-down or rebooting, as rather than going through an orderly shutdown, StorageOS (and other processes) are killed before the disks are synced and unmounted. Devices in this inaccessible state will log a warning similar to:

Transport endpoint not connected

To prevent this behaviour, we advise disabling this feature by setting

{
    ...
    "live-restore": false
}

in /etc/docker/daemon.json.

Here’s an example Ansible snippet that might achieve this

...
- name: configure /etc/docker/daemon.json
  lineinfile:
      path: /etc/docker/daemon.json
      regexp: '^.*"live-restore": true,$'
      line: '  "live-restore": false,'
      backrefs: yes
  notify: restart docker
...

Note: Use at own risk; you may need to adapt the example to work in your environment