时间之旅

参考：Ingress | Kubernetes、《Kubernetes进阶实战》、《Kubernetes网络权威指南 》 何谓Ingress？从字面意思解读，就是入站流量。Kubernetes的Ingress资源对象是指授权入站连接到达集群内服务的规则集合。 我们知道，Kubernetes上的NodePort和LoadBalancer类型的Service资源能够把集群内部服务暴露给集群外部客户端访问，但两个负载均衡跃点(路由)必然产生更大的网络延迟，且无疑会大大增加组织在使用云服务方面的费用开销。 因此，Kubernetes为这种需求提供了一种更为高级的流量管理约束方式，尤其是对HTTP/HTTPS协议的约束。Kubernetes使用Ingress控制器作为统一的流量入口，管理内部各种必要的服务，并通过Ingress这一API资源来描述如何区分流量以及内部的路由逻辑。有了Ingress和Ingress控制器，我们就可通过定义路由流量的规则来完成服务发布，而无须创建一堆NodePort或LoadBalancer类型的Service，而且流量也会由Ingress控制器直接到达 ...

参考：Service | Kubernetes、《Kubernetes进阶实战》 有了 Workload，我们可以方便地管理多实例的应用，但是要想能够方便地访问应用，我们还需要一个类似于 负载均衡 的资源来分发请求，在 kubernetes 中，有两个资源负责这个功能，分别是 Service 以及 Ingress。其中 Service 主要负责集群内部的访问，而 Ingress 主要负责来自集群外部的访问。 Kubernetes Service从逻辑上代表了一组Pod(通常称为微服务)，具体是哪些Pod则是由label来挑选的(selector)。Service有自己的IP，而且这个IP是不变的。客户端只需要访问Service的IP，Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化，对客户端不会有任何影响，因为Service没有变。 举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化， 前端客户端不应该也没必要知道， ...

参考：《深入理解Zabbix监控系统》、《Zabbix用户手册》 Zabbix服务端进程被分为不同的种类，每一种进程负责相应的任务，包括收集原始监控数据、对原始监控数据进行预处理、将预处理后的监控数据同步到数据库、对监控数据进行计算以生成事件、计算和获取内部监控数据，以及对数据库中的数据进行清理等。 监控数据的收集进程Zabbix服务器的重要任务之一就是被动接收由Zabbix代理和各种Zabbix客户端发送的监控数据，以及主动向Zabbix代理、Zabbix java gateway和Zabbix客户端等数据源请求数据，其中被动接收数据由trapper类进程实现，主动请求数据则由poller类进程实现。 trapper类进程通过监听TCP套接字来捕获符合通信协议的原始监控数据，poller类进程则使用ConfigCache作为输入，根据缓存信息实现完善的任务调度。trapper类和poller类进程的下游是预处理进程，这两类进程需要将收集到的原始监控数据发送到预处理进程。trapper类进程和poller类进程都会在进程内部维护一个静态变量cached_message，用于暂存待发 ...

除了创建，Deployment 提供的另一个重要的功能就是更新应用，这是一个比创建复杂很多的过程。想象一下在日常交付中，在线升级是一个很常见的需求，同时应该尽量保证不能因为升级中断服务。这就要求我们必须使用一定的策略来决定何时创建新的 Pod，何时删除旧版本的 Pod。kubectl 支持滚动升级的方式，每次更新一个pod，而不是同时删除整个服务。 前置知识回顾知识： Kubernetes：总结(一) Kubernetes：总结(二) 命令格式： 1kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N 例如： 123456789101112Examples: # Set a deployment's nginx container image to 'nginx:1.9.1', and its busybox container image to 'busy ...

本部署文档适用于 CentOS 8.X/RHEL 8.X/Anolis OS 8.X/AlmaLinux 8.X/Rocky Linux 8.X。 原生的HA方案终于来了😀 相比之前的 Keepalived 方案，原生方案配置简单了不少。 Zabbix HA 最少需要2个 Zabbix Server 节点即可实现HA集群高可用及故障转移。在同一个 Zabbix HA 集群中，只有一个实例或节点处于 active（活动）状态，standby（备用）节点不进行数据收集、处理或其他任务，并且不监听端口，并保持一个最少的数据库连接。 HA节点分为以下几种状态： Active（活动） Standby（备用） Unavailable（不可用） Stopped（停止） 中文版界面将Active翻译成主动式，并不是很准确。 关于TimescaleDB当数据保存在 Zabbix 服务器内存中时还好，但是当数据需要写入数据库 (或从数据库中读取) 时，无论多么好的缓存和算法,如果数据库性能严重低于收集指标的速度，这些算法都是没有任何帮助的。 监控系统中 ...

本部署文档适用于CentOS 8.X/RHEL 8.X/Anolis OS 8.X/AlmaLinux 8.X/Rocky Linux 8.X。 Zabbix 6.0 LTS于2022年2月15日发布，本次大版本更新，最大亮点是增加了原生HA、机器学习、Kubernetes监控等。 Requirements硬件要求 Name Platform CPU/Memory Database Monitored hosts Small CentOS Virtual Appliance MySQL InnoDB 100 Medium CentOS 2 CPU cores/2GB MySQL InnoDB 500 Large RedHat Enterprise Linux 4 CPU cores/8GB RAID10 MySQL InnoDB or PostgreSQL >1000 Very large RedHat Enterprise Linux 8 CPU cores/16GB Fa ...

关于panthlib模块pathlib模块提供表示文件系统路径的类，其语义适用于不同的操作系统。路径类被分为提供纯计算操作而没有 I/O 的纯路径，以及从纯路径继承而来但提供 I/O 操作的具体路径。 以下是一个映射了 os 与 PurePath/Path 对应相同的函数的表。 💡注意：尽管 os.path.relpath() 和 PurePath.relative_to() 拥有相同的重叠的用例，但是它们语义相差很大，不能认为它们等价。 os 和 os.path pathlib os.path.abspath() Path.resolve() os.chmod() Path.chmod() os.mkdir() Path.mkdir() os.makedirs() Path.mkdir() os.rename() Path.rename() os.replace() Path.replace() os.rmdir() Path.rmdir() os.remove(), os.unlink() Path.unlink( ...

应用在运行过程中难免会出现错误，如程序异常、软件异常、硬件故障、网络故障等。因此，系统通过一些手段来判断应用是否运行正常，这些手段称之为健康检查(诊断)。 前置知识回顾一下Pod的生命周期： 检查机制(Check mechanisms)有以下几种方法来检查容器： exec：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。 gRPC：使用gRPC执行远程过程调用。目标应该实施gRPC运行状况检查。如果响应的状态为SERVING，则认为诊断成功。gRPC检查是一项Alpha功能，仅当您启用GRPCContainerProbe时才可用。 httpGet：对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。 tcpSocket：对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。 每次探测都将获得以下三种结果之一： Success（成功）：容器通过了诊断。 Failure（失败）：容器未通过诊断。 Unknown（未知）：诊断失败，因此不会采取任何 ...

A Container is guaranteed to have as much memory as it requests, but is not allowed to use more memory than its limit. 概念资源需求：定义需要系统预留给该容器使用的资源最小可用值，容器运行时可能用不到这些额度的资源，但用到时必须确保有相应数量的资源可用。 资源限制(约束)：定义该容器可以申请使用的资源最大可用值，超出该额度的资源使用请求将被拒绝；显然，该限制需要大于等于requests的值，但系统在某项资源紧张时，会从容器回收超出request值的那部分。 一般来讲，资源需求 <= 资源限制。 💡Tips：如果某 Container 设置了自己的内存限制但未设置内存请求，Kubernetes 自动为其设置与内存限制相匹配的请求值。 单位在Kubernetes上，可由容器或Pod请求与消费的资源主要是指CPU和内存（RAM），它可统称为计算资源。 计算资源的数量是可测量的，可以被请求、被分配、被消耗。 CPU属于可压缩型资源，即资源额度可按需弹性 ...

承接上文。 在实际的生产使用场景中，直接用 Pod 是不合适的，因为必然会产生单点故障。因此，我们需要有一种方法来方便地创建、管理同一个服务的多个实例 Pod。Kubernetes 中引入了 Workload(工作负载) 的概念，它可以理解为 Pod 的父资源，主要的作用就是来管理多个 Pod 的生命周期。 Workload资源主要分为以下几类： Deployment 和 ReplicaSet ：最常见的类型，用来管理集群上的无状态应用。 DaemonSet：在集群的每个节点上部署一个 Pod，适用于各种 agent 业务的场景。 such as a networking helper tool, or be part of an add-on. StatefulSet：适用于各种有状态服务的场景。 例如，如果负载会将数据作持久存储，可以运行一个 StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来。 Job 和 CronJob： 用于一些自动化任务。Job 用来表达的是一次性的任务，而 CronJob 会根据其时间规划反复运行。 接下来将详细 ...