环境 tke(腾讯云容器服务) 1.12.4 托管集群. 节点操作系统：ubuntu16.04.1 LTSx86_64，4.4.0-104-generic kube-proxy mode: ipvs Docker version 18.06.3-ce, build d7080c1 过程 集群内的业务rpc请求大量超时，与kube-proxy的ipvs模式udp转发规则过期问题 的现象一致。 从集群-事件中观察到以下事件，且该节点有coredns的pod。 2020-06-14 13:15:39 Warning Node 172.21.128.138.1618e2878157535e Rebooted Node 172.21.128.138 has been rebooted, boot id: 281c2a66-2bb2-4274-b979-e1f50cc56fd 后客服反馈：CVM在当时发生了OOM。在得到云厂商客服的反馈后，运维同学没有继续跟进，只是简单的认为是编排中的资源配置问题，可能导致了OOM(我们的编排中, resources.limit.memory > resources.requests.memory)，对编排进行了调整。在后续的几天里，发生了4次类似的reboot情况，发生OOM时的时间点和内存监控图如下: 143, 2020-06-11 10:52 138, 2020-06-14 13:15 124, 2020-06-15 23:00 47, 2020-06-16 09:40 从以上的图表中发现： 发生OOM时，部分节点的free指标(绿色)是充裕的，按理不应该触发OOM。 发生OOM前，cache指标占80%。这可能是正常的。 我们将以上信息同步给了云厂商的技术支持，后反馈 ins-xxx ins-yyy 在这两个节点上都有发现上面的内核报错。我反馈给相关同事进一步看下 找到内核报错的方式 # journalctl --since "2020-06-14 13:00" --until "2020-06-14 14:00" ... Jun 14 13:14:38 host-172-21-128-138 kernel: ------------[ cut here ]------------ Jun 14 13:14:38 host-172-21-128-138 kernel: kernel BUG at /build/linux-SwhOyu/linux-4.

在引入 Kubernetes 时，我们需要提供对应的 CI/CD 方案。 需求&痛点 私有的统一认证，授权。角色，权限管控。 审计合规。主要包括测试人员发版，发版有历史，可审计追溯。 多云，多集群。 功能产品化。如：发版，扩容，回滚，下线。 “回滚”机制要求“编排文件”也需要用版本控制工具管理起来，版本化。 选型 rancher drone spinnaker helm 生态 为什么选择 Kubeapps Kubeapps 在整理这篇的时候，特意确认了 kubeapps 的最新架构，一些组件的名字已经发生了改变。 需求描述中的“编排文件版本化”，这正是 helm 的特性，虽然社区有其它的解决方案，但 helm 目前仍是那个应用最广泛的，成熟且有丰富的生态。 kubeapps 基于 helm。 kubeapps 是产品化的，而不是一个“轮子”。 封装良好的 api，极容易复用和扩展。这些 api 包括：整合了chartmuseum，并提供了chartsvc；tiller-proxy api；apprepository api；搜索 api，基于mongo的缓存，定时同步。 权限透明。它的权限完全是基于 Kubernetes 的 RBAC 机制，是透明的。 前端 React。 chartmuseum chartmuseum 是 helm 的 charts 仓库。 无状态 几乎支持所有云的对象存储作为后端，简单，安全。 由于我们的业务主要是在腾讯云，我们希望用其 cos 服务作为存储 backend。我们为社区提供了两个pr，完善了 chartmuseum 对腾讯云 cos 的支持。 https://github.com/helm/chartmuseum/pull/239 https://github.com/chartmuseum/storage/pull/30 系统架构 charts 的维护 charts 通过 git 进行版本控制，通过 MergeRequest(gitlab 的概念，github 叫 PullRequest) 提交变更，合并操作触发 CI 自动推送到 chartmuseum。下面是 CI 脚本，helm 的 push 插件需要自行安装。

我们在使用腾讯云容器服务(tke)的过程中，遇到"no route to host"问题，这里记录为运维日志。 环境 tke 1.12.4(1.14.3) 托管集群. 节点操作系统：ubuntu16.04.1 LTSx86_64 kube-proxy ipvs模式 /usr/bin/kube-proxy –proxy-mode=ipvs –ipvs-min-sync-period=1s –ipvs-sync-period=5s –ipvs-scheduler=rr –masquerade-all=true –kubeconfig=/etc/kubernetes/kubeproxy-kubeconfig –hostname-override=172.21.128.111 –v=2 运行时：Docker version 18.06.3-ce, build d7080c1 排查过程 请详见tke团队roc的文章Kubernetes 疑难杂症排查分享: 诡异的 No route to host 其它找到的一些有用的文章 https://engineering.dollarshaveclub.com/kubernetes-fixing-delayed-service-endpoint-updates-fd4d0a31852c https://fuckcloudnative.io/posts/kubernetes-fixing-delayed-service-endpoint-updates/ 中文版本 五元组：源IP地址，源端口，目的IP地址，目的端口，和传输层协议这五个量组成的一个集合 终局 kube-proxy ipvs conn_reuse_mode setting causes errors with high load from single client #81775 该issue说明了最终的解决方案，是通过操作系统来解决的。2020年7月，我们将所有TKE集群的节点更换为“CentOS 7.6 64bit TKE-Optimized”后，没有再出现过问题。关于如何判定自己的内核有没有应用这个修订，issue中有说明。

我们在使用腾讯云容器服务(tke)的过程中，遭遇了kube-proxy的ipvs模式udp转发规则过期问题，过程记录。 环境 tke 1.12.4 托管集群. 节点操作系统：ubuntu16.04.1 LTSx86_64 kube-proxy ipvs模式 /usr/bin/kube-proxy –proxy-mode=ipvs –ipvs-min-sync-period=1s –ipvs-sync-period=5s –ipvs-scheduler=rr –masquerade-all=true –kubeconfig=/etc/kubernetes/kubeproxy-kubeconfig –hostname-override=172.21.128.111 –v=2 运行时：Docker version 18.06.3-ce, build d7080c1 操作和现象 目标节点：172.21.128.109, 该节点有coredns, coredns的svc ClusterIP: 172.23.127.235。执行封锁后，执行drain操作。操作后的现象：业务大量报错“getaddrinfo failed: Name or service not known (10.010s)”,持续约8分钟. 和腾讯云的伙伴复盘时关注dns的变化.操作后会看到新的pod在172.21.128.111节点生成，在集群的任意节点上查看ipvs规则,发现tcp规则已更新成新podip，但udp规则还是老的podip。 # kubectl drain 172.21.128.109 # kubectl get pod -n kube-system -o wide|grep dns coredns-568cfc555b-4vdgk 1/1 Running 0 66s 172.23.3.41 172.21.128.111 <none> coredns-568cfc555b-7zkfz 1/1 Running 0 77d 172.23.0.144 172.21.128.10 <none> # ipvsadm -Ln|grep -A2 172.