《Kubernetes设计与实现》
  • Introduction
  • 内容简介
  • 前言
  • [第二章:Kubernetes基础]
    • 2.3 Kubernetes API
  • [第三章:工作负载管理]
    • [3.1 Pod]
      • 3.1.1 Pod概述
      • 3.1.1 Pod初体验
    • [3.2 ReplicationController]
      • 3.2.1 ReplicationController概述
      • 3.2.2 ReplicationController初体验
    • [3.3 ReplicaSet]
      • 3.3.1 ReplicaSet概述
      • 3.3.2 ReplicaSet初体验
    • [3.4 Deployment]
      • 3.4.1 Deployment概述
      • 3.4.2 Deployment初体验
    • [3.5 DaemonSet]
      • 3.5.1 DaemonSet概述
      • 3.5.2 DaemonSet初体验
  • [第四章:服务]
    • [4.1 Service]
      • 4.1.1 Service概述
      • 4.1.1 Service上手体验
  • [第六章:配置管理]
    • [6.1 Secret--机密信息管理]
      • 6.1.1 Secret概述
  • [第七章:集群认证]
    • [7.1 证书]
      • 7.1.1 证书基础
      • 7.1.2 证书签发流程
  • [第九章:准入控制器]
    • [9.1 准入控制器概述]
      • 9.1.1 概述
      • [9.1.2 内置默认启动的插件]
        • 9.1.2.1 NamespaceLifecycle
        • 9.1.2.15 MutatingAdmissionWebhook
  • [第十章:ResourceQuota]
    • 10.1 ResourceQuota概述
  • [第十六章:API设计约定]
    • 16.1 字段可选性设计约定
    • 16.2 condition设计约定
    • 16.3 event设计约定
  • [第十九章:Kubernetes生态]
    • [19.1 Kind]
      • [19.1.1 Kind概述]
      • 19.1.2 映射端口到主机
      • 19.1.3 配置端口转发
由 GitBook 提供支持
在本页
  • 导读
  • Event设计约定

这有帮助吗?

  1. [第十六章:API设计约定]

16.3 event设计约定

导读

当设计API扩展及实现其控制器时,如何设计events和status?什么样的信息需要放到status中,什么样的信息需要放到events中?

Event设计约定

event的设计初衷是为status提供一个补充,与status不同的是,event可以提供历史信息。与status类似的是,event也由控制器维护。那么什么时候需要报告event?需要报告什么信息呢?

当控制器观测到资源的某个状态(正常状态或异常状态)时,如果需要用户或管理员注意,那就需要报告事件。 报告的事件,通常包含3个信息:

  • reason:事件名称

  • type:事件类型(或事件等级),可以为”Normal“或”Warning“

  • message: 事件详细描述信息

事件类型当前只有Normal和Warning可选,将来如有必要可以扩展出新的类型,比如Critical来表示更严重的信息。事件名称使用驼峰风格表示,名字尽量简短,但信息量也要充足,避免使用极简的名称,比如"Failed",至少也要使用”xxxFailed“,指出到底是什么出错了。

上一页16.2 condition设计约定下一页[第十九章:Kubernetes生态]

最后更新于4年前

这有帮助吗?