I’ve covered Docker in my previous blogs so won’t go too much around Docker around the Tanzu series but here is a quick recap. Docker images are fetched from a public repo named Docker Hub. On a vSphere Tanzu environment, we deploy this image registry on-prem and this is named Harbor.
In a nutshell, a container workflow would look as below
Typical Docker Workflow
With Docker, our containers are all managed from a single host so if that host crashes we lose the containers too so think of this all your virtual machines running on a single host and no vCenter controlling it.
A docker container workflow involves processes like
- Building an image
- Sending an image to the image registry
- Download an image from the image registry
- Finally, run the image as a container.
Here are some of the docker-related commands that can come in handy.
# To search for an official image in docker hub
docker search xwiki –filter is-official=true
docker search <imagename>
docker search image –limit 5
# To download a new image:
docker pull centos:latest
# Show all documentation of images
docker image –help
# To show all image:
docker image ls
# # stop all running containers
docker stop $(docker ps -q)
# remove all containers
docker rm $(docker ps -aq)
# remove all image
docker rmi $(docker images -q)
# To assign a TAG to an image
docker tag imageid tag1:tag2
# To add another tag to an existing image with a tag
docker tag imageiD existingtag:v1 newtag:v2
# To “delete” an image: ( ie: remove image downloaded )
docker rmi image
# To remove all untagged images
docker image prune
# To remove images with no containers connected
docker image prune -a
# To remove all untagged images:
docker rmi $(docker images | grep “^<none>” | awk “{print $3}”
The 10000-foot view of Kubernetes
Components of the Kubernetes Master Machine
| Kubernetes Control Plane | etcd | •Holds the configuration information for all nodes in the cluster and it’s only accessible by the Kubernetes API server. |
| Kubernetes Control Plane | API Server | •Provides an outbound interface that provides all the operations on the cluster |
| Kubernetes Control Plane | Controller Manager | •Reports state of all activities to the API cluster regularly and its responsibility is to make changes to bring the current status of the server to the desired state configuration. •The key controllers are; the replication controller, endpoint controller, namespace controller, and service account controller. |
| Kubernetes Control Plane | Scheduler | • Resource allocation/(load redistribution) is handled in Kubernetes by the scheduler so this functions much like the DRS. |
| Docker | Each container in a pod has a docker image running on it and these form the building blocks of the containerized world. | |
| Kubernetes Node | Kubelet Service | Runs on every node and interacts with etcd to read all the configuration data to maintain the desired states on every node. |
| Kubernetes Node | Kube Proxy Service | As per its name, its responsible for ensuring services are available to external hosts so things like forwarding requests, load balancing, and pod health checks are all done by the proxy services |
Core Components of the Kubernetes Engine
| Manifest | Instruct Kubernetes to do something via some YAML declarations is known as a Manifest file |
| Pods | Small Groups of containers and volumes |
| Docker | Each container in a pod has a docker image running on it and these form t |
| Replica Sets | This declares attributes such as how many pods to deploy for application redundancy eg: Desired State = 2 and Current State=1 |
| Network Policy | This is responsible for controlling firewall rules in Kubernetes ( ie: Egres / Ingres ) |
| NameSpaces | Just think of this as Resource Pool – Shares, Reservations, and Limits on a vCenter |
Typical Kubernetes Workflow
With Kubernetes, several containers can be managed from a single pane so this is much similar to how ESXi hosts are handled by our vCenter which handles host failures, etc so if a host managed by Kubernetes crashes, Kubernetes solves the issue by just restarting all these containers on the next available host(POD) much like our HA/DRS on vCenter to keep the explanation very simple to understand.
A Kubernetes workflow involves processes like
- Building an image
- Sending an image to the image registry
- Tell Kubernetes to run the image into a pod
- Assign pod to a node
- Kubelet accepts the pod
- Docker starts the container in the pod.
The developer will be responsible for managing the image whilst the vSphere admins will be controlling the Kubernetes control plane and Kubernetes node.
