Prefetch Technologies // Keeping your cache lines cozy

Notes from episode 1 of TGIK: A Quick Tour

Over the past few months I've been trying to learn everything there is to know about Kubernetes. Kubernetes is an amazing technology for deploying and scaling containers though it comes with a cost. It's an incredibly complex piece of software and there are a ton of bells and whistles to become familiar with. One way that I've found for coming up to speed is Joe Beda's weekly TGIK live broadcast. This occurs each Friday at 4PM EST and is CHOCK full of fantastic information. In episode one Joe goes into the basics of Kubernetes. You can watch it here:

Watch on YouTube

Here are some of my takeways from the episode:

  • Heptio put together the building Kubernetes clusters quickstart on AWS. There is no such thing as a "master". There is a control plane that consists of the API server, controller and scheduler. Kubernetes clusters can scale to 5000 nodes but etcd is typically the bottleneck. Pods consist of one or more containers. Typically a pod will consist of one container but can have several (which is a common approach for logging, debugging and service meshes). The dry-run and -o options can be used to view the YAML sent from kubectl to the API server:
    kubectl run ... --dry-run -o yaml
  • You can use port forwarding to reach an application running in a pod negating the need to open up firewall rules (the example below forward TCP port 8080 locally to port 8080 in the pod):
    kubectl port-forward webserver 8080:8080
  • Pods live on a specific node for their lifetime. This was a conscious design decision to address situations where a machine rebooted or a network split causing the node to appear in two places. Kubernetes was designed to work with arrays and sets of resources vs. singletons. Deployments are built on top of replica sets. Replica sets ensure that a specified number of pods are running at any given point in time. Templates define the layout for each pod in a replica set. Each pod gets a unique name. Here is the format: deploymentname-hashoftemplate-uniquevalueforeachpod
  • Deployments can be scaled up with the scale option:
    kubectl scale deployment kuard --replicas=10
  • Scale causes the current deployment to be downloaded, edited and sent back to the API server. * You can bring up the current deployment resource with the kubectl edit command. Once you are done editing the the changes will be pushed to the API server:
    kubectl edit deployment kuard
  • The set image option can be used to change the image the pods are running in a staged fashion:
    kubectl set image deployment ...
  • The rollout undo option can be used to rollback a deployment
    kubectl rollout undo deployment kuard
  • The kubefed utility is a tool for dealing with federation * Custom Resource Definitions (CRDS) allow users to create new types of resources without adding a new API server.
  • Daemonsets allow you to run a set of containers on each machine in a cluster (e.g., flanneld, log aggregator or performance collector). * The node authorizer limits nodes access to the minimum set of resources they need.

Things I need to learn more about:

  • How services and pods interact with iptables What is the correct way to deploy and roll out changes to a cluster Which LoadBalancers are supporter outside of GCE, AWS, etc. * How do LoadBalancers actually work