摘要: etcd是一个高可用的分布式键值数据库,可用于服务发现,etcd采用 raft 一致性算法,基于 Go 语言实现。其特点有简单易用,所谓简单易用是指安装配置简单,提供http/https接口;安全,安全是指etcd支持ssl证书认证,支持集群各节点间使用对等证书认证;客户端和服务端的双向证书认证;可靠,可靠是指etcd使用raft协议实现分布式系统数据的可用性和一致性;etcd主要有两个版本v2和v3;v2和v3的api是互不兼容的,所以我们在同一服务器上安装多个版本的etcd时,我们需要用ETCDCTL_API这个环境变量指定; 阅读全文
posted @ 2021-01-30 21:58 Linux-1874 阅读(377) 评论(3) 推荐(1) 编辑
摘要: 继上一篇博客,我们了解了使用helm在k8s上安装应用,卸载应用,以及仓库的添加删除更新等等操作;对于helm chart来说,它就是一个打包文件,把我们需要用到的配置清单,以模板的形式发布出来,用户使用时,可以根据values.yaml文件来自行定义对应的属性的值,当然也可以使用--set选项来指定个别配置清单的属性的值;那么我们使用helm命令从仓库中安装应用,它对应的打包文件放在那里的呢?默认情况我们使用helm命令安装应用,它会把对应应用的chart 打包文件存放在当前用户的家目录中的.cache/helm/repository/目录下,以.tgz结尾的一个压缩包; 阅读全文
posted @ 2021-01-21 18:38 Linux-1874 阅读(299) 评论(0) 推荐(1) 编辑
摘要: 如果我们把k8s的资源清单类比成centos上的rpm包,那么helm的作用就如同yum;简单讲helm就是类似yum这样的包管理器,它能够让我们在k8s上部署应用变得简单,我们需要部署某些应用到k8s上,我们直接使用helm就可以完成一键部署;有了helm工具,我们甚至都不需要再写什么资源清单了;对于helm来说,它只是把对应应用需要的资源清单通过模板引擎,将对应资模板源清单赋值以后,发送给k8s进行应用,从而实现把应用部署到k8s上;我们把部署到k8s上的应用称为release;即把模板资源清单通过模板引擎渲染以后,部署到k8s上的就称为一个release; 阅读全文
posted @ 2021-01-21 02:45 Linux-1874 阅读(348) 评论(0) 推荐(0) 编辑
摘要: HPA的全称是Horizontal Pod Autoscaler,从字面意思理解它就是水平pod自动伸缩器;简单讲HPA的主要作用是根据指定的指标数据,监控对应的pod控制器,一旦对应pod控制器下的pod的对应指标数据达到我们定义的阀值,即HPA就会被触发,它会根据对应指标数据的值来扩展/缩减对应pod副本数量;扩展和缩减都是有上下限的,当pod数量达到上限,即便指标数据还是超过了我们定义的阀值它也不会再扩展,对于下线默认不指定就是为1;下限和上限都是一样的逻辑,即便一个访问都没有,它会保持最低有多少个pod运行;需注意hpa只能用于监控可扩缩的pod控制器,对DaemonSet类型控制器不支持; 阅读全文
posted @ 2021-01-18 20:58 Linux-1874 阅读(305) 评论(0) 推荐(1) 编辑
摘要: Pushgateway组件类似Prometheus retrieval代理,它主要负责收集主动推送指标数据的pod的指标数据,在Prometheus 监控系统中也有主动监控和被动监控的概念,主动监控是指被监控端主动推送数据到server,被动监控是指被监控端被动等待server来拉去数据,默认情况Prometheus是工作为被动监控模式,即server主动到被监控端采集数据;节点级别metrics 数据可以使用node-exporter来收集,当然node-exporter也可以收集pod容器里的指标数据;alertmanager主要用来为Prometheus监控系统提供告警功能;Prometheus web ui主要作用是为其提供一个web查询页面; 阅读全文
posted @ 2021-01-17 17:24 Linux-1874 阅读(377) 评论(0) 推荐(0) 编辑
摘要: k8s原生apiserver主要有两个组件组成,第一个组件aggregator,其功能类似web代理服务器,第二个组件就是真正的apiserver;其工作逻辑是,用户请求首先送达给aggregator,由aggregator根据用户请求的资源,将对应请求路由至apiserver;简单讲aggregator这个组件主要作用就是用来路由用户请求;默认情况aggregator会把所有请求都路由至原生的apiserver上进行响应;如果我们需要自定义apiserver,就需要在默认的aggregator上使用apiservice资源将自定义apiserver注册到原生的apiserver上,让其用户请求能够被路由至自定义apiserver进行响应; 阅读全文
posted @ 2021-01-15 11:16 Linux-1874 阅读(599) 评论(0) 推荐(1) 编辑
摘要: 在k8s上扩展资源类型的方式有三种,第一种是crd,crd是k8s内建的资源类型,该类型资源主要用来创建用户自定义资源类型的资源;即通过crd资源,可以将用户自定义资源类型转换为k8s上资源类型;第二种是自定义apiserver;这种方式要比第一种方式要复杂一点,需要用户手动开发程序实现对应功能的apiserver,让其用户创建自定义类型资源能够通过自定义apiserver实现;第三种方式就是修改现有k8sapiserver,让其支持对应用户自定义资源类型; 阅读全文
posted @ 2021-01-14 19:38 Linux-1874 阅读(528) 评论(0) 推荐(0) 编辑
摘要: 对于污点效用为NoSchedule来说,它只会拒绝新建的pod,不会对原有pod进行驱离;如果对应pod能够容忍该污点,则对应pod就有可能运行在对应节点上;如果不能容忍,则对应pod一定不会调度到对应节点运行;对于污点效用为PreferNoSchedule来说,它也不会驱离已存在pod,它只有在所有节点都不满足对应pod容忍度时,对应pod可以勉强运行在此类污点效用的节点上;对于污点效用为NoExecute来说,默认不指定其容忍宽限时长,表示能够一直容忍,如果指定了其宽限时长,则到了宽限时长对应pod将会被驱离;对应之前被调度到该节点上的pod,在节点污点效用变为NoExecute后,该节点会立即驱离所有不能容忍污点效用为NoExecute的pod; 阅读全文
posted @ 2021-01-09 21:14 Linux-1874 阅读(346) 评论(0) 推荐(0) 编辑
摘要: 在k8s上有一个非常重要的组件kube-scheduler,它主要作用是监听apiserver上的pod资源中的nodename字段是否为空,如果该字段为空就表示对应pod还没有被调度,此时kube-scheduler就会从k8s众多节点中,根据pod资源的定义相关属性,从众多节点中挑选一个最佳运行pod的节点,并把对应主机名称填充到对应pod的nodename字段,然后把pod定义资源存回apiserver;此时apiserver就会根据pod资源上的nodename字段中的主机名,通知对应节点上的kubelet组件来读取对应pod资源定义,kubelet从apiserver读取对应pod资源定义清单,根据资源清单中定义的属性,调用本地docker把对应pod运行起来; 阅读全文
posted @ 2021-01-07 23:46 Linux-1874 阅读(383) 评论(0) 推荐(1) 编辑
摘要: 在k8s上网络策略是白名单机制,所谓白名单机制是指,只有明确定义的策略才会被允许放行,默认没有指定的规则就是拒绝的,即条件不匹配的都会被拒绝;其次对于ingress或egress来说,对应的from或to都是用来指定访问端或被访问端的信息;如果我们在对应的字段中没有定义namespaceSelector字段,默认ingress或egrss会匹配当前netpol所在名称空间,即在没有明确指定namespaceSelector字段时,对应的其他条件都是针对当前netpol所在名称空间;多个条件组合使用,如果多个条件都在一个列表中,则表示多个条件间是与关系,即指定的条件需要同时满足对应策略才会放行;如果多个条件不再同一个列表中,则多个条件之间是或关系,即满足其中一个条件都会被对应策略放行; 阅读全文
posted @ 2021-01-04 21:42 Linux-1874 阅读(402) 评论(1) 推荐(1) 编辑
摘要: 在flannel网络插件中,对应的网络信息是存储在一个存储系统中的,比如使用etcd存储;在k8s上安装好flannel插件以后,对应的它会在每个宿主机上运行一个守护进程,并且在每个节点上创建一个cni0的接口,这个接口就是我们上面说的虚拟网桥;除了这个网桥,它还会创建一个flannel.1的接口,这个接口就是隧道接口;随后flannel会借助vxlan把10.244.0.0/16这个网络进行子网划分,并把对应划分的子网信息同对应节点上的物理网卡上的ip地址,mac地址,进行一一对应;比如节点1的子网为10.244.0.0/24,对应物理网卡上的ip地址为192.168.0.41,mac地址xxx;把节点2的子网信息以及对应节点ip地址,mac地址等信息一一对应起来,并把这些信息保存在etcd中; 阅读全文
posted @ 2021-01-03 20:33 Linux-1874 阅读(384) 评论(0) 推荐(1) 编辑
摘要: k8s的webui是一个插件运行在k8s之上,以pod的方式提供服务;它能够给使用k8s用户提供一个web面板,我们可以基于这个web面板来管理k8s集群;比如创建pod,创建svc,部署应用等等;在部署之前,先说一下dashboard认证过程;dashboard是以pod的形式运行在k8s之上,它本身没有做访问权限认证相关的功能,它只是把用户的认证信息代理到k8s集群上,具体的认证授权还是由k8s的apiserver进行;所以我们登录dashboard必须是k8s上的用户;其次它是一个pod形式把我们的认证信息代理到apiserver上,所以我们登录dashboard的用户必须是一个sa用户,它不支持常规用户;简单讲dashboard就是一个代理服务;它把我们所有操作通过https协议代理到apiserver做相应的操作; 阅读全文
posted @ 2021-01-02 15:57 Linux-1874 阅读(462) 评论(0) 推荐(2) 编辑
摘要: 对于准入控制来说,它有两种类型,一种是变异型,一种是校验型;所谓变异型是指我们在提交给apiserver进行资源创建时,默认没有指定的对应字段的信息;它会给我们补上,或者我们定义资源的某些属性的值不太规范,它会帮助我们修改对应的属性的值为一个规范的值,然后提交给apiserver;这种准入控制器通常是帮助我们把对应提交的资源创建信息,规范后提交给apiserver,使得我们提交资源的信息是能够满足对应api规范;校验型准入控制器是用来限制我们对应创建资源是否合理,是否满足我们定义的规则,如果不满足就直接拒绝我们创建;这种控制器主要用来限制我们对k8s上的资源的使用; 阅读全文
posted @ 2021-01-01 22:41 Linux-1874 阅读(442) 评论(0) 推荐(1) 编辑
摘要: 对于RBAC授权模型来说,在k8s上用户是没法直接关联资源;它是通过角色对象来实现对资源的授权;用户授权是通过角色绑定对象来关联到对应角色;只要用户绑定到对应角色,那么该用户就拥有绑定角色上的所有权限;比如,在k8s上有一个角色名为pod-reader,这个角色能够对default名称空间下的pod资源有只读权限;对其他名称空间任何资源没有任何权限;如果一个用户绑定到该角色上,对应用户就有对default名称空间下的pod资源拥有只读权限,对其他名称空间任何资源没有任何权限;对于k8s上的资源来说,资源有两个级别,一个是名称空间级别的资源,一个是集群级别的资源;比如pod,svc,pvc等等这些资源都是名称空间级别资源,它们的存在必须是在某个名称空间下;对于类似像pv,node,ns这些资源就是集群级别资源,它们的存在不依赖任何名称空间; 阅读全文
posted @ 2020-12-31 23:50 Linux-1874 阅读(480) 评论(0) 推荐(1) 编辑
摘要: 用户认证只是验证对应客户端是否是合法客户端,这里的验证的机制是一票通过的机制;所谓一票通过是指在APIserver上有多种验证机制(方法),它会从上至下依次进行验证,如果对应验证方法没有明确拒绝,接着它会用下一个验证方法,直到有一个机制通过以后,余下的就不验证了;比如,在k8s上有证书验证,用户名密码验证,token验证,如果此时有一个客户端拿着一个token来登陆APIserver,此时APIserver就会先用证书验证的方法验证客户端,如果对应验证方法没有明确拒绝,说明此方法不识别对应的客户端信息,接着它会用用户名密码的方法进行验证,如果对应方法也没有明确拒绝,接着它会用token方法进行验证,如果对应方法通过了,那么接下来的其他方法验证就不会再进行下去; 阅读全文
posted @ 2020-12-30 02:15 Linux-1874 阅读(438) 评论(0) 推荐(2) 编辑
摘要: 简单讲statefulset控制器只是帮助我们在k8s上启动对应数量的pod,每个pod分配一个固定不变的名称,不管pod怎么调度,对应pod的名称是一直不变的;即便把对应pod删除再重建,重建后的pod的名称还是和之前的pod名称一样;其次就是自动帮我们把对应pod的pvc挂载到重建后的pod上,以保证两者数据的相同;statefulset控制器只帮我们做这些事,至于pod内部跑的容器应用怎么去适配对应的集群架构,类似业务逻辑的问题需要我们用户手动去写代码解决,因为对于不同的应用其集群逻辑架构和组织方式都不同,statefulset控制器不能做到以某种机制去适配所有的有状态应用的逻辑架构和组织方式; 阅读全文
posted @ 2020-12-28 23:48 Linux-1874 阅读(459) 评论(2) 推荐(1) 编辑
摘要: 在docker容器里我们要给容器里的应用提供配置的方式有两种,一种是通过环境变量的方式,把对应容器里跑的程序的某些属性通过一个环境变量传递给容器运行时的环境中去,这样容器启动时,读取对应的环境变量,对应容器里的应用程序就会根据我们传递的环境变量来启动对应的程序,从而实现配置容器里应用程序的目的;这种能够通过环境变量向容器里的应用传递配置的前提是对应应用程序支持;第二种方式就是通过存储卷的方式,把外部的配置文件直接通过存储卷的方式挂载到容器里的应用程序对应位置,对应程序在启动时,通过读取挂载的配置文件,从而实现配置容器里的应用程序的目的;这两种方式都有一个特点,只能在初始化容器时做,一旦一个容器初始化完成以后,修改对应的配置,必须要重新初始化容器,对应配置才能生效;对于k8s上的pod来说,也是类似的逻辑; 阅读全文
posted @ 2020-12-27 03:04 Linux-1874 阅读(517) 评论(0) 推荐(1) 编辑
摘要: volume的基础使用,需要我们用户手动来向不同类型存储接口传递不同的参数,从而实现把外部存储映射到k8s上的一个volume对象,使得pod才能正常的挂载对应的存储卷,对应pod里的容器才能正常使用;这种使用方式的前提是用户必须了解对应的存储系统,了解对应类型的存储接口,以及相关参数;这使得用户在k8s上使用存储卷变得有些复杂;为了简化这一过程,在k8s上使用pv和pvc资源来把对应底层存储接口给隐藏了,用户使用存储卷不再关心底层存储系统接口;不管底层是那种类型的存储,用户只需面对一个pvc接口即可; 阅读全文
posted @ 2020-12-25 23:59 Linux-1874 阅读(714) 评论(0) 推荐(0) 编辑
摘要: 在k8s上pod里可以运行一个或多个容器,运行多个容器,其中一个容器我们叫主容器,其他的容器是用来辅助主容器,我们叫做sidecar;对于pod来说,不管里面运行多少个容器,在最底层都会运行一个pause容器,该容器最主要用来为pod提供基础架构支撑;并且位于同一个pod中的容器都共享pause容器的网络名称空间以及IPC和UTS;这样一来我们要想给pod里的容器提供存储卷,首先要把存储卷关联到pause容器,然后在容器里挂载pause里的存储卷即可; 阅读全文
posted @ 2020-12-24 02:23 Linux-1874 阅读(518) 评论(2) 推荐(0) 编辑
摘要: 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资源的规则; 阅读全文
posted @ 2020-12-22 02:42 Linux-1874 阅读(555) 评论(0) 推荐(3) 编辑
摘要: 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; 阅读全文
posted @ 2020-12-20 19:15 Linux-1874 阅读(483) 评论(0) 推荐(1) 编辑
摘要: DaemonSet控制器的主要作用是管理守护进程类的Pod,通常用于在每个节点需要运行一个这样的Pod场景;比如我们要收集日志到es中,我们就可以使用这种控制器在每个节点上运行一个Pod;DaemonSet控制器和Deployment控制器很类似,不同的是ds(DaemonSet的简写)控制器不需要我们手动指定其运行的pod数量,它会根据k8s集群节点数量的变化而变化,如果新加入一个节点它会自动扩展对应pod数量,减少节点时,它也不会把之前运行在该节点上的pod调度到其他节点,总之一个节点上只能运行同类型Pod1个;除此之外ds它还支持通过节点选择器来做选择性的调度;比如,在某个拥有对应标签的节点就运行对应pod,没有就不运行;其他的更新操作和deployment差不多; 阅读全文
posted @ 2020-12-19 00:23 Linux-1874 阅读(445) 评论(0) 推荐(0) 编辑
摘要: 在k8s上控制器的类型有很多,比如pod控制,service控制器,endpoint控制器等等;不同类型的控制器有着不同的功能和作用;比如pod控制器就是针对pod资源进行管理的控制器;单说pod控制器,它也有很多类型,根据pod里容器跑的应用程序来分类,可以分为有状态应用和无状态应用控制,从应用程序是否运行为守护进程我们可以将控制器分为,守护进程和非守护进程控制器;其中无状态控制器中最常用的有ReplicaSet控制器和Deployment控制;有状态应用控制器常用的有StatefulSet;守护进程控制器最常用的有daemonSet控制器;非守护进程控制器有job控制器,对Job类型的控制器,如果要周期性执行的有Cronjob控制器; 阅读全文
posted @ 2020-12-18 02:21 Linux-1874 阅读(476) 评论(0) 推荐(0) 编辑
摘要: pod生命周期分两个阶段,第一阶段是初始化容器,第二阶段是主容器的整个生命周期;其中对于主容器来来说,它的生命周期有分了三个阶段,第一阶段是运行post start hook,这个阶段是主容器运行之后立即需要做的事;第二阶段是主容器正常运行的阶段,在这个阶段中,我们可以定义对容器的健康状态检查和就绪状态检查;第三阶段是运行pre stop hook,这个阶段主要做容器即将退出前需要做的事;这里需要注意对于初始化容器来说,一个pod中可以定义多个初始化容器,他们必须是串行执行,只有当所有的初始化容器执行完后,对应的主容器才会启动;对于对容器的健康状态检查和就绪状态检查,我们也可以定义开始检查的延迟时长;因为有些容器存在容器显示running状态,但内部程序还没有初始化,如果立即做健康状态检查,可能存在健康状态为不健康,从而导致容器重启的状况; 阅读全文
posted @ 2020-12-16 22:14 Linux-1874 阅读(620) 评论(0) 推荐(0) 编辑
摘要: 对于pod来讲,我们知道使用pod控制器创建的pod在pod故障以后,重建后的pod它的ip地址和名称是变化的,为了解决pod访问问题,我们特此创建了service,我们访问service的ip地址就可以正常访问到pod;那么问题来了,service是怎样去关联pod的呢?我们知道在k8s上如果使用pod控制创建的pod,在pod发生故障以后,对应pod会被对应的控制器重启或重建,一个pod重建以后,对应的ip地址和名称都是会发生变化的,所以靠ip地址和名称关联pod是不行的;那靠什么关联pod呢?在k8s上是使用的标签和标签选择器的机制实现资源和资源间相互关联的; 阅读全文
posted @ 2020-12-15 22:48 Linux-1874 阅读(487) 评论(0) 推荐(0) 编辑
摘要: 我们知道在k8s上管理资源的方式有两种,一种是陈述式接口,一种是声明式接口;在前文我们用kubectl create的方式创建pod控制器,创建service,创建名称空间都是使用的陈述式命令的方式在k8s上管理资源;陈述式命令接口管理k8s上的资源的确很方便,但通常创建出来的资源有很多属性都不是我们期望的,所以陈述式命令在k8s集群上管理资源的方式一般不怎么推荐使用;我们要想自己手动定义一个资源,就需要使用声明式接口来创建资源;那么声明式接口该怎么用呢?很简单,我们只需要写一个描述资源的配置文件,然后使用apply命令指定应用对应的资源配置文件即可; 阅读全文
posted @ 2020-12-14 20:05 Linux-1874 阅读(536) 评论(0) 推荐(1) 编辑
摘要: kubectl是k8s官方提供的工具,它是一款命令行工具,我们可以使用它来管理k8s集群,管理k8s集群上的资源;kubectl这个工具有很多子命令,每个子命令都有不同的功能,比如创建资源我们可以使用create或apply子命令来实现;不同的是在k8s上创建资源的方式有两种,一种是陈述式接口,一种是声明式接口;所谓声明式接口就是把我们要创建的资源,通过写成一个配置文件,然后使用apply子命令应用指定的配置文件的方式;陈述式接口是指我们要在命令行告诉k8s怎么去创建资源,比如创建pod控制器,使用什么镜像,副本数量等等;通常我们使用create子命令来陈述创建一个资源;当然create子命令也可以指定一个资源清单的方式来创建资源;两者不同的是apply可以多次执行,如果发现对应清单有变化就应用变化部分,没变化就不应用;而create不能多次执行; 阅读全文
posted @ 2020-12-13 22:28 Linux-1874 阅读(564) 评论(0) 推荐(1) 编辑
摘要: kubernetes是google公司用go语言开发的一套容器编排系统,简称k8s;它主要用于容器编排;所谓容器编排简单的我们可以理解为管理容器;这个有点类似openstack,不同的是openstack是用来管理虚拟机,而k8s中是管理的pod(所谓pod就是容器的一个外壳,里面可以跑一个或多个容器,可以理解为pod就是将一个或多个容器逻辑的组织在一起);k8s除了可以全生命周期的管理pod,它还可以实现pod的自动化部署,自动修复以及动态的扩缩容等功能; 阅读全文
posted @ 2020-12-13 00:24 Linux-1874 阅读(794) 评论(0) 推荐(1) 编辑
摘要: 在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才可以正常通信; 阅读全文
posted @ 2020-12-07 19:40 Linux-1874 阅读(335) 评论(0) 推荐(0) 编辑
摘要: 在puppet中模块的概念有点类似ansible中的角色;在puppet中模块就是把定义在一个资源清单中的各个资源拆分到不同的资源文件中,然后把对应的文件放在特定的目录中;简单讲puppet中的模块就是一个按约定的、预定义的结构存放了多个文件或子目录的目录,目录里的文件或子目录必须遵循某种命名规范;puppet会按照此种规范在特定位置查找模块所需文件,不过这些特定的目录可以通过puppet配置参数modulepath来指定; 阅读全文
posted @ 2020-12-04 23:22 Linux-1874 阅读(395) 评论(0) 推荐(0) 编辑