在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

docker主机，也就是docker server端，通过http,https接受客户端的命令。docker daemon接受到命令后会在本地启动创建容器，一个docker主机上运行多个容器。容器启动基于镜像启动。如果没有镜像就会链接到docker registries。如下图： 获取镜像后存储在本地，这个存储是特殊的，在1.18后的版本使用的是overlay2的存储驱动。镜像本身是只读的，镜像在

通常，编辑一个dockerfile进行build，或者将运行中的容器containers，使用commit将容器最上一层可写层单独创建一个镜像。或者如上github antomated builds,这种方式还是需要基于dockerfile。大致形式如下： 制作镜像 基于容器制作镜像 我们run起一个容器，而后在容器内添加一些文件。随后将这个容器commit成一个镜像，在将此镜像run起来。如上图

名称空间的六种分别是：UTC,User,Mount，ipc,pid,Net。网络的名称空间在早些时候就已经添加到内核当中，现在的内核上，基本上是支持的。 网络名称空间主要用于协议栈，网络设备的隔离实现。 一般情况，一个网卡设备只能关联到一个名称空间上，并且都会配置ip地址与外部通讯。假如现在名称空间数量超过物理网卡数量，每一个名称空间内部的进程也需要通过网络进行通讯。 当然，我们是不可能有那么多的

docker网络 docker安装完成后自动提供了三种网络 [root@linuxea.com142 ~]# docker network ls NETWORK ID NAME DRIVER SCOPE c46b68610246 bridge bridge local ffc5941362d9 host host local 1f143e6b01ea none null local bridge

此前我们知道在容器中一共有6个名称空间是被隔离的，其中NET,UTS,ITC是能够共享的。 其中网络也有多种方式，现在我们可以使用ip route模拟容器的名称空间。ip netns命令来进行添加，编辑等。 网络名称空间 我们手动创建名称空间，网络名称空间 添加linuxea-r1和linuxea-r2网络名称空间，并进行配置虚拟网卡对，而后配置ip，模拟 先添加linuxea-r1和linuxe

端口暴露有4中方式： 1，将指定容器端口映射到主机所有地址的一个动态端口 我们将内网的端口80使用—p暴露 [root@linuxea.com_10_10_240_145 ~]$ docker run --name linuxea -it --network bridge -p 80 --rm linuxea/httpd:v1 httpd -f -h /data/5idocker 而后可以使用cu