Components

Concept	Description	Diagram
node	A machine in the cluster Can be physical or virtual
pod	Group of containers running on the same host Configured to share a network stack and other resources such as volumes
deployments	Requirements you give to Kubernetes regarding your applications (your Pods) Allows scaling, rolling updates, rollbacks Multiple deployments can be used together to implement a canary deployment Delegates pods management to replica sets A Kubernetes process (the scheduler) continually checks the state of all the Deployments
service	Abstract way to expose an app as a network service Causes a proxy to be configured to forward requests to a set of pods Services are stable network endpoint to connect to one or multiple containers Single, unchanging IP address or DNS name which will be automatically routed to any matching Pod Services allow to talk to pods from within the cluster Service DNS names always follow this pattern: `SERVICE.NAMESPACE.svc.cluster.local`
ingress	Ingress objects are rules that define the routes to our Services They expose Services to the internet

Concept	Description
namespace	Abstraction used to support multiple virtual clusters on the same physical cluster
ReplicaSet	Low-level construct Makes sure that a given number of identical pods are running (allows scaling) Rarely used directly
DaemonSet	Ensures a copy of a Pod is running across a set of nodes
StatefulSet	Provides guarantees about the ordering and uniqueness of Pods Maintains a sticky identity for each Pod (across rescheduling)
Secret	Stores sensitive information
ConfigMap	Object used to store non-confidential data in key-value pairs Can be consumed as: environment variables command line arguments config files in a volume

Concept	Description
etcd	Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data It stores the cluster state including items like service tokens, secrets and service configurations
kubelet	Primary "node agent" that runs on each node It works in terms of a PodSpec, a YAML or JSON object that describes a pod The kubelet takes a set of PodSpecs provided and ensures that the containers described in those PodSpecs are running and healthy

Name	Description
`etcd`	etcd server
`kube-apiserver`	API server
`kube-controller-manager` `kube-scheduler`	other master components
`kube-dns`	additional component (not mandatory)
`kube-proxy`	the (per-node) component managing port mappings and such
`weave`	the (per-node) component managing the network overlay