关于k8s的资源分配/限制
相关概念引自kubesphere - requests与limits 简介为了实现 K8s 集群中资源的有效调度和充分利用， K8s 采用requests和limits两种限制类型来对资源进行容器粒度的分配。每一个容器都可以独立地设定相应的requests和limits。这 2 个参数是通过每个容器 containerSpec 的 resources 字段进行设置的。一般来说，在调度的时候requests比较重要，在运行时limits比较重要。 一些本地临时存储的配置 **注: ** 当容器申请内存超过limits时会被oomkill，并根据重启策略进行重启。而cpu超过limit则是限流，但不会被kill 由于CPU资源是可压缩的，进程无论如何也不可能突破上限，因此设置起来比较容易。对于Memory这种不可压缩资源来说，它的Limit设置就是一个问题了，如果设置得小了，当进程在业务繁忙期试图请求超过Limit限制的Memory时，此进程就会被Kubernetes杀掉 1234567891011121314# requests:...
各种ip以及固定ip
Cluster IP即Service的IP，通常在集群内部使用Service Name来访问服务，用户不需要知道该IP地址，kubedns会自动根据service name解析到服务的IP地址，将流量分发给Pod。 Service Name才是对外暴露服务的关键。在kubeapi的配置中指定该地址范围。 默认配置 12--service-cluster-ip-range=10.254.0.0/16--service-node-port-range=30000-32767 Pod IPflannel通过配置flannel的network和subnet来实现。 默认配置 12FLANNEL_NETWORK=172.30.0.0/16FLANNEL_SUBNET=172.30.46.1/24 Pod的IP地址不固定，当pod重启时IP地址会变化。 该IP地址也是用户无需关心的。 但是Flannel会在本地生成相应IP段的虚拟网卡，为了防止和集群中的其他IP地址冲突，需要规划IP段。 主机/Node...
定时监控node和pod并发送webhook(wechat)的一个小脚本
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107#!/usr/bin/env bash# 0.定义webhook urlwebhookurl=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=4b7128c5-0e5a-46f5-b5ef-77dff4eb5c99# 1.定义变量值,namespace不能为空if [ -z "$1" ]; then exit 1else nameSpace=$1fi# 节点cpu限制值(%)cpuVPT=85# 节点mem限制值(%)memVPT=85# pod...
定时自动重启Pod服务
方法1：滚动重启从1.15版开始，Kubernetes允许您滚动重启部署。作为Kubernetes的新增功能，这是最快的重启方法。 kubectl rollout restart deployment [deployment_name] 上面提到的命令将逐步执行关闭操作，并重新启动deployment中的每个pod容器。在重启过程中应用仍然可用，因为大多数容器仍在运行。 方法2：使用环境变量另一种方法是设置或更改环境变量，以强制Pod重新启动并与您所做的更改同步。 例如，可以更改容器部署日期： kubectl set env deployment [deployment_name] DEPLOY_DATE="$(date)" 在上面的示例中，该命令**set env设置环境变量的更改，deployment...
最大最小内存设置为一致
在 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 和...
查看pod是否正常打印日志
查看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` ...
根据pid查找到pod的一些信息
编辑~/.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...
滚动更新控制副本数
适用停机发布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,...
移除CPU限制,服务运行更快
转自: 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...
结合prometheus调整Kubernetes资源限制
转自： https://www.51cto.com/article/704723.html Kubernetes 资源限制往往是一个难以调整的配置，因为你必须在太严格或者太宽松的限制之间找到最佳的平衡点。 通过本文，你可以学习到如何设置正确的 Kubernetes 资源限制：从检测到无限制的容器，到找出你应该在集群中正确配置的 Kubernetes 资源限制。我们假设你使用 Prometheus 来监控你的 Kubernetes 集群。这就是为什么本文中的每个步骤都使用 PromQL 查询进行示例说明的原因。 检测没有 Kubernetes 资源限制的容器 设置正确的 Kubernetes 资源限制的第一步是检测没有任何限制的容器。没有 Kubernetes 资源限制的容器可能会在你的节点中造成非常严重的后果。在最好的情况下，节点将开始按顺序或评分驱逐 pod。由于 CPU 节流，它们也会出现性能问题。在最坏的情况下，节点将由于内存不足而被终止。 查找没有 Kubernetes 资源限制的容器 根据命名空间查找没有限制 CPU 的容器 1sum by...
公告