Kubernetes began as Google's internal container orchestration system called Borg and was open sourced as Kubernetes in 2014. It uses a declarative model where users describe their application components and infrastructure as code to manage the desired state. Key principles include being extensible through custom resources and controllers, meeting users where they are through integration with applications, and decoupling applications from infrastructure. Common extension points allow customizing authorization, scheduling, resources, and controllers. Operators help manage custom applications and Prometheus is a widely used monitoring operator. Best practices for day 2 operations focus on cluster design, application patterns, and security. A rich ecosystem of tools has grown around Kubernetes.
3. April 2008
Google Cloud is
launched
LxC launched,
complete Linux
container manager
merged into the Linux
Kernel
Work begins to open
source Google’s Borg
as Kubernetes
2013
Docker
launched
The term “Cloud Computing”
enters the common vernacular.
Birth of Borg
3-4 Google Engineers
working to automate
cluster management
inside Google. Cloud Run
Anthos
gVisor
Process Containers
initiative to bring
containers to the
Linux kernel
Nov 2014
GKE Alpha
Istio
announced
Aug 2015
GKE GA
Envoy 1.0
GKE on Prem
Announced
July 2015
Kubernetes
1.0
Knative
announced
Istio 1.0
2003 2006 2008 2013 2015 20192018
Scheduling ~4 BILLION
containers per week in 2020
across the entire Google
environment.
June 2014
First Github
commit for
Kubernetes
Kubernetes evolution in Google
Innovation Timeline
5. What makes Kubernetes unique
● Declarative rather than imperative
● Extensible - custom resource, controllers, schedulers
● No hidden internal APIs - External and internal apis are same
● Meet the user where they are - (eg) read config, secrets from applications
● Decouple distributed system application development
● Open source ecosystem friendly
9. Extensions - Kubernetes Operator
Kubernetes operator
(eg: prometheus, etcd,
Spark, Airflow)
API server
Custom resources
Desired
State
Current
State
Operators manage the lifecycle of the custom application
11. Meet user where they are - Consume secrets in App
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
apiVersion: v1
kind: Pod
metadata:
name: secret-env-pod
spec:
containers:
- name: mycontainer
image: redis
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: SECRET_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
restartPolicy: Never
Use Mount paths Use environment variables
Applications can consume config/secrets without knowledge of Kubernetes
12. Decouple distributed system - Storage provisioning
https://itnext.io/tutorial-basics-of-kubernetes-volumes-part-2-b2ea6f397402
Kubernetes provides portability
by decoupling
infrastructure(Storage,
networking) from the application
manifest
13. Pod patterns - Init containers
Init container
(Clone git repo and
generate config)
App container
(Web server)
Pod
Execution sequence
Specialized containers that runs to completion before application containers in a pod can
get started. This enforces sequence.
14. Pod patterns - Sidecar
Sidecar containers extend and enhance the “main” container
Other examples:
Istio envoy proxy
Monitoring
Database config
15. Pod patterns - Adapter
Adapter containers standardize and normalize output so that external services can access
interface in a standard way(eg: Prometheus adapter)
16. Pod patterns - Ambassador
Ambassador containers proxies a local connection to the world and hides the complexity to
access external service.
Examples:
Accessing different kinds of
cache based on environment
Client side service discovery
using different mechanisms
17. Map Twelve factor applications to Kubernetes
Single app defined using Dockerfile and
multiple apps done using deployment
Config map and secrets
Service abstraction
and discovery
Stateless containers, stateful
dataset where needed
Services provides
different options for
port bindings
Autoscaler support
is comprehensive
Centralized log management with
third party integrations possible
Autohealing
Many ways to create and
manage clusters(cloud
provider, kops, kubeadm)
18. Kubernetes Day 2 operations - Best practises
● Cluster infrastructure
○ Multi-tenant design(clusters/namespaces, multi-cluster handling, zonal/regional), Upgrade policy(node and
containers, pod disruption budget), Ingress(load balancers), External service access policy(db, cache etc)
● Application design
○ Pod design(using pod design patterns), Lifecycle(health check, graceful termination), Scaling(resource
request, autoscaling), Application types(stateful/stateless/batch), service mesh
● Security
○ Access control(rbac), Image validation(binary authorization, vulnerability scanning), Secure clusters(private
cluster, firewall)