5 - Hands-on Kubernetes Workshop:
0 likes230 views
The document outlines a comprehensive overview of Kubernetes deployment and management, discussing historical developments from bare-metal to containerized environments. Key concepts include dynamic scaling, infrastructure as code, orchestration, application perspectives, and security measures. It also highlights tools like Rancher for managing Kubernetes clusters and the importance of monitoring solutions like Prometheus for cloud-native environments.
5 - Hands-on Kubernetes Workshop:
- 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