标签：kubernetes

背景

Kubernetes中的调度策略可以大致分为两种，一种是全局的调度策略，要在启动调度器时配置，包括kubernetes调度器自带的各种predicates和priorities算法，具体可以参看文章《Kubernetes调度详解》；另一种是运行时调度策略，包括nodeAffinity（主机亲和性），podAffinity（POD亲和性）以及podAntiAffinity（POD反亲和性）。

nodeAffinity 主要解决POD要部署在哪些主机，以及POD不能部署在哪些主机上的问题，处理的是POD和主机之间的关系。

podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题（拓扑域用主机标签实现，可以是单个主机，也可以是多个主机组成的cluster、zone等。），podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。

三种亲和性和反亲和性策略的比较如下表所示：

本文主要介绍如何使用亲和性和反亲和性做资源调度。

使用场景

nodeAffinity使用场景 ：

• 将S1服务的所有Pod部署到指定的符合标签规则的主机上。
• 将S1服务的所有Pod部署到除部分主机外的其他主机上。

podAffinity使用场景 ：

• 将某一特定服务的pod部署在同一拓扑域中，不用指定具体的拓扑域。
• 如果S1服务使用S2服务，为了减少它们之间的网络延迟（或其它原因），把S1服务的POD和S2服务的pod部署在同一拓扑域中。

podAntiAffinity使用场 景：

• 将一个服务的POD分散在不同的主机或者拓扑域中，提高服务本身的稳定性。
• 给POD对于一个节点的独占访问权限来保证资源隔离，保证不会有其它pod来分享节点资源。
• 把可能会相互影响的服务的POD分散在不同的主机上。

对于亲和性和反亲和性，每种都有三种规则可以设置：

RequiredDuringSchedulingRequiredDuringExecution ：在调度期间要求满足亲和性或者反亲和性规则，如果不能满足规则，则POD不能被调度到对应的主机上。在之后的运行过程中，如果因为某些原因（比如修改label）导致规则不能满足，系统会尝试把POD从主机上删除（现在版本还不支持）。

RequiredDuringSchedulingIgnoredDuringExecution ：在调度期间要求满足亲和性或者反亲和性规则，如果不能满足规则，则POD不能被调度到对应的主机上。在之后的运行过程中，系统不会再检查这些规则是否满足。

PreferredDuringSchedulingIgnoredDuringExecution ：在调度期间尽量满足亲和性或者反亲和性规则，如果不能满足规则，POD也有可能被调度到对应的主机上。在之后的运行过程中，系统不会再检查这些规则是否满足。

使用示例

使用POD亲和性调度时要先开启Kubernetes调度器的MatchInterPodAffinity筛选功能，具体的操作方式是修改调度器的配置文件，在predicates中增加如下内容：

{"name": "MatchInterPodAffinity"}

测试环境的主机信息如下：

其中每个主机上都有 beta.kubernetes.io/arch、beta.kubernetes.io/os、kubernetes.io/hostname这几个标签，在测试过程中把这些标签当做拓扑域使用。

nodeAffinity 使用示例:

使用nodeAffinity把POD部署到主机mesos-slave1和mesos-slave2上，yaml定义如下：

{
  "nodeAffinity": {
    "requiredDuringSchedulingIgnoredDuringExecution": {
      "nodeSelectorTerms": [
        {
          "matchExpressions": [
            {
              "key": "kubernetes.io/hostname",
              "operator": "In",
              "values": [
                "mesos-slave1",
                "mesos-slave2"
              ]
            }
          ]
        }
      ]
    }
  }
}

创建一个有6个POD的RC，结果如下:

从结果可以看出POD被部署到了mesos-slave1和mesos-slave2上，mesos-slave3上没有部署POD。

podAffinity使用示例 ：

使用kubernetes.io/hostname作为拓扑域，把pod创建在同一主机上。其中matchExpressions中填写内容对应到RC中POD自身的标签。可以通过修改需要匹配的标签内容来控制把一个服务中的POD和其它服务的POD部署在同一主机上。

yaml中的定义如下：

{
  "podAffinity": {
    "requiredDuringSchedulingIgnoredDuringExecution": [
      {
        "labelSelector": {
          "matchExpressions": [
            {
              "key": "name",
              "operator": "In",
              "values": [
                "node-rc"
              ]
            }
          ]
        },
        "topologyKey": "kubernetes.io/hostname"
      }
    ]
  }
}

创建一个有3个POD的RC，结果如下：

所有创建的POD集中在同一个主机上，具体的主机是哪个不需要指定。

podAntiAffinity 使用示例：

使用kubernetes.io/hostname作为拓扑域，把pod创建在不同主机上，每个主机上最多只有一个同类型的POD（同类型用标签区分）。其中matchExpressions中填写内容对应到RC中POD自身的标签。可以通过修改需要匹配的标签内容来控制把一个服务中的POD和其它服务的POD部署在不同主机上。

yaml中的定义如下：

{
  "podAntiAffinity": {
    "requiredDuringSchedulingIgnoredDuringExecution": [
      {
        "labelSelector": {
          "matchExpressions": [
            {
              "key": "name",
              "operator": "In",
              "values": [
                "node-rc"
              ]
            }
          ]
        },
        "topologyKey": "kubernetes.io/hostname"
      }
    ]
  }
}

创建一个有4个POD的RC，结果如下：

三个主机上都有一个POD运行，因为每个主机上最多只能运行一个这种类型的POD，所以有一个POD一直处于Pending状态，不能调度到任何节点。

上边的例子中可以通过修改topologyKey来限制拓扑域的范围，实现把相关服务部署在不同的容灾域等其它功能。

总结

Kubernetes提供了丰富的调度策略，包括静态的全局调度策略，以及动态的运行时调度策略，用户可以根据需要自由组合使用这些策略来实现自己的需求。在调度过程中，使用nodeAffnity决定资源可以部署在哪些主机上，使用podAffinity和podAntiAffinity决定哪些资源需要部署在同一主机（拓扑域）或者不能部署在同一主机。

由于在企业中部署私有云的场景会更普遍，所以在私有云中运行Kubernetes + Docker集群之前，就需要自己搭建符合Kubernetes要求的网络环境。现在的开源世界里，有很多开源组件可以帮助我们打通Docker容器和容器之间的网络，实现Kubernetes要求的网络模型。当然每种方案都有自己适合的场景，我们要根据自己的实际需要进行选择。

一、Kubernetes + Flannel

Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（Google Compute Engine）里面是现成的网络模型，Kubernetes假定这个网络已经存在。而在私有云里搭建Kubernetes集群，就不能假定这个网络已经存在了。我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问先打通，然后运行Kubernetes。

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。

下面是一张它的网络原理图：

可以看到，Flannel首先创建了一个名为flannel0的网桥，而且这个网桥的一端连接docker0的网桥，另一端连接一个名为flanneld的服务进程。

Flanneld进程并不简单，它首先上连etcd，利用etcd来管理可分配的IP地址段资源，同时监控etcd中每个Pod的实际地址，并在内存中建立了一个Pod节点路由表；然后下连docker0和物理网络，使用内存中的Pod节点路由表，将docker0发给它的数据包包装起来，利用物理网络的连接将数据包投递到目标flanneld上，从而完成pod到pod之间的直接的地址通信。

Flannel之间的底层通信协议的可选余地有很多，比如UDP、VXlan、AWS VPC等等。只要能通到对端的Flannel就可以了。源Flannel封包，目标Flannel解包，最终docker0看到的就是原始的数据，非常透明，根本感觉不到中间Flannel的存在。

Flannel的安装配置网上讲的很多，在这里就不在赘述了。在这里注意一点，就是flannel使用etcd作为数据库，所以需要预先安装好etcd。

下面说说几个场景：

1. 同一Pod内的网络通信。在同一个Pod内的容器共享同一个网络命名空间，共享同一个Linux协议栈。所以对于网络的各类操作，就和它们在同一台机器上一样，它们可以用localhost地址直接访问彼此的端口。其实这和传统的一组普通程序运行的环境是完全一样的，传统的程序不需要针对网络做特别的修改就可以移植了。这样做的结果是简单、安全和高效，也能减少将已经存在的程序从物理机或者虚拟机移植到容器下运行的难度。

2. Pod1到Pod2的网络，分两种情况。Pod1与Pod2不在同一台主机与Pod1与Pod2在同一台主机。

• 先说Pod1与Pod2不在同一台主机。Pod的地址是与docker0在同一个网段的，但docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。
• Pod1与Pod2在同一台主机。Pod1和Pod2在同一台主机的话，由Docker0网桥直接转发请求到Pod2，不需要经过Flannel。

1. Pod到Service的网络。创建一个Service时，相应会创建一个指向这个Service的域名，域名规则为{服务名}.{namespace}.svc.{集群名称}。之前Service IP的转发由iptables和kube-proxy负责，目前基于性能考虑，全部为iptables维护和转发。iptables则由kubelet维护。Service仅支持UDP和TCP协议，所以像ping的ICMP协议是用不了的，所以无法ping通Service IP。

2. Pod到外网。Pod向外网发送请求，查找路由表, 转发数据包到宿主机的网卡，宿主网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求。

3. 集群外部访问Pod或Service

由于Pod和Service是Kubernetes集群范围内的虚拟概念，所以集群外的客户端系统无法通过Pod的IP地址或者Service的虚拟IP地址和虚拟端口号访问到它们。为了让外部客户端可以访问这些服务，可以将Pod或Service的端口号映射到宿主机，以使得客户端应用能够通过物理机访问容器应用。

总结：Flannel实现了对Kubernetes网络的支持，但是它引入了多个网络组件，在网络通信时需要转到flannel0网络接口，再转到用户态的flanneld程序，到对端后还需要走这个过程的反过程，所以也会引入一些网络的时延损耗。另外Flannel默认的底层通信协议是UDP。UDP本身是非可靠协议，虽然两端的TCP实现了可靠传输，但在大流量、高并发应用场景下还需要反复调试，确保不会出现传输质量的问题。特别是对网络依赖重的应用，需要评估对业务的影响。

二、基于Docker Libnetwork的网络定制

容器跨主机的网络通信，主要实现思路有两种：二层VLAN网络和Overlay网络。

• 二层VLAN网络的解决跨主机通信的思路是把原先的网络架构改造为互通的大二层网络，通过特定网络设备直接路由，实现容器点到点的之间通信。
• Overlay网络是指在不改变现有网络基础设施的前提下，通过某种约定通信协议，把二层报文封装在IP报文之上的新的数据格式。

Libnetwork是Docker团队将Docker的网络功能从Docker核心代码中分离出去，形成一个单独的库。 Libnetwork通过插件的形式为Docker提供网络功能。 使得用户可以根据自己的需求实现自己的Driver来提供不同的网络功能。

Libnetwork所要实现的网络模型基本是这样的： 用户可以创建一个或多个网络（一个网络就是一个网桥或者一个VLAN ），一个容器可以加入一个或多个网络。 同一个网络中容器可以通信，不同网络中的容器隔离。这才是将网络从docker分离出去的真正含义，即在创建容器之前，我们可以先创建网络（即创建容器与创建网络是分开的），然后决定让容器加入哪个网络。

Libnetwork实现了5种网络模式：

• bridge：Docker默认的容器网络驱动，Container通过一对veth pair链接到docker0网桥上，由Docker为容器动态分配IP及配置路由、防火墙等。
• host：容器与主机共享同一Network Namespace。
• null：容器内网络配置为空，需要用户手动为容器配置网络接口及路由。
• remote：Docker网络插件的实现，Remote driver使得Libnetwork可以通过HTTP Resful API 对接第三方的网络方案，类似于SocketPlane的SDN方案只要实现了约定的HTTP URL处理函数以及底层的网络接口配置方法，就可以替代Docker原生的网络实现。
• overlay：Docker原生的跨主机多子网网络方案。

Docker自身的网络功能比较简单，不能满足很多复杂的应用场景。因此，有很多开源项目用来改善Docker的网络功能，如Pipework、Weave、SocketPlane等。

举例：网络配置工具Pipework

Pipework是一个简单易用的Docker容器网络配置工具。由200多行shell脚本实现。通过使用IP、brctl、ovs-vsctl等命令来为Docker容器配置自定义的网桥、网卡、路由等。有如下功能：

• 支持使用自定义的Linux Bridge、veth pair为容器提供通信。
• 支持使用MacVLAN设备将容器连接到本地网络。
• 支持DHCP获取容器的IP。
• 支持Open vSwitch。
• 支持VLAN划分。

Pipework简化了在复杂场景下对容器连接的操作命令，为我们配置复杂的网络拓扑提供了一个强有力的工具。对于一个基本应用而言，Docker的网络模型已经很不错了。然而，随着云计算和微服务的兴起，我们不能永远停留在使用基本应用的级别上，我们需要性能更好且更灵活的网络功能。Pipework是个很好的网络配置工具，但Pipework并不是一套解决方案，我们可以利用它提供的强大功能，根据自己的需求添加额外的功能，帮助我们构建自己的解决方案。

OVS跨主机多子网网络方案

OVS的优势是，作为开源虚拟交换机软件，它相对成熟和稳定，而且支持各类网络隧道协议，经过了OpenStack等项目的考验。这个网上很多，就不再赘述了。

三、Kubernetes集成Calico

Calico是一个纯3层的数据中心网络方案，而且无缝集成像OpenStack这种IaaS云架构，能够提供可控的VM、容器、裸机之间的IP通信。

通过将整个互联网的可扩展IP网络原则压缩到数据中心级别，Calico在每一个计算节点利用Linux Kernel实现了一个高效的vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息像整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGP route reflector来完成。这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。

Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。

Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。

Calico有两种布署方案，一般集群都配有SSL证书和非证书的情况。

• 第一种无HTTPS连接etcd方案，HTTP模式部署即没有证书，直接连接etcd
• 第二种HTTPS连接etcd集群方案，加载etcd https证书模式，有点麻烦

总结：目前Kubernetes网络最快的第一就是Calico，第二种稍慢Flannel，根据自己的网络环境条件来定。 Calico作为一款针对企业级数据中心的虚拟网络工具，借助BGP、路由表和iptables，实现了一个无需解包封包的三层网络，并且有调试简单的特点。虽然目前还有些小缺陷，比如stable版本还无法支持私有网络，但希望在后面的版本中会更加强大。

四、应用容器IP固定（参考网上资料）

Docker 1.9开始支持Contiv Netplugin，Contiv带来的方便是用户可以根据实例IP直接进行访问。

Docker 1.10版本支持指定IP启动容器，并且由于部分数据库应用对实例IP固定有需求，有必要研究容器IP固定方案的设计。

在默认的Kubernetes + Contiv的网络环境下，容器Pod的IP网络连接是由Contiv Network Plugin来完成的，Contiv Master只实现了简单的IP地址分配和回收，每次部署应用时，并不能保证Pod IP不变。所以可以考虑引入新的Pod层面的IPAM（IP地址管理插件），以保证同一个应用多次发生部署时，Pod IP始终是不变的。

作为Pod层面的IPAM，可以把这一功能直接集成在Kubernetes里。Pod作为Kubernetes的最小调度单元，原有的Kubernetes Pod Registry（主要负责处理所有与Pod以及Pod subresource相关的请求：Pod的增删改查，Pod的绑定及状态更新，exec/attach/log等操作）并不支持在创建Pod时为Pod分配IP，Pod IP是通过获取Pod Infra Container的IP来获取的，而Pod Infra Container的IP即为Contiv动态分配得来的。

在原有Kubernetes代码基础上，修改Pod结构（在PodSpec中加入PodIP）并重写了Pod Registry同时引入了两个新的资源对象：

• Pod IP Allocator：Pod IP Allocator是一个基于etcd的IP地址分配器，主要实现Pod IP的分配与回收。Pod IP Allocator通过位图记录IP地址的分配情况，并且将该位图持久化到etcd；
• Pod IP Recycler：Pod IP Recycler是一个基于etcd的IP地址回收站，也是实现PodConsistent IP的核心。Pod IP Recycler基于RC全名（namespace + RC name）记录每一个应用曾经使用过的IP地址，并且在下一次部署的时候预先使用处于回收状态的IP。Pod IP Recycler只会回收通过RC创建的Pod的IP，通过其他controller或者直接创建的Pod的IP并不会记录，所以通过这种方式创建的Pod的IP并不会保持不变；同时Pod IP Recycle检测每个已回收IP对象的TTL，目前设置的保留时间为一天。

这里对kubelet也需要进行改造，主要包括根据Pod Spec中指定IP进行相关的容器创建（docker run加入IP指定）以及Pod删除时释放IP操作。

Pod的创建在PaaS里主要有两种情形：

• 应用的第一次部署及扩容，这种情况主要是从IP pool中随机分配；
• 应用的重新部署：在重新部署时，已经释放的IP已根据RC全名存放于IP Recycle列表中，这里优先从回收列表中获取IP，从而达到IP固定的效果。

另外为了防止IP固定方案中可能出现的问题，在Kubernetes中加入了额外的REST API：包括对已分配IP的查询，手动分配/释放IP。

容器IP固定方案已测试评估中，运行基本上没问题，但稳定性有待提升。主要表现在有时不能在预期时间内停止旧Pod，从而无法释放IP造成无法复用（初步原因是由于Docker偶尔的卡顿造成无法在规定时间内停止容器），可以手动去修复。但从长期考虑，IP固定方案还需要加强稳定性并根据具体需求进行优化。

总结：目前已有多种支持Kubernetes的网络方案，比如Flannel、Calico、华为的Canal、Weave Net等。因为它们都实现了CNI规范，用户无论选择哪种方案，得到的网络模型都一样，即每个Pod都有独立的 IP，可以直接通信。区别在于不同方案的底层实现不同，有的采用基于VXLAN的Overlay实现，有的则是Underlay，性能上有区别，再有就是是否支持Network Policy了。

【编者的话】本文是Kubernetes监控系列的第三篇，主要讲述了Kubernetes的故障排除以及服务发现。

本文是关于在生产中使用Kubernetes系列的一部分。第一部分介绍了Kubernetes和监控工具的基础知识；第二部分涵盖了Kubernetes报警的最佳实践。这部分将介绍对Kubernetes故障排除，特别是服务发现，最后一部分是监控Kubernetes的实际使用案例。像Kubernetes，DC / OS Mesos或Docker Swarm这样的容器编排平台可以帮助你方便地管理容器，但对解决容器问题并没有什么帮助：

• 它们是孤立的，你和你要监视的进程之间存在一定的障碍，在主机上运行的传统故障排除工具不了解容器、命名空间和编排平台。
• 它们带来最小的运行时间，只需要服务及其依赖项，而不需要所有的故障排除工具，想象下只用busybox来进行故障排除！
• 它们调度在你集群、进行容器移动，扩容或者缩容。随着流程的结束，它们变得非常不稳定，出现并消失。
• 并通过新的虚拟网络层互相通信。

本文将通过一个真实用例讲诉如何在Kubernetes中进行故障排除。我们将涵盖Kubernetes内部3个不同层的故障排除：

• 第一部分：Kubernetes故障排除之服务发现
• 第二部分：Kubernetes故障排除之DNS解析
• 第三部分：Kubernetes故障排除之使用Docker运行容器

本文场景将使用一个简单的Kubernetes服务，包括3个Nginx pod和一个带有curl命令的客户端。在链接中可以看到场景需要使用的yaml文件 backend.yaml。如果你刚刚接触Kubernetes，可以看下“Understanding how Kubernetes DNS services work”这篇文章来学习如何部署上述服务。实际操作如下：

$ kubectl create namespace critical-app
namespace "critical-app" created
$ kubectl create -f backend.yaml
service "backend" created
deployment "backend" created

然后创建一个客户端来加载我们的后端服务：

$ kubectl run -it --image=tutum/curl client --namespace critical-app --restart=Never

第一部分：Kubernetes故障排除之服务发现

在我们的client容器中可以运行一个简单测试 root@client:/# curl backend 来查看我们的Kubernetes service是如何工作的。但我们不想遗漏下什么，我们认为可以使用FQDN进行服务发现测试，在Kubernetes文档中会发现，每个service都会获得一个默认的DNS：my-svc.my-namespace.svc.cluster.local。因此，我们用它作为FQDN进行测试。

在client容器的shell端运行：root@client:/# curl backend.critical-app.svc.cluster.local，不过这次curl命令卡住了10秒，然后返回了预期网址！作为一个分布式系统工程师，这是最糟糕的事情之一：你希望直接失败或者成功，而不是等待10秒。

为了定位出问题，我们使用了Sysdig。Sysdig是一个开源Linux可视化工具，提供对容器的本地可见性，包括Docker、Kubernetes、DC / OS和Mesos等等。将htop，tcpdump，strace，lsof，netstat等的功能组合在一起，Sysdig提供了Kubernetes基础架构环境中的所有系统调用和应用程序数据。Monitoring Kubernetes with Sysdig中很好地介绍了如何在Kubernetes中使用这个工具。

为了分析上述问题原因，我们将请求sysdig来dump所有信息到捕获文件中：

$ sudo sysdig -k http://127.0.0.1:8080 -s8192 -zw capture.scap

快速解释下每个参数：

• -k http://localhost:8080 连接Kubernetes API
• -s8192 扩大IO缓冲区，因为我们需要显示全部内容，否则默认情况下会被切断，
• -zw capture.scap 将系统调用与元数据信息压缩并dump到文件中

同时，我们将再次运行curl命令来复现这个问题：# curl backend.critical-app.svc.cluster.local。这确保了我们在上面捕获的文件中拥有所有数据，以重现场景并解决问题。

一旦curl返回，我们可以执行Ctrl+C来终止数据捕获，并且我们将拥有一个10s的捕获文件，包括我们的Kubernetes主机中发生的所有事情以及服务发现过程。现在我们可以开始在集群内或集群外解决问题，只要在安装了sysdig的环境中复制文件：

$ sysdig -r capture.scap -pk -NA "fd.type in (ipv4, ipv6) and (k8s.ns.name=critical-app or proc.name=skydns)" | less

快速解释下每个参数：

• -r capture.scap 读取捕获文件
• -pk 打印Kubernetes部分到stdout中
• -NA 显示ASCII输出

以及双引号中是过滤内容。Sysdig能够理解Kubernetes语义，因此我们可以过滤来自名称空间critical-app中的任何容器或任何名为skydns的进程的套接字IPv4或IPv6上的流量。加入proc.name = skydns因为这是内部Kubernetes DNS解析器，并且作为Kubernetes基础结构的一部分运行在我们的命名空间之外。

Sysdig也有一个交互式的ncurses接口。

为了跟随此服务发现故障排除示例，你可以下载捕获文件capture.scap并使用sysdig自行查看它。

我们立即看到curl如何尝试解析域名，但在DNS查询有效载荷上我们有些奇怪（10049）：backend.critical-app.svc.cluster.local.critical-app.svc.cluster.local。看上去由于某些原因，curl不识别已经给定的FQDN，并且决定追加一个搜索域。

[...]
10030 16:41:39.536689965 0 client (b3a718d8b339) curl (22370:13) < socket fd=3(<4>)
10031 16:41:39.536694724 0 client (b3a718d8b339) curl (22370:13) > connect fd=3(<4>)
10032 16:41:39.536703160 0 client (b3a718d8b339) curl (22370:13) < connect res=0 tuple=172.17.0.7:46162->10.0.2.15:53
10048 16:41:39.536831645 1  (36ae6d09d26e) skydns (17280:11) > recvmsg fd=6(<3t>:::53)
10049 16:41:39.536834352 1  (36ae6d09d26e) skydns (17280:11) < recvmsg res=87 size=87 data=
backendcritical-appsvcclusterlocalcritical-appsvcclusterlocal tuple=::ffff:172.17.0.7:46162->:::53
10050 16:41:39.536837173 1  (36ae6d09d26e) skydns (17280:11) > recvmsg fd=6(<3t>:::53)
[...]

SkyDNS发送请求（10097）到etcd的API（/local/cluster/svc/critical-app/local/cluster/svc/critical-app/backend），显然etcd不能识别这个service，然后返回（10167）“Key not found”。这通过DNS查询响应传回给curl。

[...]
10096 16:41:39.538247116 1  (36ae6d09d26e) skydns (4639:8) > write fd=3(<4t>10.0.2.15:34108->10.0.2.15:4001) size=221
10097 16:41:39.538275108 1  (36ae6d09d26e) skydns (4639:8) < write res=221 data=
GET /v2/keys/skydns/local/cluster/svc/critical-app/local/cluster/svc/critical-app/backend?quorum=false&recursive=true&sorted=false HTTP/1.1
Host: 10.0.2.15:4001
User-Agent: Go 1.1 package http
Accept-Encoding: gzip


10166 16:41:39.538636659 1  (36ae6d09d26e) skydns (4617:1) > read fd=3(<4t>10.0.2.15:34108->10.0.2.15:4001) size=4096
10167 16:41:39.538638040 1  (36ae6d09d26e) skydns (4617:1) < read res=285 data=
HTTP/1.1 404 Not Found
Content-Type: application/json
X-Etcd-Cluster-Id: 7e27652122e8b2ae
X-Etcd-Index: 1259
Date: Thu, 08 Dec 2016 15:41:39 GMT
Content-Length: 112

{"errorCode":100,"message":"Key not found","cause":"/skydns/local/cluster/svc/critical-app/local","index":1259}
[...]

curl没有放弃并再次尝试（10242），不过这次用的是backend.critical-app.svc.cluster.local.svc.cluster.local。看起来这次curl尝试将critical-app这个追加搜索域去除，使用一个不同的搜索域。显然，当请求到达etcd（10247）时，再次失败（10345）。

[...]
10218 16:41:39.538914765 0 client (b3a718d8b339) curl (22370:13) < connect res=0 tuple=172.17.0.7:35547->10.0.2.15:53
10242 16:41:39.539005618 1  (36ae6d09d26e) skydns (17280:11) < recvmsg res=74 size=74 data=
backendcritical-appsvcclusterlocalsvcclusterlocal tuple=::ffff:172.17.0.7:35547->:::53
10247 16:41:39.539018226 1  (36ae6d09d26e) skydns (17280:11) > recvmsg fd=6(<3t>:::53)
10248 16:41:39.539019925 1  (36ae6d09d26e) skydns (17280:11) < recvmsg res=74 size=74 data=
0]backendcritical-appsvcclusterlocalsvcclusterlocal tuple=::ffff:172.17.0.7:35547->:::53
10249 16:41:39.539022522 1  (36ae6d09d26e) skydns (17280:11) > recvmsg fd=6(<3t>:::53)
10273 16:41:39.539210393 1  (36ae6d09d26e) skydns (4639:8) > write fd=3(<4t>10.0.2.15:34108->10.0.2.15:4001) size=208
10274 16:41:39.539239613 1  (36ae6d09d26e) skydns (4639:8) < write res=208 data=
GET /v2/keys/skydns/local/cluster/svc/local/cluster/svc/critical-app/backend?quorum=false&recursive=true&sorted=false HTTP/1.1
Host: 10.0.2.15:4001
User-Agent: Go 1.1 package http
Accept-Encoding: gzip


10343 16:41:39.539465153 1  (36ae6d09d26e) skydns (4617:1) > read fd=3(<4t>10.0.2.15:34108->10.0.2.15:4001) size=4096
10345 16:41:39.539467440 1  (36ae6d09d26e) skydns (4617:1) < read res=271 data=
HTTP/1.1 404 Not Found
[...]

curl会再次尝试，我们可以看这次的DNS查询请求（10418），加上了cluster.local变成backend.critical-app.svc.cluster.local.cluster.local。这次etcd请求（10479）同样失败（10524）。

[...]
10396 16:41:39.539686075 0 client (b3a718d8b339) curl (22370:13) < connect res=0 tuple=172.17.0.7:40788->10.0.2.15:53
10418 16:41:39.539755453 0  (36ae6d09d26e) skydns (17280:11) < recvmsg res=70 size=70 data=
backendcritical-appsvcclusterlocalclusterlocal tuple=::ffff:172.17.0.7:40788->:::53
10433 16:41:39.539800679 0  (36ae6d09d26e) skydns (17280:11) > recvmsg fd=6(<3t>:::53)
10434 16:41:39.539802549 0  (36ae6d09d26e) skydns (17280:11) < recvmsg res=70 size=70 data=
backendcritical-appsvcclusterlocalclusterlocal tuple=::ffff:172.17.0.7:40788->:::53
10437 16:41:39.539805177 0  (36ae6d09d26e) skydns (17280:11) > recvmsg fd=6(<3t>:::53)
10478 16:41:39.540166087 1  (36ae6d09d26e) skydns (4639:8) > write fd=3(<4t>10.0.2.15:34108->10.0.2.15:4001) size=204
10479 16:41:39.540183401 1  (36ae6d09d26e) skydns (4639:8) < write res=204 data=
GET /v2/keys/skydns/local/cluster/local/cluster/svc/critical-app/backend?quorum=false&recursive=true&sorted=false HTTP/1.1
Host: 10.0.2.15:4001
User-Agent: Go 1.1 package http
Accept-Encoding: gzip


10523 16:41:39.540421040 1  (36ae6d09d26e) skydns (4617:1) > read fd=3(<4t>10.0.2.15:34108->10.0.2.15:4001) size=4096
10524 16:41:39.540422241 1  (36ae6d09d26e) skydns (4617:1) < read res=267 data=
HTTP/1.1 404 Not Found
[...]

对于未经训练的人来说，可能看起来我们发现了这个问题：一堆无效的请求。但实际上这不是事实，如果我们查看时间戳，第一个etcd请求（10097）和最后一个（10479）之间的差异，第二列中的时间戳相距小于10ms。而我们正在寻找一个秒数问题，而不是毫秒——那么等待的时间在哪里？

当我们继续浏览捕获文件时，我们可以看到curl不停止尝试使用DNS查询到SkyDNS，现在使用backend.critical-app.svc.cluster.local.localdomain（10703）。这个.localdomain不被SkyDNS识别为Kubernetes的内部域，因此它决定将这个查询转发给它的上游DNS解析器（10691），而不是去etcd进行服务发现。

[...]
10690 16:41:39.541376928 1  (36ae6d09d26e) skydns (4639:8) > connect fd=8(<4>)
10691 16:41:39.541381577 1  (36ae6d09d26e) skydns (4639:8) < connect res=0 tuple=10.0.2.15:44249->8.8.8.8:53
10702 16:41:39.541415384 1  (36ae6d09d26e) skydns (4639:8) > write fd=8(<4u>10.0.2.15:44249->8.8.8.8:53) size=68
10703 16:41:39.541531434 1  (36ae6d09d26e) skydns (4639:8) < write res=68 data=
Nbackendcritical-appsvcclusterlocallocaldomain
10717 16:41:39.541629507 1  (36ae6d09d26e) skydns (4639:8) > read fd=8(<4u>10.0.2.15:44249->8.8.8.8:53) size=512
10718 16:41:39.541632726 1  (36ae6d09d26e) skydns (4639:8) < read res=-11(EAGAIN) data=
58215 16:41:43.541261462 1  (36ae6d09d26e) skydns (4640:9) > close fd=7(<4u>10.0.2.15:54272->8.8.8.8:53)
58216 16:41:43.541263355 1  (36ae6d09d26e) skydns (4640:9) < close res=0
[...]

扫描时间戳列时，我们发现SkyDNS发出请求后第一个较大的间隙，然后等待大约4秒（10718-58215）。鉴于.localdomain不是有效的TLD（顶级域名），上游服务器将只是忽略此请求。超时后，SkyDNS再次尝试使用相同的查询（75923），再等待几秒钟（75927-104208）。总的来说，我们一直在等待大约8秒钟，以查找不存在并且被忽略的DNS条目。

[...]
58292 16:41:43.542822050 1  (36ae6d09d26e) skydns (4640:9) < write res=68 data=
Nbackendcritical-appsvcclusterlocallocaldomain
58293 16:41:43.542829001 1  (36ae6d09d26e) skydns (4640:9) > read fd=8(<4u>10.0.2.15:56371->8.8.8.8:53) size=512
58294 16:41:43.542831896 1  (36ae6d09d26e) skydns (4640:9) < read res=-11(EAGAIN) data=
75904 16:41:44.543459524 0  (36ae6d09d26e) skydns (17280:11) < recvmsg res=68 size=68 data=
[...]
75923 16:41:44.543560717 0  (36ae6d09d26e) skydns (17280:11) < recvmsg res=68 size=68 data=
Nbackendcritical-appsvcclusterlocallocaldomain tuple=::ffff:172.17.0.7:47441->:::53
75927 16:41:44.543569823 0  (36ae6d09d26e) skydns (17280:11) > recvmsg fd=6(<3t>:::53)
104208 16:41:47.551459027 1  (36ae6d09d26e) skydns (4640:9) > close fd=7(<4u>10.0.2.15:42126->8.8.8.8:53)
104209 16:41:47.551460674 1  (36ae6d09d26e) skydns (4640:9) < close res=0
[...]

但最后，它一切正常！为什么？curl停止尝试修补事物并应用搜索域。当我们在命令行中输入时，它会逐字尝试域名。SkyDNS通过etcd服务发现API请求解析DNS请求（104406）。打开一个与服务IP地址（107992）的连接，然后使用iptables将其转发给Pod，并且HTTP响应返回到curl容器（108024）。

[...]
104406 16:41:47.552626262 0  (36ae6d09d26e) skydns (4639:8) < write res=190 data=
GET /v2/keys/skydns/local/cluster/svc/critical-app/backend?quorum=false&recursive=true&sorted=false HTTP/1.1
[...]
104457 16:41:47.552919333 1  (36ae6d09d26e) skydns (4617:1) < read res=543 data=
HTTP/1.1 200 OK
[...]
{"action":"get","node":{"key":"/skydns/local/cluster/svc/critical-app/backend","dir":true,"nodes":[{"key":"/skydns/local/cluster/svc/critical-app/back
end/6ead029a","value":"{"host":"10.3.0.214","priority":10,"weight":10,"ttl":30,"targetstrip":0}","modifiedIndex":270,"createdIndex":270}],
"modifiedIndex":270,"createdIndex":270}}
[...]
107992 16:41:48.087346702 1 client (b3a718d8b339) curl (22369:12) < connect res=-115(EINPROGRESS) tuple=172.17.0.7:36404->10.3.0.214:80
108002 16:41:48.087377769 1 client (b3a718d8b339) curl (22369:12) > sendto fd=3(<4t>172.17.0.7:36404->10.3.0.214:80) size=102 tuple=NULL
108005 16:41:48.087401339 0 backend-1440326531-csj02 (730a6f492270) nginx (7203:6) < accept fd=3(<4t>172.17.0.7:36404->172.17.0.5:80) tuple=172.17.0.7:36404->172.17.0.5:80 queuepct=0 queuelen=0 queuemax=128
108006 16:41:48.087406626 1 client (b3a718d8b339) curl (22369:12) < sendto res=102 data=
GET / HTTP/1.1
[...]
108024 16:41:48.087541774 0 backend-1440326531-csj02 (730a6f492270) nginx (7203:6) < writev res=238 data=
HTTP/1.1 200 OK
Server: nginx/1.10.2
[...]

通过系统层面的情况，我们可以得出结论：造成这个问题的根本原因有两个方面。首先，当我给curl一个FQDN时，它不相信我并试图应用搜索域算法。其次，.localdomain不应该存在，因为它在我们的Kubernetes集群中是不可路由的。

如果你认为这是通过使用tcpdump也能完成，只是你还没尝试。我能100％肯定它不会被安装在你的容器内，你可以在主机外部运行它，但祝你找到与对应Kubernetes调度容器的网络命名空间匹配的网络接口。请继续阅读：我们还没有完成故障排除。

第二部分：Kubernetes故障排除之DNS解析

让我们看看resolv.conf文件中的内容。容器可能已经不存在了，或者curl调用后文件可能已经改变。但是我们有一个包含发生了所有事情的捕获文件。

通常情况下，容器的运行时间与进程内运行的时间一样长，当进程结束时容器就消失了。这是对容器进行故障排除最具挑战性的部分之一。我们如何探索已经消失的东西？我们如何重现发生的事情？在这些情况下，Sysdig捕获文件非常有用。

我们来分析捕获文件，但不是过滤网络流量，我们将在这次对resolv文件进行过滤。我们希望看到resolv.conf与curl读取的完全一样，以确认我们的想法，它包含localdomain。

$ sysdig -pk -NA -r capture.scap -c echo_fds "fd.type=file and fd.name=/etc/resolv.conf"
------ Read 119B from  [k8s_client.eee910bc_client_critical-app_da587b4d-bd5a-11e6-8bdb-028ce2cfb533_bacd01b6] [b3a718d8b339]  /etc/resolv.conf (curl)

search critical-app.svc.cluster.local svc.cluster.local cluster.local localdomain
nameserver 10.0.2.15
options ndots:5
[...]

这是使用sysdig的一种新的方式：

-c echo_fds 使用Sysdig chisel——附加脚本——用以聚合信息并格式化输出。此外，过滤器仅包含文件描述符上的IO活动，该文件描述符是一个文件，名称为/etc/resolv.conf，正是我们所要寻找的。

通过系统调用，我们看到有一个选项叫做ndots。 此选项是curl不信任我们的FQDN并试图首先追加所有搜索域的原因。如果你阅读了manpage，就会知道ndots会强制libc，任何小于5个点的域名解析都不会被视为fqdn，但会尝试首先追加所有搜索域。ndots有一个很好的理由，所以我们可以执行 curl backend。但是谁在那里添加了localdomain？

第三部分：Kubernetes故障排除之使用Docker运行容器

我们不想在没有找到这个本地域的罪魁祸首的情况下完成我们的故障排除。 这样，我们可以责怪软件而不是人，是Docker加了搜索域？或者Kubernetes在创建容器时指导Docker这么做？

既然我们知道Kubernetes和Docker之间的所有控制通信都是通过Unix套接字完成的，我们可以使用它来过滤掉所有的东西：

$ sudo sysdig -pk -s8192 -c echo_fds -NA "fd.type in (unix) and evt.buffer contains localdomain"

这一次，我们将使用一个非常棒的过滤器的来捕捉现场 evt.buffer containers。 这个过滤器需要所有的事件缓冲区，如果它包含我们正在寻找的字符串，将被我们的chisel捕获并格式化输出。

现在我需要创建一个新的客户端来窥探容器编排时发生的情况：

$ kubectl run -it --image=tutum/curl client-foobar --namespace critical-app --restart=Never

可以看到，Kubernetes中的hyperkube使用Docker API在/var/run/docker.sock上写了一个HTTP POST请求到/containers/create。如果我们通读它，我们会发现这个请求包含一个选项“DnsSearch”：[“critical-app.svc.cluster.local”，“svc.cluster.local”，“cluster.local”，“localdomain”]。Kubernetes，我们抓到你了！很可能它出于某种原因，就像我的本地开发机器设置了该搜索域一样。无论如何，这是一个不同的故事。

[...]
------ Write 2.61KB to  [k8s-kubelet] [de7157ba23c4]   (hyperkube)

POST /containers/create?name=k8s_POD.d8dbe16c_client-foobar_critical-app_085ac98f-bd64-11e6-8bdb-028ce2cfb533_9430448e HTTP/1.1
Host: docker
[...]
"DnsSearch":["critical-app.svc.cluster.local","svc.cluster.local","cluster.local","localdomain"],
[...]

总结

准确地再现容器内发生的事情可能会非常具有挑战性，因为它们在进程死亡或刚刚结束时终止。Sysdig捕获通过系统调用包含所有信息，包括网络流量、文件系统I/O和进程行为，提供故障排除所需的所有数据。

在容器环境中进行故障排除时，能够过滤和添加容器上下文信息（如Docker容器名称或Kubernetes元数据）使我们的排查过程更加轻松。

Sysdis在所有主流Linux发行版、OSX以及Windows上都能使用，下载它获得最新版本。Sysdig是一个开源工具，但该项目背后的公司也提供了一个商业产品来监视和排除多个主机上的容器和微服务。

【编者的话】本文是Kubernetes监控系列的第二篇，主要讲述了配置Kubernetes报警的一些最佳实践。

本文将介绍关于如何在Kubernetes集群中配置基础设施层的警报。本文是关于在生产中使用Kubernetes系列的一部分。第一部分介绍了Kubernetes和监控工具的基础知识；这部分涵盖了Kubernetes报警的最佳实践，第三部分将介绍Kubernetes服务发现与故障排除，最后一部分是监控Kubernetes的实际使用案例。

监控是每个优质基础设施的基础，是达到可靠性层次的基础。监控有助于减少对突发事件的响应时间，实现对系统问题的检测、故障排除和调试。在基础设施高度动态的云时代，监控也是容量规划的基础。

有效的警报是监控策略的基石。当你转向容器和Kubernetes编排环境，你的警报策略也需要演进。正是因为以下几个核心原因，其中许多我们在”如何监视Kubernetes”中进行了讲述：

• 可见性：容器是一个黑盒。传统工具只能针对公共监控端点进行检查。如果想深入监控相关服务，则需要采取不一样的方法。
• 新的基础架构层：现在服务和主机之间有一个新的层：容器和容器编排服务。这些是你需要监控的新内部服务，你的监控系统需要了解这些服务。
• 动态重调度：容器没有像之前那样的服务节点，所以传统的监控不能有效地工作。没有获取服务度量标准的静态端点，没有运行服务实例的静态数量（设想一个金丝雀发布或自动伸缩设置）。在某节点中一个进程被kill是正常的，因为它有很大的机会被重新调度到基础设施的其他节点。
• 元数据和标签：随着服务跨多个容器，为所有这些服务添加系统级别的监控以及服务特定的度量标准，再加上Kubernetes带来的所有新服务，如何让所有这些信息对我们有所帮助？有时你希望看到分布在不同节点容器中的服务的网络请求度量，有时你希望看到特定节点中所有容器的相同度量，而不关心它们属于哪个服务。这就需要一个多维度量系统，需要从不同的角度来看待这些指标。如果通过Kubernetes中存在的不同标签自动标记度量标准，并且监控系统能够了解Kubernetes元数据，那么只需要在每种情况下按照需要聚合和分割度量标准就可以实现多维度度量。

考虑到这些问题，让我们创建一组对Kubernetes环境至关重要的报警策略。我们的Kubernetes报警策略教程将涵盖：

• 应用程序层度量标准的报警
• Kubernetes上运行的服务的报警
• Kubernetes基础设施的报警
• 在主机/节点层上的报警

最后我们还将通过检测系统调用问题来了解如何通过报警加速故障排除。

应用程序层度量标准的报警

工作指标（working metrics）可以确认应用程序是否按预期执行，这些度量标准通常来自用户或消费者对服务的期望操作，或者是由应用程序通过statsd或JMX在内部生成。如果监控系统本身提供网络数据，就可以使用它来创建基于响应时间的报警策略。

以下示例是一个公共REST API端点监控警报，监控prod命令空间中的名为javaapp的deployment，在10分钟内如果延迟超过1秒则报警。

所有这些报警高度依赖于应用程序、工作负载模式等等，但真正的问题是如何在所有服务中一致性地获取数据。在理想环境中，除了核心监控工具之外，无需再购买综合监控服务即可获得这一套关键指标。

这个类别中经常出现的一些指标和报警是：

• 服务相应时间
• 服务可用性
• SLA合规性
• 每秒请求的成功/失败数

Kubernetes上运行的服务的报警

对于服务级别，和使用Kubernetes之前对于服务集群需要做的事情应该没什么不同。试想下，当在MySQL/MariaDB或者MongoDB等数据库服务中查看副本状态与延迟时，需要考虑些什么？

没错，如果想知道服务的全局运行和执行情况，就需要利用监视工具功能根据容器元数据将度量标准进行聚合和分段。

如第一篇文章所述，Kubernetes将容器标记为一个deployment或者通过一个service进行暴露，在定义报警时就需要考虑这些因素，例如针对生产环境的报警（可能通过命名空间进行定义）。

以下是Cassandra集群的示例：

如果我们在Kubernetes、AWS EC2或OpenStack中运行Cassandra，则衡量指标cassandra.compactions.pending存在每个实例上，但是现在我们要查看在prod命名空间内的cassandra复制控制器中聚合的指标。这两个标签都来自Kubernetes，但我们也可以更改范围，包括来自AWS或其他云提供商的标签，例如可用区域。

这个类别中经常出现的一些指标和警报是：

• HTTP请求数
• 数据库连接数、副本数
• 线程数、文件描述符数、连接数
• 中间件特定指标：Python uwsgi worker数量，JVM堆大小等

另外，如果正在使用外部托管服务，则很可能需要从这些提供程序导入度量标准，因为它们可能还有需要做出反应的事件。

Kubernetes基础设施的报警

在容器编排层面的监控和报警有两个层面。一方面，我们需要监控Kubernetes所处理的服务是否符合所定义的要求。另一方面，我们需要确保Kubernetes的所有组件都正常运行。
由Kubernetes处理的服务

1.1 是否有足够的Pod/Container给每个应用程序运行？

Kubernetes可以通过Deployments、Replica Sets和Replication Controllers来处理具有多个Pod的应用程序。它们之间区别比较小，可以使用它们来维护运行相同应用程序的多个实例。运行实例的数量可以动态地进行伸缩，甚至可以通过自动缩放来实现自动化。

运行容器数量可能发生变化的原因有多种：因为节点失败或资源不足将容器重新调度到不同主机或者进行新版本的滚动部署等。如果在延长的时间段内运行的副本数或实例的数量低于我们所需的副本数，则表示某些组件工作不正常（缺少足够的节点或资源、Kubernetes或Docker Engine故障、Docker镜像损坏等等）。

在Kubernetes部署服务中，跨多个服务进行如下报警策略对比是非常有必要的：

timeAvg(kubernetes.replicaSet.replicas.running) < timeAvg(kubernetes.replicaSet.replicas.desired)

正如之前所说，在重新调度与迁移过程运行中的实例副本数少于预期是可接受的，所以对每个容器需要关注配置项 .spec.minReadySeconds （表示容器从启动到可用状态的时间）。你可能也需要检查 .spec.strategy.rollingUpdate.maxUnavailable 配置项，它定义了在滚动部署期间有多少容器可以处于不可用状态。

下面是上述报警策略的一个示例，在 wordpress 命名空间中集群 kubernetes-dev 的一个deployment wordpress-wordpress。

1.2 是否有给定应用程序的任何Pod/Container？

与之前的警报类似，但具有更高的优先级（例如，这个应用程序是半夜获取页面的备选对象），将提醒是否没有为给定应用程序运行容器。

以下示例，在相同的deployment中增加警报，但不同的是1分钟内运行Pod <1时触发：

1.3 重启循环中是否有任何Pod/Container？

在部署新版本时，如果没有足够的可用资源，或者只是某些需求或依赖关系不存在，容器或Pod最终可能会在循环中持续重新启动。这种情况称为“CrashLoopBackOff”。发生这种情况时，Pod永远不会进入就绪状态，从而被视为不可用，并且不会处于运行状态，因此，这种场景已被报警覆盖。尽管如此，笔者仍希望设置一个警报，以便在整个基础架构中捕捉到这种行为，立即了解具体问题。这不是那种中断睡眠的报警，但会有不少有用的信息。

这是在整个基础架构中应用的一个示例，在过去的2分钟内检测到4次以上的重新启动：

监控Kubernetes系统服务

除了确保Kubernetes能正常完成其工作之外，我们还希望监测Kubernetes的内部健康状况。这将取决于Kubernetes集群安装的不同组件，因为这些可能会根据不同部署选择而改变，但有一些基本组件是相同的。

2.1 etcd是否正常运行？

etcd是Kubernetes的分布式服务发现、通信、命令通道。监控etcd可以像监控任何分布式键值数据库一样深入，但会使事情变得简单。

我们可以进一步去监控设置命令失败或者节点数，但是我们将会把它留给未来的etcd监控文章来描述。

2.2 集群中有足够的节点吗？

节点故障在Kubernetes中不是问题，调度程序将在其他可用节点中生成容器。但是，如果我们耗尽节点呢？或者已部署的应用程序的资源需求超过了现有节点？或者我们达到配额限制？

在这种情况下发出警报并不容易，因为这取决于你想要在待机状态下有多少个节点，或者你想要在现有节点上推送多少超额配置。可以使用监控度量值kube_node_status_ready和kube_node_spec_unschedulable进行节点状态警报。

如果要进行容量级别报警，则必须将每个已调度Pod请求的CPU和memory进行累加，然后检查是否会覆盖每个节点，使用监控度量值kube_node_status_capacity_cpu_cores和kube_node_status_capacity_memory_bytes。

在主机/节点层上的报警

主机层的警报与监视虚拟机或物理机区别不大，主要是关于主机是启动还是关闭或不可访问状态，以及资源可用性（CPU、内存、磁盘等）。

主要区别是现在警报的严重程度。在此之前，系统服务宕机可能意味着你的应用程序停止运行并且要紧急处理事故（禁止有效的高可用性）。而对于Kubernetes来说当服务发生异常，服务可以在主机之间移动，主机警报不应该不受重视。

让我们看看我们应该考虑的几个方面：

1. 主机宕机

如果主机停机或无法访问，我们希望收到通知。我们将在整个基础架构中应用此单一警报。我们打算给它一个5分钟的等待时间，因为我们不想看到网络连接问题上的嘈杂警报。你可能希望将其降低到1或2分钟，具体取决于你希望接收通知的速度。

2. 磁盘利用率

这是稍微复杂一些的警报。我们在整个基础架构的所有文件系统中应用此警报。我们将范围设置为 everywhere，并针对每个 fs.mountDir 设置单独的评估/警报。

以下是超过80％使用率的通用警报，但你可能需要不同的策略，如具有更高阈值（95％）或不同阈值的更高优先级警报（具体取决于文件系统）。

如果要为不同的服务或主机创建不同的阈值，只需更改要应用特定阈值的范围。

3. 一些其他资源

此类别中的常见资源是有关负载、CPU使用率、内存和交换空间使用情况的警报。如果在一定的时间内这些数据中的任何一个显著提升，可能就需要警报提醒您。我们需要在阈值、等待时间以及如何判定噪声警报之间进行折中。

如果您想为这些资源设置指标，请参考以下指标：

• 负载：load.average.1m, load.average.5m 和 load.average.15m
• CPU：cpu.used.percent
• memory：memory.used.percent 或 memory.bytes.used
• swap：memory.swap.used.percent 或 memory.swap.bytes.used

一些人同样使用这个类别监控他们部分基础架构所在云服务提供商的资源。

Sysdig额外监控：监控系统调用

从警报触发并收到通知的那一刻起，真正的工作就开始为DevOps值班成员开展工作。有时运行手册就像检查工作负载中的轻微异常一样简单。这可能是云提供商的一个事件，但希望Kubernetes正在处理这个问题，并且只需要花费一些时间来应对负载。

但是如果一些更棘手的问题出现在我们面前，我们可以看到我们拥有的所有武器：提供者状态页面、日志（希望来自中心位置）、任何形式的APM或分布式追踪（如果开发人员安装了代码或者外部综合监测）。然后，我们祈祷这一事件在这些地方留下了一些线索，以便我们可以追溯到问题出现的多种来源原因。

我们怎么能够在警报被解除时自动dump所有系统调用？系统调用是所发生事情的真实来源，并将包含我们可以获得的所有信息。通过系统调用有可能发现触发警报的根本问题所在。Sysdig Monitor允许在警报触发时自动开始捕获所有系统调用。

例如，可以配置CrashLoopBackOff场景：

只有当你安装代码后，Sysdig Monitor代理才能从系统调用拦截中计算出来相应的指标。考虑HTTP响应时间或SQL响应时间。Sysdig Monitor代理程序在套接字上捕获read()和write()系统调用，解码应用程序协议并计算转发到我们时间序列数据库中的指标。这样做的好处是可以在不触及开发人员代码的情况下获得仪表盘数据和警报：

结论

我们已经看到如何使用容器编排平台来增加系统中移动部分的数量。拥有容器本地监控是建立可靠基础架构的关键要素。监控不能仅仅关注基础架构，而是需要从底层的主机到应用程序指标所在的顶端来了解整个技术栈。

能够利用Kubernetes和云服务提供商的元数据信息来汇总和细分监控指标和警报将成为多层次有效监控的必要条件。我们已经看到如何使用标签来更新我们已有的警报或创建Kubernetes上所需的新警报。

接下来，让我们看看在Kubernetes编排环境中的典型服务发现故障排除的挑战。

视频：https://v.qq.com/x/page/s06032nah0m.html