kubectl日志（kubeproxy日志）



注：本文基于K8S v1.21.2版本编写

当我们以默认配置部署kube-proxy时，将使用iptables作为proxier，我们可以从日志中查看相关信息。

Iptabels是与Linux内核集成的包过滤防火墙系统，包含五表五链，其中，对于表，按先后顺序分别为，raw->mangle->nat->filter->security,

• raw表——两个链：PREROUTING、OUTPUT
  作用：决定数据包是否被状态跟踪机制处理，和conntrack相关
  
  
• mangle表——五个链：PREROUTING、INPUT、OUTPUT、POSTROUTING、FORWARD
  作用：修改数据包的服务类型、TTL以及QOS相关
  
  
• nat表——三个链：PREROUTING、OUTPUT、POSTROUTING
  作用：用于网络地址转换
  
  
• filter表——三个链：INPUT、FORWARD、OUTPUT
  作用：过滤数据包
  
  
• security表——三个链：INPUT、FORWARD、OUTPUT
  作用：对连接进行安全标记，比如SECMARK，CONNSECMARK
  
  

其中，mangle和security用的比较少，raw主要用于iptables规则调试，因此在kube-proxy主要起作用的就是nat和filter表，这点我们可以通过查看iptables规则可知，其他三个表并没有规则。

而对于链，按先后顺序为，

• 本机数据包：PREROUTING -> INPUT -> OUTPUT -> POSTROUTING
• 转发数据包：PREROUTING -> FORWARD -> POSTROUTING

我们以coredns服务为例，看下dns请求是如何通过iptables规则从其他pod到达coredns pod。

考虑到集群中的iptables规则繁多，我们可以通过raw表来实现规则的trace，方便跟踪数据包的流动，具体可以参考——CentOS通过raw表实现iptables日志输出和调试

因此我们在测试容器所在的node上创建以下两条规则，

其中10.244.1.62是测试容器的ip，规则越细，我们越容易筛选出我们的数据报文，不然一大堆日志。

然后通过kubectl exec进入到测试容器，执行ping操作，

有两点需要注意，

• 只ping一个报文，不然日志太多
• 域名最后要加一个点，不然会先在集群中查询这个域名

然后在系统日志/var/log/messages中查看数据流动情况，以下日志有精简，因为我们只关注数据流向，

而其中，最需要注意的是nat表的prerouting链，这里我把对应的iptables规则择出来，

由此可见，

• 我们发往coredns的DNS请求开始时使用的clusterip，最后会被DNAT到对应的coredns的ip
• k8s集群中每个服务都会有对应的iptables来路由请求

那对于多个服务的情况，负载是如何进行的呢，为此，我们在dashboard中，将coredns的副本数量调整为3个，再查看下对应的iptables规则，这里我们只看变化的部分，也就是服务部分，

可见，这时候规则里多了probability，这就是iptables的负载均衡。不过有意思的是，这个规则的概率和我们平常的有点不一样，按理三个服务，那每个都是1/3的概率，这里却出现了0.5。这是因为iptables的规则计算不一样，它是从前往后匹配，所以第一条规则的命中是1/3，但是到了第二条，那就是后面两条二选一，因此是1/2，到了最后一条，就是100%了。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/12542.html