Making Resilient, Self-Adaptive, And Autonomous Kubernetes Clusters
summary
Argues for instrumenting services and automating responses: applications emit metrics to Prometheus + Alertmanager, logs go to stdout and a central store (Elasticsearch/CloudWatch), and horizontal scaling uses HPA v2 with custom metrics (example rule: scale when response time >50ms, min 3 max 10). Shows node autoscaling triggered by pending pods (cluster grows from 3 to 5), claims automated handlers resolve ~97% of incidents so humans only get notified for escalations, and stresses granular in‑app metrics over CPU/memory.
AI-written summary · about
chapters (17)
- 0:00Introduction
- 2:20How we approach application development
- 3:05When to scale
- 3:29Dashboards
- 4:50Scaling
- 6:32Memory CPU
- 7:04Overprovisioning
- 9:39Server Scaling
- 10:11SelfAdaptive Scaling
- 12:13SelfAdaptive Monitoring
- 13:21Prometheus
- 14:42Alert Manager
- 22:50Instrumentation
- 25:48Spam
- 26:49Logs
- 29:13Horizontal Pod Autoscale
- 31:27Notifications
related talks
14mA Tale of Autoscale: Increasing Resiliency while Reducing On-Call Toil
29mKubernetes Autoscaling: Beyond One Size Fits All
30mHorizontal Pod Autoscaler Reloaded - Scale on Custom Metrics
07mScaling Predictive Manufacturing Analytics: Kubernetes-Powered CRM
19mKeynote: Monitoring Kubernetes Clusters with Prometheus
46mAdvanced Kubernetes: Lesson Learned From Building..
08mGetting Creative with HPA Scaling in Kubernetes
32mTesting Kubernetes apps' observability end-to-end