0.1. Download and install Docker desktop.
0.2. Download and install minikube.
windows / Linux / docker
Reference : https://kubernetes.io/docs/tutorials/kubernetes-basics/
Kubernetes Basics Modules
Pods that are running inside Kubernetes are running on a private, isolated network. By default they are visible from other pods and services within the same kubernetes cluster, but not outside that network.
A Pod is a Kubernetes abstraction that represents a group of one or more application containers (such as Docker), and some shared resources for those containers. Those resources include:
- Shared storage, as Volumes
- Networking, as a unique cluster IP address
- Information about how to run each container, such as the container image version or specific ports to use
A Pod models an application-specific "logical host" and can contain different application containers which are relatively tightly coupled.
A Pod always runs on a Node. A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. Each Node is managed by the control plane. A Node can have multiple pods, and the Kubernetes control plane automatically handles scheduling the pods across the Nodes in the cluster. The control plane's automatic scheduling takes into account the available resources on each Node.
A Node can have multiple pods, and the Kubernetes control plane automatically handles scheduling the pods across the Nodes in the cluster.
Services and Labels
A Service routes traffic across a set of Pods. Services are the abstraction that allows pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) are handled by Kubernetes Services.
Services match a set of Pods using labels and selectors, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:
- Designate objects for development, test, and production
- Embed version tags
- Classify an object using tags
Services can be exposed in different ways by specifying a type in the spec of the Service:
- ClusterIP (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.
- NodePort - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using
<NodeIP>:<NodePort>. Superset of ClusterIP. - LoadBalancer - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.
- ExternalName - Maps the Service to the contents of the
externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of kube-dns, or CoreDNS version 0.0.8 or higher.
Create a new Service
> kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
> kubectl get services
> kubectl describe services/kubernetes-bootcamp
#query our list of Pods. We’ll use the kubectl get pods command with -l as a parameter
> kubectl get pods -l app=kubernetes-bootcamp
NAME READY STATUS RESTARTS AGE
kubernetes-bootcamp-5485cc6795-fj5v9 1/1 Running 0 5h7m
kubernetes-bootcamp-5485cc6795-qf8l8 1/1 Running 0 5h8m
#do the same to list the existing Services:
> kubectl get services -l app=kubernetes-bootcamp
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes-bootcamp LoadBalancer 10.111.187.193 <pending> 8080:30790/TCP 4h2m
# apply a new label we use the label subcommand followed by the object type
kubectl label pods "$POD_NAME" version=v1
#query now the list of pods using the new label:
kubectl describe pods "$POD_NAME"
kubectl get pods -l version=v1
Deleting a service
kubectl delete service -l app=kubernetes-bootcamp
Previously we created a Deployment, and then exposed it publicly via a Service. The Deployment created only one Pod for running our application. When traffic increases, we will need to scale the application to keep up with user demand.
Scaling an application
Scaling out a Deployment will ensure new Pods are created and scheduled to Nodes with available resources.
Scaling will increase the number of Pods to the new desired state.
To see the ReplicaSet created by the Deployment, run kubectl get rs
scale the Deployment to 4 replicas. We’ll use the kubectl scale command
kubectl scale deployments/kubernetes-bootcamp --replicas=4
To list your Deployments once again, use get deployments:
kubectl get deployments
The change was applied, and we have 4 instances of the application available. Next, let’s check if the number of Pods changed:
kubectl get pods -o wide
There are 4 Pods now, with different IP addresses. The change was registered in the Deployment events log. To check that, use the describe subcommand:
kubectl describe deployments/kubernetes-bootcamp
You can also view in the output of this command that there are 4 replicas now.
Scale Down
To scale down the Deployment to 2 replicas, run again the scale subcommand:
kubectl scale deployments/kubernetes-bootcamp --replicas=2
kubectl get deployments
kubectl get pods -o wide
Performing a Rolling Update
for
Updating an application
To update the image of the application to version 2, use the set image subcommand, followed by the deployment name and the new image version:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
#deployment.apps/kubernetes-bootcamp image updated
The command notified the Deployment to use a different image for your app and initiated a rolling update.
Verify an update
check that the app is running
kubectl describe services/kubernetes-bootcamp
#confirm the update by running the rollout status subcommand:
kubectl rollout status deployments/kubernetes-bootcamp
Let’s perform another update, and try to deploy an image tagged with v10:
kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10
Use get deployments to see the status of the deployment:
kubectl get deployments
Notice that the output doesn't list the desired number of available Pods. Run the get pods subcommand to list all Pods:
kubectl get pods
Notice that some of the Pods have a status of ImagePullBackOff.
To get more insight into the problem, run the describe pods subcommand:
kubectl describe pods
In the Events section of the output for the affected Pods, notice that the v10 image version did not exist in the repository.
To roll back the deployment to your last working version, use the rollout undo subcommand:
kubectl rollout undo deployments/kubernetes-bootcamp
#deployment.apps/kubernetes-bootcamp rolled back
Use the get pods subcommand to list the Pods again:
kubectl get pods
Four Pods are running. To check the image deployed on these Pods, use the describe pods subcommand:
kubectl describe pods
#clean up local cluster
kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp
Troubleshooting with kubectl
- kubectl get - list resources
kubectl get pods # like docker ps - kubectl describe - show detailed information about a resource
kubectl describe pods # like docker inspect -it $container_name - kubectl logs - print the logs from a container in a pod
kubectl logs "$POD_NAME" # like docker logs -it $container_name - kubectl exec - execute a command on a container in a pod
kubectl exec -it $POD_NAME -- bash # like docker exec -it $container_name
