Kubernetes - Mehr als eine Spielwiese für DevOps Nerds

Nachdem Docker die Container-Welt revolutioniert hatte, wurde in den letzten Jahren ein bunter Strauß verschiedener Container-Orchestrierungs Tools veröffentlicht. Diese helfen, Deployments auf mehreren Hosts effizient zu verwalten.

Spätestens durch die Integration von Kubernetes bei allen namhaften Cloud-Anbietern ist nun klar, dass Kubernetes nicht “just another” Framework ist, sondern das Rennen mit Abstand anführt.

Nach dem Aufsetzen einer Testumgebung werden wir uns mit dem Hosten von eigenen Anwendungen und Themen wie High Availability, Load Balancern, Logging und Monitoring beschäftigen.

Ihr erfahrt im Talk, aus welchen Modulen sich ein Kubernetes Deployment zusammensetzt und lernt die Vor- und Nachteile von Kubernetes gegenüber anderen Plattformen kennen.

Transcript

1. Jannis Schaefer | cosee jannis.schaefer@cosee.biz | @jannisschaefer Kubernetes
2. Frontend Mobile Backend DevOps Agile Coach Team based approach Dauerwerbetechtalk
3. – kubernetes.io/docs/concepts/overview/what-is-kubernetes/ Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.
4. Kubernetes • κυβερνήτης - Steuermann • Docker das „skaliert“
5. • Open Source Software Foundation • Zertifiziert Kubernetes Projekte
7. Master/Node Architektur Khtan66 (Own work) [CC BY-SA 4.0] (via Wikimedia Commons)
8. Interface Architektur Ziel: Möglichst Cloud/Host unabhängige Anwendungen Bedarfsgerechte Konfiguration des „Backends“ • CSI - Container Storage Interface (beta) • CNI - Container Network Interface • CRI - Container Runtime Interface • Logging
9. kubectl Demo
10. yaml all the things! • Reproduzierbare Deployments • kubectl apply -f file.yaml erstellt/updated Resourcen
11. • „Kleinste Deploybare Einheit“ • Ein oder mehrere (unterschiedliche!) Container • Pods werden vom Scheduler auf Nodes verteilt • Normal wird nie direkt Pod erstellt Pod apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp spec: containers: - name: myapp-container image: busybox command: ['sh', '-c', 'echo Hello Kubernetes! "&& sleep 3600']
12. • Verwaltet mehrere gleiche Pods in Cluster • Werden oft von Deployments verwaltet Replica Set
13. • Verwaltet Replica Sets • Rolling Updates und Rollback Deployment apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
14. Markiert einen Port eines Deployments als erreichbar ClusterIP
 virtueller LoadBalancer innerhalb des Clusters NodePort
 Gibt Port auf jeder Node frei und proxied zu dem Service LoadBalancer
 Erstellt externen Load Balancer (AWS ELB etc.) Service kind: Service apiVersion: v1 metadata: name: nginx-http spec: selector: app: nginx-app ports: - name: http protocol: TCP port: 80 targetPort: 80
15. Ingress apiVersion: extensions/v1beta1 kind: Ingress metadata: name: main-ingress annotations: nginx.ingress.kubernetes.io /rewrite-target: / spec: rules: - host: app.example.com http: paths: - path: / backend: serviceName: nginx-app servicePort: 80 - path: /api backend: serviceName: backend servicePort: 8080 • Markiert Port als HTTP-Service • Keine eigene Logik • Ingress Controller suchen über API nach Ingress Objekten
16. • Nginx oder Traefik mit externem LoadBalancer • Beta: AWS Application Load Balancer Ingress Controller
17. • Pods können Files aus ConfigMap mounten • Oder ConfigMap als Umgebungsvariable • Docker Images Konfigurationsunabhängig Config Map apiVersion: v1 kind: ConfigMap metadata: name: env-config namespace: default data: log_level: INFO ""--- apiVersion: v1 kind: Pod metadata: name: pod-with-config spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh", "-c", "env" ] env: - name: LOG_LEVEL valueFrom: configMapKeyRef: name: env-config key: log_level restartPolicy: Never
18. Demo
19. Plenty YAMLs to manage? • Mehrere YAMLs + Go Templating = helm chart • Charts können mit Parametern aus Repositories
 installiert werden • Installation, Rollback etc. über Helm CLI
20. How to try k8sing? • Docker for Mac & Windows mit eingebautem Kubernetes • Minikube erstellt Single Node Cluster in VirtualBox • play-with-k8s
21. What about my own k8s cluster? • Viel große Clouds bieten managed Kubernetes • Einfache Updates • etcd Backups • LoadBalancer Unterstützung • Self-Hosted (-Managed)
22. Road to production
23. Pod Ressourcen • Wieviel CPU & RAM benötigt mein Pod mindestens und maximal? • Pods werden anhand requests und limits gescheduled • Unterschiedliche QoS Klassen (Best-Effort, Guaranteed, Burstable) https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md
24. Roll Based Access Control (RBAC) • Kubernetes-API Berechtigungen für Pods • Role: Per Namespace • ClusterRole: Cluster wide • Per (Cluster-)RoleBinding werden Pods und Rollen verbunden
25. Pod Security Policies (PSP) • Software Berechtigungen des Containers Beispiele: • Root Filesystem Read-only? • Als welcher User darf der Container Prozesse ausführen? Sobald eine PSP deployed wurde benötigen alle Container eine!
26. Monitoring & Logging • Viele verschieden OpenSource Tools und PaaS Angebote • Aktuell oft noch „Spielwiese“ • Sinnvolles Logging und Monitoring kostet Zeit
27. Autoscaling • Horizontal Pod Autoscaler • Skaliert Replica Sets, Deployments und Replication Controller • Unterstützt CPU Last und eigene (externe) Metriken
28. Healthchecks • Microservices stellen oft /healthz Endpoint bereit • HTTP oder TCP Test möglich Liveness Probe
 Ist meine Anwendung abgestürzt?
 Readiness Probe
 Pod ist verfügbar, kann aber aktuell kein Traffic handeln

29. k8s on AWS • kops = CLI Tool für k8s Deployment • AWS EKS in Private Beta Phase • Native Loadbalancer Unterstützung (ELB/NLB) • EBS als persistenter Storage • Viele weitere Open Source Tools (kube2iam, cluster-autoscaler, ALB ingress)
30. kube2iam • YAML Definiert IAM Role der Pods • Jeder Pod darf nur auf bestimmte AWS Services zugreifen
31. Tipps • Nodes mit ähnlicher CPU Leistung wählen • Keine Instanzen mit CPU-Credits (AWS: T-Instanzen) • Achtung vor fertigen YAMLs und Helm-Charts
32. Nächster Talk … Wie verarbeitet unser Gehirn Informationen? Eine Einführung in cognitive modeling mit Python <Nicolina Wenzler/> 24.05.2018 > blog.cosee.biz > talks.cosee.biz