This talk discusses the core concepts behind the Kubernetes extensibility model. We are going to see how to implement new CRDs, operators and when to use them to automate the most critical aspects of your Kubernetes clusters.
4. Why are we here?
- Operations are boring
- Repeating work over and over
- Distributed Systems are hard to manage by humans
- Application Lifecycle Management as Code
14. K8s Resource Types
● API-Server is a REST Application with CRUD interface
● API-Server doesn’t know anything about infrastructure
● API-Server manages Pods/Deployments/Services like apples and pears (no special meaning)
● Object Properties:
○ Apiversion
○ Kind
○ Metadata
○ Specs
21. Controllers
- Reconciliation loops: Observe + Analyze + Act
- Converge desidered state with real state
- Attached to infrastructure events (getters & listers & informers)
- Simple Interface to implement: ADD, UPDATE, DELETE
- Cluster aware
- Actions can be internal to the cluster or external (beginning of service catalog)
23. Custom controllers examples
- Automatic notification on resources allocation, role bindings, errors
- Automatic service creation for every new deployment
- Automatic Secret distribution
- Automatic new namespace configurations (conservatives defaults)
- Automatic Custom horizontal pod scaler
- Automatic ingress controller configuration
demo
26. Operators
- Not a kubernetes Object: just a pattern
- Introduced by COREOS → 3/11/2016
- Go program running in the cluster as deployment (other language supported)
27. Operators available
- Etcd / kafka / kubedb / prometheus / influx / elasticsearch / mongodb / memcached / postgres
- Vitess / redis
- Rook
- Cert-manager
- Api gateway: kanali / kong
- All operations infrastructure facing: backup, dr, snapshots, vpn
29. Why Operators?
- How to automate application lifecycle without operators?
- Many Wheels:
- Accessibility
- Availability (HA)
- Authorization
- Events
- Reconciliation Loop ( real state → desired state )
30. Operator’s alternatives?
- YAML manifest → not templatable, very verbose
- Helm Charts → only deploy, no cluster aware
- Third party automation → reinvent wheels and polling on api-server for changes
- Operator → complex business logic to deal with, simple for multiple instances of object
demo
31. Problems
● Bring together people who knows about go, kubernetes and the specific application
● Convince people to trust automation
● Like kernel modules → very powerful, but it can crash the whole system
● Kubernetes Go SDK is a mess
32. Recap
- Manual operations are expensive, boring and error prone
- Abstracting apps livecycle management from underlying infrastructure (k8s feature)
- Non-cloud application can become simple objects
- Stateful is hard but not blocking