Evan Harmon - Memex

Kubernetes

Kubernetes is an open-source container orchestration system for automating software deployment, scaling, and management. Originally designed by Google, the project is now maintained by the Cloud Native Computing Foundation.
wikipedia:: Kubernetes
  • commonly used as a way to host a microservice-based implementation, because it and its associated ecosystem of tools provide all the capabilities needed to address key concerns of any microservice architecture.
  • Kubernetes follows the primary/replica architecture.
  • The components of Kubernetes can be divided into those that manage an individual node and those that are part of the control plane.
    Kuhernetes aka K8s
    computer and storage resources aka objects
    diagram

Cluster Objects

Control Plane

Kubernetes Master

  • Usually multiple masters. (For resilience?)
  • Less resource requirements than nodes.
Etcd
  • Key value store for cluster state.
  • Whenever something happens like a pod going down, gets recorded and kept track of in etcd.
  • The cluster brain, so to speak.
  • No application data stored. Just cluster state information for master processes to communicate with worker node processes.
  • As an example, if the deployer specified that three instances of a particular pod need to be running, this fact is stored in etcd. If it is found that only two instances are running, this delta will be detected by comparison with etcd data, and Kubernetes will use this to schedule the creation of an additional instance of that pod.
API server
  • Gateway to cluster
  • Authenticates requests to master
  • Can access via
    • JSON and REST over HTTP
    • CLI (kubectl)
    • GUI
  • Internal and external interface to Kubernetes
  • Upates objects in etcd
Scheduler
  • selects which node an unscheduled pod (the basic entity managed by the scheduler) runs on, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints
  • Eg api server might handle a request for a new pod to the scheduler and it will create it. Scheduler decides where to put it. Kubelet actually creates it.
Controller Manager
  • Detects state changes. Like crashing pods. Tries to recover the resources as best it can.
  • Helps manage Replication Controller and DaemonSetController?

Nodes

"nodes" aka "workers" aka "minions"

  • a machine where containers (workloads) are deployed.

Kubelet

  • responsible for the running state of each node, ensuring that all containers on the node are healthy. It takes care of starting, stopping, and maintaining application containers organized into pods as directed by the control plane.
  • monitors the state of a pod, and if not in the desired state, the pod re-deploys to the same node.
  • Node status is relayed every few seconds via heartbeat messages to the primary. Once the primary detects a node failure, the Replication Controller observes this state change and launches pods on other healthy nodes.

Kube-proxy

  • an implementation of a network proxy and a load balancer
  • routes traffic to the appropriate container based on IP and port number of the incoming request.

Container runtime

  • Every node in the cluster must run a container runtime such as Docker

Namespaces

  • Kubernetes provides a partitioning of the resources it manages into non-overlapping sets called namespaces.
  • e.g., for separating environments like development, test, and production.

DaemonSets

  • Normally, the locations where pods are run are determined by the algorithm implemented in the Kubernetes Scheduler. For some use cases, though, there could be a need to run a pod on every single node in the cluster. This is useful for use cases like log collection, ingress controllers, and storage services. The ability to do this kind of pod scheduling is implemented by the feature called DaemonSets.

Workload Objects

Pods

  • An abstraction over containers
  • one or more containers in a pod
  • Ephemeral
  • Usually meant to run one application container in each pod.
  • Each pod gets its own IP address.
  • Within the pod, all containers can reference each other on localhost, but a container within one pod has no way of directly addressing another container within another pod; for that, it has to use the Pod IP Address.
    • An application developer should never use the Pod IP Address though, to reference/invoke a capability in another pod, as Pod IP addresses are ephemeral - the specific pod that they are referencing may be assigned to another Pod IP address on restart. Instead, they should use a reference to a Service, which holds a reference to the target pod at the specific Pod IP Address.
  • A pod can define a volume, such as a local disk directory or a network disk, and expose it to the containers in the pod.

ReplicaSets

  • A ReplicaSet’s purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
  • Declares the number of instances of a pod that is needed.

Replication Controllers

  • A Replication Controller manages the system so the number of healthy pods matches the number specified in the ReplicaSet (determined by evaluating its selector).

Volumes

  • filesystems in a kubernetes container are ephemeral by default - will get wiped out on restart. Contra volumes which are persistent for the lifetime of the pod.
  • K8s doesn't directly manage persistence. You provide it via the volume's object/resource
  • Can be used as a shared disk space among containers in a pod.
  • Volumes are mounted at specific mount points within a container, defined by the pod configuration.
  • The volume cannot mount onto other volumes or link to other volumes.
  • The same volume can be mounted at different points in the filesystem tree by different containers.
  • Can be internal or external to the cluster.

ConfigMaps & Secrets

  • Bound to objects as confiured in deployment
  • Only sent to a node if a pod on that node requires it.
    • Kubernets will then keep it in memory on that node
    • When the pod is deleted, the in-memory copy of all bound secrets and configmaps are deleted too.
  • Available to the pod in 1 of 2 ways:
    • Environment Variables
      • which will be created by Kubernetes when the pod is started.
    • Container filesystem that is visible only from within the pod
  • Data itself stored on master which should be highly secured with limited login (or no login? only api or something?).

ConfigMaps

StatefulSets

  • Like deployments but for applications with state like databases and AWS Elasticsearch.
  • Does replication and scaling. And keeps track of the data synchronization, etc. Don't use deployments for stateful apps.
  • Much more tedious than deployments (stateless applications).
  • Why it's common to actually host the database/persistence part outside the kubernetes cluster. Like a managed RDS I think.
  • StatefulSets are controllers (under ControllerManager) that enforce the properties of uniqueness and ordering amongst instances of a pod and can be used to run stateful applications

Labels and Selectors

  • You can attach keys called labels to any API object in the system - like nodes and pods.
  • Label selectors are queries against labels that resolve to matching objects.
  • When a service is defined, one can define the label selectors that will be used by the service router/load balancer to select the pod instances that the traffic will be routed to. Thus, simply changing the labels of the pods or changing the label selectors on the service can be used to control which pods get traffic and which don't, which can be used to support various deployment patterns like blue-green deployments or A-B testing. This capability to dynamically control how services utilize implementing resources provides a loose coupling within the infrastructure.

API

Operators

Cluster API

Files

~/.kube/config

  • created when you create a cluster. How kubectl knows what cluster to connect to.

Tools

Issues

Sources

Courses

Kubernetes
Interactive graph
On this page
Kubernetes
Cluster Objects
Control Plane
Kubernetes Master
Etcd
API server
Scheduler
Controller Manager
Nodes
Kubelet
Kube-proxy
Container runtime
Namespaces
DaemonSets
Workload Objects
Pods
ReplicaSets
Replication Controllers
Kubernetes Services
Volumes
ConfigMaps & Secrets
ConfigMaps
Kubernetes Secrets
Kubernetes Deployments
StatefulSets
Labels and Selectors
API
Operators
Cluster API
kubectl
Files
Kubernetes Config Files
Tools
minikube
eksctl
Helm
Rancher
K3s
Issues
Sources
Courses