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:
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