They can be used for various purposes, mainly related to identifying and targeting resources based on them having a label(s) assigned.
Labels are a very useful tool in Kubernetes. Wait can also be useful if waiting for resources to delete: kubectl wait -for=delete pod/civo-pod If you wish to wait for a condition to not be met add =false eg -for=condition=Ready=false. This will wait for the pod civo-pod to be in a Ready state, and timeout after 30 seconds if not met. This is used to wait for a resource to match a specific state, such as Ready: kubectl wait -for=condition=Ready pod/civo-pod -timeout=30s With the above you might be watching for pods in the default namespace to become ready, for example. This will output the results of the get command and then watch for changes in the resources and output them. One method for this is the -w ( -watch=true) option for kubectl get. Commonly you might want to watch for changes in a particular resource, for example when waiting for a deployment with a number of pods to become ready.
You would use this as kubectl logs pod-name -n namespace -previous for the default container, and so on.Īs mentioned above, you can follow the streaming of logs of active containers. The -previous option for kubectl logs is useful if a container has restarted (for example in a CrashLoopBackoff) as it will load the logs from the previous container. previous 5 minutes of logs: kubectl logs pod-name -n namespace -c container1 -since=5m kubectl logs pod-name -n namespace -c container1 -fĪnother useful option is -since which will print logs newer than a duration of time, e.g. If you wish stream the live container logs to your terminal you can append the -f (follow) option, which is useful when watching for a log related to an action you are performing. To view logs from all containers use the -all-containers option. (The above will fetch logs from a container named container1 inside the pod named pod-name) kubectl logs pod-name -n namespace -c container1 If there are multiple containers in the pod you can use the -c option to specify which container to fetch logs from. To fetch the container logs of the default container in the pod (defined in the /default-container annotation). In this situation examining pod and container logs can be useful: If a pod is successfully scheduled, but enters an Error or CrashLoopBackoff state this is because the container has encountered an error. The events should provide some indication of why the pod cannot be scheduled, for example if nodes have taints the pod does not tolerate. To investigate, you can check the events for the pod by running a describe command. If a pod is stuck in a pending state, this means the Kubernetes scheduler is unable to schedule the pod to a node in the cluster. Pods can fail for a number of reasons, either related to the Kubernetes cluster being unable to create the pod, or the container(s) inside the pod failing after launch. More information can be found in the official Kubernetes documentation on defining clusters, users, and contexts. The configuration file can be edited directly or with the use of kubectl config set.
#KUBECTL GET CONTEXTS FULL#
If you need to view the full configuration, you can use: kubectl config view You can switch switch contexts using kubectl without having to specify a whole new kubeconfig file: kubectl config use-context production-context Production-context production production-user defaultĬurrent context is shown with *, but can also be retrieved with kubectl config current-context. * staging-context staging staging-user default You can get currently-configured contexts as follows: $ kubectl config get-contexts Therefore they can be used to switch between combinations of clusters, users with different role permissions (RBAC), and namespaces. With contexts you can have multiple Kubeconfigs merged into one file and just switch between contexts to administer different clusters.Ī context is a combination of a cluster, authentication, and namespace. Or you can use the -kubeconfig flag for kubectl to specify the path to a config file as part of the command, like kubectl get nodes -kubeconfig ~/custom_config. It is possible to switch between cluster configs using the KUBECONFIG environment variable.
If you manage multiple Kubernetes clusters it is useful to get to grips with using contexts.
0 kommentar(er)
