在前面的笔记中记载了flannel，flannel是做不了网络策略，但是flannel的vxlan隧道模式和directrouting，以及host-gw都非常简单好用。但是缺陷在某些场景也是不适应的，本篇笔记中简单介绍projectcalio，简称calico。 calico并且支持BGP协议的方式构建pod网络，通过BGP的路由学习生成节点到节点直接pod路由表信息，并且在变动时候自动修改，并

在kubernets中运行pod资源的节点中，master节点运行控制组件，主要控制组件如： apiserver controller-manager scheduler 除此之外，master还依赖ETCD存储节点，或者是一个有冗余能力的存储集群。在使用kubeadm部署时候，这些组件会被运行成pod应用程序，并且是静态pod。简单的讲，就是运行在master本地的一个守护进程。从这个方面讲，m

之前的scheduler，默认的default scheduler分三部实现调度过程，首先是预选，从所有节点当中选择基本符合选择条件的节点，而后在众多基本符合选择条件的节点中通过优选函数，对这些节点加以比较。并且从最高得分当中随机选择一个作为运行pod的节点。这就是scheduler负责的功用。 高级调度机制 节点调度 在某些调度参加中，可通过自己的预设来影响预选，优选的过程，从而使得调度的操作符

Pod自身的亲和性调度分为两种表示形式，第一种podinity(亲和性)，第二张podAffinity(反亲和性) pod亲和性 pod与pod更倾向运行在一起。一般出于高效通讯的需求把pod对象组织在相近的位置，同一个节点，同一个机架，同一个机房，甚至于同一个区域或者地区，便于pod通讯。但是有些时候在部署两套系统的时候，出于一些安全或者其他的考虑，不能够部署在一起的时候，就需要反亲和性。 po

在前面的两种方式中，都是由pod去选择的，节点被动选择运行。而污点调度方式就给了节点的选择权。让节点可以选择让那些pod运行在节点上。总的来说，污点就是定义在节点上的键值属性数据。 此前，我们知道，键值属性有三类，第一类叫标签，第二类叫注解，第三类便是污点。污点用在节点之上，而前两类所有资源对象都可以使用。 pod亲和性和node亲和性都是pod的属性，而污点是节点的属性 污点也是一种键值属性，主

之前介绍的pod资源调度，此篇主要记录的是kubernetes上运行pod的对象的时，如何去监控系统级的一些资源指标，业务指标的获取，以及监控。 容器在启动的时候，可以根据资源需求，配置资源限额的，如CPU，内存。而CPU资源属于可压缩资源，一个容器在本应该获取指定的资源获取不到的时候，进行等待即可，而内存则不一样。内存属于非可压缩资源，如果内存资源因为指定的大小而不够的时候会因为内存资源耗尽而被

在docker中可以使用那个stats查看容器的资源使用，而在Kubernetes中可以使用top查看。但是一般都会报错，如下： [root@linuxea metrics]# kubectl top pod Error from server (NotFound): the server could not find the requested resource (get services ht

我们在之前知道heapster在1.113后将完全启用。 在资源指标中分为资源指标和自定义指标，先前的heapster就提供了资源收集存储和监控基本的功能，并且支持多个存储接收器，如：InflxDB等。这些组件均由第三方提供，由于某些不稳定的因素，heapster整合了十多个后端存储适配器，匹配这些适配器同时也增加了代码量，并且尚未得到改善，由此可见，这种架构下，heapster并不是很适用于后期

metrics-server metrics-server是用户开放的一个api server，这个api server用于服务资源指标服务器，并不是服务kubernetes api，更不是服务pod api，仅仅用于服务cpu利用率，内存使用率等等对象。 metrics-server并不是kubernetes组成部分，只是托管在kubernetes之上的一个pod，为了能让用户使用metrics

prometheus metrics-server可以对核心指标进行监控。 除开节点，podCPU内存之外的其他指标是无法获取的，就要借助prometheus。 prometheus提供的资源指标是不能够被k8s解析的，要想能在k8s上使用prometheus， 就需要额外加一个prometheus的资源转换，转成k8s api能够兼容的格式，才能被当作指标数据使用。 架构形式如下： promet

hpa hpa有着非常强大的功能，支持应用规模的自动伸缩。如果某一个pod，资源利用率达到一个临界值后，会自动的修改Deployment的replicas值，这种方式也有自动计算结果得到的。比如说，我有5个pod，我期望每个负载率是90% 就进行扩展一个pod，依次类推。当负载降下来的时候就在自动所容到正常的个数。 hpa是有两个版本，v1使用核心指标定义，而核心指标中只有cpu和内存，而内存不可

此前，不管是无状态还是有状态的应用在部署在系统之上，如果是无状态的，使用Deployment控制器进行应用伸缩是很容易。有状态的应用也可以做一些限制不进行规模的伸缩，并且也可以完成持久存储能力的。 但是一旦将有状态的应用扩展成多个副本，就会面临问题，不同的应用程序在扩展的时候，扩展的方式是各自都不相同的。如：redis主从，以及cluster都是不同的方式，etcd也是如此，这样的有状态应用部署在

核心组件与程序架构 核心组件 Chart 一个helm程序包，包含了k8s上部署应用程序的清单的定义(并不包含镜像，镜像是由镜像仓库来提供)，镜像的引用，依赖关系，资源定义等等。必要时，包含其他的定义，如：Service. Repository 而Chart是有多个，放置到Repository，也可以说是一个Chart。同时也是一个http/https服务器。 Release Chart实例化后部

在helm的体系中，有helm，tiller server，以及chart。tiller作为服务端一般运行在k8s集群之上，helm能够通过tiller server在k8s之上部署应用程序，这些应用程序来在helm能够访问到的仓库当中的chart。此前我们自定义了一些简单的值文件，实现实例化chart可安装的，可运行的release。也可以通过chart生成release，其中配置文件confi

efk ElasticSearch 是一个搜索引擎，由java编写，Logstash用于生成日志，收集日志，转换日志，而后输入到ElasticSearch 。 Logstash扮演agent用来收集日志，因此使用DaemonSet，日志收集完成发送到Logstash server端，Logstash统一整理之后注入到ElasticSearch 当中。ElasticSearch 一般情况下会是一个集

通常我们指容器而是一个容納其它物品的工具，可以部份或完全封閉，被用於容納、儲存、運輸物品[3]。物體可以被放置在容器中，而容器則可以保護內容物。我们参考：https://zh.wikipedia.org/wiki/%E5%AE%B9%E5%99%A8 虚拟化 我们知道常规虚拟化的形式，主流的有两种。 第一种主机级虚拟化，虚拟整个完整的物理平台。比如vmwarer，vmware创建的虚拟机就像一个完

namespace 容器技术出现较早，最早FreeBSD的操作系统虚拟化，其目的就是为了让进程不受其他干扰。就算这个经常出现了某些故障，bug，以及异常行为也不会影响到容器边界之外的其他进程，破坏的边界也是此jail而已。这种隔离可使应用安全运行。 这种技术被用到linux后，叫VServer，VServer也能实现一定的jail的效果，vserver实现的功能chroot，chroot将正在运行

lxc 容器技术jail,vserver，后来为了将容器创建的更易用，已工具的方式使用，就出现了lxc(linux Container)，lxc除开vserver，也是最早的真正的将容器技术用简易的工具和模板来极大的简化容器技术使用的方案。所以将自己称为linux Container，简称lxc。 还有一些工具，如：lxc-create，使用这些命令去快速创建一个容器。通常称为一个用户空间。这个用

我们知道，要想使用容器就需要在内核支持namespace，cgroups，借助于在用户空间组织一些工具利用内核所提供的技术，显示运行容器的目的。docker在容器运行简化上又近一步的，提供了镜像，分层构建，使得容器技术的使用更加被简化。后来在docker的主导下，演化出ocf(open container initiative)标准：皆在围绕容器格式和运行时制定一个开放的工业化标准。而runC是在

安装docker 先决条件： 64bits CPU linux Kernet 3.10+ (centos7以上完美支持) 我们使用清华大学的mirros仓库https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/centos/ curl -Lks https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linu