使用 Metricbeat 监控 Kubernetes
简介 Metricbeat 是服务器上的轻量级收集器，用于定期收集主机和服务的监控指标【包括events】。 Metricbeat 默认收集系统指标，但也包含大量其他模块，用于收集 Nginx、Kafka、MySQL、Redis 等服务的指标。支持的模块的完整列表可以在 Elastic 官网查看：https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-modules.html。 kube-state-metrics官方地址：https://github.com/kubernetes/kube-state-metrics 注：对于使用 prometheus-operator/kube-prometheus 的用户， kube-prometheus 将 kube-state-metrics 作为其组件之一。 如果已经安装了 kube-prometheus，则无需安装 kube-state-metrics。 首先，我们需要安装 kube-state-metrics，这是一个组件，它是一个侦听 Kube...
Kubernetes Pod 端口代理：借道访问集群内部服务
概述在 Kubernetes 环境中，经常需要从本地访问集群内部的服务（如 Redis、MySQL 等），但出于安全考虑，这些服务通常不对外暴露。本文介绍如何利用已有的 Pod 作为跳板，安全地从本地连接到内部服务。 核心方案： 🔐 Pod 作为代理跳板 🔄 socat 端口转发 🛡️ kubectl port-forward 隧道 🚀 无需暴露服务到公网 适用场景： 访问内部数据库（Redis、MySQL、MongoDB） 调试集群内部服务 开发环境数据查询 临时访问未暴露的服务 方案架构网络拓扑12345本地电脑 (127.0.0.1:6379) ↓ kubectl port-forwardPod (my-app:6379) ↓ socat 代理内部服务 (Redis:10.244.0.5:6379) 流量路径1234567本地 Redis 客户端 → localhost:6379 → kubectl port-forward 隧道 → Pod:6379 → socat 监听 → 转发到 10.244.0.5:637...
几种强制删除资源对象的方式
在 Kubernetes 中，有时候删除资源对象（如 Namespace）时会卡住无法删除完成，这通常是因为存在 finalizers。以下是几种强制删除资源对象的方式。 1. 仅删除1kubectl delete namespace <ns> 2. 强制删除12# --grace-period=0: 设置优雅删除时间为 0kubectl delete namespace <ns> --force --grace-period=0 3. 修改 finalizers 字段12kubectl edit namespace <ns># 查找 finalizers，将后面的值置为 [] 4. 通过 API 接口修改 finalizers通过 Kubernetes 提供的 API 接口，修改 .spec.finalizers 和 metadata.finalizers 字段，将值置为 []，从而让 Kubernetes 直接删除该资源。 1234567891011# 1. 导出 namespace JSONkubectl get namespace...
Kubernetes IP 地址完全指南：类型、范围与固定 IP 配置
概述Kubernetes 集群中存在多种类型的 IP 地址，包括 Cluster IP、Pod IP、Node IP 等。理解这些 IP 的作用范围和配置方法对于网络规划至关重要。 核心内容： 🌐 Kubernetes 各类 IP 地址详解 📋 IP 地址范围配置 🔒 固定 IP 地址实现方案 ⚙️ K8s/K3s 配置差异 Kubernetes IP 地址类型Cluster IP（服务 IP）定义： Service 的虚拟 IP 地址，用于集群内部服务访问 特点： 特性 说明 作用范围 仅集群内部可访问 生命周期 与 Service 绑定（除非删除 Service） DNS 解析 通过 Service Name 自动解析 负载均衡 自动分发流量到后端 Pod 工作机制： 1Client → Service Name → kube-dns 解析 → Cluster IP → kube-proxy → Pod 示例： 123456789101112apiVersion: v1kind: Servicemetadata: name:...
定时自动重启 Pod 服务
方法1：滚动重启从 1.15 版开始，Kubernetes 允许滚动重启 Deployment，这是最快的重启方式： 1kubectl rollout restart deployment [deployment_name] 该命令会逐步关闭并重启 Deployment 中的每个 Pod 容器，重启过程中应用仍然可用，因为大多数容器仍在运行。 方法2：使用环境变量通过设置或更改环境变量，可以强制 Pod 重新启动并同步变更。例如，更改容器部署日期： 1kubectl set env deployment [deployment_name] DEPLOY_DATE="$(date)" 方法3：缩放副本数使用 scale 命令将副本数设置为 0 来关闭容器： 1kubectl scale deployment [deployment_name] --replicas=0 再将副本数恢复为大于零的值来重新启动： 1kubectl scale deployment [deployment_name] --replicas=1 Kubernetes 会销...
最大最小内存设置为一致
在 Kubernetes 中，像 CPU 这样的资源被称作"可压缩资源"（compressible resources）。它的典型特点是，当可压缩资源不足时，Pod 只会"饥饿"，但不会退出。而像内存这样的资源，则被称作"不可压缩资源"（incompressible resources）。当不可压缩资源不足时，Pod 就会因为 OOM（Out-Of-Memory）被内核杀掉。 1. 容器最小内存和最大内存设置为一致简单来理解：最小内存等同于 k8s 的 resources.requests 资源，最大内存等同于 resources.limits 资源。参考：为容器和 Pod 分配内存资源 | Kubernetes 上述配置中，查看对应的 YAML 文件可以看到，对应的 memory 的请求和限制保持一致。 一般情况下，对于核心资源，我们推荐 requests == limits，这是为什么呢？ Pod 的三种 QoS 类别 Guaranteed：当 Pod 里的每一个 Container 都同时设置了 request...
根据 PID 查找 Pod 信息
编辑 ~/.bashrc，粘贴以下函数，并执行 source ~/.bashrc 使其生效，使用时执行 podinfo $pid通过 PID 获取 Pod 名称12345podinfo() { 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 UID123podUid() { cat /proc/$1/mountinfo | grep "etc-hosts" | awk -F / {'print $6'}...
滚动更新控制副本数
在 Kubernetes 中，Deployment 提供了两种更新策略： 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） maxUn...
查看 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" +%...
结合 Prometheus 调整 Kubernetes 资源限制
转自： https://www.51cto.com/article/704723.html Kubernetes 资源限制往往是一个难以调整的配置，因为你必须在太严格或者太宽松的限制之间找到最佳的平衡点。 通过本文，你可以学习到如何设置正确的 Kubernetes 资源限制：从检测到无限制的容器，到找出你应该在集群中正确配置的 Kubernetes 资源限制。我们假设你使用 Prometheus 来监控你的 Kubernetes 集群。这就是为什么本文中的每个步骤都使用 PromQL 查询进行示例说明的原因。 检测没有 Kubernetes 资源限制的容器 设置正确的 Kubernetes 资源限制的第一步是检测没有任何限制的容器。没有 Kubernetes 资源限制的容器可能会在你的节点中造成非常严重的后果。在最好的情况下，节点将开始按顺序或评分驱逐 pod。由于 CPU 节流，它们也会出现性能问题。在最坏的情况下，节点将由于内存不足而被终止。 查找没有 Kubernetes 资源限制的容器 根据命名空间查找没有限制 CPU 的容器 1sum by (namespace...
公告