查看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...
记录一次k8s网络DNS问题排查过程
问题1: k8s环境下,服务使用node:xxx-alpine镜像,服务间访问报错: getaddrinfo EAI_AGAIN问题2: 非alpine镜像, 使用clusterip访问频繁出现超时问题: connect ECONNRESET,read ECONNRESET还有服务本身axios报的timeout问题3: 非alpine镜像, 使用dns访问报错: getaddrinfo ENOTFOUND 详细背景见: https://github.com/k3s-io/k3s/issues/5897 问题4: coreDns报错出现error: [ERROR] plugin/errors: 2 . NS: read udp 10.42.2.5:38764->183.60.82.98:53: i/o timeout[DONE]记录问题解决过程问题1问题排查/解决过程 现象1: 问题发生在流量高峰阶段 现象2: 压测tps,200线程仅30多每秒, 吞吐量极差 现象3: 是偶尔性的,...
rancher导入集群
导入集群 进入之后选择导入已有集群,随后进入此页面,点击创建 对于自签证书选择第二项,复制,然后在k3s-server节点执行 问题error: no objects passed to apply 这里的问题主要是无法连接到部署Rancher的主机，无法获取yaml文件导致的。可以将yaml文件直接下载到k3s-server，再手动执行kubectl apply -f {xxx}.yaml (针对配置了--tls-san参数 - 自签证书)可能会执行失败,提示域名rancher.k3s.cn 不识别(前面的证书域名以及对应ip) 更新资源的字段 1234567891011121314151617181920212223242526272829303132333435(because the cert was made by myself,so i need configured the hosts, otherwise it does not know my cert's domain name,unless you used ip...
Orange网关容器化改造
orange网关传统集群部署模式1、在orange.conf的 plugins中加入node，表示开启node插件（容器集群节点管理插件） 12345678910111213141516171819202122232425262728 "plugins": [ "stat", "headers", "monitor", "redirect", "rewrite", "rate_limiting", "property_rate_limiting", "basic_auth", "key_auth", "jwt_auth", "hmac_auth", ...
SpringBoot+K8S中的滚动发布、优雅停机、弹性伸缩、应用监控、配置分离
参考： https://mp.weixin.qq.com/s/D8efjj9ZhLyEu7zEqWvJiQ https://stackoverflow.com/questions/71860152/actuator-health-endpoint-returns-out-of-service-when-all-groups-are-up https://docs.spring.io/spring-boot/docs/2.6.x/reference/htmlsingle/#actuator.endpoints.kubernetes-probes 本文使用 K8s + SpringBoot 实现零宕机发布：健康检查 + 滚动更新 + 优雅停机 + 弹性伸缩 + Prometheus监控 + 配置分离（镜像复用） 配置健康检查 健康检查类型：就绪探针（readiness）+ 存活探针（liveness） 探针类型：exec（进入容器执行脚本）、tcpSocket（探测端口）、httpGet（调用接口） 业务层面项目依赖...
自定义监控指标开发(六):精简Prometheus指标减少资源占用
前言随着 Prometheus 监控的组件、数量、指标越来越多，Prometheus 对计算性能的要求会越来越高，资源占用也会越来越高。 在这种情况下，要优化 Prometheus 性能, 优化存储占用. 第一时间想到的可能是各种 Prometheus 的兼容存储方案, 如 Thanos 或 VM、Mimir 等。但是实际上虽然集中存储、长期存储、存储降采样及存储压缩可以一定程度解决相关问题，但是治标不治本。 真正的本，还是在于指标量（series）过于庞大。 治本之法，应该是减少指标量。有 2 种办法： 解决高基数问题 根据实际使用情况，只保留（keep）展示（Grafana Dashboards）和告警（prometheus rules）会用到的指标。 高基数问题什么是基数(Cardinality)?基数的 基本定义 是指一个给定集合中的元素的数量。 在Prometheus中指代series 的基数 (High Cardinality) 在 Prometheus 和可观察性的世界里，标签基数...
公告
