• List all nodes:

  • kubectl get no

• List all pods in the kube-system namespace:

  • kubectl -n kube-system get pods

• Apply a YAML configuration file (No Last-Applied Configuration**)**

  • kubectl create -f ****.yaml

• Apply a YAML configuration file: (with Last-Applied Configuration )

  • kubectl apply -f ****.yaml

• List all pods in the kube-system namespace:

  • kubectl -n kube-system get pods

• List pods with all infomation:

  • kubectl get pod -o wide

• List nodes with all infomation:

  • kubectl get pod -o wide

• describe a specific node:

  • kubectl describe node node-1

• show logs:

  • kubectl logs nginx

• show live object configuration form etcd:

  • kubectl get pod nginx -o yaml

• show labels:

  • kubectl get po --show-lables

• to show pod with specific label:

  • kubectl get po -l "client=abc"

• to show pod with specific label with AND condition:

  • kubectl get po -l "client=abc,env=dev"

• Quality of Service (QoS) classes manage the resource allocation for pods to ensure they get the CPU and memory they need. There are three QoS classes:

  1. Best Effort:

     • Pods in this class have no guaranteed or limited resource requests.

     • They are the first to be terminated if the node runs out of resources.

     • Example YAML:

         apiVersion: v1
         kind: Pod
         metadata:
           name: best-effort-pod
         spec:
           containers:
           - name: best-effort-container
             image: nginx
       

  2. Burstable:

     • Pods have some guaranteed resources (requests) but can use more (limits) if available.

     • They are prioritized over Best Effort pods but can be throttled or evicted when resources are scarce.

     • Example YAML:

         apiVersion: v1
         kind: Pod
         metadata:
           name: burstable-pod
         spec:
           containers:
           - name: burstable-container
             image: nginx
             resources:
               requests:
                 memory: "64Mi"
                 cpu: "250m"
               limits:
                 memory: "128Mi"
                 cpu: "500m"
       

  3. Guaranteed:

     • Pods have equal requests and limits for all containers.

     • They receive the highest priority and are the last to be evicted when resources are constrained.

     • Example YAML:

         apiVersion: v1
         kind: Pod
         metadata:
           name: guaranteed-pod
         spec:
           containers:
           - name: guaranteed-container
             image: nginx
             resources:
               requests:
                 memory: "128Mi"
                 cpu: "500m"
               limits:
                 memory: "128Mi"
                 cpu: "500m"
       

     • Out of Memory (OOM)

       • OOM Killer: If a container exceeds its memory limit, the OOM killer terminates it. Kubernetes restarts the container based on its restart policy.

       • Eviction: For BestEffort pods, Kubernetes may evict the entire pod. For Burstable or Guaranteed pods, Kubernetes evicts the least critical pods first, based on their QoS class and priority.

CPU Constraints

• CPU Throttling: If a container exceeds its CPU limit, Kubernetes throttles its CPU usage, slowing down its processing.

• No OOM Killer: Unlike memory, CPU constraints do not terminate the container; it is simply limited to its specified CPU limit.

Request and Limit Management

• Requests: Kubernetes scheduler uses pod resource requests (e.g., CPU, memory) to find a suitable node with available resources to place the pod.

• Limits: Kubernetes kubelet enforces pod resource limits, ensuring that containers do not exceed allocated resources, preventing resource contention and ensuring stability.

• Top comamdn to k8s (you neeed a matrix server can download the yaml from fork repo):

  • kubectl top pods

  • kubectl top no

• Kubernetes deployment strategies

  • Recreate:

    • This strategy stops the old version of the application and then starts the new version. It involves downtime since the old version is terminated before the new version is up and running.

  • Rolling Update:

    • This strategy updates the application incrementally, one pod at a time. It ensures minimal downtime by gradually replacing old pods with new ones. It allows for a smooth transition and rollback if issues arise.

  • Blue/Green Deployment:

    • In this strategy, two environments (blue and green) are used. The blue environment runs the current version while the green environment is set up with the new version. Once the new version is tested and verified in the green environment, traffic is switched from blue to green, ensuring zero downtime.

  • A/B Testing:

    • This strategy directs a subset of users to a new version (B) while the rest continue using the old version (A). It is used to compare the performance and user response of two different versions, helping in data-driven decision-making.

  • Canary Deployment:

    • This strategy deploys the new version to a small subset of users first (canary group) while the majority continue using the old version. If the new version performs well, it is gradually rolled out to more users. It helps in minimizing the impact of potential issues with the new version.

• Command: kubectl rollout history deploy hello-deploy

  • Syntax: kubectl rollout history deploy <deployment-name>

  • Definition: Displays the rollout history of the specified deployment, showing previous revisions and their details.

• Command: kubectl annotate deployment.apps/hello-deploy kubernetes.io/change-cause="initial version"

  • Syntax: kubectl annotate deployment.apps/<deployment-name> <annotation-key>=<annotation-value>

  • Definition: Adds or updates an annotation to the specified deployment, providing a description of the changes or the purpose of the deployment.

• Command: kubectl apply -f deploy-with-strategy --record=true

  • Syntax: kubectl apply -f <file-name> --record=true

  • Definition: Applies the specified configuration file and records the change in the resource's annotations, enabling tracking of the changes made.

• When we change the version in a rolling update deployment, it creates a new ReplicaSet (RS):

  • Definition: Updating the version in a rolling update deployment triggers the creation of a new ReplicaSet to manage the updated version of the application while gradually replacing the old version.

• Command: kubectl rollout undo deployment/hello-deploy

  • Syntax: kubectl rollout undo deployment/<deployment-name>

  • Definition: Reverts the deployment to its previous revision, effectively undoing the most recent changes made to the deployment.

• Command: kubectl rollout undo deployment/hello-deploy --to-revision=2

  • Syntax: kubectl rollout undo deployment/<deployment-name> --to-revision=<revision-number>

  • Definition: Reverts the deployment to a specific revision, specified by the revision number, allowing you to roll back to a particular state.

• revisionHistoryLimit: 6:

  • Definition: Configures the maximum number of old ReplicaSets to retain for a deployment, keeping up to 6 historical revisions for rollbacks.

• Adding annotations in the YAML:

    yamlCopy codemetadata:
      name: hello-deploy
      annotations:
        kubernetes.io/change-cause: "I added nginx images"
  

  • Definition: Includes annotations in the deployment's YAML file to document changes or reasons for the deployment update, enhancing the clarity of deployment history.

• Probes and their types:

  • Definition: Kubernetes supports several types of probes to ensure application health:

    • Startup Probe: Checks if the application has started successfully.

    • Readiness Probe: Determines if the application is ready to handle traffic.

    • Liveness Probe: Monitors if the application is still alive and running.

    • Note: In production environments, always configure probes to avoid deploying applications without health checks.