kubernetes

kubernetes 实用技巧: 使用 ksniff 抓包

介绍如何使用 kubectl 的 sniff 插件快速抓包

Kubernetes 特性调研: Sidecar Containers

介绍 Sidecar Containers 特性背景、历史、当前进展以及一点思考

打造云原生大型分布式监控系统(四): Kvass+Thanos 监控超大规模容器集群

目录 概述 有 Thanos 不够吗 ? 什么是 Kvass ? 部署实践 部署准备 部署 Kvass 部署 thanos-query 小结 概述 继上一篇 Thanos 部署与实践 发布半年多之后,随着技术的发展,本系列又迎来了一次更新。本文将介绍如何结合 Kvass 与 Thanos,来更好的实现大规模容器集群场景下的监控。

Nginx Ingress 高并发实践

目录 概述 内核参数调优 调大连接队列的大小 扩大源端口范围 TIME_WAIT 复用 调大最大文件句柄数 配置示例 全局配置调优 调高 keepalive 连接最大请求数 调高 keepalive 最大空闲连接数 调高单个 worker 最大连接数 配置示例 总结 参考资料 概述 Nginx Ingress Controller 基于 Nginx 实现了 Kubernetes Ingress API,Nginx 是公认的高性能网关,但如果不对其进行一些参数调优,就不能充分发挥出高性能的优势。之前我们在 Nginx Ingress on TKE 部署最佳实践 一文中讲了 Nginx Ingress 在 TKE 上部署最佳实践,涉及的部署 YAML 其实已经包含了一些性能方面的参数优化,只是没有提及,本文将继续展开介绍针对 Nginx Ingress 的一些全局配置与内核参数调优的建议,可用于支撑我们的高并发业务。

Nginx Ingress on TKE 部署最佳实践

目录 概述 什么是 Nginx Ingress ? 有哪些部署方案 ? 方案一: Deployment + LB 方案二:Daemonset + HostNetwork + LB 方案三:Deployment + LB 直通 Pod 如何选型? 如何支持内网 Ingress ? 如何复用已有 LB ?

Kubernetes 服务部署最佳实践(二) 如何提高服务可用性

目录 引言 如何避免单点故障? 如何避免节点维护或升级时导致服务不可用? 如何让服务进行平滑更新? 健康检查怎么配才好? 参考资料 引言 上一篇 文章我们围绕如何合理利用资源的主题做了一些最佳实践的分享,这一次我们就如何提高服务可用性的主题来展开探讨。 怎样提高我们部署服务的可用性呢?K8S 设计本身就考虑到了各种故障的可能性,并提供了一些自愈机制以提高系统的容错性,但有些情况还是可能导致较长时间不可用,拉低服务可用性的指标。本文将结合生产实践经验,为大家提供一些最佳实践来最大化的提高服务可用性。 如何避免单点故障? K8S 的设计就是假设节点是不可靠的。节点越多,发生软硬件故障导致节点不可用的几率就越高,所以我们通常需要给服务部署多个副本,根据实际情况调整 replicas 的值,如果值为 1 就必然存在单点故障,如果大于 1 但所有副本都调度到同一个节点了,那还是有单点故障,有时候还要考虑到灾难,比如整个机房不可用。 所以我们不仅要有合理的副本数量,还需要让这些不同副本调度到不同的拓扑域(节点、可用区),打散调度以避免单点故障,这个可以利用 Pod 反亲和性来做到,反亲和主要分强反亲和与弱反亲和两种。 先来看个强反亲和的示例,将 dns 服务强制打散调度到不同节点上:

Kubernetes 服务部署最佳实践(一) 如何合理利用资源

目录 引言 Request 与 Limit 怎么设置才好 所有容器都应该设置 request 老是忘记设置怎么办 重要的线上应用改如何设置 怎样设置才能提高资源利用率 尽量避免使用过大的 request 与 limit 避免测试 namespace 消耗过多资源影响生产业务 如何让资源得到更合理的分配 使用亲和性 使用污点与容忍 弹性伸缩 如何支持流量突发型业务 如何节约成本 无法水平扩容的服务怎么办 参考资料 引言 业务容器化后,如何将其部署在 K8S 上?如果仅仅是将它跑起来,很简单,但如果是上生产,我们有许多地方是需要结合业务场景和部署环境进行方案选型和配置调优的。比如,如何设置容器的 Request 与 Limit、如何让部署的服务做到高可用、如何配置健康检查、如何进行弹性伸缩、如何更好的进行资源调度、如何选择持久化存储、如何对外暴露服务等。

打造云原生大型分布式监控系统(三): Thanos 部署与实践

目录 视频 概述 部署方式 方案选型 Sidecar or Receiver 评估是否需要 Ruler 评估是否需要 Store Gateway 与 Compact 部署实践 准备对象存储配置 给 Prometheus 加上 Sidecar 安装 Query 安装 Store Gateway 安装 Ruler 安装 Compact 安装 Receiver 指定 Query 为数据源 总结 视频 附上本系列完整视频 打造云原生大型分布式监控系统(一): 大规模场景下 Prometheus 的优化手段 https://www.bilibili.com/video/BV17C4y1x7HE 打造云原生大型分布式监控系统(二): Thanos 架构详解 https://www.bilibili.com/video/BV1Vk4y1R7S9 打造云原生大型分布式监控系统(三): Thanos 部署与实践 https://www.bilibili.com/video/BV16g4y187HD 概述 上一篇 Thanos 架构详解 我们深入理解了 thanos 的架构设计与实现原理,现在我们来聊聊实战,分享一下如何部署和使用 Thanos。

打造云原生大型分布式监控系统(二): Thanos 架构详解

目录 概述 Thanos 架构 架构设计剖析 Query 与 Sidecar Store Gateway Ruler Compact 再看架构图 Sidecar 模式与 Receiver 模式 总结 概述 之前在 大规模场景下 Prometheus 的优化手段 中,我们想尽 “千方百计” 才好不容易把 Prometheus 优化到适配大规模场景,部署和后期维护麻烦且复杂不说,还有很多不完美的地方,并且还无法满足一些更高级的诉求,比如查看时间久远的监控数据,对于一些时间久远不常用的 “冷数据”,最理想的方式就是存到廉价的对象存储中,等需要查询的时候能够自动加载出来。 Thanos (没错,就是灭霸) 可以帮我们简化分布式 Prometheus 的部署与管理,并提供了一些的高级特性:全局视图,长期存储,高可用。下面我们来详细讲解一下。

打造云原生大型分布式监控系统(一): 大规模场景下 Prometheus 的优化手段

目录 概述 大规模场景下 Prometheus 的痛点 从服务维度拆分 Prometheus 对超大规模的服务做分片 拆分引入的新问题 集中数据存储 Prometheus 联邦 Prometheus 高可用 总结 概述 Prometheus 几乎已成为监控领域的事实标准,它自带高效的时序数据库存储,可以让单台 Prometheus 能够高效的处理大量的数据,还有友好并且强大的 PromQL 语法,可以用来灵活的查询各种监控数据以及配置告警规则,同时它的 pull 模型指标采集方式被广泛采纳,非常多的应用都实现了 Prometheus 的 metrics 接口以暴露自身各项数据指标让 Prometheus 去采集,很多没有适配的应用也会有第三方 exporter 帮它去适配 Prometheus,所以监控系统我们通常首选用 Prometheus,本系列文章也将基于 Prometheus 来打造云原生环境下的大型分布式监控系统。 大规模场景下 Prometheus 的痛点 Prometheus 本身只支持单机部署,没有自带支持集群部署,也就不支持高可用以及水平扩容,在大规模场景下,最让人关心的问题是它的存储空间也受限于单机磁盘容量,磁盘容量决定了单个 Prometheus 所能存储的数据量,数据量大小又取决于被采集服务的指标数量、服务数量、采集速率以及数据过期时间。在数据量大的情况下,我们可能就需要做很多取舍,比如丢弃不重要的指标、降低采集速率、设置较短的数据过期时间(默认只保留15天的数据,看不到比较久远的监控数据)。 这些痛点实际也是可以通过一些优化手段来改善的,下面我们来细讲一下。