1874

摘要： ingress 控制器和k8s上的其他控制不一样，ingress控制器并不能直接运行为kube-controller-manager的一部分，它类似k8s集群上的coredns，需要在集群上单独部署，本质上就是一个pod，我们可以使用k8s上的ds或deploy控制器来创建它；ingress controller pod的作用主要是引入集群外部流量，并实时监控着apiserver上ingress资源的变动，并将其ingress中定义的规则转化为对应ingress控制器对应应用程序的专有配置，然后动态的重载或重启对应守护进程来使其配置文件生效；在k8s上ingress是一种标准资源，它本质上就是我们定义的基于dns名称（host）或url路径把请求转发至指定service资源的规则； 阅读全文

摘要： Service资源在k8s上主要用来解决pod访问问题；我们知道在k8s上pod由于各种原因重建，对于重建后的podip地址和名称都是变化的，这样一来使得我们访问pod就变得有些不便；为了解决pod访问能有一个固定的端点，在k8s上就是用service来解决的；简单来讲，service对象就是工作在节点上的一组iptables或ipvs规则，用于将到达service对象ip地址的流量调度转发至相应endpoint对象指向的ip地址和端口之上；工作于每个节点的kube-proxy组件通过apiserver持续监控着各service及其关联的pod对象，并将其创建或变动实时反映至当前工作节点上相应的iptables或ipvs规则；其实service和pod或其他资源的关联，本质上不是直接关联，它依靠一个中间组件endpoint； 阅读全文

摘要： DaemonSet控制器的主要作用是管理守护进程类的Pod，通常用于在每个节点需要运行一个这样的Pod场景；比如我们要收集日志到es中，我们就可以使用这种控制器在每个节点上运行一个Pod；DaemonSet控制器和Deployment控制器很类似，不同的是ds(DaemonSet的简写)控制器不需要我们手动指定其运行的pod数量，它会根据k8s集群节点数量的变化而变化，如果新加入一个节点它会自动扩展对应pod数量，减少节点时，它也不会把之前运行在该节点上的pod调度到其他节点，总之一个节点上只能运行同类型Pod1个；除此之外ds它还支持通过节点选择器来做选择性的调度；比如，在某个拥有对应标签的节点就运行对应pod，没有就不运行；其他的更新操作和deployment差不多； 阅读全文

摘要： 在k8s上控制器的类型有很多，比如pod控制，service控制器，endpoint控制器等等；不同类型的控制器有着不同的功能和作用；比如pod控制器就是针对pod资源进行管理的控制器；单说pod控制器，它也有很多类型，根据pod里容器跑的应用程序来分类，可以分为有状态应用和无状态应用控制，从应用程序是否运行为守护进程我们可以将控制器分为，守护进程和非守护进程控制器；其中无状态控制器中最常用的有ReplicaSet控制器和Deployment控制；有状态应用控制器常用的有StatefulSet；守护进程控制器最常用的有daemonSet控制器；非守护进程控制器有job控制器，对Job类型的控制器，如果要周期性执行的有Cronjob控制器； 阅读全文

摘要： pod生命周期分两个阶段，第一阶段是初始化容器，第二阶段是主容器的整个生命周期；其中对于主容器来来说，它的生命周期有分了三个阶段，第一阶段是运行post start hook，这个阶段是主容器运行之后立即需要做的事；第二阶段是主容器正常运行的阶段，在这个阶段中，我们可以定义对容器的健康状态检查和就绪状态检查；第三阶段是运行pre stop hook，这个阶段主要做容器即将退出前需要做的事；这里需要注意对于初始化容器来说，一个pod中可以定义多个初始化容器，他们必须是串行执行，只有当所有的初始化容器执行完后，对应的主容器才会启动；对于对容器的健康状态检查和就绪状态检查，我们也可以定义开始检查的延迟时长；因为有些容器存在容器显示running状态，但内部程序还没有初始化，如果立即做健康状态检查，可能存在健康状态为不健康，从而导致容器重启的状况； 阅读全文

摘要： 对于pod来讲，我们知道使用pod控制器创建的pod在pod故障以后，重建后的pod它的ip地址和名称是变化的，为了解决pod访问问题，我们特此创建了service，我们访问service的ip地址就可以正常访问到pod；那么问题来了，service是怎样去关联pod的呢？我们知道在k8s上如果使用pod控制创建的pod，在pod发生故障以后，对应pod会被对应的控制器重启或重建，一个pod重建以后，对应的ip地址和名称都是会发生变化的，所以靠ip地址和名称关联pod是不行的；那靠什么关联pod呢？在k8s上是使用的标签和标签选择器的机制实现资源和资源间相互关联的； 阅读全文

摘要： 我们知道在k8s上管理资源的方式有两种，一种是陈述式接口，一种是声明式接口；在前文我们用kubectl create的方式创建pod控制器，创建service，创建名称空间都是使用的陈述式命令的方式在k8s上管理资源；陈述式命令接口管理k8s上的资源的确很方便，但通常创建出来的资源有很多属性都不是我们期望的，所以陈述式命令在k8s集群上管理资源的方式一般不怎么推荐使用；我们要想自己手动定义一个资源，就需要使用声明式接口来创建资源；那么声明式接口该怎么用呢？很简单，我们只需要写一个描述资源的配置文件，然后使用apply命令指定应用对应的资源配置文件即可； 阅读全文

摘要： kubectl是k8s官方提供的工具，它是一款命令行工具，我们可以使用它来管理k8s集群，管理k8s集群上的资源；kubectl这个工具有很多子命令，每个子命令都有不同的功能，比如创建资源我们可以使用create或apply子命令来实现；不同的是在k8s上创建资源的方式有两种，一种是陈述式接口，一种是声明式接口；所谓声明式接口就是把我们要创建的资源，通过写成一个配置文件，然后使用apply子命令应用指定的配置文件的方式；陈述式接口是指我们要在命令行告诉k8s怎么去创建资源，比如创建pod控制器，使用什么镜像，副本数量等等；通常我们使用create子命令来陈述创建一个资源；当然create子命令也可以指定一个资源清单的方式来创建资源；两者不同的是apply可以多次执行，如果发现对应清单有变化就应用变化部分，没变化就不应用；而create不能多次执行； 阅读全文

摘要： kubernetes是google公司用go语言开发的一套容器编排系统，简称k8s；它主要用于容器编排；所谓容器编排简单的我们可以理解为管理容器；这个有点类似openstack，不同的是openstack是用来管理虚拟机，而k8s中是管理的pod（所谓pod就是容器的一个外壳，里面可以跑一个或多个容器，可以理解为pod就是将一个或多个容器逻辑的组织在一起）；k8s除了可以全生命周期的管理pod，它还可以实现pod的自动化部署，自动修复以及动态的扩缩容等功能； 阅读全文

摘要： 在puppet的master/agent模型中，master和agent通信是以https协议通信；使用https通信就意味着要有证书验证，有证书就会有ca；在puppet的master/agent模型中，它内置了ca，意思就是我们不需要再手动搭建ca；对应master的证书，私钥文件以及ca的证书私钥文件，puppet master都会自动生成；对于agent的私钥和证书签署文件也会由puppet agent自动生成；并且在第一次启动agent时，它默认会把生成的证书签发文件发送给master，等待master签发证书；在master上签发证书，这一步需要人工手动干预；证书签发好以后，master和agent才可以正常通信； 阅读全文

摘要： 在puppet中模块的概念有点类似ansible中的角色；在puppet中模块就是把定义在一个资源清单中的各个资源拆分到不同的资源文件中，然后把对应的文件放在特定的目录中；简单讲puppet中的模块就是一个按约定的、预定义的结构存放了多个文件或子目录的目录，目录里的文件或子目录必须遵循某种命名规范；puppet会按照此种规范在特定位置查找模块所需文件，不过这些特定的目录可以通过puppet配置参数modulepath来指定； 阅读全文

摘要： 整个selector语句会被当作一个单独的值，puppet会将控制变量按列出的次序依次与每个case进行比较，并在遇到一个匹配的case后，将其值作为整个语句的值进行返回，并忽略后面的其他case；控制变量与各case比较的方式和case语句相同，但如果没有任何一个case与控制变量匹配，puppet在编译时将报错，因此，我们在使用selector必须提供一个default case;控制变量只能是一个变量或一个有返回值的函数，不能使用表达式；各个case的值可以是字符串，变量，有返回值的函数，正则表达式或default； 阅读全文

摘要： 我们知道一个服务的配置文件发生了变化，如果要让其配置生效，通常会重新启动服务或重新载入配置文件内容；在ansible中当一个服务的配置文件发生变化，是通过定义handler和notify来触发对应的服务执行重启或重载配置操作；在puppet中当一个服务的配置文件发生变化触发对应服务重启或重新载入配置，需要定义资源与资源间的通知或订阅关系； 阅读全文

摘要： 在puppet中，资源就是指我们要操作被管控端主机的对象；puppet中的资源概念有点类似ansible中的模块，在ansible中不同模块有着不同的功能，比如用户管理，我们就要用user模块，文件管理就要用file模块，执行命令有shell模块和command模块；puppet中的资源也是类似的作用，不同的是puppet中资源是高度抽象的；所谓高度抽象就是指用户无需关心底层操作系统接口；比如我们要在被管控端安装一个nginx软件，如果用puppet来实现，我们直接使用package这个资源即可完成，用户不用考虑底层到底是windows还是centos或者ubuntu，puppet它能够自动识别，然后采用不同的安装方法； 阅读全文

摘要： puppet是一个IT基础设施自动化运维工具，它能够帮助系统管理员管理基础设施的整个生命周期；比如，安装服务，提供配置文件，启动服务等等一系列操作；基于puppet，可实现自动化重复任务、快速部署关键性应用以及在本地或云端完成主动变更和快速扩展架构规模等；它遵循GPL协议（2.7.0以前），基于ruby语言开发，2.7.0以后使用apache 2.0协议； 阅读全文

摘要： 我们试想一个场景，我们要监控一个集群，这个集群有100台物理主机，每个物理主机都要监控cpu，内存，磁盘等等，一台服务器平均监控项为20个，那么100台服务器就要2000个socket连接；这意味着zabbix server要有2000个socket连接需要维持；这样一来无疑对zabbix server性能有很大的影响；为了降低zabbix server连接socket数量过大而带来的性能消耗，此时zabbix server就应该委托其他主机来代理收集数据；这个代理就是zabbix proxy； 阅读全文

摘要： SNMP的工作机制SNMP网络元素分为NMS和Agent两种： NMS（Network Management Station，网络管理站）是运行SNMP客户端程序的工作站，能够提供非常友好的人机交互界面，方便网络管理员完成绝大多数的网络管理工作。 Agent是驻留在设备上的一个进程，负责接收、处理来自NMS的请求报文。在一些紧急情况下，如接口状态发生改变等，Agent也会主动通知NMS。 NMS是SNMP网络的管理者，Agent是SNMP网络的被管理者。NMS和Agent之间通过SNMP协议来交互管理信息。 阅读全文

摘要： 在zabbix中描述主动监控和被动监控都是站在agent的一方来描述的；我们把agent主动将数据发送给zabbix server这种方式采集数据，叫做主动监控；把zabbix server 向zabbix agent获取数据的方式叫做被动监控，这种方式只有zabbix server周期性的请求zabbix agent，zabbix agent才会响应对应的数据给zabbix server ，如果zabbix server 不请求，则zabbix agent不会发送数据给zabbix server ；而主动监控不管zabbix server请不请求agent,agent它都会以指定时间频率向server推送数据；默认zabbix 是使用的被动监控，这也意味着zabbix server 要不停的去请求各zabbix agent去采集数据，否则就没有数据； 阅读全文

摘要： 简单说zabbix的网络发现功能，它能帮助我们在我们指定的网段内扫描主机，当扫描到对应网段有符合我们定义的扫描规则时，它就会触发一个discovery事件，而对应action监听到对应的事件发生后，就能触发action的操作，比如把某主机添加到zabbix，然后链接指定的模板等等；这样一来我们要想去监控一个集群，我们只需要定义怎么去发现主机的规则和监听对应discovery事件的action，就能够完成一个集群的快速监控； 阅读全文

摘要： 在zabbix中宏分内建宏和自定义宏，所谓内建宏就是zabbix中原生就有的宏，我们可以直接调用；自定义宏就是我们自己按照需求定义的一个宏；除了按照这种方式划分宏，我们也可以按照宏的作用范围来划分；比如定义在某一个主机之上，其作用域仅对该主机生效的宏我们叫主机宏，这种宏作用范围小，但优先级很高；除了主机宏还有模板宏，全局宏；所谓模板宏就是定义在某个模板上的宏，其作用域是针对链接了该模板的所有主机，其优先级要略小主机宏；全局宏是指作用整个zabbix的宏，其优先级最小，生效范围是zabbix上的所有调用了该宏主机； 阅读全文