Welcome to the Black Parade

预告一下接下来的几个内容(免得自己太懒跳票了, 所以先立 flags). 1. runc 2. systemd 的小坑 3. calico 的进一步细节: ToR, eBGP, RR 4. 安卓应用道德委员会 (Android Applications Ethics Commission)

Welcome to the Black Parade pinned «还是简单说一下, 创建这个初衷是发现自己自从离开北京后就不爱记录自己遇到的困难; 之前在北京时用 trello 总是会详细记录自己对工作的反思以及排查问题的经验教训, 如今不知怎的没啥动力, 正好 NUS 这边很多同学流行创建自己的 Telegram 频道分享对世界的见解, 我觉得挺好, 让知识流动 同样也是之前在爱因互动时的公司文化, 所以尝试做一个内容发布, 核心主题是自己在编程领域上的吐槽, 被操, 和思考. 当然水平有限, 错误难免, 欢迎吐槽和斧正.»

还是简单说一下, 创建这个初衷是发现自己自从离开北京后就不爱记录自己遇到的困难; 之前在北京时用 trello 总是会详细记录自己对工作的反思以及排查问题的经验教训, 如今不知怎的没啥动力, 正好 NUS 这边很多同学流行创建自己的 Telegram 频道分享对世界的见解, 我觉得挺好, 让知识流动 同样也是之前在爱因互动时的公司文化, 所以尝试做一个内容发布, 核心主题是自己在编程领域上的吐槽, 被操, 和思考. 当然水平有限, 错误难免, 欢迎吐槽和斧正.

发现 sh 居然不支持 brace expansion: mv ./{a,b} .. 习惯性地执行 sh script.sh结果因为 sh 无法解释 brace expansion 导致失败, 因为没有 set -e导致这个错误被 skip, 我没认真看输出甚至还以为是 dpkg 又挂了… 这也意味着 brace expansion 居然不是 POSIX Shell 标准: https://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html 这大概是 bash_supported.set() - sh_supported.set() 里最简单的语法之一, 其他的记得貌似 process substitution 也是, 不过都比较高级了.

调试 Calico 的一些方法 最近一直在死磕 Calico, 因为领导层已经拍板了要让 Kubernetes 的 Pod 暴露给集群外访问, 也就是说什么 Ingress / Service / NodePort 全都不用, 而是依赖 operator + DNS 做 failover 和 automation, 原因居然是认为 Nginx(Ingress) 和 iptables(Service) 影响性能, 匪夷所思... 经典场景: node1 上 ping 不通 node2 上的容器 IP. 1. 确认 wep, 看对应的容器是否创建了对应的 Calico WorkloadEndpoint, 如果不存在那么是 network plugin 的问题, 查看 libnetwork (CNM) 或者 kubelet (CNI) 的日志. 2. 确认 node2 上的路由, 在 node2 上 ping 容器 IP, 如果失败, 那么是 calico-felix 监听 datastore (etcd / kubernetes) 失败或者修改路由失败, 查看 felix 日志. 3. 确认 node1 上的路由, 如果路由正常, 那么几乎可以确认是 iptables 的问题, 进一步通过在 node1 和 node2 上抓包确认 node1 到容器的包已经发到 node2 4. 如果第三步路由正常, 排查 iptables 4.a. 先检查 Calico profile, 是否 allow ingress / egress, 是否设置了 selector 4.b. 如果 profile 正常, 手动检查 iptables, 不用死记硬背表链, 只要 iptables-save 后的顺序检查表就行了; 需要在 node1 上检查 OUTPUT -> POSTROUTING, 在 node2 上检查 PREROUTING -> INPUT 4.c 如果实在没精力/时间/不熟悉 iptables, 不妨 systemctl stop iptables 会 drop 所有规则, 不过 Calico 会立刻把它的 profile 修改到 iptables 中, 这么做只能清理掉非 Calico 的规则 5. 如果第三步路由不正常, 排查 BGP 5.a. 进入 calico-node 容器, 进入 bird 命令行, 查看 protocol 和 route, node1 需要查看 node2 的 protocol, node2 需要查看 kernel1 的 protocol 5.b. 一般来说是 node2 的 kernel1 protocol 显示有所需的路由, 但是 node1 的 node2 protocol 缺失了该路由, 那么在两个节点上抓 BGP 包, 在 bird cli 里执行 restart node2 protocol, 期望看到两个节点分别发送 OPEN 和 UPDATE message 5.c. 若 OPEN 失败, 查看 bird 日志, 可能的原因是 recursive cidr, 这种情况发生在 calico in calico 5.d. 若 UPDATE 发送成功但是依然没有路由, 依然查看 bird 日志, 可能的原因是 interface unreachable, 这意味着 node1 和 node2 L2 不通, 需要建立 ipip 隧道 5.e 若压根没看到 node1 收到有正确的 NLRI 和 NEXT_HOP 的 UDPATE message, 那么一定是 BGPPeer 没有正确交换路由信息; 如果 peer 是我们能控制的 RR 节点, 上去撸; 如果是 ToR 交换机, 找 infra. 大致就是如此.

Channel name was changed to «The Infinite Sadness»

Channel created