小五的个人杂货铺

在 Kubernetes 中，像 CPU 这样的资源被称作“可压缩资源”（compressible resources）。它的典型特点是，当可压缩资源不足时，Pod 只会“饥饿”，但不会退出。而像内存这样的资源，则被称作“不可压缩资源（incompressible resources）。当不可压缩资源不足时，Pod 就会因为 OOM（Out-Of-Memory）被内核杀掉。 1.容器最小内存和最大内存设置为一致简单来理解：最小内存等同于k8s的resources：requests资源，最大内存等同于resources：limits资源。参考：为容器和 Pod 分配内存资源 | Kubernetes 刚才的配置，我们查看对应yml文件可以看到，对应的memory的请求和限制保持一致。 一般情况下，对于核心资源，我们推荐 requests == limits，这个是为什么呢？ 这里涉及pod的三种模式： Guaranteed 类别：当 Pod 里的每一个 Container 都同时设置了 requests 和 limits，并且 requests 和 l...

查看pod是否正常打印日志，并发送webhook到企微 12345678910111213141516171819202122232425262728293031323334#!/bin/sh# 获取当前UTC时间utc_now=`date -u`# 将时间转换为timestamptimestamp_now=`date -d "$utc_now" +%s`PODNAME=NAMASPACE=function restart_pod() { for i in `kubectl get pod -n iot|grep $PODNAME|awk '{print $1}'`;do for time in `kubectl logs --tail=1 --timestamps $i -n $NAMASPACE | awk '{print $1}'`;do timestamp_pod=`date -d "$time" +%s` d...

编辑~/.bashrc, 粘贴以下函数,并执行source ~/.bashrc使其生效, 使用的时候执行函数podinfo $pid通过pid 获取pod name12345podinfo() { CID=$(cat /proc/$1/cgroup | awk -F '/' '{print $5}') CID=$(echo ${CID:0:8}) crictl inspect -o go-template --template='{{index .status.labels "io.kubernetes.pod.name"}}' $CID} 通过pid获取pod id123podUid() { cat /proc/$1/mountinfo | grep "etc-hosts" | awk -F / {'print $6'}&...

适用停机发布Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod。 适用零停机发布RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。 服务在滚动更新时，deployment控制器的目的是：给旧版本(old_rs)副本数减少至0、给新版本(new_rs)副本数量增至期望值(replicas)，以下是kubernetes提供的两个参数： maxUnavailable：和期望ready的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑； maxSurge：和期望ready的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快。 取值范围 数值(两者不能同时为0。) maxUnavailable: [0, 副本数] maxSurge: [0, 副本数] 比例(两者不能同时...

转自: https://blog.fleeto.us/post/k8s-faster-services-no-cpu-limits/ 配合站内最大最小内存设置为一致文章一起阅读 Kubernetes：移除 CPU 限制，服务运行更快我们（Buffer）早在 2016 年就开始使用 Kubernetes 了。我们使用 kops 对 Kubernetes 集群进行管理，其中包含了大约 60 个运行在 AWS 的节点，运行着 1500 个左右的容器。我们的微服务迁移之路充满坎坷。在和 Kubernetes 相处多年以后，我们还是会时不时遭到它的毒打。本文接下来要讨论的案例就是这样——CPU Limit 是一头披着狼皮的羊。 CPU 限制和流控Google 等公司强烈建议设置 CPU 限制。如果不进行这一限制，节点上的容器可能会耗尽所有 CPU 资源，这可能会引发多种意料之外的事故——例如导致 Kubernetes 关键进程（比如说 kubelet）停止响应。因此理论上为容器设置 CPU 限制能够很好的对节点进行保护。 该特性能限制一个容器在给定周期内（缺省为 100 毫秒）能够消耗...

转自： https://www.51cto.com/article/704723.html Kubernetes 资源限制往往是一个难以调整的配置，因为你必须在太严格或者太宽松的限制之间找到最佳的平衡点。 通过本文，你可以学习到如何设置正确的 Kubernetes 资源限制：从检测到无限制的容器，到找出你应该在集群中正确配置的 Kubernetes 资源限制。我们假设你使用 Prometheus 来监控你的 Kubernetes 集群。这就是为什么本文中的每个步骤都使用 PromQL 查询进行示例说明的原因。 检测没有 Kubernetes 资源限制的容器 设置正确的 Kubernetes 资源限制的第一步是检测没有任何限制的容器。没有 Kubernetes 资源限制的容器可能会在你的节点中造成非常严重的后果。在最好的情况下，节点将开始按顺序或评分驱逐 pod。由于 CPU 节流，它们也会出现性能问题。在最坏的情况下，节点将由于内存不足而被终止。 查找没有 Kubernetes 资源限制的容器 根据命名空间查找没有限制 CPU 的容器 1sum by (namespace...

1 - 两数之和 给定一个整数数组 nums 和一个整数目标值 target，请你在该数组中找出 和为目标值 target 的那 两个 整数，并返回它们的数组下标。 你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。 你可以按任意顺序返回答案。 解题方法暴力法 遍历数组，依次判断arr[0]+arr[1]，arr[0]+arr[2] ... ，arr[1]+arr[2]，arr[1]+arr[3] ... ，arr[2]+arr[3]，arr[1]+arr[3] ... 因为需要遍历Nb*Nb次循环，所以时间复杂度为O(N^2) 123456789101112131415161718192021class Solution { // Brute Force // @爱学习的饲养员 // N is the size of nums // Time Complexity: O(N^2) // Space COmplexity: O(1) public int[] twoSum(int[] nums, i...

使用命令行方式运行Jmeter前言命令行方式支持在多个环境下使用，windosw的dos环境下，也可以在linux环境上执行。 怎么用**执行路径：**执行命令前要检查当前目录是否是%JMeter_Home%\bin目录；如果 JMeter 脚本不在当前目录，需要指定完整的路径；如果要把执行的结果保存在其他地方也要指定完整的路径。命令中不指定测试计划与测试结果的路径时，默认都是在该目录下。 命令：jmeter -n -t <testplan filename> -l <listener filename> 示例测试计划与结果，都在%JMeter_Home%\bin目录1jmeter -n -t test1.jmx -l result.jtl 指定日志路径的1jmeter -n -t test1.jmx -l report\01-result.csv -j report\01-log.log 默认分布式执行1jmeter -n -t test1.jmx -r -l report\01-result.csv -j report\01-log.log ...

前言Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持 Moby BuildKit 提供的功能。提供了与 docker build 相同的用户体验，并增加了许多新功能。 该功能仅适用于 Docker v19.03+ 版本 BuildKitBuildKit 是下一代的镜像构建组件，在 https://github.com/moby/buildkit 开源。 注意：如果您的镜像构建使用的是云服务商提供的镜像构建服务（腾讯云容器服务、阿里云容器服务等），由于上述服务提供商的 Docker 版本低于 18.09，BuildKit 无法使用，将造成镜像构建失败。建议使用 BuildKit 构建镜像时使用一个新的 Dockerfile 文件（例如 Dockerfile.buildkit） 目前，Docker Hub 自动构建已经支持 buildkit，具体参考 https://github.com/docker-practice/docker-hub-buildx Dockerfile 新增指令详解启用 BuildKit 之后，我们可以使用...

初识spring native官方介绍 Spring Native提供了使用GraalVM 本机图像编译器将Spring应用程序编译为本机可执行文件的支持。与Java虚拟机相比，本机映像可以为许多类型的工作负载提供更便宜，更可持续的托管。这些包括微服务，功能工作负载，非常适合容器和Kubernetes使用本机映像具有关键优势，例如即时启动，即时峰值性能和减少的内存消耗。GraalVM本机项目希望随着时间的推移会改善一些缺点和折衷方案。构建本机映像是一个繁重的过程，比常规应用程序要慢。预热后，本机映像具有较少的运行时优化。最后，它比具有某些不同行为的JVM还不成熟。常规JVM和此本机映像平台之间的主要区别是： - 在构建时将未使用的零件删除。 - 反射，资源和动态代理需要配置。 - 类路径在构建时是固定的。 - 没有类延迟加载：可执行文件中附带的所有内容都将在启动时加载到内存中。 - 一些代码将在构建时运行。 - 围绕Java应用程序的某些方面存在一些局限性，这些局限性未得到完全支持。 简单来说,就是更快.更短,更小 更快的启动速度 更短的响应时间 更小的内存消耗 十分适用...