（作者：陈玓玏）
- 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对吗？
