使用 sniffer 排查进程以及连接流量情况
Rust/C++/Golang 我全都要！
sniffer 项目地址：https://github.com/chenjiandongx/sniffer
在 Linux 系统中，进程的多数指标数据都能在 /proc/${PID} 路径下获取到，但网络 IO 的数据，比如网络流量或者进出网络包吞吐量这类的是没有办法直接读取到的。一番搜索后，在 Github 上找到两个工具，imsnif/bandwhich 和 raboof/nethogs，前者使用 Rust 编写，后者使用 C++ 编写。bandwhich 界面精巧并且支持以多种视角查看流量数据，像 Socket 连接、进程以及远程端点，但不支持传入 BPF 过滤条件，比如只想查看某个端口的流量数据或者过滤某个 IP 的数据。而 nethlogs 支持 BPF 过滤条件但只能以进程维度查看数据。
那问题就来了，能不能两者兼得呢？既能使用 BPF 过滤特性又能以多种视角查看数据。
当然可以，自己动手写一个不就行了。
chenjiandongx/sniffer 是一个 Golang 编写的，支持 TCP/UDP 协议 ...
从零开始实现一个时序数据库
从零开始实现一个时序数据库项目地址：https://github.com/chenjiandongx/mandodb
时序数据库（TSDB: Time Series Database）大多数时候都是为了满足监控场景的需求，这里先介绍两个概念：
数据点（Point）: 时序数据的数据点是一个包含 (Timestamp:int64, Value:float64) 的二元组。
时间线（Series）: 不同标签（Label）的组合称为不同的时间线，如 series1: {"__name__": "netspeed", "host": "localhost", "iface": "eth0"}series2: {"__name__": "netspeed", "host": "localhost", "iface": "eth1&quo ...
BPF 在 Golang 中 Crash 导致用户进程奔溃
进程奔溃 现场丢失 对于排查问题来说 就等于是白给了 🐶
感觉好像可行！事情的起因是这样的，最近线上有一个服务的 RPC 调用出现了问题，虽然调用频率不高，但耗时偶尔会高于预期，且我们并没有将每次调用的耗时都记录下来，所以并不知道具体每次调用到底持续了多久。刚好最近在研究 BPF，所以就萌生了一个想法，能不能在保留现场的情况下，直接在进程的用户态进行插桩，记录方法的执行时间呢。
实践出真知，决定动手试一试。
BPF 的众多新特性得 Linux 内核版本 5.0 以上才支持，秉持着一步到位的态度，用虚拟机梭哈了一个 Fedora33，内核版本 5.10。
[root@localhost ~]# uname -r5.10.10-200.fc33.x86_64
本次实验使用的是 bpftrace，bpftrace 是 BPF 一门前端语言，设计灵感来自 awk 和 C 语言，按照官方介绍把套件装完之后，开码！这里得吐槽一点，Fedora 用 yum 安装官方 BCC 套件会出现头文件缺失的问题… 最后我还是用源码自己 make 了一遍搞定。
试试到底行不行？先准备一套 RPC 服务的 ...
Kubernetes 访问 dashboard
安装 Kubernetes-dashboard按照 kubernetes-dashboard 介绍安装好 dashboard
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml
权限相关资源创建kubernetes-dashboard 需要较大的权限才能够访问所有资源，所以我们可以创建一个 admin-user 的 ServiceAccount 来获取对应的 token
创建 ClusterRoleBinding
# admin-clusterrole-binding.yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: admin-userroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRol ...
Kubernetes 中使用 nfs-storageclass 持久化数据
在 Kubernetes 中有三种资源对象用来描述持久化存储，PresistentVloume(PV)/PresistentVolumeClaim(PVC)/StroageClass
概念篇PVPV 是后端存储实体，持久化卷。PV 包含存储类型，存储大小和访问模式，生命周期独立于 Pod（不然怎么叫持久化存储呢…），目前 Kubernetes 支持以下的 PV 类型
awsElasticBlockStore
azureDisk
azureFile
cephfs
cinder
configMap
csi
downwardAPI
emptyDir
fc (fibre channel)
flexVolume
flocker
gcePersistentDisk
gitRepo (deprecated)
glusterfs
hostPath
iscsi
local
nfs
persistentVolumeClaim
projected
portworxVolume
quobyte
rbd
scaleIO
secret
storageos
vsphereVolume
每种类型的具体介绍请参考 ...
Kubernetes 修改 kube-porxy ipvs 模式
Kubernetes 默认的 kube-proxy 模式为 iptables，但是 iptables 有时候会出现一些问题，比如 clusterip 不能相互 ping 通。所以决定把模式从 iptables 切换为 ipvs。
查看 kube-proxy 信息$ kubectl get pods -n kube-system -o wide | grep proxy
使用 kubectl logs 可以看到目前 kube-proxy pod 的 proxy 模式$ kubectl logs kube-proxy-4hw9j -n kube-system
启动 ipvs 模块cat <<EOF > /etc/sysconfig/modules/ipvs.modules #!/bin/bash ipvs_modules_dir="/usr/lib/modules/\`uname -r\`/kernel/net/netfilter/ipvs" for i in \`ls \$ipvs_modules_dir | sed -r 's ...
kubernetes 之 Ingress-Controller
Kubernetes 中有两种最重要网络，Pod 网络和 Sevice 网络。
Pod 网络：Pod 网络的边界在集群节点（Node）组成的局域网，因为 Kubernetes 默认要求集群网络中每个 Pod-IP 都能互通。
Service 网络：如若是 ClusterIP 类型，则网络边界是容器网络，因为 ClusterIP 并没有对应的虚拟网卡，仅仅只是 iptables 的转发规则而已，kube-proxy/core-dns 两者负责处理网络的转发和解析工作。
什么是 Ingress?Kubernetes 与集群外部的通信最简单的方式就是通过暴露一个 NodePort 类型的 Service，然后集群外部即可与集群内部的服务互通。这样做确实比较方便，但需要自己对 NodePort 进行端口的规划和管理，而且 Service 本身并不能自定义转发规则，比如根据 Header 或者 Host 转发到不同的后端。
# NodePort 与外部交互 internet | --|-----|-- [ Services ]
Ingress 就是为了解决这个问题 ...