监视集群运行状况

在 IBM Cloud® Kubernetes Service 中设置监控，以帮助您排除故障，改善 Kubernetes 集群和应用程序的健康状况和性能。

持续监视和日志记录是检测对集群的攻击并在发生问题时进行故障诊断的关键。通过持续监视集群，可以更好地了解集群容量以及可供应用程序使用的资源的可用性。根据此洞察，您可以做好准备以避免应用程序发生中断。

选择监视解决方案

度量值可帮助您监视集群的运行状况和性能。您可以使用标准 Kubernetes 和容器运行时功能来监视集群和应用程序的运行状况。

IBM持续监视每个 Kubernetes 主节点。IBM Cloud Kubernetes Service 会自动扫描部署了 Kubernetes 主节点的每个节点，以查找在 Kubernetes 和特定于操作系统的安全修订中找到的漏洞。如果找到了漏洞，IBM Cloud Kubernetes Service 会自动代表用户应用修订并解决漏洞，以确保保护主节点。您负责监视和分析其余集群组件的日志。

为了避免在使用度量值服务时发生冲突，请确保各个资源组和区域上的集群具有唯一名称。

IBM Cloud® Monitoring: 通过将 Monitoring 代理程序部署到工作程序节点，获取应用程序和集群的性能和运行状况的操作可视性。代理程序收集 pod 和集群度量值，并将这些度量值发送到 IBM Cloud Monitoring。有关 IBM Cloud Monitoring的更多信息，请参阅服务文档。要在集群中设置 Monitoring 代理程序，请参阅使用 IBM Cloud Monitoring。
Kubernetes 仪表板: Kubernetes 仪表板是一个管理 Web 界面，可以在其中查看工作程序节点的运行状况，查找 Kubernetes 资源，部署容器化应用程序，以及使用日志记录和监视信息对应用程序进行故障诊断。有关如何访问 Kubernetes 仪表板的更多信息，请参阅启动 IBM Cloud Kubernetes Service 的 Kubernetes 仪表板。

将日志记录和监控代理迁移到云日志

不再支持可观察性 CLI 插件 ibmcloud ob 和 v2/observe 端点。目前还没有直接替代方案，但您现在可以通过控制台或 Helm 图表管理日志记录和监控集成。有关最新步骤，请参阅管理 IBM Cloud Kubernetes Service 集群的日志记录代理和使用 Kubernetes 监控代理。

您不能再使用 ob 插件、Terraform或API在集群上安装可观察性代理或修改现有配置。 Sysdig代理继续将指标发送到指定的 IBM Cloud Monitoring 实例。 LogDNA 代理无法再发送日志，因为已被 Logs取代。IBM Cloud Log Analysis IBM Cloud

检查您的可观察性代理

可观察性插件在 ibm-observe 命名空间中安装 Sysdig 和 LogDNA 代理。

登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。

查看 ibm-observe 命名空间中的配置映射。

kubectl get cm -n ibm-observe

Example output

NAME                                   DATA   AGE

e405f1fc-feba-4350-9337-e7e249af871c   6      25m

f59851a6-ede6-4719-afa0-eee7ce65eeb5   6      20m

由可观察性插件安装的可观察性代理使用配置映射，其中包含日志或指标发送到的 IBM Cloud Monitoring 实例或 IBM Cloud Log Analysis 实例的GUID。如果您的集群中的代理位于 ibm-observe 以外的命名空间中，或者 ibm-observe 中的配置映射未使用实例 GUID 命名，则这些代理未安装 IKS 可观测性 (ob) 插件。

移除可观察性插件代理

清理守护进程和配置文件。

kubectl delete daemonset logdna-agent -n ibm-observe
kubectl delete daemonset sysdig-agent -n ibm-observe
kubectl delete configmap <logdna-configmap> -n ibm-observe
kubectl delete configmap <sysdig-configmap> -n ibm-observe

可选：删除命名空间。在命名空间中没有其他资源可用之后。
```
kubectl delete namespace ibm-observe
```

移除插件后，使用集群仪表板、Terraform或手动在集群中重新安装记录和监控代理。

有关更多信息，请参阅以下链接：

设置 IBM Cloud® Monitoring 警报

设置警报时，请确保允许集群有足够的时间进行自我修复。由于 Kubernetes 具有自愈功能，因此请仅针对随时间推移而发生的问题配置警报。通过随时间推移观察集群，您可以了解 Kubernetes 可以自行解决哪些问题以及哪些问题需要警报以避免停机时间。

根据集群的大小，请考虑在以下级别设置警报:

应用程序
工作程序节点
集群
区域
帐户
Block Storage for VPC

在工作程序节点上设置 autorecovery 以使集群能够自动解决问题。

应用程序警报

查看以下应用程序级别度量值和警报阈值，以帮助在集群中设置应用程序监视。

要监视的常见应用程序级别条件包括:

将在 10 分钟内重新启动多个应用程序 pod 或容器。
应用程序的多个副本未在运行。
在 10 分钟内收到超过 10 个 5XX HTTP 响应代码。
名称空间中的多个 pod 处于未知状态。
无法在工作程序节点上调度超过 5 个 pod (暂挂状态)。

这些症状的根本问题包括:

一个或多个工作程序节点处于不正常状态。
工作程序节点已耗尽 CPU，内存或磁盘空间。
已达到每个集群的最大 pod 限制。
应用程序本身存在问题。

要为这些条件设置监视，请根据以下 IBM Cloud Monitoring 度量值配置警报。请注意，您的警报阈值可能会根据集群配置而更改。

应用程序级别度量
指标	IBM Cloud Monitoring 度量	警报阈值
在短时间内多次重新启动 pod。	`kubernetes_pod_restart_count`	在过去 10 分钟内大于 4
ReplicaSet中没有正在运行的副本。	`kube_replicaset_status_replicas` 在 `kubernetes_deployment_name` 中	不到一个。
集群中有超过 5 个 Pod 处于暂挂状态。	`kube_pod_container_status_waiting`	状态等于 `pending` 大于 5。
部署中没有可用的副本。	`kubernetes_deployment_replicas_available`	不到一个。
每个节点达到阈值 110 的 pod 数。	计数依据 `(kube_cluster_name,kube_node_name)(kube_pod_container_info)`	大于或等于 100。请注意，此查询是 `promQL` 查询。
处于未知状态的工作负载。	`(kube_workload_status_unavailable)`	大于或等于 1。请注意，此查询是 `promQL` 查询。

工作程序节点警报

查看工作程序节点的以下阈值和警报。

工作程序节点度量
指标	IBM Cloud Monitoring 度量	警报阈值
工作程序节点的 CPU 利用率超过阈值。	`cpu_used_percent`	1 小时大于 80%。
工作程序节点的 CPU 利用率超过阈值。	`cpu_used_percent`	24 小时超过 65%。
工作程序节点的内存利用率超过阈值。	`memory_used_percent`	1 小时大于 80%。
工作程序节点的内存利用率超过阈值。	`memory_used_percent`	24 小时超过 65%。
已用内存量超过阈值。	`memory_bytes_used`	大于 `NUMBER_OF_BYBTES`。
存在具有磁盘压力的节点。	`kube_node_status_condition`	大于或等于 1 10 分钟。
Kubernetes 节点未就绪。	`kube_node_status_ready >= 1`

解析工作程序节点警报

重新装入或重新引导工作程序可以解决此问题。但是，您可能需要添加更多工作程序以增加容量。

获取工作程序节点并查看状态。
```
kubectl get nodes
```
如果所有工作程序节点不处于 Ready 状态，请将工作程序节点添加到集群。
- 将工作程序节点添加到经典集群。
- 将工作程序节点添加到 VPC 集群。
如果所有工作程序节点都处于 Ready 状态，请重新装入或重新引导工作程序节点。
1. 描述工作程序节点，并查看事件部分以获取常见错误消息。
```
kubectl describe node <node>
```
2. 将不是 Ready 的节点封锁起来，以便您可以开始调查。
3. 清空工作程序节点。查看 Kubernetes 文档以安全地从工作程序节点中排出 pod。
```
kubectl drain <node>
```
4. 重新装入或重新引导工作程序节点。

区域警报

要设置区域级别警报，请编辑 sysdig-agent ConfigMap 以包含必需的标签过滤器。

运行以下命令编辑 ConfigMap。

kubectl edit configmap sysdig-agent -n ibm-observe

在 k8s_cluster_name: <cluster_name> 之后添加以下 YAML 块。将 <cluster_name> 替换为要监视的集群的名称。

k8s_labels_filter:
  - include: "kubernetes.node.label.kubernetes.io/hostname"
  - include: "kubernetes.node.label.kubernetes.io/role"
  - include: "kubernetes.node.label.ibm-cloud.kubernetes.io/zone"
  - exclude: "*.kubernetes.io/*"
  - exclude: "*.pod-template-hash"
  - exclude: "*.pod-template-generation"
  - exclude: "*.controller-revision-hash"
  - include: "*"

重新启动 IBM Cloud Monitoring pod。删除所有 pod 并等待其重新启动。获取 pod 的列表。
```
kubectl get pods -n ibm-observe
```

删除 pod 以重新启动它们。

kubectl delete pods sysdig-agent-1111 sysdig-agent-2222 sysdig-agent-3333 -n ibm-observe

等待 5 分钟以重新启动 pod。重新启动 pod 后，先前添加的标签在 IBM Cloud Monitoring 中可用
通过打开 IBM Cloud Monitoring 仪表板 > Explore > PromQL 查询来验证现在是否显示标签。
在查询字段中输入 kube_node_labels，然后单击 Run Query。

区域级别警报
指标	PromQL 查询
每个区域的 CPU 使用率超过阈值	`sum(sysdig_container_cpu_used_percent{agent_tag_cluster="<cluster_name>"}) by (kube_node_label_ibm_cloud_kubernetes_io_zone) / sum (kube_node_info) by (kube_node_label_ibm_cloud_kubernetes_io_zone) > 80`
每个专区的内存使用率超过阈值	`sum(sysdig_container_cpu_used_percent{agent_tag_cluster="<cluster_name>"}) by (kube_node_label_ibm_cloud_kubernetes_io_zone)/ sum (kube_node_info) by (kube_node_label_ibm_cloud_kubernetes_io_zone) > 80`

集群警报

查看以下用于在集群级别创建警报的示例阈值。

区域中的所有工作程序节点都达到容量阈值 80%。
超过 50% 的工作程序节点处于不正常状态。
达到每个帐户的最大文件和块存储卷数 (250)。
达到每个集群的最大工作程序节点数 (500)。

帐户警报

您可以在每个帐户的最大集群数达到限制时设置警报。例如，每个区域/基础架构提供者 100 个。

Block Storage for VPC 警报

以下度量可用于 Block Storage for VPC 警报:

kubelet_volume_stats_available_bytes
kubelet_volume_stats_capacity_bytes
kubelet_volume_stats_inodes
kubelet_volume_stats_inodes_free
kubelet_volume_stats_inodes_used

为 Block Storage for VPC 警报创建监视实例。请参阅 Forwarding cluster and app metrics to IBM Cloud Monitoring 中的说明。
安装 syslog 代理。
1. 在 IBM Cloud 控制台中，从菜单中选择 可观察性。
2. 选择监视。
3. 在 Block Storage for VPC 警报的实例行中，选择 打开仪表板。
4. 从菜单中，选择入门。
5. 在 安装代理程序 部分下，选择 添加源。
6. 按照说明安装代理。
7. 确保代理程序正在使用 kubectl get pods -n CLUSTER_NAME | grep syslog 命令运行。
配置通知通道。
1. 在 IBM Cloud“监视”仪表板中，选择 监视操作> 设置。
2. 选择 通知通道 > 添加通知通道 并选择其中一种可用通知方法。
3. 完成新通道的设置，然后单击保存。
4. 可选：重复前面的步骤添加更多通道。
创建警报。
1. 在 IBM Cloud“监视”仪表板中，选择警报 > 库。
2. 选择其中一个模板，然后选择 启用警报。例如，您可以搜索 PVC storage 并启用 PVC Storage Usage Is Reaching The Limit 警报。
3. 定制模板上的警报设置，然后选择 启用警报 以应用设置。

如果 Block Storage for VPC 卷正在达到容量，那么可以设置卷扩展。

使用自动恢复功能监控工作节点的运行状况

自动恢复系统会使用各种检查来查询工作程序节点的运行状态。如果 Autorecovery 根据配置的检查检测到运行状况不佳的工作程序节点，那么 Autorecovery 会触发纠正操作，例如重新引导 VPC 工作程序节点或在经典工作程序节点中重新装入操作系统。一次只会对一个工作程序节点执行更正操作。该工作节点必须在其他工作节点执行纠正操作之前完成纠正操作。

自动恢复需要至少一个健康的工作节点才能正常运行。仅在具有两个或两个以上工作程序节点的集群中，将自动恢复配置为执行主动检查。

开始之前：

确保您具有以下 IBM Cloud IAM 角色：
- 群集的管理员平台访问角色
- 编写者或经理服务访问角色 kube-system 命名空间
登录您的账户。如果适用，请将相应的资源组设定为目标。设置集群的上下文。

要配置自动恢复，请执行以下操作：

遵循指示信息在本地机器上安装 Helm V 3 客户机。

创建配置映射文件以通过 JSON 格式定义检查。例如，以下 YAML 文件定义了三项检查：一项 HTTP 检查和两项 Kubernetes API 服务器检查。请参阅组件说明和健康检查组件表，了解三种检查的信息以及检查的各个组件的信息。

在配置映射的 data 部分，将每个检查定义为唯一的键。

kind: ConfigMap
apiVersion: v1
metadata:
  name: ibm-worker-recovery-checks
  namespace: kube-system # The `kube-system` namespace is a constant and can't be changed.
data:
  checknode.json: |
    {
      "Check":"KUBEAPI",
      "Resource":"NODE",
      "FailureThreshold":3,
      "CorrectiveAction":"RELOAD",
      "CooloffSeconds":1800,
      "IntervalSeconds":180,
      "TimeoutSeconds":10,
      "Enabled":true
    }
  checkpod.json: |
    {
      "Check":"KUBEAPI",
      "Resource":"POD",
      "PodFailureThresholdPercent":50,
      "FailureThreshold":3,
      "CorrectiveAction":"RELOAD",
      "CooloffSeconds":1800,
      "IntervalSeconds":180,
      "TimeoutSeconds":10,
      "Enabled":true
    }
  checkhttp.json: |
    {
      "Check":"HTTP",
      "FailureThreshold":3,
      "CorrectiveAction":"REBOOT",
      "CooloffSeconds":1800,
      "IntervalSeconds":180,
      "TimeoutSeconds":10,
      "Port":80,
      "ExpectedStatus":200,
      "Route":"/myhealth",
      "Enabled":false
    }

在集群中创建配置映射。

kubectl apply -f ibm-worker-recovery-checks.yaml

使用相应检查来验证是否已在 ibm-worker-recovery-checks 名称空间中创建名称为 kube-system 的配置映射。
```
kubectl -n kube-system get cm ibm-worker-recovery-checks -o yaml
```

通过安装 ibm-worker-recovery Helm chart，将自动恢复部署到集群中。

helm install ibm-worker-recovery iks-charts/ibm-worker-recovery --namespace kube-system

过几分钟后，可以检查以下命令的输出中的 Events 部分，以查看自动恢复部署上的活动。
```
kubectl -n kube-system describe deployment ibm-worker-recovery
```
如果在自动恢复部署上看不到活动，可以通过运行自动恢复图表定义中的测试来检查 Helm 部署。
```
helm test ibm-worker-recovery -n kube-system
```

了解配置映射的组成部分

查看有关运行状况检查的各个组件的以下信息。

name:配置名称 ibm-worker-recovery-checks 是一个常量，不能更改。
namespace: kube-system 命名空间是一个常量，不能更改。
checknode.json:定义 Kubernetes API 节点检查，用于检查每个工作节点是否处于 Ready 状态。如果特定工作节点不在 Ready 状态，则对该工作节点的检查算作失败。示例 YAML 中的检查每 3 分钟运行一次。如果连续失败三次，将重新装入该工作程序节点。该操作等同于运行 ibmcloud ks worker reload。节点检查启用，直到您将启用字段设置为 false 或删除检查。请注意，仅经典基础架构上的工作程序节点支持重新装入。
checkpod.json:定义 Kubernetes API pod 检查，根据分配给工人节点的 pod 总数，检查工人节点上 NotReady pod 的总百分比。如果 NotReady pod 的总百分比大于定义的 PodFailureThresholdPercent，则对特定工作节点的检查算作失败。示例 YAML 中的检查每 3 分钟运行一次。如果连续失败三次，将重新装入该工作程序节点。该操作等同于运行 ibmcloud ks worker reload。例如，缺省值 PodFailureThresholdPercent 为 50%。如果 NotReady pod 的百分比连续三次大于 50%，那么将重新装入工作程序节点。缺省情况下，此检查在所有名称空间上运行。要将检查限制为只检查指定命名空间中的 pod，请在检查中添加 Namespace 字段。 pod 检查启用，直到您将启用字段设置为 false 或删除检查。请注意，仅经典基础架构上的工作程序节点支持重新装入。
checkhttp.json:定义 HTTP 检查，用于检查在工作节点上运行的 HTTP 服务器是否健康。要使用此检查，必须使用守护进程集在群集中的每个工作节点上部署 HTTP 服务器。您必须在 /myhealth 路径上实施健康检查，以验证 HTTP 服务器是否健康。您可以通过更改 Route 参数定义其他路径。如果 HTTP 服务器健康，则必须返回 ExpectedStatus 中定义的 HTTP 响应代码。必须将 HTTP 服务器配置为侦听工作程序节点的专用 IP 地址。您可以运行 kubectl get nodes 查找专用 IP 地址。例如，假设集群中有两个节点，其专用 IP 地址分别为 10.10.10.1 和 10.10.10.2。在本例中，对两个路由进行了检查，以获得 200 HTTP 的响应：http://10.10.10.1:80/myhealth 和 http://10.10.10.2:80/myhealth。示例 YAML 中的检查每 3 分钟运行一次。如果连续失败三次，将重新引导该工作程序节点。该操作等同于运行 ibmcloud ks worker reboot。 HTTP 检查被禁用，直到您将启用字段设置为 true。

了解健康检查的各个组成部分

请查看下表以获取有关运行状况检查的各个组件的信息。

运行状况检查组件
组件	描述
`Check`	输入您希望 Autorecovery 使用的检查类型。 `HTTP` ：自动恢复调用每个节点上运行的 HTTP 服务器，以确定节点是否正常运行。 `KUBEAPI` ：自动恢复会调用 Kubernetes API 服务器，并读取工作节点报告的健康状态数据。
`Resource`	当检查类型为 `KUBEAPI` 时，输入您希望 Autorecovery 检查的资源类型。可接受的值是 `NODE` 或 `POD`。
`FailureThreshold`	输入检查连续失败次数的阈值。达到此阈值时，自动恢复会触发指定的更正操作。例如，如果值为 3 且自动恢复连续三次执行配置的检查失败，那么自动恢复会触发与检查关联的更正操作。
`PodFailureThresholdPercent`	当资源类型为 `POD` 时，请输入工作者节点上处于以下状态的 pod 的百分比阈值 NotReady 状态的 pod 所占百分比的阈值。此百分比基于安排到一个工作程序节点的 pod 总数。检查确定运行状况欠佳的 pod 百分比大于阈值时，该检查计为一次失败。
`CorrectiveAction`	输入在达到失败阈值时要运行的操作。只有当没有其他工人正在维修，且该工人节点未处于上一次操作的冷却期时，纠正操作才会运行。 `REBOOT` ：重新引导工作程序节点。 `RELOAD`: 从一个干净的操作系统为工作节点重新加载所有必要的配置。
`CooloffSeconds`	输入自动恢复在对节点发出更正操作后，必须等待多长时间才能再次向该节点发出其他更正操作（以秒为单位）。等待期自发出更正操作时开始计算。
`IntervalSeconds`	输入连续检查之间的间隔秒数。例如，如果值为 180，那么自动恢复会每 3 分钟对每个节点运行一次检查。
`TimeoutSeconds`	输入在自动恢复终止调用操作之前，对数据库执行检查调用所用的最长时间（以秒为单位）。 `TimeoutSeconds` 的值必须小于 `IntervalSeconds` 的值。
`Port`	当检查类型为 `HTTP` 时，输入 HTTP 服务器必须绑定到工作节点上的端口。此端口必须在集群中每个工作程序节点的 IP 上公开。自动恢复需要一个跨所有节点的常量端口号以用于检查服务器。将自定义服务器部署到群集中时，请使用守护进程集。
`ExpectedStatus`	当检查类型为 `HTTP` 时，输入您希望从检查返回的 HTTP 服务器状态。例如，值为 200 表示您希望服务器作出 `OK` 的响应。
`Route`	当检查类型为 `HTTP` 时，输入从 HTTP 服务器请求的路径。该值通常是在所有工作节点上运行的服务器的度量路径。
`Enabled`	输入 `true` 可启用检查，输入 `false` 可禁用检查。
`Namespace`	可选：要限制 `checkpod.json` 只能检查一个命名空间中的 pod，请添加 `Namespace` 字段并输入命名空间。