Docker Certified Associate DCA Book

The command ‘docker ps http’ is not the correct command to view the list of historical tasks for a service in Docker1. The ‘docker ps’ command is used to list containers1. If you want to view the list of historical tasks for a service, you should use the ‘docker service ps’ command2. This command lists the tasks that are running as part of the specified services and also shows the task history2. Therefore, to view the list of historical tasks for the ‘http’ service, you should use the command 'docker service ps http’2.

 The command ‘kubectl get pods --all-namespaces -I env=development’ does not display all the pods in the cluster that are labeled as ‘env: development’. The reason is that the flag -I is not a valid option for kubectl get pods. The correct flag to use is --selector or -l, which allows you to filter pods by labels1. Labels are key-value pairs that can be attached to Kubernetes objects to identify, group, or select them2. For example, to label a pod with env=development, one can run:

kubectl label pods my-pod env=development

To display all the pods that have the label env=development, one can run:

kubectl get pods --selector env=development

or

kubectl get pods -l env=development

The --all-namespaces flag can be used to list pods across all namespaces3. Therefore, the correct command to display all the pods in the cluster that are labeled as ‘env: development’ is:

kubectl get pods --all-namespaces --selector env=development

or

kubectl get pods --all-namespaces -l env=development References:

• kubectl Cheat Sheet | Kubernetes
• Labels and Selectors | Kubernetes
• kubectl get | Kubernetes

= The livenessProbe is a mechanism that checks if the container is alive and healthy, and restarts it if it fails1. The orchestrator is the component that manages the deployment and scaling of containers across a cluster of nodes2. The action taken by the orchestrator to fix the unhealthy container is not to autoscale back and delete the pod, but to recreate the pod on the same or a different node3. This ensures that the desired number of replicas for the pod is maintained, and that the pod can resume its normal operation. Autoscaling back and deleting the pod would reduce the availability and performance of the service, and would not necessarily alleviate the load.

References:

• Configure Liveness, Readiness and Startup Probes | Kubernetes
• What is a Container Orchestrator? | Docker
• Pod Lifecycle | Kubernetes

I hope this helps you understand the concept of livenessProbe and orchestrator, and how they work with Docker and Kubernetes. If you have any other questions related to Docker, please feel free to ask me. ????

The command kubectl get deployment api will only show the status of the deployment object, such as the number of replicas, available pods, and updated pods1. It will not display the events table for the deployment, which contains information about the creation, scaling, and updating of the deployment and its pods2. To see the events table for the deployment, you need to use the kubectl describe deployment api command, which will show the details of the deployment object, including the events3. Alternatively, you can use the kubectl get events --field-selector involvedObject.name=api command, which will filter the events by the name of the involved object4. References:

• Kubectl: Get Deployments - Kubernetes - ShellHacks
• Events in Kubernetes | Kubernetes
• kubectl Cheat Sheet | Kubernetes
• kubernetes - kubectl get events only for a pod - Stack Overflow