处理记录 Ceph版本：octopus 首先遇到問題是，业务端无法挂在 cephfs 查看内核日志发现是 bad authorize reply ，以为是 ceph keyring被替换了 text 1 2 3 4 5 6 7 8 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10....

Overview 阅读完本文，您当了解 Linux oom kill Kubernetes oom 算法 Kubernetes QoS 本文只是个人理解，如果有大佬觉得不是这样的可以留言一起讨论，参考源码版本为 1.18.20，与高版本相差不大 什么是OOM Kill 当你的Linux机器内存不足时，内核会调用Out of Memory (OOM) killer来释放一些内存。这经常在运行许多内存密集型进程的服务器上遇到。 OOM Killer是如何选择要杀死的进程的？ Linux内核为每个运行的进程分配一个分数，称为 oom_score，==显示在内存紧张时终止该进程的可能性有多大==。该 Score 与进程使用的内存量成比例。 Score 是进程使用内存的百分比乘以10。因此，最大分数是 $100% \times 10 = 1000$。此外，如果一个进程以特权用户身份运行，那么与普通用户进程相比，它的 oom_score 会稍低。 在主发行版内核会将 /proc/sys/vm/overcommit_memory 的默认值设置为零，这意味着进程可以请求比系统中当前可用的内存更多的内存。这是基于以下启发式完成的：分配的内存不会立即使用，并且进程在其生命周期内也不会使用它们分配的所有内存。如果没有过度使用，系统将无法充分利用其内存，从而浪费一些内存。过量使用内存允许系统以更有效的方式使用内存，但存在 OOM 情况的风险。占用内存的程序会耗尽系统内存，使整个系统陷入瘫痪。当内存太低时，这可能会导致这样的情况：即使是单个页面也无法分配给用户进程，从而允许管理员终止适当的任务，或者内核执行重要操作，例如释放内存。在这种情况下，OOM Killer 就会介入，并将该进程识别为牺牲品，以保证系统其余部分的利益。 用户和系统管理员经常询问控制 OOM Killer 行为的方法。为了方便控制，引入了 /proc/<pid>/oom_adj 来防止系统中的重要进程被杀死，并定义进程被杀死的顺序。 oom_adj 的可能值范围为 -17 到 +15。Score 越高，相关进程就越有可能被 OOM-killer Kill。如果 oom_adj 设置为 -17，则 OOM Killer 不会 Kill 该进程。 oom_score 分数为 1 ~ 1000，值越低，程序被杀死的机会就越小。 oom_score 0 表示该进程未使用任何可用内存。 oom_score 1000 表示该进程正在使用 100% 的可用内存，大于1000，也取1000。 谁是糟糕的进程？ 在内存不足的情况下选择要被终止的进程是基于其 oom_score 。糟糕进程 Score 被记录在 /proc/<pid>/oom_score 文件中。该值是基于系统损失的最小工作量、回收的大量内存、不终止任何消耗大量内存的无辜进程以及终止的进程数量最小化（如果可能限制在一个）等因素来确定的。糟糕程度得分是使用进程的原始内存大小、其 CPU 时间（utime + stime）、运行时间（uptime - 启动时间）以及其 oom_adj 值计算的。进程使用的内存越多，得分越高。进程在系统中存在的时间越长，得分越小。...

本文使用 helm 方式部署 grafana 9 并同样将 keycloak 部署在 kubernetes 集群之上；接下来使用 keycloak 作为 grafana authentication，并实现 oauth2 的用户权限管理。 在Kubernetes 集群之上使用helm部署keycloak 在 kubernetes 集群安装 keycloak 有两种方式： bitnami helm offical 下面使用 offical 提供的方式进行部署 bash 1 kubectl create -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/latest/kubernetes/keycloak.yaml helm 部署完成后默认密码是存储在 secret 中，上面方式安装的密码默认为 admin/admin Keycloak configuration 创建realm Realm 管理这一组用户(users), 凭据(credentials), 角色(roles) 和 组(groups)，realm之间是相互隔离，一个用户属于并登录到某个 realm，只能管理和验证其控制的用户。 下面为 grafana 创建一个 realm，如果你的环境已经存在通用的 realm，则可以使用这个 realm，默认 keycloak 的 realm 是 master，超级管理员属于这个 realm。 创建 client Client 是可以请求Keycloak对用户进行身份验证的实体。最常见用途是希望使用Keycloak来保护自己并提供单点登录(SSO)解决方案的应用程序和服务。客户端也可以是只希望请求身份信息或访问令牌的实体，以便它们可以安全地调用由 Keycloak 保护的网络上的其他服务。因此，我们需要为 grafana 创建一个 client...

2018 年，Kayenta（一种用于自动化金丝雀分析的开源工具）作为 Spinnaker 项目的一部分推出。在本文中，我们描述了如何将 Kayenta 集成到我们现有的部署设施中，极大地提高了部署管道的可靠性并为自动化生产部署创造了先决条件。 概念理解 什么是金丝雀分析？ 金丝雀分析 (canary analysis) 是一个两步的过程，分析将根据选定的指标和日志评估金丝雀，以推断我们是否要升级或回滚新版本。因此，我们需要确保在测试过程中收集正确的信息（指标和日志）并进行可靠的分析。 金丝雀分析的执行步骤 指标选择 指标评估 指标选择 该步骤涉及选择正确的指标来监控应用程序和金丝雀健康状况。因此我们需要确保创建一套平衡的指标来评估指标。最后，需要根据彼此的相关性对指标进行分组。 对于指标的选择，根本不需要选择所有指标，因为目前流行的基于微服务的应用程序通常会生成大量监控指标数据，因此我们不能简单地分析所有指标。 指标评估标准 选择重要的业务指标 最重要的指标是值对 可以反应服务 “成功/失败” 最重要的指标。例如，在在线购物结帐系统中，一定要测量每分钟的交易次数、失败率等。如果这些指标中的任何一个超出基线，您可能会决定回滚金丝雀。再例如，可以检测服务的数据库连接状态，初始化状态等指标，一旦指标超出基线则表示服务异常，这时候需要回滚。 平衡一组慢速与快速指标 一个有意义的金丝雀流程来说，单个指标是不够的。一些要监控的重要指标是立即生成的，而另一些则需要一些时间才能生成，因为它们依赖于负载，网络流量，高内存使用率或其他因素。在快速指标和慢速指标之间平衡您选择的指标非常重要。例如，服务器查询时间和延迟检查可以分别是慢度量和快度量的示例。因此选择一组平衡的指标，是对金丝雀的健康状况有全面的了解。 冒烟测试 从平衡组测试中，我们必须确保我们拥有直接表明金丝雀中存在问题的指标。所以冒烟测试很适合在这里使用，尽管我们的目标是找出金丝雀的健康状况，但使用此类指标找出金丝雀是否存在潜在问题也同样重要。例如，404 响应或其他意外的 HTTP 返回代码（200 秒、300 秒）可能意味着您的测试应立即停止并进行调试。CPU 使用率、内存占用、HTTP 响应码（200 秒、300 秒等）、响应延迟、正确性是一组很好的指标，但 HTTP 返回代码和响应延迟表明影响用户和服务的实际问题。 metrics 标准范围 这些公制选择需要有一个可接受的发挥范围，通过商定的可接受的指标行为，这样将能够消除那些被错误评估为好金丝雀的坏金丝雀。 金丝雀判断 执行金丝雀分析的最后一步是评估指标的值。通过这个步骤，将能够评估金丝雀实例是否应该升级到生产环境。 在提出每个假设之前，我们将定义两个假设，并根据我们的数据证明其中一个假设是错误的。 Unacceptable：回滚 Acceptable：部署到生产 Kayenta 比较两个时间序列，并在偏差超过某个阈值时发出警报。作为这些应用程序指标的来源，我们使用 New Relic Insights。对于这个后端，我们还将代码作为开源代码贡献给Kayenta ³。还可以支持其他后端（Datadog、Prometheus 等）。有关自动金丝雀分析的一般信息，请参阅Google和Netflix的优秀文章。 Reference ​ [1] Install Halyard on Docker ​ [2] ERROR Could not load “versions.yml” from config bucket: 403 #3920...

项目设计 需求：外部分析器工具连接到运行在 kubernetes 集群上 Java pod 的 JVM，通过 jprofiler 暴露其接口，可以直接连接至这个 java pod，并且可以实现自动化映射，为了安全保证，映射将在不活跃时自动取消。 需要解决的问题 Jprofiler 如何在 kubernetes 集群中运行： 方法1：打包至业务Pod容器内 缺点：需要侵入业务Pod内，不方便 方法2：使用 Init Container 将 JProfiler 安装复制到 Init Container 和将在 Pod 中启动的其他容器之间共享的卷 方法3：使用 sidecar 方式 共享业务Pod与 sidecar 共享名称空间 缺点：涉及到容器共享进程空间，与 jprofiler-agent 机制问题，所以需要共享 /tmp 目录 JProfiler finds JVMs via the “Attach API” that is part of the JDK. Have a look at the $TMP/hsperfdata_$USER directory, which is created by the hot spot JVM. It should contain PID files for all running JVMs....