k8s学习笔记-基础概念
11. deployment部署的是服务pod,所以才有下面这张图是吗?是不是表示,deployment部署服务pod,然后service可以去代理对应标签的服务pod?所以daemonset部署的应该不是服务pod,而是监控的pod对吗?
·
(作者:陈玓玏)
- deployment特别的地方在于replica和selector,docker根据镜像起容器,pod控制容器,job、cronjob、deployment控制pod,job做离线任务,pod大多一次性的,cronjob控制离线定时任务,deployment保证pod挂掉的情况下自动重启,永远保持设置的副本数个的pod,修改副本数即可伸缩容(应该都是基于同一个镜像的容器的pod的副本),通过selector可以管理对应标签的pod;
- daemonset和deployment的区别是,deployment会自动重启pod到副本个数,保证业务永远在线,但不会在意pod在集群的哪个节点上。而daemonset会保证每个节点上都有一个pod,用于与其他节点进行通信、监控本节点、上报节点信息等,是守护进程,又称看门狗,能让每个节点都得到守护。但daemonset可能不会运行在master上,因为master上默认有一个“污点”,为了避免乱七八糟的业务都往master上部,所以如果想要master也有守护进程,可以修改守护进程的yaml中的“容忍度”。
- 容忍度就是每个pod能容忍有哪些“污点”的节点,“污点”就是节点有哪些限制等,修改污点和容忍度就能调节pod可以部署在哪些节点上,对deployment、daemonset来说都是一样的;
- service存在的意义就是,deployment保证永远能保持有n个在线的pod,daemonset就是能保证每个节点上都有可通信、监控的pod,service就是在复杂的pod重启后,保持前端只需要访问固定的ip。如果没有service,pod重启后,ip可能会变化,但service让前端只需要访问固定的ip,service去把具体的需求转发给具体的pod,称为服务发现。Service是利用kubeproxy实现的,有四层结构,有四种模式,只有nodeport和clusterip是非云厂商模式,前者能直接外网访问服务,后者只能集群内部访问。service是为动态ip地址的服务提供静态ip或域名访问,域名访问需要dns解析。域名访问可以用服务名加命名空间的形式来访问,Service另一个主要功能就是做负载均衡。
- Service的四层负载均衡和虚拟ip域名这些,导致它只适合做集群内部的负载均衡,要做外部的负载均衡,还需要更高级的功能,比如能利用常用的七层网络协议做负载均衡,并且能对接外部流量,对接到内部以后再由sevice做负载均衡。所以就有了ingress。Ingress的意思就是集群内外边界上的入口。你应该知道,Service 本身是没有服务能力的,它只是一些 iptables 规则,真正配置、应用这些规则的实际上是节点里的 kube-proxy 组件。如果没有 kube-proxy,Service 定义得再完善也没有用。ingress controller最常用的就是nginx。ingress和ingress controller中间还有一层ingress class,不同业务领域可以用不同的class,对接到不同的controller,避免了太多controller无法管理。
- 为什么要有持久卷?因为pod里的容器是由镜像产生的,镜像文件不能写,只能在pod里临时有个存储空间来写,如果pod消失了,存储空间和它里面的文件也就消失了,所以需要持久卷来持久化存储某些文件。持久卷一般通过挂载的形式挂载到容器中,其本质就是ceph、nfs等存储空间,pod没有管理权限。持久卷涉及两个概念,pvc和sc,pvc是代表pod向系统申请pv,一旦申请成功,k8s会把pv和pvc绑定在一起,sc叫storageclass,可以帮pvc找到合适的pv,避免pvc自己在一堆pv里面去找。pv就是持久卷,可以挂载到pod中的可持久化存储的位置,pvc就是代替pod向系统申请pv存储资源的,sc就是帮助pvc快速找到合适的pv的。一般我们想要持久化存储,先创建pv,再创建pvc,再把pv挂载到容器中,就可以在容器中实现持久化存储了。
- 持久卷如果使用hostpath,就是在本机,但pod可能在任意节点上,想要在集群任意节点实现持久化存储,就需要用网络存储,通常采用的就是分布式存储。
- 为什么有了deployment,还要有statefulset?因为deployment可以部署无状态应用,比如nginx,随时重启都可以接受网络请求,不需要记住上次运行到哪里了,然后接着运行,但有些应用是需要记住上次崩溃或者结束时的运行状态,中断重启需要能够接着运行,这就叫有状态的应用,deployment做不到,就需要statefulset。statefulset应用如果要对外提供服务,也需要配service,一般的service的域名使用的是“对象名. 名字空间”,每个 Pod 也会有一个域名,形式是“IP 地址. 名字空间”,但pod的ip不稳,所以一般不用,但有状态集的pod是有状态应用,需要有稳定的pod地址,所以service一般用有状态pod的新的域名,格式是“Pod 名. 服务名. 名字空间.svc.cluster.local”。为了保证有状态应用的持久化存储不会因为读写冲突而丢失数据,statefulset的持久化存储是专门内嵌在statefulset的yaml中的volumeClaimTemplates字段表示的。
- 滚动升级,pod中会定义策略strategy字段,用来指定应用升级的方式,比如滚动升级,共20个pod,每次杀掉的pod不能超过75%,必须留下25%的pod保证应用稳定运行,让前端客户感知不到升级。当机器资源足够时,我们可以先起升级的20个pod,确定可以运行之后再杀掉原来的20个pod,或者一部分一部分地升级,如果资源不够,就只能一次少升级几个pod,或者先杀掉pod,再升级。有状态应用的升级比较复杂,还需要考虑到pod之间的依赖关系,即使按照依赖关系进行升级,升级过程中也可能出现问题,比如前一个未执行完,就因为时间到了而被杀掉,或者被杀掉的pod还没完全启动,就已经跑到这个位置了,容易出现问题。
10.怎么让应用运行得更健康? 可以限制pod能够申请的资源,通过resource字段,其中的requests和limits,可以写申请的资源和资源的上限。cpu一般用0.1之类的,memory一般用Ki、Mi、Gi 来表示 KB、MB、GB。还可以设置容器探针,Startup是启动探针,检查程序是否成功启动,Liveness是存活探针,用来检查应用是否正常运行,是否存在死锁、死循环。Readiness,就绪探针,用来检查应用是否可以接收流量,是否能够对外提供服务。另一种方法是对命名空间使用ResourceQuota这个api对象,来限制每个命名空间可占用的资源份额。
问题:
11. deployment部署的是服务pod,所以才有下面这张图是吗?是不是表示,deployment部署服务pod,然后service可以去代理对应标签的服务pod?所以daemonset部署的应该不是服务pod,而是监控的pod对吗?
更多推荐
已为社区贡献11条内容
所有评论(0)