发表于 | 分类于 ， ， | | 热度: ℃
字数统计: 1,868 字 | 阅读时长 ≈ 9 分钟

背景

最近将 aws ALBIgressController 升级到 2.0 后发现在中国区有点问题，随后就将 alb-ingress-controller 回退到 1.x。具体 2.0 的问题已经解决，原因是中国区 aws 没有对应的 waf ，解决方法是将 waf 相关的配置关闭即可。当然，这不是重点，重点是当我回退到 1.x 后遇到了几个问题：

    1. kube-controller-manager 报如下错误日志
1
E1029 02:43:20.921678       1 reflector.go:153] k8s.io/client-go/metadata/metadatainformer/informer.go:89: Failed to list *v1.PartialObjectMetadata: the server could not find the requested resource
    1. k8s ingress 资源无法删除，hang 住了，查看对应的 ingress yaml 看到如下信息
1
2
3
4
5
6
7
...
creationTimestamp: "2020-10-28T10:22:42Z"
deletionGracePeriodSeconds: 0
deletionTimestamp: "2020-10-29T06:57:04Z"
finalizers:
- ingress.k8s.aws/resources
...
阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 3,098 字 | 阅读时长 ≈ 12 分钟

概念介绍

原地升级一词中，“升级”不难理解，是将应用实例的版本由旧版替换为新版。那么如何结合 Kubernetes 环境来理解“原地”呢？

我们先来看看 K8s 原生 workload 的发布方式。这里假设我们需要部署一个应用，包括 foo、bar 两个容器在 Pod 中。其中，foo 容器第一次部署时用的镜像版本是 v1，我们需要将其升级为 v2 版本镜像，该怎么做呢？

阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 9,328 字 | 阅读时长 ≈ 49 分钟

1 背景

最近升级了一版 kubelet，修复因 kubelet 删除 Pod 慢导致平台删除集群超时的问题。在灰度 redis 隔离集群的时候，发现升级 kubelet 并重启服务后，少量宿主状态变成了 NotReady，并且回滚 kubelet 至之前版本，宿主状态仍然是 NotReady。查看宿主状态时提示 ‘container runtime is down’ ，根据经验，此时一般就是容器运行时出了问题。弹性云使用的容器运行时是 docker，我们就去检查 docker 的状态，检测结果如下：

  • docker ps 查看所有容器状态，执行正常
  • docker inspect 查看某一容器详细状态，执行阻塞

典型的 docker hang 死行为。因为我们最近在升级 docker 版本，存量宿主 docker 的版本为 1.13.1，并且在逐步升级至 18.06.3，新宿主的 docker 版本都是 18.06.3。docker hang 死问题在 1.13.1 版本上表现得更彻底，在执行 docker ps 的时候就已经 hang 死了，一旦某个容器出了问题，docker 就处于无响应状态；而 docker 18.06.3 做了一点小小的优化，在执行 docker ps 时去掉了针对容器级别的加锁操作，但是 docker inspect 依然会加容器锁，因此某一个容器出现问题，并不会造成 docker 服务不可响应，受影响的也仅仅是该容器，无法执行任何操作。

至于为什么以 docker ps 与 docker inspect 为指标检查 docker 状态，因为 kubelet 就是依赖这两个 docker API 获取容器状态。

所以，现在问题有二：

  1. docker hang 死的根因是什么？
  2. docker hang 死时，为什么重启 kubelet，会导致宿主状态变为 NotReady？
    阅读全文 »

发表于 | 分类于 ， | | 热度: ℃
字数统计: 5,596 字 | 阅读时长 ≈ 25 分钟

一段时间以来，我一直在寻找 Linux 上的底层网络调试（debug）工具。

Linux 允许在主机上用虚拟网卡（virtual interface）和网络命名空间（network namespace）构建复杂的网络。但出现故障时，排障（troubleshooting）相当痛苦。如果是 3 层路由问题，mtr 可以排上用场。但如果是更底层的问题，我通常只能手动检查每个网 卡/网桥/网络命名空间/iptables 规则，用 tcpdump 抓一些包，以确定到底是什么状况。如 果不了解故障之前的网络设置，那感觉就像在走迷宫。

阅读全文 »