Kubernetes连载之03 Monitoring and Logging

[andy2046]

Monitoring Kubernetes with Heapster

Heapster是一个Kubernetes项目，为Kubernetes集群提供强大的监控解决方案。它作为一个pod运行，所以它可以由Kubernetes自己管理。Heapster支持Kubernetes和CoreOS集群。它有一个非常模块化和灵活的设计。Heapster从集群中的每个节点收集metrics和events，并将它们存储在持久的后端（具有良好定义的schema），并允许可视化和程序化访问。Heapster可以被配置为使用不同的后端（sinks）以及相应的可视化前端。最常见的组合是InfluxDB作为后端和Grafana作为前端。Google云端平台将Heapster与Google监控服务集成在一起。

您可以通过在命令行中指定sinks来使用多个后端：

--sink=log --sink=influxdb:http://monitoring-influxdb:80/

cAdvisor

cAdvisor是kubelet的一部分，它在每个节点上运行。它收集有关每个容器的CPU/内核使用情况，内存，网络和文件系统的信息。它提供了一个基于4194端口的UI，但对Heapster来说最重要的是，它通过kubelet提供了所有这些信息。Heapster将cAdvisor收集的信息记录在每个节点上，并将其存储在后端进行分析和可视化。

如果你想快速验证特定节点是否正确设置，例如在创建新集群的情况下，Heapster尚未启动时，cAdvisor UI很有用。

InfluxDB backend

InfluxDB是一个强大的分布式时间序列数据库。它非常适合并广泛用于metrics和log记录。

The storage schema

InfluxDB存储schema定义了Heapster存储在InfluxDB中的信息，并可在稍后查询。metrics分为多个类别，称为measurements。你可以分别处理和查询每个metric，也可以将整个类别作为一个measurement来查询和把各个metric作为字段来接收。命名惯例是/（uptime除外，它只有一个metric）。你可以将measurements视为表。每个metric都存储在单个容器中。每个metric都标有以下信息：

• pod_id：一个pod的唯一ID
• pod_name：用户提供的pod名称
• pod_namespace：一个pod的命名空间
• container_base_image：容器的基础image
• container_name：用户提供的容器名称或系统容器的完整cgroup名称
• host_id：节点的云提供者或用户指定的标识符
• 主机名：容器运行的主机名
• 标签：用户提供的逗号分隔的标签列表，格式是键：值
• namespace_id：一个pod的命名空间的UID
• resource_id：用于区分同一类型的多个metrics的唯一标识符

CPU

• cpu/limit: CPU hard limit in millicores
• cpu/node_capacity: CPU capacity of a node
• cpu/node_allocatable: CPU allocatable of a node
• cpu/node_reservation: Share of CPU that is reserved on the node allocatable
• cpu/node_utilization: CPU utilization as a share of node allocatable
• cpu/request: CPU request (the guaranteed amount of resources) in
  millicores
• cpu/usage: Cumulative CPU usage on all cores
• cpu/usage_rate: CPU usage on all cores in millicores

Filesystem

• filesystem/usage: Total number of bytes consumed on a filesystem
• filesystem/limit: The total size of the filesystem in bytes
• filesystem/available: The number of available bytes remaining in the filesystem

Memory

• memory/limit: Memory hard limit in bytes
• memory/major_page_faults: Number of major page faults
• memory/major_page_faults_rate: Number of major page faults per second
• memory/node_capacity: Memory capacity of a node
• memory/node_allocatable: Memory allocatable of a node
• memory/node_reservation: Share of memory that is reserved on the node allocatable
• memory/node_utilization: Memory utilization as a share of memory allocatable
• memory/page_faults: Number of page faults
• memory/page_faults_rate: Number of page faults per second
• memory/request: Memory request (the guaranteed amount of resources) in bytes
• memory/usage: Total memory usage
• memory/working_set: Total working set usage; working set is the memory
  being used and is not easily dropped by the kernel

Network

• network/rx: Cumulative number of bytes received over the network
• network/rx_errors: Cumulative number of errors while receiving over
  the network
• network/rx_errors_rate: Number of errors per second while receiving over the network
• network/rx_rate: Number of bytes received over the network per second
• network/tx: Cumulative number of bytes sent over the network
• network/tx_errors: Cumulative number of errors while sending over the network
• network/tx_errors_rate: Number of errors while sending over the network
• network/tx_rate: Number of bytes sent over the network per second

Uptime

• uptime: Number of milliseconds since the container was started
  输入以下命令查找influxdb端口：

k describe service monitoring-influxdb --namespace=kube-system | grep NodePort
Type:     NodePort
NodePort: http    32699/TCP
NodePort: api     30020/TCP

Grafana visualization

Grafana运行在自己的容器中，并提供一个仪表板，可以很好地处理influxDB作为数据源。要找到端口，输入以下命令：

k describe service monitoring-influxdb --namespace=kube-system | grep NodePort
Type:                   NodePort
NodePort:               <unset> 30763/TCP

Performance analysis with the dashboard

k describe service kubernetes-dashboard --namespace=kube-system | grep NodePort
Type:                   NodePort
NodePort:               <unset> 30000/TCP

Top-level view

dashboard有几个分类：

• Admin
• Workloads
• Services and discovery
• Storage
• Config

Adding central logging

对于具有多个节点，pod或容器的任何集群，集中日志记录或集群级日志记录是基本要求。

Planning central logging

在每个节点上运行一个专用代理程序，该代理程序拦截来自节点上所有容器和pod的所有日志消息，并将它们连同元数据一起发送到安全存储它们的中心存储， 常用的有Fluentd。

Detecting node problems

在Kubernetes的概念模型中，工作单位是pod。 但是pod运行在节点上。当涉及到监控和可靠性时，节点是最需要关注的，因为Kubernetes本身（scheduler和replication controller）负责处理Pod。节点可能遭受Kubernetes不知道的各种问题。

Node problem detector

节点问题检测器是一个在每个节点上运行的pod。它需要解决一个难题。它需要检测不同环境，不同硬件和不同操作系统的各种问题。它需要足够可靠，不会受到影响（否则它不能报告问题），并且它需要相对较低的开销以避免影响节点。另外，它需要运行在每个节点上。

DaemonSet

DaemonSet是运行在每个节点的pod。一旦你定义了DaemonSet，添加到集群的每个节点都会自动获得一个pod。如果该pod挂了，Kubernetes将在该节点上启动该pod的另一个实例。可以将其视为具有1：1 node-pod的replication controller。节点问题检测器被定义为一个DaemonSet，这与它的要求完美匹配。

Problem Daemons

节点问题检测器的问题在于它需要处理很多问题。试图将所有这些代码塞进一个代码库可能会导致一个复杂的，臃肿的，永不稳定的代码库。节点问题检测器的设计要求检测特定问题的功能与将节点问题报告给主节点的功能分离。reporting API基于一般条件和事件。问题检测应该由单独的问题守护进程完成（每个守护进程都在它自己的容器中）。这样就有可能添加和发展新的问题检测器，而不会影响节点问题检测器的代码。另外，control plane可能有一个remedy controller，可以自动解决一些节点问题，从而实现自我修复。

Designing robust systems

当你想要设计一个强大的系统时，你首先需要了解可能的故障模式，每次故障的风险/概率以及每次故障的影响/成本。然后，你可以考虑各种预防和缓解措施，减损策略，事件管理策略和恢复程序。最后，你可以制定一份计划，将风险与减排成本相匹配。