正如一位英国诗人所说的，“犯错是人，宽恕是神”。错误处理是编程实践中非常重要的一部分，但在很多流行语言中并没有对它给予足够的重视。
作为众多语言的鼻祖，C 语言从一开始就没有一个完善的错误处理和异常机制。在 C 语言中，错误处理完全由程序员来负责，要么通过设置一个错误码，或者程序直接就崩溃了（segment fault）。
虽然异常处理机制早在 C 语言发明之前就出现了（最早由 LISP 1.5在1962年支持），但直到19世纪80年代它才流行开来。C++ 和 Java 让程序员熟悉了 try...catch 这一模式，所有的解释型语言也沿用了它。
尽管在语法上略有差异（比如是用 try 还是 begin），我之前遇到的每一种语言在一开始学习的时候都不会让你注意到错误处理的概念。通常，在你刚开始写着玩的时候根本用不到它，只有当你开始写一个真正的项目时才会意识到需要有错误处理。至少对于我而言，一直如此。
然后我遇到了 Golang ：一开始大家都是从《a Tour of Go》来认识它的。
对于 tcpdump 的使用，大部分管理员会分成两类。有一类管理员，他们熟知 tcpdump 和其中的所有标记；另一类管理员，他们仅了解基本的使用方法，剩下事情都要借助参考手册才能完成。出现这种情况的原因在于， tcpdump 是一个相当高级的命令，使用的时候需要对网络的工作机制有相当深入的了解。
在今天的文章中，我想提供一个快速但相当实用的 tcpdump 参考。我会谈到基本的和一些高级的使用方法。我敢肯定我会忽略一些相当酷的命令，欢迎你补充在评论部分。
在我们深入了解以前，最重要的是了解 tcpdump 是用来做什么的。 tcpdump 命令用来保存和记录网络流量。你可以用它来观察网络上发生了什么，并可用来解决各种各样的问题，包括和网络通信无关的问题。除了网络问题，我经常用 tcpdump 解决应用程序的问题。如果你发现两个应用程序之间无法很好工作，可以用 tcpdump 观察出了什么问题。 tcpdump 可以用来抓取和读取数据包，特别是当通信没有被加密的时候。
集群中有台node服务器因为资源达到上限出现假死现状，重启后发现calico node 无法启动成功，提示如下信息：1
:Readiness probe failed: caliconode is not ready: BIRD is not ready: BGP not established with 172.18.0.1
使用calicoctl node status 命令查看node状态信息提示如下：1
2
3
4
5
6
7
8
9Calico process is running.
IPv4 BGP status
+--------------+-------------------+-------+----------+--------------------------------+
| PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO |
+--------------+-------------------+-------+----------+--------------------------------+
| 172.18.0.1 | node-to-node mesh | start | 01:56:41 | Connect Socket: Network |
| | | | | unreachable |
+--------------+-------------------+-------+----------+--------------------------------+
回想最开始接触 k8s 的时候, 经常搞不懂 CRI 和 OCI 的联系和区别, 也不知道为啥要垫那么多的 “shim”(尤其是 containerd-shim 和 dockershim 这两个完全没啥关联的东西还恰好都叫 shim). 所以嘛, 这篇就写一写 k8s 的 runtime 部分, 争取一篇文章把下面这张 Landscape 里的核心项目给白话明白
我们从最常见的 runtime 方案 Docker 说起, 现在 Kubelet 和 Docker 的集成还是挺啰嗦的:
你可能会说，简单，netstat -antp找到连接，kill掉这个进程就行了。
1 | # netstat -antp|grep 6789 |
连接确实关掉了，进程也跟着一起杀死了。达不到“在线”的要求。
有没有办法不杀死进程，但还是可以关闭socket连接呢？
我们知道，在编码的时候，要关闭一个socket，只要调用 close 函数就可以了，但是进程在运行着呢，怎么让它调用 close 呢？