Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

5 - Hands-on Kubernetes Workshop:

48 vues

Publié le

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.

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

5 - Hands-on Kubernetes Workshop:

  1. 1. Open19 k8s workshop Part 1: Kubernetes deployment & management K8S & Rancher - concepts
  2. 2. Historically - from bare-metal installations (90's), - through virtualized deployments (2000's), - to containerized deployments (now)
  3. 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. 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. 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. 6. Bringing it together: orchestration - go beyond a simple ‘docker run’ - scheduling in function of: - load - availability - rolling updates
  7. 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. 8. K8S Roles – contd. - worker nodes: - run the actual workloads - can scale dynamically, leveraging cloud services
  9. 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. 10. K8s: application perspective - declarative syntax: YAML - unit of work: the pod - deployments, stateful sets, daemonsets
  11. 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. 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. 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. 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. 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. 16. Accessing apps… - easy & cheap: dns rr - in-app provisioned cloud lb - on-prem or separately managed lb
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. monitoring - make sure to monitor both within Kubernetes and on infrastruture level. - logging solution: ELK, splunk, syslog, fluentd, kafka

×