#Kubernetes tutorial for beginners | K8s Monitoring and troubleshooting | Deploy Prometheus Grafana
761 بار بازدید -
3 سال پیش
-
#Kubernetes tutorial
#Kubernetes tutorial for beginners | Kubernetes Monitoring and troubleshooting | Deploy Prometheus and Grafana
kubernetes monitoring, kubernetes monitoring prometheus grafana, grafana kubernetes monitoring, kubernetes monitoring prometheus-grafana, prometheus operator kubernetes
Monitoring the Cluster Components
Monitoring the Applications Running within a Cluster
Managing Cluster Component Logs
Managing Application Logs
Deploy Prometheus & Grafana
Debugging your Kubernetes object configuration relies heavily on using a few key commands combined with the experience of having seen things break in a similar way in the past. The benefit of Kubernetes—compared to ad-hoc deployment systems - is that it breaks in a predictable way. Once you've seen a certain type of failure and you know how to fix it, you can expect that resolution to work in other situations. The kubectl get all command is an easy way to get a complete picture of what's running in your namespace. While details are scant, it's useful to get a quick idea of what's running, what's failed, and what's about to start running. The most useful command when debugging Kubernetes is kubectl describe. It describes the entire state of an object, its desired state, and recent events that have affected the object. kubectl describe all gives you a detailed description of everything in your cluster, and kubectl describe pod pod helps you narrow that down to a single pod.kubectl logs and kubectl logs --previous get you the output of a given pod, and the output of a previously-run pod respectively.
Run kubectl describe pod pod and kubectl get pods.
Check the pod's status. CrashLoopBackOff means that the pod runs a container that immediately exits. This is commonly caused by a misconfiguration or invalid image. ErrImagePull means that the image could not be retrieved from the image repository. Check that the node has network access to the repository.
Your pod can be configured with imagePullSecrets that provide authentication when it needs to access the registry. Make sure you understand and are using the correct service type - the default is clusterIP, where the service is only exposed inside the cluster. Use kubectl exec -it pod sh to get a shell in a pod inside the cluster, then try to curl one of the pod's directly. kubectl get pods -o wide gets you the IP address of all the pods in the cluster.
Then try to curl the service.
This helps you diagnose if the pod is misconfigured or if the service is misconfigured. Real-world monitoring goes far beyond checking whether a system is up and running. Operation teams can best serve the business when they can anticipate the issues and mitigate them before a system goes offline.
Best practices in monitoring are to measure the performance and usage of core resources and watch for trends that stray from the normal baseline.
Containers are not different here, and a key component to managing our Kubernetes cluster is having a clear view into performance and availability of the OS, network, system CPU and memory, and storage resources across all nodes. If our nodes were already running a number of monitoring services, we can see these by running the get pods command with the kube-system namespace:
kubectl get pods --namespace=kube-system
Monitoring needs to be set up at the container, pod, service, node, and cluster level. Heapster is a widely used tool for monitoring performance and resource usage of the cluster. If Heapster is running, the command kubectl top pod outputs resource usage for pods in the cluster. cAdvisor is an open source project from Google, which provides various metrics on container resource use. Metrics include CPU, memory, and network statistics.
There is no need to tell cAdvisor about individual containers; it collects the metrics for all containers on a node and reports this back to the kublet, which in turn reports to Heapster.To learn latest technology online, visit https://www.skillpedia.co
kubernetes monitoring, kubernetes monitoring prometheus grafana, grafana kubernetes monitoring, kubernetes monitoring prometheus-grafana, prometheus operator kubernetes
Monitoring the Cluster Components
Monitoring the Applications Running within a Cluster
Managing Cluster Component Logs
Managing Application Logs
Deploy Prometheus & Grafana
Debugging your Kubernetes object configuration relies heavily on using a few key commands combined with the experience of having seen things break in a similar way in the past. The benefit of Kubernetes—compared to ad-hoc deployment systems - is that it breaks in a predictable way. Once you've seen a certain type of failure and you know how to fix it, you can expect that resolution to work in other situations. The kubectl get all command is an easy way to get a complete picture of what's running in your namespace. While details are scant, it's useful to get a quick idea of what's running, what's failed, and what's about to start running. The most useful command when debugging Kubernetes is kubectl describe. It describes the entire state of an object, its desired state, and recent events that have affected the object. kubectl describe all gives you a detailed description of everything in your cluster, and kubectl describe pod pod helps you narrow that down to a single pod.kubectl logs and kubectl logs --previous get you the output of a given pod, and the output of a previously-run pod respectively.
Run kubectl describe pod pod and kubectl get pods.
Check the pod's status. CrashLoopBackOff means that the pod runs a container that immediately exits. This is commonly caused by a misconfiguration or invalid image. ErrImagePull means that the image could not be retrieved from the image repository. Check that the node has network access to the repository.
Your pod can be configured with imagePullSecrets that provide authentication when it needs to access the registry. Make sure you understand and are using the correct service type - the default is clusterIP, where the service is only exposed inside the cluster. Use kubectl exec -it pod sh to get a shell in a pod inside the cluster, then try to curl one of the pod's directly. kubectl get pods -o wide gets you the IP address of all the pods in the cluster.
Then try to curl the service.
This helps you diagnose if the pod is misconfigured or if the service is misconfigured. Real-world monitoring goes far beyond checking whether a system is up and running. Operation teams can best serve the business when they can anticipate the issues and mitigate them before a system goes offline.
Best practices in monitoring are to measure the performance and usage of core resources and watch for trends that stray from the normal baseline.
Containers are not different here, and a key component to managing our Kubernetes cluster is having a clear view into performance and availability of the OS, network, system CPU and memory, and storage resources across all nodes. If our nodes were already running a number of monitoring services, we can see these by running the get pods command with the kube-system namespace:
kubectl get pods --namespace=kube-system
Monitoring needs to be set up at the container, pod, service, node, and cluster level. Heapster is a widely used tool for monitoring performance and resource usage of the cluster. If Heapster is running, the command kubectl top pod outputs resource usage for pods in the cluster. cAdvisor is an open source project from Google, which provides various metrics on container resource use. Metrics include CPU, memory, and network statistics.
There is no need to tell cAdvisor about individual containers; it collects the metrics for all containers on a node and reports this back to the kublet, which in turn reports to Heapster.To learn latest technology online, visit https://www.skillpedia.co
3 سال پیش
در تاریخ 1400/08/20 منتشر شده
است.
761
بـار بازدید شده