设置Rancher创建的Kubernetes集群的eviction策略

我一直把Rancher当Docker控制面板用,每个cluster都是单节点,启动一个算一个。最近就遇到这么个问题,一个node硬盘不足,触发了kubelet的eviction策略,于是kubelet干掉了两个container,又重启了两个——在唯一那个node上。如此循环往复了一刻钟,我就收获了几十个failed的container。

解决这个问题的方法很简单,用YAML方式编辑Rancher Cluster的设置,把kubelet的eviction策略设成空即可。

services: 
  kubelet: 
    extra_args:
      eviction-hard: ""
      eviction-soft: ""
      eviction-minimum-reclaim: ""

然后测试一下:

fallocate -l 37580963840 test.35g

应该就不会触发DiskPressure了。

说来这个eviction的设计也是很扯淡,它竟然是kubelet在本地计算的,不考虑整个cluster的情况。那我花那么多内存跑个etcd意义何在呢?

继续阅读

IOS XE把全局路由表导入VRF

首先要配置BGP(但是可以没有Peer)。要确保待导入的表在BGP的RIB里面;如果不在的话需要redistribute到BGP进程里。然后用route-map导入。示例:

! 除默认路由外
ip prefix-list NO_DEFAULT_ROUTE seq 5 deny 0.0.0.0/0
ip prefix-list NO_DEFAULT_ROUTE seq 10 permit 0.0.0.0/0 le 32

route-map GLOBAL_TO_PROXY_VRF permit 10
 match ip address prefix-list NO_DEFAULT_ROUTE

ip vrf PROXY
 rd 100:100
 import ipv4 unicast 65535 map GLOBAL_TO_PROXY_VRF
 route-target export 100:100
 route-target import 100:100

配置里的65535是导入数量上限,默认只有不到1000条,完全不够用。配置完成以后可能需要等几分钟才能看到效果,因为VRF之间路由泄露完全靠BGP进程来实现,BGP进程刷新还是挺慢的。

注意这样导入以后,如果路由上没有next hop interface信息,那么这条路由是无效的。所以要么手工设置一下recursive路由到interface上:

ip route vrf PROXY 192.0.2.100 255.255.255.255 Dialer1 10
ip route vrf PROXY 192.0.2.200 255.255.255.255 Dialer0 10

要么把connected路由也redistribute进VRF。(注意如果你有BGP peer尤其是隧道里面的peer的话,要记得filter掉这些路由。)

在家也要玩BGP(2):可控地给部分局域网设备设置透明代理网关

现在越来越多中小企业开始抛弃传统的Access VPN方案,转而向员工提供应用层代理服务器来访问内部资源。四层代理服务器方案具有部署简单、维护成本低、对BYOD设备侵入性低等特点,在不需要过多访问控制和日志记录能力,缺乏专业IT人员的情况下是一个不错的内网访问方案。但是这种方案有一个显而易见的缺点:应用层代理服务器需要应用支持。对于不支持设置代理服务器的应用,它就无能为力。另外,有些场合,比如给设备安装系统时,你并不总能找到代理服务器设置的位置。这就给应用层代理服务器的推广带来了很大麻烦。

为了克服这个缺点,我们有一个办法:在局域网设置一个透明代理网关。透明代理网关是一种应用层单臂路由,它对局域网设备来说是一个路由器,但是其特定应用层协议的上联链路是一个代理服务器。如果代理服务器支持,使用Linux内核iptables模块中的REDIRECT或TPROXY功能可以很容易地配置这样一个透明代理网关。但是一旦我们把整个局域网的默认网关配置成透明代理网关,整个局域网的流量都会经过公司的内部网络,这不一定是我们想要的结果,也不便做访问控制。另外,如果把代理网关和用户设备放在同一个二层中,用户只需要改一下设备自己的网络配置就可以使用该代理服务器,这可能导致严重的安全问题。因此,我们需要一种方法来动态地控制某台设备的默认网关是本站点的互联网出口,还是公司的代理服务器出口。

而BGP协议,正是能实现这一功能的成本最低的方案。

继续阅读