This is the second article in a series I plan to write about my experience learning and using Kubernetes. In the previous post I talked about why I wanted to use Kubernetes. In this post I will go over the main concepts of Kubernetes.
Summary If you don’t have time to read the entire article, here are the most important things to know.
Key Components of Kubernetes:
Node: A machine (or VPS) in your cluster Pod: One or more containers that run together ReplicaSet: Manages multiple pods and controls concurrency/redundancy Deployment: Manages deploying new versions of pod by spinning ReplicaSets up and down Service: Routes communication between pods Ingress: Routes requests from the outside world into your cluster Secret: Manages secrets that are deployed to pods Important concepts:
I’ve been using Docker for a couple of years now, but only for running local development environments. That on its own is a great way to use it. With a simple "docker run" or "docker-compose up" you can have a project running locally without installing any prerequisites on your machine. It’s amazing how quickly technology advances. A few years ago, I wouldn’t have believed that you could run a WordPress site locally without installing nginx, php and mariadb (or Xampp).
When I started playing with Kubernetes a few months ago, there was one question that didn’t seem to have a clear answer: Where do I store the images that will be running in Kubernetes?
Most of the documentation and examples are for deploying ready-made services like nginx or MariaDB. The services tend to be open source with images publicly available on Docker Hub. But sooner or later you’re going to want to build a custom image and deploy it.