Skip to content

Instantly share code, notes, and snippets.

@jonbrouse

jonbrouse/kube-notes.md

Created November 7, 2017 15:13
Show Gist options
  • Save jonbrouse/bf480a5b6499adf6b3811a3d513c75db to your computer and use it in GitHub Desktop.
Save jonbrouse/bf480a5b6499adf6b3811a3d513c75db to your computer and use it in GitHub Desktop.
Download ZIP
Notes from kube research.
Raw
kube-notes.md

Kubernetes

Greek for "Helmsman"; also the root of the words "governor" and "cubernetic"

Table of Contents

Links

Requirements

Mac

curl -O https://storage.googleapis.com/kubernetes-release/release/v1.6.4/bin/darwin/amd64/kubectl
chmod +x kubectl 
sudo mv kubectl /usr/local/bin/

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.20.0/minikube-darwin-amd64 
chmod +x minikube 
sudo mv minikube /usr/local/bin/

Linux

curl -O https://storage.googleapis.com/kubernetes-release/release/v1.6.4/bin/linux/amd64/kubectl
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.20.0/minikube-linux-amd64
chmod +x minikube
sudo mv minikube /usr/local/bin/

Best Practicies

  • Deployments
    • User the "record" option for easier rollbacks
      • kubectl apply -f deployment.yaml --record
    • Use plenty of descriptive labels
      • App: nifty
      • Phase: Dev
      • Role: BE
    • Use sidecar containers for proxies, watchers, etc
      • Don't use sidecars for bootstrapping!
      • Use init containers instead!
    • Don't use :latest or no tag
    • Readiness Probe - is the app ready to start service traffic?
      • Won't be added to a service endpoint until it passes
      • Required for a "production app"
    • Liveness Probe - is the app still running?
      • Default is "process is running"
      • Possible that the process can be running but not working correctly
      • Good to define, might not be 100% necessary
  • Services
    • Don't always use type: LoadBalancer
      • Ingress
    • type: NodePort cant be "good enough"
    • Use Static IPs. Theuy are free!
    • Map external services to internal ones
  • Application Architecture
    • Use Helm Charts
    • ALL downstream dependencies are unreliable
    • Make sure your microservices aren't too micro
    • Use a "Service Mesh"
    • PaaS
  • Cluster Management
    • Resources, Anti-Affinity, and Scheduling
    • Use Namespaces to split up your cluster
    • Role Based Access Control
    • Chaos Monkey

Kubernetes Basics

  • Kubernetes coordinates a highly available cluster of computers that are connected to work as a single unit.
    • Kubernetes automates the distribution and scheduling of application containers across a cluster in a more efficient way.
  • Cluster Components
    • Master
      • Manages and coordinates the cluster (scheduling applications, maintaining applications desired state, scaling applications, and rolling out new updates).
    • Nodes
      • Workers that run applications.
      • Runs a kubelet agent that communicates with the master via the Kubernetes API.
      • Pods run on nodes, containers run in pods.
  • Deployment: Responsible for creating and updating instances of your application. Lives on your master node.
  • Deployment Controller: continuously monitors the deployed instances.
  • Scaling is accomplished by changing the number of replicas in a Deployment.

Architecture

Users -> Control Plane -> Nodes

  1. Post desired state (aka spec) via API
  2. Placement (aka scheduling) figures out on which node to run the task.
  3. Assignment (aka binding) is when the control plane tells the node to run the task.
  4. Kubelete fetches container image
  5. Kubelete sends status of container to control plane
  6. User can qwuery if their task is running

Pods

  • Pods are a building block of the infrastructure.
  • In essense this is a group of containers (associated volumes, networking, image version, ports, etc) sharing the same networking and host linux namespaces.
    • We create pods and in turn they create containers
  • Tightly coupled
    • the atom of replicaton and placement
  • "logical" host for contaienrs
    • each pod gets an IP address
    • share data: localhost, volumes, IPC, etc.
  • Facilitates composite applications (side cars)
    • preserves 1:1 app to image

Volumes

  • Storage automatically attached to pod.
    • Local scratch directories created on demand
    • Cloud block storage
      • GCE Persistent Disk
      • AWS Elastic Block Storage
    • Cluster storage
      • File: NFS, Gluster, Ceph
      • Block: iSCSI, Cinder, Ceph
    • Special Voumes
      • Git repository
      • Secret
  • Critical building block for higer-level automation

Secrets

  • Inject them as "virtual volumes" into Pods
    • not baked into images nor pod configs
    • kept in memory - never touches disk
    • not coupled to non-portable metadata API
  • Manage secrest via the Kubernetes API

ReplicationControllers

  • Ensures N copies of a Pod
    • grouped by a label selector
  • Explicit specification of desired scale
    • enables self-healing
    • facilitates auto-scaling

Services

  • A group of pods that work together
  • Publishes how to access the service
    • DNS Name
    • DNS SRV records for ports
    • Kubernetes Endpoints API
  • Define access policy
    • Load-balanced: name maps to stable virtual IP
    • "Headless": name maps to set of pod IPs
  • Hides complextiy - ideal for non-native apps
  • Decoupled from Pods and ReplicationControllers
  • Defined using YAML.

Types of Services

  • ClusterIP (default): Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.
  • NodePort: Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using :. Superset of ClusterIP.
  • LoadBalancer: Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.
  • ExternalName: Exposes the Service using an arbitrary name (specified by externalName in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of kube-dns.

Jobs

  • Manages pods that run to completion
    • differentiates number running at any one time from the total number of completed runs
  • Similar to ReplicationController, but for pods that don't always restart
    • workflow: restart on failure
    • build/test: don't restart on app failure
  • Principle: do one thing, don't overload

DaemonSets

  • Runs a Pod on every node
    • or a selected subset of nodes
  • Not a fixed umber of replicas
    • created and deleted as nodes come and go
  • Useful for running cluster-wide services
    • logging agents
    • storage systems
  • DaemonSet manager is both a controller and scheduler

Deployment

  • Rollouts as a service
    • updates to pod template will be rolled out by controller
    • can chose between rolling update and recreate
  • Enables declarative updates
    • manipulates replication controllers
  • Promote an application from one environment to another (via container image updates)

PaaS Like Systems Build on Kubernetes

  • Apache Stratos
  • Openshift 3
  • Deis
  • Gondor

Design Principle Summary

  • Declarative > Imperative: State your desired results, let the system actuate
  • Control loops: Observe, rectify, repeat
  • Simple > Complex: Try to do as little as possible
  • Modularity: Components, interfaces, & plugins
  • Legacy compatible: Requiring apps to change is a non-starter
  • Network-centric: IP address are cheap
  • No grouping: Labels are the only groups
  • Cattle > Pets: Manage your workload in bulk
  • Open > Close: Open Source, standards, REST, JSON, etc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment