{"id":1539,"date":"2023-03-25T01:50:33","date_gmt":"2023-03-25T01:50:33","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=1539"},"modified":"2023-03-25T01:50:36","modified_gmt":"2023-03-25T01:50:36","slug":"native-kubernetes-monitoring-monitoring-and-metrics-for-users","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2023\/03\/25\/native-kubernetes-monitoring-monitoring-and-metrics-for-users\/","title":{"rendered":"Native Kubernetes Monitoring: Monitoring and Metrics for Users"},"content":{"rendered":"<div class=\"wrapper p-t-md\">\n<div class=\"row center-xs\">\n<div class=\"col-md-8 col-xs-12\"><\/div>\n<\/div>\n<hr>\n<\/div>\n<div class=\"wrapper\">\n<article class=\"main-content row center-xs\">\n<div class=\"col-md-8 col-xs-12\">\n<h2 id=\"introduction\"><strong>Introduction<\/strong><\/h2>\n<p>Kubernetes is an open-source orchestration platform for working with containers. At its core, it gives us the means to do deployments, easy ways to scale, and monitoring. In this article, we will talk about the built-in monitoring capabilities of Kubernetes and include some demos for better understanding.<\/p>\n<h2 id=\"brief-overview-of-kubernetes-architecture\"><strong>Brief Overview of Kubernetes Architecture<\/strong><\/h2>\n<p>At the&nbsp;<strong>infrastructure<\/strong>&nbsp;level, a Kubernetes cluster is a set of physical or virtual machines, each acting in a specific role. The machines acting in the role of master function as the brain of the operations and are charged with orchestrating the management of all containers that run on all of the nodes.<\/p>\n<ul>\n<li>Master components manage the life cycle of a pod:\n<ul>\n<li><strong>apiserver:<\/strong>&nbsp;main component exposing APIs for all the other master components<\/li>\n<li><strong>scheduler:<\/strong>&nbsp;uses information in the pod spec to decide on which node to run a pod<\/li>\n<li><strong>controller-manager:<\/strong>&nbsp;responsible for node management (detecting if a node fails), pod replication, and endpoint creation<\/li>\n<li><strong>etcd:<\/strong>&nbsp;key\/value store used for storing all internal cluster data<\/li>\n<\/ul>\n<\/li>\n<li>Node components are worker machines in Kubernetes, managed by the master. Each node contains the necessary components to run pods:\n<ul>\n<li><strong>kubelet:<\/strong>&nbsp;handles all communication between the master and the node on which it is running. It interfaces with the container runtime to deploy and monitor containers<\/li>\n<li><strong>kube-proxy:<\/strong>&nbsp;is in charge with maintaining network rules for the node. It also handles communication between pods, nodes, and the outside world.<\/li>\n<li><strong>container runtime:<\/strong>&nbsp;runs containers on the node.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>From a&nbsp;<strong>logical<\/strong>&nbsp;perspective, a Kubernetes deployment is comprised of various components, each serving a specific purpose within the cluster:<\/p>\n<ul>\n<li><strong>Pods:<\/strong>&nbsp;are the basic unit of deployment within Kubernetes. A pod consists of one or more containers that share the same network namespace and IP address.<\/li>\n<li><strong>Services:<\/strong>&nbsp;act like a load balancer. They provide an IP address in front of a pool (set of pods) and also a policy that controls access to them.<\/li>\n<li><strong>ReplicaSets:<\/strong>&nbsp;are controlled by deployments and ensure that the desired number of pods for that deployment are running.<\/li>\n<li><strong>Namespaces:<\/strong>&nbsp;define a logical segregation for different kind of resources like pods and\/or services.<\/li>\n<li><strong>Metadata:<\/strong>&nbsp;marks containers based on their deployment characteristics.<\/li>\n<\/ul>\n<h2 id=\"monitoring-kubernetes\"><strong>Monitoring Kubernetes<\/strong><\/h2>\n<p>Monitoring an application is absolutely required if we want to anticipate problems and have visibility of potential bottlenecks in a dev or production deployment.<\/p>\n<p>To help monitor the cluster and the many moving parts that form a deployment, Kubernetes ships with some built-in monitoring capabilities:<\/p>\n<ul>\n<li><strong>Kubernetes dashboard:<\/strong>&nbsp;gives an overview of the resources running on your cluster. It also gives a very basic means of deploying and interacting with those resources.<\/li>\n<li><strong>cAdvisor:<\/strong>&nbsp;is an open source agent that monitors resource usage and analyzes the performance of containers.<\/li>\n<li><strong>Liveness and Readiness Probes:<\/strong>&nbsp;actively monitor the health of a container.<\/li>\n<li><strong>Horizontal Pod Autoscaler:<\/strong>&nbsp;increases the number of pods if needed based on information gathered by analyzing different metrics.<\/li>\n<\/ul>\n<p>In this article, we will be covering the first two built-in tools. A follow up article focusing on the remaining tools can be found&nbsp;<a href=\"https:\/\/rancher.com\/blog\/2019\/native-kubernetes-monitoring-tools-part-2\">here<\/a>.<\/p>\n<p>There are many Kubernetes metrics to monitor. As we\u2019ve described the architecture in two separate ways (infrastructure and logical), we can do the same with monitoring and separate this into two main components: monitoring the cluster itself and monitoring the workloads running on it.<\/p>\n<h3 id=\"cluster-monitoring\"><strong>Cluster Monitoring<\/strong><\/h3>\n<p>All clusters should monitor the underlying server components since problems at the server level will show up in the workloads. Some metrics to look for while monitoring node resources are CPU, disk, and network bandwidth. Having an overview of these metrics will let you know if it\u2019s time to scale the cluster up or down (this is especially useful when using cloud providers where running cost is important).<\/p>\n<h3 id=\"workload-monitoring\"><strong>Workload Monitoring<\/strong><\/h3>\n<p>Metrics related to deployments and their pods should be taken into consideration here. Checking the number of pods a deployment has at a moment compared to its desired state can be relevant. Also, we can look for health checks, container metrics, and finally application metrics.<\/p>\n<h2 id=\"prerequisites-for-the-demo\"><strong>Prerequisites for the Demo<\/strong><\/h2>\n<p>In the following sections, we will take each of the listed built-in monitoring features one-by-one to see how they can help us. The prerequisites needed for this exercise include:<\/p>\n<ul>\n<li><strong>a Google Cloud Platform account:<\/strong>&nbsp;the free tier is more than enough. Most other cloud should also work the same.<\/li>\n<li><strong>a host where Rancher will be running:<\/strong>&nbsp;This can be a personal PC\/Mac or a VM in a public cloud.<\/li>\n<li><strong><a href=\"https:\/\/cloud.google.com\/sdk\/install\">Google Cloud SDK<\/a>:<\/strong>&nbsp;should be installed along&nbsp;<a href=\"https:\/\/kubernetes.io\/docs\/tasks\/tools\/install-kubectl\/\">kubectl<\/a>&nbsp;on the host running Rancher. Make sure that&nbsp;<code>gcloud<\/code>&nbsp;has access to your Google Cloud account by authenticating with your credentials (<code>gcloud init<\/code>&nbsp;and&nbsp;<code>gcloud auth login<\/code>).<\/li>\n<\/ul>\n<h3 id=\"starting-a-rancher-instance\">Starting a Rancher Instance<\/h3>\n<p>To begin, start your Rancher instance. There is a very intuitive&nbsp;<a href=\"https:\/\/rancher.com\/quick-start\/\">getting started guide for Rancher<\/a>&nbsp;that you can follow for this purpose.<\/p>\n<h3 id=\"using-rancher-to-deploy-a-gke-cluster\">Using Rancher to Deploy a GKE cluster<\/h3>\n<p>Use Rancher to set up and configure a Kubernetes cluster by following the how-to&nbsp;<a href=\"https:\/\/rancher.com\/docs\/rancher\/v2.x\/en\/cluster-provisioning\/hosted-kubernetes-clusters\/gke\/\">guide<\/a>.<\/p>\n<p>As mentioned previously, in this guide we will be covering the first two built-in tools: the Kubernetes dashboard and cAdvisor. A follow up article that discusses probes and horizontal pod autoscalers can be found&nbsp;<a href=\"https:\/\/rancher.com\/blog\/2019\/native-kubernetes-monitoring-tools-part-2\">here<\/a>.<\/p>\n<h2 id=\"kubernetes-dashboard\"><strong>Kubernetes Dashboard<\/strong><\/h2>\n<p>The Kubernetes dashboard is a web-based Kubernetes user interface that we can use to troubleshoot applications and manage cluster resources.<\/p>\n<p><a href=\"https:\/\/github.com\/rancher\/rancher\">Rancher<\/a>, as seen above, helps us install the dashboard by just checking a radio button. Let\u2019s take a look now at how the dashboard can help us by listing some of its uses:<\/p>\n<ul>\n<li>Provides an overview of cluster resources (overall and per individual node), shows us all of the namespaces, lists all of the storage classes defined<\/li>\n<li>Shows all applications running on the cluster<\/li>\n<li>Provides information about the state of Kubernetes resources in your cluster and on any errors that may have occurred<\/li>\n<\/ul>\n<p>To access the dashboard, we need to proxy the request between our machine and Kubernetes API server. Start a proxy server with&nbsp;<code>kubectl<\/code>&nbsp;by typing the following:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">kubectl proxy &amp;<\/code><\/pre>\n<\/div>\n<p>The proxy server will start in the background, providing output that looks similar to this:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">[1] 3190\n$ Starting to serve on 127.0.0.1:8001<\/code><\/pre>\n<\/div>\n<p>Now, to view the dashboard, navigate to the following address in the browser:<\/p>\n<blockquote><p><a href=\"http:\/\/localhost:8001\/api\/v1\/namespaces\/kube-system\/services\/https:kubernetes-dashboard:\/proxy\/\">http:\/\/localhost:8001\/api\/v1\/namespaces\/kube-system\/services\/https:kubernetes-dashboard:\/proxy\/<\/a><\/p><\/blockquote>\n<p>We will then be prompted with the login page to enter the credentials:<\/p>\n<figure><img decoding=\"async\" src=\"https:\/\/rancher.com\/img\/blog\/2019\/monitoring-kubernetes-with-built-in-tools\/04-rancher-monitoring-dashboard-login.png\" alt=\"Fig. 4: Dashboard login\"><figcaption>\n<h4>Fig. 4: Dashboard login<\/h4>\n<\/figcaption><\/figure>\n<p>Let\u2019s take a look on how to create a user with admin permission using the Service Account mechanism. We will use two YAML files.<\/p>\n<p>One will create the Service Account:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">cat ServiceAccount.yaml<\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-yaml\" data-lang=\"yaml\">apiVersion: v1\nkind: ServiceAccount\nmetadata:\n  name: admin-user\n  namespace: kube-system<\/code><\/pre>\n<\/div>\n<p>The other will create the&nbsp;<code>ClusterRoleBinding<\/code>&nbsp;for our user:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">cat ClusterRoleBinding.yaml<\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-yaml\" data-lang=\"yaml\">apiVersion: rbac.authorization.k8s.io\/v1\nkind: ClusterRoleBinding\nmetadata:\n  name: admin-user\nroleRef:\n  apiGroup: rbac.authorization.k8s.io\n  kind: ClusterRole\n  name: cluster-admin\nsubjects:\n- kind: ServiceAccount\n  name: admin-user\n  namespace: kube-system<\/code><\/pre>\n<\/div>\n<p>Apply the two YAML files to create the objects they define:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">kubectl apply -f ServiceAccount.yaml \nkubectl apply -f ClusterRoleBinding.yaml <\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">serviceaccount \"admin-user\" created\nclusterrolebinding.rbac.authorization.k8s.io \"admin-user\" created<\/code><\/pre>\n<\/div>\n<p>Once our user is created and the correct permissions have been set, we will need to find out the token in order to login:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')<\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">Name:         admin-user-token-lnnsn\nNamespace:    kube-system\nLabels:       &lt;none&gt;\nAnnotations:  kubernetes.io\/service-account.name=admin-user\n              kubernetes.io\/service-account.uid=e34a9438-4e12-11e9-a57b-42010aa4009e\n\nType:  kubernetes.io\/service-account-token\n\nData\n====\nca.crt:     1119 bytes\nnamespace:  11 bytes\ntoken:      <strong>COPY_THIS_STRING<\/strong>\n<\/code><\/pre>\n<\/div>\n<p>Select \u201cToken\u201d at the Kubernetes dashboard credentials prompt and enter the value you retrieved above in the token field to authenticate.<\/p>\n<p>The Kubernetes Dashboard consists of few main views:<\/p>\n<ul>\n<li><strong>Admin view:<\/strong>&nbsp;lists nodes, namespaces, and persistent volumes along with other details. We can get an aggregated view for our nodes (CPU and memory usage metrics) and an individual details view for each node showing its metrics, specification, status, allocated resources, events, and pods.<\/li>\n<li><strong>Workload view:<\/strong>&nbsp;shows all applications running in a selected namespace. It summarizes important information about workloads, like the number of pods ready in a StatefulSet or Deployment or the current memory usage for a pod.<\/li>\n<li><strong>Discover and Load Balancing view:<\/strong>&nbsp;shows Kubernetes resources that expose services to the external world and enable discovery within the cluster.<\/li>\n<li><strong>Config and storage view:<\/strong>&nbsp;shows persistent volume claim resources used by applications. Config view is used to shows all of the Kubernetes resources used for live configuration of applications running in the cluster.<\/li>\n<\/ul>\n<p>Without any workloads running, the dashboard\u2019s views will be mainly empty since there will be nothing deployed on top of Kubernetes. If you want to explore all of the views the dashboard has to offer, the best option is to deploy apps that use different workload types (stateful set, deployments, replica sets, etc.). You can check out&nbsp;<a href=\"https:\/\/rancher.com\/blog\/2019\/deploying-redis-cluster\/\">this article on deploying a Redis cluster<\/a>&nbsp;for an example that deploys a Redis cluster (a stateful set with volume claims and configMaps) and a testing app (a Kubernetes deployment) so the dashboard tabs will have some relevant info.<\/p>\n<p>After provisioning some workloads, we can take down one node and then check the different tabs to see some updates:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">kubectl delete pod redis-cluster-2\nkubectl get pods<\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">pod \"redis-cluster-2\" deleted\nNAME                              READY     STATUS        RESTARTS   AGE\nhit-counter-app-9c5d54b99-xv5hj   1\/1       Running       0          1h\nredis-cluster-0                   1\/1       Running       0          1h\nredis-cluster-1                   1\/1       Running       0          1h\nredis-cluster-2                   0\/1       Terminating   0          1h\nredis-cluster-3                   1\/1       Running       0          44s\nredis-cluster-4                   1\/1       Running       0          1h\nredis-cluster-5                   1\/1       Running       0          1h<\/code><\/pre>\n<\/div>\n<h2 id=\"cadvisor\"><strong>cAdvisor<\/strong><\/h2>\n<p>cAdvisor is an open-source agent integrated into the&nbsp;<code>kubelet<\/code>&nbsp;binary that monitors resource usage and analyzes the performance of containers. It collects statistics about the CPU, memory, file, and network usage for all containers running on a given node (it does not operate at the pod level). In addition to core metrics, it also monitors events as well. Metrics can be accessed directly, using commands like&nbsp;<code>kubectl top<\/code>&nbsp;or used by the scheduler to perform orchestration (for example with autoscaling).<\/p>\n<p>Note that cAdvisor doesn\u2019t store metrics for long-term use, so if you want that functionality, you\u2019ll need to look for a dedicated monitoring tool.<\/p>\n<p>cAdvisor\u2019s UI has been marked deprecated as of Kubernetes version 1.10 and the interface is scheduled to be completely removed in version 1.12. Rancher gives you the option to choose what version of Kubernetes to use for your clusters. When setting up the infrastructure for this demo, we configured the cluster to use version 1.10, so we should still have access to the cAdvisor UI.<\/p>\n<p>To access the cAdvisor UI, we need to proxy between our machine and Kubernetes API server. Start a local instance of the proxy server by typing:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">kubectl proxy &amp;<\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">[1] 3190\n$ Starting to serve on 127.0.0.1:8001<\/code><\/pre>\n<\/div>\n<p>Next, find the name of your nodes:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">kubectl get nodes<\/code><\/pre>\n<\/div>\n<p>You can view the UI in you browser by navigating to the following address, replacing the node name with the identifier you found on the command line:<\/p>\n<blockquote><p><a href=\"http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5:4194\/proxy\/containers\/\">http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5:4194\/proxy\/containers\/<\/a><\/p><\/blockquote>\n<p>To confirm that&nbsp;<code>kubelet<\/code>&nbsp;is listening on port 4194, you can log into the node to get more information:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">gcloud compute ssh admin@gke-c-plnf4-default-pool-5eb56043-23p5 --zone europe-west4-c<\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">Welcome to Kubernetes v1.10.12-gke.7!\n\nYou can find documentation for Kubernetes at:\n  http:\/\/docs.kubernetes.io\/\n\nThe source for this release can be found at:\n  \/home\/kubernetes\/kubernetes-src.tar.gz\nOr you can download it at:\n  https:\/\/storage.googleapis.com\/kubernetes-release-gke\/release\/v1.10.12-gke.7\/kubernetes-src.tar.gz\n\nIt is based on the Kubernetes source at:\n  https:\/\/github.com\/kubernetes\/kubernetes\/tree\/v1.10.12-gke.7\n\nFor Kubernetes copyright and licensing information, see:\n  \/home\/kubernetes\/LICENSES<\/code><\/pre>\n<\/div>\n<p>We can confirm that in our version of Kubernetes, the&nbsp;<code>kubelet<\/code>&nbsp;process is serving the cAdvisor web UI over that port:<\/p>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">sudo su -\nnetstat -anp | grep LISTEN | grep 4194<\/code><\/pre>\n<\/div>\n<div class=\"highlight\">\n<pre><code class=\"language-command\" data-lang=\"command\">tcp6       0      0 :::4194                 :::*                    LISTEN      1060\/kubelet <\/code><\/pre>\n<\/div>\n<p>If you run Kubernetes version 1.12 or later, the UI has been removed, so&nbsp;<code>kubelet<\/code>&nbsp;does not listening on port 4194 anymore. You can confirm this with the commands above. However, the metrics are still there since cAdvisor is part of the&nbsp;<code>kubelet<\/code>&nbsp;binary.<\/p>\n<p>The&nbsp;<code>kubelet<\/code>&nbsp;binary exposes all of its runtime metrics and all of the cAdvisor metrics at the&nbsp;<code>\/metrics<\/code>&nbsp;endpoint using the Prometheus exposition&nbsp;<a href=\"https:\/\/github.com\/prometheus\/docs\/blob\/master\/content\/docs\/instrumenting\/exposition_formats.md\">format<\/a>:<\/p>\n<blockquote><p><a href=\"http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5\/proxy\/metrics\/cadvisor\">http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5\/proxy\/metrics\/cadvisor<\/a><\/p><\/blockquote>\n<p>Among the output, metrics you can look for include:<\/p>\n<ul>\n<li>CPU:\n<ul>\n<li><code>container_cpu_user_seconds_total<\/code>: Cumulative \u201cuser\u201d CPU time consumed in seconds<\/li>\n<li><code>container_cpu_system_seconds_total<\/code>:\u200aCumulative \u201csystem\u201d CPU time consumed in seconds<\/li>\n<li><code>container_cpu_usage_seconds_total<\/code>: Cumulative CPU time consumed in seconds (sum of the above)<\/li>\n<\/ul>\n<\/li>\n<li>Memory:\n<ul>\n<li><code>container_memory_cache<\/code>: Number of bytes of page cache memory<\/li>\n<li><code>container_memory_swap<\/code>: Container swap usage in bytes<\/li>\n<li><code>container_memory_usage_bytes<\/code>: Current memory usage in bytes, including all memory regardless of when it was accessed<\/li>\n<li><code>container_memory_max_usage_bytes<\/code>: Maximum memory usage in byte<\/li>\n<\/ul>\n<\/li>\n<li>Disk:\n<ul>\n<li><code>container_fs_io_time_seconds_total<\/code>: Count of seconds spent doing I\/Os<\/li>\n<li><code>container_fs_io_time_weighted_seconds_total<\/code>: Cumulative weighted I\/O time in seconds<\/li>\n<li><code>container_fs_writes_bytes_total<\/code>: Cumulative count of bytes written<\/li>\n<li><code>container_fs_reads_bytes_total<\/code>: Cumulative count of bytes read<\/li>\n<\/ul>\n<\/li>\n<li>Network:\n<ul>\n<li><code>container_network_receive_bytes_total<\/code>: Cumulative count of bytes received<\/li>\n<li><code>container_network_receive_errors_total<\/code>: Cumulative count of errors encountered while receiving<\/li>\n<li><code>container_network_transmit_bytes_total<\/code>: Cumulative count of bytes transmitted<\/li>\n<li><code>container_network_transmit_errors_total<\/code>: Cumulative count of errors encountered while transmitting<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Some additional useful metrics can be found here:<\/p>\n<ul>\n<li><code>\/healthz<\/code>: Endpoint for determining whether cAdvisor is healthy<\/li>\n<li><code>\/healthz\/ping<\/code>: To check connectivity to etcd<\/li>\n<li><code>\/spec<\/code>: Endpoint returns the cAdvisor&nbsp;<code>MachineInfo()<\/code><\/li>\n<\/ul>\n<p>For example, to see the cAdvisor&nbsp;<code>MachineInfo()<\/code>, we could visit:<\/p>\n<blockquote><p><a href=\"http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5:10255\/proxy\/spec\/\">http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5:10255\/proxy\/spec\/<\/a><\/p><\/blockquote>\n<p>The&nbsp;<code>pods<\/code>&nbsp;endpoint provides the same output as&nbsp;<code>kubectl get pods -o json<\/code>&nbsp;for the pods running on the node:<\/p>\n<blockquote><p><a href=\"http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5:10255\/proxy\/pods\/\">http:\/\/localhost:8001\/api\/v1\/nodes\/gke-c-plnf4-default-pool-5eb56043-23p5:10255\/proxy\/pods\/<\/a><\/p><\/blockquote>\n<p>Similarly, logs can also be retrieved by visiting:<\/p>\n<blockquote><p><a href=\"http:\/\/localhost:8001\/logs\/kube-apiserver.log\">http:\/\/localhost:8001\/logs\/kube-apiserver.log<\/a><\/p><\/blockquote>\n<h2 id=\"conclusion\"><strong>Conclusion<\/strong><\/h2>\n<p>Monitoring is vital in order to understand what is happening with our applications. Kubernetes helps us with a number of built-in tools and provides some great insights for both, infrastructure layer (nodes) and logical one (pods).<\/p>\n<p>This article concentrated on the tools that focus on providing monitoring and metrics for users. Continue on to the&nbsp;<a href=\"https:\/\/rancher.com\/blog\/2019\/native-kubernetes-monitoring-tools-part-2\">second part of this series<\/a>&nbsp;to learn about the included monitoring tools focused on workload scaling and life cycle management.<\/p>\n<\/div>\n<\/article>\n<\/div>\n<p><a href=\"https:\/\/rancher.com\/blog\/2019\/native-kubernetes-monitoring-tools-part-1\/\" target=\"_blank\" rel=\"noopener\">Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction Kubernetes is an open-source orchestration platform for working with containers. At its core, it gives us the means to do deployments, easy ways to scale, and monitoring. In this article, we will talk about the built-in monitoring capabilities of Kubernetes and include some demos for better understanding. Brief Overview of Kubernetes Architecture At the&nbsp;infrastructure&nbsp;level, &hellip; <\/p>\n<p class=\"link-more\"><a href=\"https:\/\/www.appservgrid.com\/paw93\/index.php\/2023\/03\/25\/native-kubernetes-monitoring-monitoring-and-metrics-for-users\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Native Kubernetes Monitoring: Monitoring and Metrics for Users&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1539","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1539","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/comments?post=1539"}],"version-history":[{"count":3,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1539\/revisions"}],"predecessor-version":[{"id":2044,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/1539\/revisions\/2044"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/media?parent=1539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/categories?post=1539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/tags?post=1539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}