[译]什么是 eBPF?
eBPF 程序是事件驱动的, 能在内核或应用程序执行到一个特定的 hook 点时执行. 预定义的 hooks 包含系统调用, 函数出/入口, 内核追踪点, 网络事件等等. 如果预定义 hook 不能满足需求, 也可以创建内核探针(kprobe)或者用户探针(uprobe), 在内核/用户应用程序的任何位置, 把探针附加到 eBPF 程序上.
eBPF 程序是事件驱动的, 能在内核或应用程序执行到一个特定的 hook 点时执行. 预定义的 hooks 包含系统调用, 函数出/入口, 内核追踪点, 网络事件等等. 如果预定义 hook 不能满足需求, 也可以创建内核探针(kprobe)或者用户探针(uprobe), 在内核/用户应用程序的任何位置, 把探针附加到 eBPF 程序上.
以下冷门命令能实现某种具体的功能, 都是在实际工作中摸索总结的经验, 获取到相关的资源名称之后, 就可以配合常用的 kubectl 命令获取其他详细信息.
pod is in the cache, so can’t be assumed, 这是调度器 scheduler 缓存失效导致的异常事件, 大致原因是 pod 已经调度, 并绑定到指定节点, 由于该节点异常导致启动失败, 重新启动 prometheus statefulset, 让集群重新调度, 其实就是将现有到 prometheus pod 副本数将至 0, 再恢复正常即可.
calico-node-4fpgp Readiness probe failed, orphaned pod
这篇文档主要演示了 opensnoop(Linux eBPF/bcc) 工具的使用. opensnoop 在系统范围内跟踪 open() 系统调用,并打印各种详细信息.
这篇文档主要演示了 tcplife(Linux eBPF/bcc) 工具的使用. tcplife 总结了在跟踪期间打开和关闭的 TCP 会话. 比如
下表是 Linux 操作系统一些常见的错误代码和对应的错误描述 1 EPERM Operation not permitted 2 ENOENT No such file or directory
周末, 有一台服务器告警: 系统负载过高, 最高的时候都已经到 100 +, 以下是排查&处理的具体过程.
uptime
显示 load average 都在70+
#因为服务器是40核心, 原则上负载40是满负荷, 现在明显存在大量等待的任务. 继续往下分析进程, 看具体那个进程一直在堵塞.
ps -ef
执行到某一个进程就卡住了
#命令执行如下:
...使用容器化安装非常便捷, 参考 osixia/openldap仓库使用说明安装即可, 如下:
|
|
好了, 现在该服务同时支持 ldap 和 ldaps 协议, 有一个初始化的账号 readonly/readonly
, 可以使用了~
查看 pod 相关 events 如下:
|
|
这是内核bug,建议升级内核
...