阿里云售后技术专家,专注操作系统、容器集群。
在阿里云开发者社区的帮助下,这一年多写的《K8S从懵圈到熟练》系列做成了一本电子书。以下是对外发布的大纲和逐字稿。 大家好,我是阿里云的声东,我目前在阿里云全球技术服务部。 我们团队负责整个阿里云产品售后技术兜底的工作。
11月22号半夜2点,被值班同学的电话打醒。了解下来,大概情况是,客户某一台K8s集群节点重启之后,他再也无法创建Istio虚拟服务和Pod了。 一来对Istio还不是那么熟悉,二来时间可能有点晚,脑子还在懵圈中,本来一个应该比较轻松解决掉的问题,花了几十分钟看代码,处理的惨不忍睹。
之前分享过一例集群节点NotReady的问题。在那个问题中,我们的排查路劲,从K8S集群到容器运行时,再到sdbus和systemd,不可谓不复杂。那个问题目前已经在systemd中做了修复,所以基本上能看到那个问题的几率是越来越低了。
Istio is the future!基本上,我相信对云原生技术趋势有些微判断的同学,都会有这个觉悟。其背后的逻辑其实是比较简单的:当容器集群,特别是K8S成为事实上的标准之后,应用必然会不断的复杂化,服务治理肯定会成为强需求。
以我的经验来讲,理解K8S集群服务的概念,是比较不容易的一件事情。尤其是当我们基于似是而非的理解,去排查服务相关问题的时候,会非常不顺利。 这体现在,对于新手来说,ping不通服务的IP地址这样基础的问题,都很难理解;而就算对经验很丰富的工程师来说,看懂服务相关的iptables配置,也是相当的挑战。
阿里云售后技术团队的同学,每天都在处理各式各样千奇百怪的线上问题。常见的有,网络连接失败,服务器宕机,性能不达标,请求响应慢等。但如果要评选,什么问题看起来微不足道事实上却足以让人绞尽脑汁,我相信答案肯定是“删不掉”的问题。
当我们尝试去理解K8S集群工作原理的时候,控制器肯定是一个难点。这是因为控制器有很多,具体实现大相径庭;且控制器的实现用到了一些较为晦涩的机制,不易理解。但是,我们又不能绕过控制器,因为它是集群的“大脑”。
阿里云K8S集群的一个重要特性,是集群的节点可以动态的增加或减少。有了这个特性,集群才能在计算资源不足的情况下扩容新的节点,同时也可以在资源利用率降低的时候,释放节点以节省费用。 这篇文章,我们讨论阿里云K8S集群扩容与缩容的实现原理。
阿里云K8S集群网络目前有两种方案,一种是flannel方案,另外一种是基于calico和弹性网卡eni的terway方案。Terway和flannel类似,不同的地方在于,terway支持Pod弹性网卡,以及NetworkPolicy功能。
不知道大家有没有意识到一个现实,就是大部分时候,我们已经不像以前一样,通过命令行,或者可视窗口来使用一个系统了。现在我们上微博、或者网购,操作的其实不是眼前这台设备,而是一个又一个集群。 通常,这样的集群拥有成百上千个节点,每个节点是一台物理机或虚拟机。
排查完全陌生的问题,完全不熟悉的系统组件,是售后工程师的一大工作乐趣,当然也是挑战。今天借这篇文章,跟大家分析一例这样的问题。排查过程中,需要理解一些自己完全陌生的组件,比如systemd和dbus。