Get an intro on Kubernetes and how to deploy through Rancher. Discover how to start your CI/CD flow and integrate your build tools within Kubernetes. We'll show you how to secure your environment and manage your logging and monitoring.

1. Open19 k8s workshop
Part 1: Kubernetes deployment & management
K8S & Rancher - concepts

2. Historically
- from bare-metal installations (90's),
- through virtualized deployments (2000's),
- to containerized deployments (now)

3. Enablers:
- cloud computing -> cloud providers !
- scale: dynamic scaling on global level.
- security
- availability: from rack to data center to global region
- features (paas):
- app: databases
- app: file services
- infra: dns, certificates

4. Enablers – contd.
- infrastructure as code (eg terraform, ansible)
- (TF) cloud provider infrastructure (firewall rules, load balancers,
networks)
- (TF) virtual servers
- (TF/Ans) supporting services: file services, database services
- (Ans) os provisioning

5. Enablers – contd….
- docker: a bundle of packaged dependencies
- pets vs cattle: microservices:
- deployable
- upgradable
- scaleable
- recoverable
- container registries:
- docker hub
- standalone registry
- in-cluster registry
- cloud provider registry

6. Bringing it together: orchestration
- go beyond a simple ‘docker run’
- scheduling in function of:
- load
- availability
- rolling updates

7. Kubernetes (K8S): a container orchestrator
Roles
- etcd: key-value store db to hold configuration
- availability and cluster quorum
- backups & restores
- bottlenecks & scaling !
- control plane:
- api service to access the cluster
- scheduling logic
- management layer !

8. K8S Roles – contd.
- worker nodes:
- run the actual workloads
- can scale dynamically, leveraging cloud services

9. so cluster composition for a basic cluster:
- 3 etcd nodes due to quorum requirements.
- at least 2 (but we might as well combine with etcd roles and use 3)
CP nodes
- 2 or more workers (if possible using auto-scaling)
- Do not combine worker with cp/management role.
- So a total of 5 nodes per cluster seems sensible for testing.

10. K8s: application perspective
- declarative syntax: YAML
- unit of work: the pod
- deployments, stateful sets, daemonsets

11. K8s: storage – some thoughts
- try to leverage cloud provider storage api's when possible
( while avoiding vendor lock-in)
- traditional storage can be challenging (nfs, iscsi)
- storage vendors can provide storage provisioners through the CSI
- try to keep microservices stateless wherever possible
- currently an evolving topic (see CSI)

12. Storage model: abstraction layers
- Persistent Volumes: leverages a storage provisioner to reserve
actual storage on a physical device.
- Persistent Volume Claims: try to claim a created PV for use by
one or more pods
- Storage Classes: more dynamic way of mapping PVC's to actual storage
…and:
- software-defined: configmaps
Useful for: injecting variables into a container, injecting a config file

13. Networking: the cluster network
- SDN drivers: choices
- in-cluster communication: pod-to-pod & dynamic ip's
- accessing apps in-cluster: services
- service discovery: dns
- try to use tags as selectors when possible (more dynamic)

14. Accessing apps outside of the cluster
- nodeports:
- bound to a socket (same on every node)
- for tcp/udp services, eg smtp
- functionality implemented within k8s

15. Accessing apps: ingress
- ingress rules:
- add layer-7 logic (use case: http)
- choice of provisioner: eg nginx
- needs some kind of ingress provisioner as a third-party
component, popular: nginx. but also eg haproxy, F5, ...

16. Accessing apps…
- easy & cheap: dns rr
- in-app provisioned cloud lb
- on-prem or separately managed lb

17. Security boundaries
- namespaces administratively separating privileges on objects
- network policies: securing network communications within the
cluster network
- RBAC
- ingress: for application access, API server: for management.
- so foresee separate incoming paths for both

18. K8s: bringing it together
- app: combination of components
- pods, services and a deployment model (eg deployments)
- persistent storage if needed
- a way to access the app: in-cluster <-> outside of cluster
- configuration objects (configmaps, static config files)
- scaling & security logic
- health checks
- ...

19. Rolling out your app
- set of yml files (or one big yml file), similar to docker compose
- k8s package manager: helm
- helm can be integrated into your deployment strategy
- can work with variables & tags, supports concept of upgrades &
rollbacks
- hierarchy: <docker image> -> <container> -> <pod>
-> <deployment> -> <ingress> -> helm chart.

20. Missing link: management
- kubectl: provided by kubernetes for most os's, but cli only
- managing the components can be challenging:
- k8s through api using kubectl: learning curve, visibility challenges
- etcd: actual data has to be managed using etcdctl (eg
backups/restores)
- vendor-specific management layers on top of k8s: eg openshift
(RedHat)

21. Vendor-agnostic solution: rancher labs
- cloud providers (as vm or as paas) or on-prem deployments
- supported linux os's: centos, ubuntu, ...
- Hardened and slimmed-down os: RancherOS
-> this is what is used for a dynamic cloud provider rollout,
if you decide not to use paas.

22. Rancher – contd.
- adds authentication layer: eg openldap, AD, Azure AD, ...
- abstracts away cluster deployment, upgrades & backups
- abstracts away complexity of yaml objects,
- eg easy for creating yaml templates
- learn by doing: create a rancher workload, underlying yaml will
be generated for needed linked objects such as services, then inspect
or export the yaml for re-use

23. Rancher – cntd.
- kubernetes clusters are rolled out within containers
(but can also be imported)
- provides cli tools, a web gui and a rest API
- provides some out-of the box additional functionality such as:
- an nginx ingress daemonset.
- helm charts

24. rancher - contd.
- Can be installed as standalone docker instance or within a HA
cluster
- Access: should be deployed as part of the management plane
-> so together with API server.
- adds concept of 'projects' (as a grouping of namespaces) to
the security/deployment model.
- gui shortcuts to eg container logs, shell exec, kubectl desribe

25. Missing link – logging/monitoring
- Rancher adds some performance monitoring but it is very basic
- Cloud-native solution: prometheus
- can be rolled out on a separate machine or within one or more
clusters
- helm chart for Prometheus icw Grafana is available (but you can
also download
k8s charts and integration apps at Grafana)

26. prometheus
- built for dynamic cloud environments:
- can eg leverage kubernetes metadata to discover new pods
- can use data exported by the cloud provider to discover vm's
- can use DNS data to discover new hosts/vm's/pods
- but can also use a static configuration.

27. monitoring
- make sure to monitor both within Kubernetes and on infrastruture
level.
- logging solution: ELK, splunk, syslog, fluentd, kafka