Kubernetes Learning Note (iii)
In the last blogs, we created three yml files for Pod, Service, and Deployment. In this post, we are learning how to deploy them using kubectl commands.
//feed a config file to Kubectl
kubectl apply -f <filename> $ kubectl apply -f client.yml//print the status of running services: Namespace/Pod/Node/Deployment/Service/ReplicaSets$ kubectl get pods
NAME READY STATUS RESTARTS AGE
pod/client-deployment-5f9dfd6f5-hncd6 0/1 Terminating 0 22d$ kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
client-deployment 1/1 1 1 71s$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
client-deployment-894fb7774-ggbkj 1/1 Running 0 3m19s 172.17.0.2 minikube <none> <none>//get detailed info about an object
kubectl describe <object type> <object name>$kubectl describe pod client-deployment-5f9dfd6f5-hncd6
Name: client-pod
Namespace: default
Priority: 0
Node: minikube/192.168.64.2
Start Time: Wed, 15 Apr 2020 20:19:43 +0100
Labels: component=web
Annotations: Status: Running
IP: 172.17.0.2
...
Events:
Type Reason Age From Message (life cycle changes)
— — — — — — — — — — — — -
Normal SandboxChanged 50m kubelet, minikube Pod sandbox changed, it will be killed and re-created.
Normal Pulling 50m kubelet, minikube Pulling image “elfiy/multi-client”
Normal Pulled 50m kubelet, minikube Successfully pulled image “elfiy/multi-client”
Normal Killing 26s kubelet, minikube Container client definition changed, will be restarted
Normal Pulling 26s kubelet, minikube Pulling image “elfiy/multi-worker”
Normal Created <invalid> (x2 over 50m) kubelet, minikube Created container client
Normal Started <invalid> (x2 over 50m) kubelet, minikube Started container client//remove an object
kubectl delete -f <config file>//update image
kubectl set image <object_type> / <object_name> <container_name>//imperative create objects
service/cronjob/deployment/job/namespace
example:create a secret$ kubectl create secret generic <secret_name> --from-literal key=value
On the updating image, how it works is that every time the master will inspect the name and kind, if it’s the same, master will not try to create new object, but to update the old one.
Also, for yml files, Pod you can only update image, but not other properties like containers, name, and port. For Deployment you have the freedom to change all the properties though, through the Pod Template.
Whole Deployment flow
1. Issue command to master e.g. 4 * multi-worker
2. Master check current status (0 running)
3. Master assign tasks to 3 nodes it has
4. Each node reach to Docker hub and fetch image
5. Each node create container out of the image (the last creates 2)
6. Master recheck, and update its status (4 running)
7. If any container down, the Master will restart 1 again (reason why if we docker kill 1, it will back to life soon)🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🛥 🚤 ⛴ 🛳 ⛵ ⚓️ 🌊🚤
