Introduction For a typical cloud-native application with a 3-tier architecture, the diagram below illustrates how it might be described in terms of Kubernetes objects. In this example, each tier consists of a Deployment and Service object, and may additionally define ConfigMap or Secret objects. Each of these objects are typically defined in separate YAML files, and are fed into the kubectl command line tool. A Helm chart encapsulates each of these YAML definitions, provides a mechanism for configuration at deploy-time and allows you to define metadata and documentation that might be useful when sharing the package. Helm can be useful in different scenarios: Find and use popular software packaged as Kubernetes charts Share your own applications as Kubernetes charts Create reproducible builds of your Kubernetes applications Intelligently manage your Kubernetes object definitions Manage releases of Helm packages Let……
一、前言 kubectl top 可以很方便地查看node、pod 的实时资源使用情况：如CPU、内存。这篇文章会介绍其数据链路和实现原理，同时借 kubectl top 阐述 k8s 中的监控体系，窥一斑而知全豹。最后会解释常见的一些问题： kubectl top 为什么会报错？ kubectl top node 怎么计算，和节点上直接 top 有什么区别？ kubectl top pod 怎么计算，包含 pause 吗？ kubectl top pod……
Reloading Prometheus’ Configuration A common question from new users is if they need to restart Prometheus every time they change the configuration. The good news is that you don’t, allowing your monitoring to continue uninterrupted as your system changes. There are two ways to ask Prometheus to reload it’s configuration, a SIGHUP and the POSTing to the /-/reload handler. To send a SIGHUP, first determine the process id of Prometheus. This may be in a file such as /var/run/prometheus.pid, or you can use tools such as pgrep to find it. Then use the kill command to send the signal: 1kill -HUP 1234 Alternatively, you can send a HTTP POST to the Prometheus web server: 1curl -X POST :9090/-/reload Note that as of……