巩义郑州网站建设,wordpress文章如何去除p节点,北京网页设计公司兴田德润实惠,磁力天堂torrentkittykubernetes技术架构模型
一、kubernetes的Label标签 1.标签是以keyvalue的格式通过用户自定义指定#xff0c;目的是将其加入到各种资源对象上来实现多维度的资源分组管理使其更方便的进行资源分配、调度、配置和部署管理工作。 2.标签可以结合Label Selector(标签选择器)查询…
kubernetes技术架构模型
一、kubernetes的Label标签 1.标签是以keyvalue的格式通过用户自定义指定目的是将其加入到各种资源对象上来实现多维度的资源分组管理使其更方便的进行资源分配、调度、配置和部署管理工作。 2.标签可以结合Label Selector(标签选择器)查询和筛选拥有某些标签的资源对象。 label 和 label selector两者结合使被管理的对象能更精细的分组管理实现集群的高可用。 3.label selector 的使用场景 kube-controller进程通过资源对象RC上定义的label selector 来筛选要监控的Pod副本的数量使Pod的数量始终符合预期设定的全自动控制流程。 kube-proxy进程通过Service的label selector来选择对应的pod,自动建立每个Service到对应Pod的请求转发路由表 二、Replication Controller(RC) 1. RC主要是定义了一个期望的场景声明某种pod的副本数量在任意时刻都符合预期值 2. RC包括 pod期待的副本数 用于筛选目标pod的label selector 用于创建新pod的template模板 3.RC中的replicas表示期望pod的副本数 rc中动态缩放命令 kubectl scale rc pod名称 --replicasx x表示期望的pod副本数 可以通过这个命令修改rc的副本数来实现pod的动态缩放功能 注删除rc不会影响rc已经创建好的pod可以通过上述操作命令设置replicas0来删除已经存在的rc RC的应用场景在做应用的平滑升级时设置rc中期待的副本数为x,表示系统中发始终运行10个pod,每次终止一个旧的版本就会自动生成一个新的版本。
三、Deployment 1.引入deployment的目的是更好的解决pod的编排问题其内部使用的是replica set来实现前面所说的RC它和RC的区别在于它支持集合的方式去声明label selector。 2.deployment相对于RC的的亮点在于它可以随时知道pod的部署进度。 3.depolyment的使用场景 创建deployment对象来生成对对应的replica set完成pod副本的创建造 通过deployment的状态来查看部署动作是否完成 更新depolument来创建新的pod版本升级如果不稳定可以回滚到上一个版 本 可以挂起或者恢复 4.通过kubectl create -f xxx-deployment.yaml可以创建deployment 通过 kubectl get deployment 来查看已创建的deployment的信息
四、Horizontal Pod Autoscaler(HPA) 1.HPA的提出需求因为google对于kubernetes的定位是自动化和智能化即当前的分布式系统可以根据当前系统中不同主机的负载情况然后自动触发水平扩展或缩容行为而目前的手动控制的方式明显不符合kubernetes的设计理念所以HPA应运而生。 2.HPA的实现原理通过追踪RC控制的所有pod的负载情况来确定是否要针对性的调整期望的pod数量。 依据pod的实现原理可以知道hpa的实现首先需要衡量pod的负载情况的指标 第一种是 CPUUtilizationPercentage CPUUtil是一个算术平均值目标POD所有副本自身CPU1分钟内利用率的平均值如果超过了80%则意味当前的副本数目不足以支撑更多的请求需要进行动态扩容当高峰期过去后pod的利用率降下来则pod的副本数自动减少到一个适当的值。 当前这个参数值需要通过Heapster扩展组件来获取这个值 第二种是应用程序自定义的度量指标如服务在每秒内的请求数 上图示例中该参考值超过90%会触发自动动态扩容行为 3.kubectl autoscale deployment xxx --cpu-percent90 --min1 --max10,该命令可以创建上述图片的等价效果。
四、Service(微服务) 上图为service的工作位置 1.kubernetes中多个pod组成的集群被客户端访问过程客户端通过负载均衡器kube-proxy将service接收到的请求转发到后端的某个pod实例并在内部实现服务的负载均衡和会话保持机制。 2.kubernetes的服务发现 机制kubernetes中的Service都有唯一的cluster IP 和唯一的名字名字由自己定义固定在配置中 通过Service的名字找到cluster ip (通过 add-on增值包引入dns系统将服务名作为dns域名)直接使用服务名来建立通信连接。 3.外部系统访问service的问题 node ip : node节点的ip地址集群中每个节点的物理网卡的ip地址真实存在的物理网络 pod ip :pod的ip地址docker engine 根据docker 0网桥的ip地址段进行分配 cluster ip:service 的ip 地址虚拟ip,需要结合service port组成具体的通信端口集群外的节点不能直接访问 通过nodePort实现从外部访问集群内部 上述通过nodeport的方法是在kubernetes集群里每个node上为需要外部访问的service开启一个对应的tcp监听端口。 可以通过设置一个负载均衡器对上述通信方式进行优化主要是通过访问设置的负载均衡的ip地址来对访问的流量进行调度实现集群内部的负载均衡。 五、Volume(存储卷) 1.Volume是pod中可以被多个容器访问的共享目录其生命周期和pod的生命周期相同但与容器的生命周期不相关即容器终止或者重启时其卷中的数据不会丢失
上图示例是数据卷相关的配置文件写法 2.kubernetes的数据卷类型empthDir(pod分配到Node是创建初始内容为空无需指定宿主机对应的文件目录pod移除之后会被永久删除)、hostPath(pod挂载宿主机的文件或目录)、gcePersistentDisk(谷歌公有云提供的永久磁盘)、awsElasticBlockStore(亚马逊公有云提供的)、NFS(NFS网络文件系统提供共享存储目录)
六、Persistent Volume(某个网络存储中对应的一块存储)简称PV有状态的对象 1.pv和volume的区别 pv只能是网络存储不属于任何node,可以在每个node上访问 pv不是定义在pod上独立于pod之外定义 2.pv的accesModes属性 readWriteOnce:读写权限只能被单个node 挂载 readOnlyMany:只读权限允许多个node挂载 readWriteMany:读写权限允许多个node挂载 七、namespace(命名空间) 1.namespace是将集群内部的资源对象分配到不同的namespace中形成逻辑上分组的不同项目使不同的分组在共享使用集群内部整个资源同时还可以被分别管理。 2.集群启动后会创建一个default的namespace,可以通过kubectl get namespaces来查看命名空间的信息如果用户不指明则其创建的pod和rc、service将会被系统创建到default的namespace的命名空间下
