First experiences with SAP Data Hub 1.4.0 on SUSE CaaS Platform 3.0 RC1
After having installed SAP Data Hub 1.4.0 on SUSE CaaSP 2.0, I am wondering what difference there was installing it on SUSE CaaSP 3.0.
To start with, the SUSE CaaSP 3.0 installer warns me, that version 3.0 RC1 is still a Beta Distribution, which is fine for my sandbox installation:
Besides this, the installation appears very similar to SUSE CaaSP 2.0:
The first obvious improvements come with the Initial CaaS Platform Configuration that now allows me to configure the:
- Overlay network settings
- Proxy settings
- SUSE registry mirror
- Container runtime
- System wide certificate
Under the hood, mainly the Kubernetes and Tiller versions seem to have changed:
| SUSE CaaS Platform 2.0 | SUSE CaaS Platform 3.0 |
| Kubernetes 1.8.10 | Kubernetes 1.9.8 |
| sles12/caasp-dex:2.7.1 | sles12/caasp-dex:2.7.1 |
| gcr.io/kubernetes-helm/tiller:v2.6.2 | sles12/tiller:2.8.2 |
| sles12/kubedns:1.0.0 | sles12/kubedns:1.0.0 |
| sles12/dnsmasq-nanny:1.0.0 | sles12/dnsmasq-nanny:1.0.0 |
| sles12/sidecar:1.0.0 | sles12/sidecar:1.0.0 |
But most importantly, Pod Security Policies are now being enabled by default with two out of the box Pod Security Policies:
- unprivileged (Default assigned to all users)
- privileged
Since SAP Data Hub 1.4.0 Replica Set vsystem-vrep needs to create a privileged container, I chose to deploy the least restricted policy you can create, equivalent to not using the pod security policy admission controller: policy/privileged-psp.yaml.
With this the SAP Data Hub 1.4.0 deployment completes even smoother than on SUSE CaaSP 2.0:
With Velum offering me these additional settings:
- Registries
- Remote Registries
- Mirrors
- System wide certificates
- Kubernetes
- Compute Resource Reservations
- Auditing
Overall, SUSE CaaS Platform 3.0 RC1 leaves a quite positive impression with me to run SAP Data Hub 1.4.0, so that I am looking forward to the final release.