1. Build your own private Cloud environment
Nico Meisenzahl, panagenda
nico.meisenzahl@panagenda.com
@nmeisenzahl

2. Make Your Data Work For You
Build your own private Cloud
environment
Nico Meisenzahl
DNUG 46, Essen

3. @panagenda Consultant.
Blogger, speaker
IBM Cloud Champion & Docker Community Leader
Loves K8s, containers & automation. His desk is a
ping pong table.
Nico Meisenzahl
@nmeisenzahl
https://meisenzahl.org
nico@meisenzahl.org
https://panagenda.com/modernization
nico.meisenzahl@panagenda.com

4. What is Cloud?
• someone else’s computer
• you do not need to care about everything
• can abstract
– Hardware → Infrastructure-as-a-Service
– underlying OS/machine → Platform-as-a-Service
– everything except your business logic → Function-as-a-Service
4

5. What is a private on-premises Cloud?
• for your colleagues
– someone else’s computer
– a platform which abstracts various things
– examples:
• deploy, run and scale containers
• just care about the code and let the system manage everything else
• for you
– your computer 😉
– a complex environment with multiple requirements
• flexibel, scalable and fast
• secure and state-of-the-art
– various topics like compute, storage, high-availability, security, ….
5

6. Some words on Containers
• A container consists of one or more processes that are isolated from
the rest of the system
• All files necessary for execution are provided by a separate image
6

7. Some words on Kubernetes
• open-source system for automating deployment, scaling, and
management of containerized applications using a declarative
approach
• greek for captain
• abstracts underlying machines and OS
• state-of-the-art for modern application deployment
• used to manage your workload
– Think of “vSphere for your containers”
7

8. Things you need to take care of
• Kubernetes environment
– provisioning, scalability, high-availability
– update/backup strategy
• Storage
• Monitoring, Metrics
• Log management
• Security
– Authentication, Authorisation, RBAC
– Workload security
• Surroundings
– Registry, CI/CD, Vulnerability scanning, Operators, etc.
– Service mesh, Functions/Serverless
8

9. Kubernetes provisioning
• Kubernetes can be complex
• “Kubernetes the hard way” is great for learning but not for production
• Tools which can support you
– Rancher Kubernetes Engine (RKE)
– KubeOne by Loodse
– IBM Cloud Private
– kubeadm
– https://kubernetes.io/docs/setup/pick-right-solution
• design and size your cluster based on your needs
– 1,3,5,7 master nodes, worker nodes, etcd nodee?
• external dependencies: Storage, Load-Balancer, vSphere...
9

10. Kubernetes update strategy
• one minor releases (1.x) every 3 months
• the last 3 minor releases are maintained/supported
– EOL after 9 months!
• define your update strategy based on your needs
– “in-place update” by adding/removing nodes
– “side-by-side” migration
10

11. Kubernetes Nodes
• Nodes aren’t persistent!
– scaling up/down nodes based on your workload (autoscaling!)
– updates (create new ones and delete old ones)
• therefore use
– a immutable approach instead of inplace upgrades
– automation and Infrastructure-as-Code approaches
• rethink your OS and Container Runtime
– do you need a full-blown OS?
– is Docker Engine needed?
11

12. Kubernetes backup strategy
• Kubernetes API is stateful, everything else is stateless
– stores its data in a etcd database
• Applications deployed in the Cluster store their data externally
• Restore etcd
– recreate your scripted infrastructure
– restore etcd snapshot
• Rebuild everything with IaC
– recreate your scripted infrastructure
– run your pipelines to deploy your applications
12

13. Persistent Storage
• stateful applications need volumes to store their data
• worker nodes need to be stateless
– scaling services on a multi-node environment
– up/down scaling nodes
• auto-provisioning is key
– no manual tasks when deploying/scaling services
– Persistent Volume Claims with Provisioner
• NFS, Ceph, GlusterFS, Minio, ...
13

14. Log management
• a central log management is needed to effectively debug applications
– applications are scaled on multiple nodes
– complex applications consist of many microservices
• collect logs using
– a logging agent on node-level
• stdout/stderr are collected by Container runtime
– a sidecar container approach
• logging container collects logs and forwards them
• Elasticsearch, Logstash/Fluentd, Kibana as logging stack
14

15. Monitoring & Metrics
• the chosen system needs to “understand” Kubernetes
• Prometheus is the common solution for monitoring and metrics
collection for services as well as Kubernetes itself
– collects and stores metrics
– altering using Alertmanager
– Dashboards with Grafana
• Prometheus pulls metrics using HTTP
– from URL
– using Prometheus Exporter library or sidecar
– dynamic Container monitoring using Kubernetes API (kube-state-metrics agent)
15

16. Authentication, Authorisation
• external service to provide/manage users
• Authentication
– X509 Client certificates
– OpenID
– Bearer Tokens
– static password file
– Service Account (managed by K8s)
– ...
• Authorisation
– used to define access level for different users and namespaces
– Role Based Access Control (RBAC) is recommended
– resources access is defined with verbs (get, create, delete, …) and identities (user,
group, ...)
16

17. Cluster workload security
• you will run different applications in one cluster!
• use Pod Security Policies (PSP) to define what a pod is allowed to do
– permit root, allowed user/group IDs
– allowed volume types
– allowed Linux capabilities, namespaces
– ...
• only use secure Images (vulnerability scanning)
• permit usage of untrusted Container Registries
17

18. Ecosystem
• Container Registry / Chart repository
– to store internal images
– include security topics like vulnerability scanning
• Kubernetes Operators
– can be used to deploy and manage custom ressources by extending the API
– example: Resource called “mongodb” which deploys a production ready cluster
• CI/CD
– build continuous pipelines to package/build/deploy your applications
– use templating to be able to deploy to various environments (e.g. Helm)
18

19. Some more thoughts ...
• move logic from your code into your platform by using a service mesh
– timeout/retry management, load-balancing, ...
– end-to-end encryption
• allow your Devs to only care about their code
– until now, we only talked about Platform-as-a-Service
– built Function-as-a-Service on top of K8s
19

20. Questions?
• Slides → https://www.slideshare.net/nmeisenzahl
20

21. Headquarters, Austria:
panagenda GmbH (Ltd.)
Schreyvogelgasse 3/10
AT 1010 Vienna
Phone: +43 1 89 012 89
Fax: +43 1 89 012 89-15
E-Mail: info@panagenda.com
Headquarters, Germany:
panagenda GmbH (Ltd.)
Lahnstraße 17
DE 64646 Heppenheim
Phone: +49 6252 67 939-00
Fax: +49 6252 67 939-16
E-Mail: info@panagenda.com
USA:
panagenda Inc.
60 State Street, Suite 700
MA 02109 Boston
Phone: +1 617 855 5961
Fax: +1 617 488 2292
E-Mail: info@panagenda.com
Germany:
panagenda Consulting GmbH (Ltd.)
Donnersbergstrasse 1
DE 64646 Heppenheim
Phone: +49 6252 67 939-86
Fax: +49 6252 67 939-16
E-Mail: info@panagenda.com
The Netherlands:
Trust Factory B.V.
11th Floor,
Koningin Julianaplein 10
NL 2595 AA The Hague
Phone: +31 70 80 801 96
E-Mail: info@trust-factory.com
© 2007-2015 panagenda
Make Your Data Work For You

22. DNUG e.V.
Pappelallee 78/79
10437 Berlin
Telefon: +49 30 20898805 0
Telefax: +49 30 20898805 1
E-Mail: info@dnug.de
Web: http://www.dnug.de