## Pod 容忍节点异常时间调整 ### 1. 原理说明 Kubernetes 集群节点处于异常状态之后需要有一个等待时间，才会对节点上的 Pod 进行驱逐。那么针对部分关键业务，是否可以调整这个时间，便于在节点发生异常时及时将 Pod 驱逐并在别的健康节点上重建？ 要解决这个问题，我们首先要了解 Kubernetes 在节点异常时驱逐 Pod 的机制。 在 Kubernetes 1.13 那么，节点发生异常到 Pod 被驱逐的时间，就取决于两个参数：1. 节点实际异常到被判断为不健康的时间；2. Pod 对节点不健康的容忍时间。 Kubernetes 集群中默认节点实际异常到被判断为不健康的时间为 40s, Pod 对节点 NotReady 的容忍时间为 5min, 也就是说, 节点实际异常 5min40s(340s) 后, 节点上的 Pod 才会发生驱逐。 ### 2. 调整节点被标记为不健康的时间 调整节点被标记为不健康的时间 ControllerManager 参数 --node-monitor-grace-period 控制了在将一个节点标记为不健康之前允许其无响应的时长上限，该参数默认值为 40s，且必须比 Kubelet 的 nodeStatusUpdateFrequency 参数 (Kubelet 向主控节点汇报节点状态的时间间隔) 大 N 倍；这里 N 指的是 kubelet 发送节点状态的重试次数。

e3a7db198e/p9_14.jpg) 智能小程序 ## 摇一摇红包系统 - 每秒数千万用户并发 ✓+内部逻辑放大 - 单个分布式巨型系统？ ✓问题：子系统扩展性瓶颈 ✓问题：故障容忍能力 ✓问题：测试与验证的复杂性 - 以大化小（以巨化大），SET化 ✓条带化，多个单元化集群 ✓业务优化适配 ✓可防止故障扩散 ✓更可控的预案 接入 扩展 → 业务 扩展 → 存储 弹性架构：高效支撑更高的瞬间并发  ✓多级异常容忍能力，自适应，层级化自治 · 动态参数，自适应 • 预测，online结合nearline召回 能屈能伸： ✓高效简化版本，实现过载兜底 ✓周边极致优化，无短板 Best Effort模式

和内存限值 65 4.6.1. 配置 CPU 和内存限值 66 4.7. 使用容忍度来控制 OPENSHIFT LOGGING POD 放置 67 4.7.1. 使用容忍度来控制日志存储 pod 放置 68 4.7.2. 使用容忍度来控制日志可视化 pod 放置 69 4.7.3. 使用容忍度来控制日志收集器 pod 放置 70 4.7.4. 其他资源 71 4.8. 使用节点选择器移动 Elasticsearch 节点上。ClusterLogging 自定义资源（CR）允许您指定如何复制分片，以提供数据冗余和故障恢复能力。您还可以使用ClusterLogging CR中的保留策略来指定不同类型的日志的保留的时长。  ## 注意 索引模板的主分片数量等于 的更多信息，请参阅 使用 Log Forwarding API 转发日志。 ##### 4.3.2. 配置日志保留时间 您可以配置保留策略，指定默认 Elasticsearch 日志存储保留三个日志源的索引的时长：基础架构日志、应用程序日志和审计日志。 要配置保留策略，您需要为 ClusterLogging 自定义资源 (CR) 中的每个日志源设置 maxAge 参数。CR 将这些值应用到 ElasticSearch

4.5. 配置 OPENSHIFT LOGGING 存储 ..... 95 4.6. 为 OPENSHIFT LOGGING 组件配置 CPU 和内存限值 ..... 95 4.7. 使用容忍度来控制 OPENSHIFT LOGGING POD 放置 ..... 97 4.8. 使用节点选择器移动 OPENSHIFT LOGGING 资源 ..... 101 4.9. 配置 SYSTEMD-JOURNALD 节点上。ClusterLogging 自定义资源（CR）允许您指定如何复制分片，以提供数据冗余和故障恢复能力。您还可以使用 ClusterLogging CR 中的保留策略来指定不同类型的日志的保留的时长。  ## 注意 索引模板的主分片数量等于 的更多信息，请参阅使用 Log Forwarding API 转发日志。 ##### 4.3.2. 配置日志保留时间 您可以配置保留策略，指定默认 Elasticsearch 日志存储保留三个日志源的索引的时长：基础架构日志、应用程序日志和审计日志。 要配置保留策略，您需要为 ClusterLogging 自定义资源 (CR) 中的每个日志源设置 maxAge 参数。CR 将这些值应用到 ElasticSearch

公里的商家全部检索出来，检索后序列的平均长度如下表 1 所示，根据离线实验评估，最终选择 distance km 检索来建模用户的地理位置偏好。公里数 C 这个参数是根据业务经验统计得到的超参，考虑到不同的用户对于距离的容忍度可能是不一样的，如何对不同的用户在不同的情境下对该超参进行调整，还在积极探索中。 - 对于时段偏好的建模尝试了两种检索方式：从用户的历史行为中，将与当前请求的 meal_time（根据业务将一天 23pp|+0.48pp| 引入大数量级 Experts 的 MMOE 结构可带来较显著的离线收益，但同时也会相应带来离线训练以及线上服务成本的增加，需要做效果与效率之间的权衡。我们在保持一定离线训练时长与在线 Latency 约束下，选择了 4Experts MMOE 版本作为新的基线模型，并做详细的探索，进行较为细致的优化，包括： · 引入残差连接：受 Switch Transformer $ 在端上部署了智能推荐系统，取得较为显著收益（EdgeRec $ ^{[1]} $ ，双十一 IPV 提升 10%+，GMV 提升 5%+）。快手上下滑推荐场景也应用了端上重排的方案，并取得 App 时长提升了 1%+ 的效果。 搜索是大众点评 App 连接用户与商家的重要渠道，越来越多的用户在不同场景下都会通过搜索来获取自己想要的服务。理解用户的搜索意图，将用户最想要结果排在靠前的位置，是搜索引

18-Demon Set 1.19 19-配置最佳实践 1.20 20-管理容器的计算资源 1.21 21-Kubernetes资源分配 1.22 22-将Pod分配到Node 1.23 23-容忍与污点 1.24 24-Secret 1.25 25-Pod优先级和抢占 1.26 26-Service 1.27 27-Ingress Resources 1.28 28-动态水平扩容 n=true 。一旦启用 TaintNodesByCondition，scheduler将会忽略选择Node时的condition；而是看Node的taint（污点）和Pod的toleration（容忍度）。 译者按： 1. “taints and tolerations”的功能是允许你标注（taint）Node，那样Pod就不会调度到这个Node上，除非Pod明确“tolerates”这个“taint”。 csdn.net/jettery/article/details/69500150 现在用户可在旧调度模型和新的更灵活的调度模型之间选择。没有toleration（容忍度）的Pod根据旧的模型进行调度。但是，对特定Node能够容忍污点（tolerates the taints）的Pod可被调度到该Node。 请注意，由于延迟时间小，通常少于1秒，在观察condition和产生污点的时间段内，启

磁盘卷的最大数量。 {"name": "MaxAzureDiskVolumeCount"} PodToleratesNodeTaints predicate 检查 pod 是否可以容忍节点污点。 {"name": "PodToleratesNodeTaints"} CheckNodeUnschedulable predicate 会检查 pod {"name": "checkServiceAffinity"} PodToleratesNodeNoExecuteTaints predicate 检查 pod 容限是否容忍节点 NoExecute 污点。 {"name": "PodToleratesNodeNoExecuteTaints"} 3.2.3.1.2. 常规 predicates ity", "weight": 1} TaintTolerationPriority 优先级为 pod 优先选择那些在节点上具有较少 intolerable（不可容忍）污点的节点。不可容忍的污点是具有 PreferNoSchedule 键的污点。 {"name": "TaintTolerationPriority", "weight":

## 更多信息，请参考用户文档。 ## · 建表性能提升 10 倍（实验特性）#49752 @gmhdbjd 在之前的版本里，将上游数据库上万张表迁移到 TiDB 时，TiDB 创建这些表耗时长，效率低。从 v7.6.0 开始，引入了新的 TiDB DDL V2 架构，你可以通过设置系统变量 $ tidb\_ddl\_version $ 开启。相比之前的版本，新版本的 DDL 批量建表性能提升了高达 场景的集成测试，提升 PITR 稳定性 #47738 @Leavrth * 提升了 RESTORE 语句在大数据量表场景下的建表性能 #48301 @Leavrth * 重构 BR 异常处理机制，提高对未知错误的容忍度 #47656 @3pointer ## - TiCDC * 通过增加并行，优化了 TiCDC 同步数据到对象存储的性能 #10098 @CharlesCheung96 * 支持通过在 sink-uri TiDB，请参考 TiDB Cloud 快速上手指南。 要快速了解 TiUP 的基本功能、使用 TiUP 快速搭建 TiDB 集群的方法与连接 TiDB 集群并执行 SQL 的方法，建议先观看下面的培训视频（时长 15 分钟）。注意本视频只作为学习参考，如需了解 TiUP 的具体使用方法和 TiDB 快速上手具体操作步骤，请以文档内容为准。 #### 3.1.1 部署本地测试集群 - 适用场景：利用本地

TiDB，请参考 TiDB Cloud 快速上手指南。 要快速了解 TiUP 的基本功能、使用 TiUP 快速搭建 TiDB 集群的方法与连接 TiDB 集群并执行 SQL 的方法，建议先 观看下面的培训视频（时长 15 分钟）。注意本视频只作为学习参考，如需了解TiUP 的具体使用方法和TiDB 快 速上手具体操作步骤，请以文档内容为准。 3.1.1 部署本地测试集群 • 适用场景：利用本地 macOS 或者单机 注意： 如果你对 TiDB HTAP 功能还不太了解，希望快速试用体验，请参阅快速上手 HTAP。 要快速了解 TiDB 在 HTAP 场景下的体系架构与 HTAP 的适用场景，建议先观看下面的培训视频（时长 15 分钟）。 注意本视频只作为学习参考，如需了解详细的 HTAP 相关内容，请参阅下方的文档内容。 3.4.1 HTAP 适用场景 TiDB HTAP 可以满足企业海量数据的增产需求、降低运维的 上面的例子创建了一张表 t1，并指定了 created_at 为 TTL 的时间列，表示数据的创建时间。同时，它 还通过 INTERVAL 3 MONTH 设置了表中行的最长存活时间为 3 个月。超过了此时长的过期数据会在之后 被删除。 • 设置 TTL_ENABLE 属性来开启或关闭清理过期数据的功能： CREATE TABLE t1 ( id int PRIMARY KEY, created_at TIMESTAMP

TiDB，请参考 TiDB Cloud 快速上手指南。 要快速了解 TiUP 的基本功能、使用 TiUP 快速搭建 TiDB 集群的方法与连接 TiDB 集群并执行 SQL 的方法，建议先 观看下面的培训视频（时长 15 分钟）。注意本视频只作为学习参考，如需了解TiUP 的具体使用方法和TiDB 快 速上手具体操作步骤，请以文档内容为准。 3.1.1 部署本地测试集群 • 适用场景：利用本地 macOS 或者单机 注意： 如果你对 TiDB HTAP 功能还不太了解，希望快速试用体验，请参阅快速上手 HTAP。 要快速了解 TiDB 在 HTAP 场景下的体系架构与 HTAP 的适用场景，建议先观看下面的培训视频（时长 15 分钟）。 注意本视频只作为学习参考，如需了解详细的 HTAP 相关内容，请参阅下方的文档内容。 92 3.4.1 HTAP 适用场景 TiDB HTAP 可以满足企业海量数据的增产需求 上面的例子创建了一张表 t1，并指定了 created_at 为 TTL 的时间列，表示数据的创建时间。同时，它 还通过 INTERVAL 3 MONTH 设置了表中行的最长存活时间为 3 个月。超过了此时长的过期数据会在之后 被删除。 284 • 设置 TTL_ENABLE 属性来开启或关闭清理过期数据的功能： CREATE TABLE t1 ( id int PRIMARY KEY, created_at