1.简述k8s的service及其类型。

service定义了一组Pod的访问策略，作为一个稳定的网络端点。

其中最主要的有ClusterIP,NodePort,LoadBalancer以及ExternalName。

ClusterIP: 默认服务类型，仅在集群内部服务。k8s为service提供一个虚拟IP地址（ClusterIP），这个ip只能在集群内部的Pod或节点访问，集群外部无法直接访问。当访问到这个clusterIP请求后会自动负载均衡到后端匹配Pod。

依旧是打个比喻，将集群好比是一个公司，clusterIP即相当于前台总机，你的内部部门都有一个分机，当公司中一个部门想找另一个个部门时需要先拨通前台总机，然后总机再转接到分机。

那为什么不直接把部门分机的号码公布给所有人，让其直接拨打而是要加一个clusterIP？

注意，如果要直接访问部门电话（Pod的IP），你需要将这个IP固定写死，然而由于Pod的动态性，当突然宕掉或者损坏那么这个IP将直接销毁，而接替他的新Pod在创建时会分配一个全新的IP，这时候你会发现原本已经保存了旧部门电话的其他人怎么拨打也不通，这时候不得不重新修改通讯录里的电话号码。而clusterip完美解决了这个问题，只要你保存了公司总机号码，每次拨通则会直接转接对应部门，不管你的pod的ip如何变化，总机总是在不断更新。

不仅如此，clusterIp还很好解决了自动扩缩容的问题，如果你用固定ip,在流量高峰期扩容的ip无法被前端应用快速识别，导致负载不均，新Pod闲置。旧Pod过载。

NodePort: 在cluster的基础上在每个Node的静态端口上暴露服务，这使得外部客户端可以通过<任意NodeIP>:<特定NodePort>来访问集群内部的服务。因为cluster只能让内部互相之间访问，Nodeport的引入让这个“封闭”的空间与外部有了联系，外部客户端向任意一个节点的 IP 地址的 NodePort 端口发起请求。

大概流程是：数据包到达节点，根据kube-proxy的规则被拦截下来了，然后将<NodeIP>:<NodePort> 修改为 <ClusterIP>:<ServicePort>，然后就进入cluster的流程中了。假设当你为Nodeport分配了一个31000端口，你只需要在请求时添加31000这个“密令”，他就会让你进入公司。

他的优点是无需依赖云服务商，在任何k8s集群都能服务。缺点主要是端口受限，必须在30000-32767范围内，这也导致他不能使用标准的HTTPS(443)和HTTP(80)。除此之外，客户端必须知道至少一个节点IP地址，这也导致每次节点的变动客户端都需要感知，在动态环境中尤其麻烦。

在这里简单将以云服务厂商在service的作用，上面说NodePort像是一个后门，需要客户自己找门进入，而当你给云厂商提交一个申请时，云厂商会分配一个光明正大的大门，分配好固定的公网地址，并确保大门永远敞开。

这么看你是不是有所疑问，为什么云厂商这么好还要用nodeport?

 就像现实里的很多场景，当全球涌现这么优先设备，为什么有的地方依然在用老旧的仪器，是因为有些地区和条件的限制。而云厂商的api也是同理，像私有云、本地数据中心、裸金属服务器、边缘计算场景都不具备此条件，因此Nodeport便发挥了重要的作用，因此也体现了他的灵活性和环境普遍性。

loadBalancer: 他是在nodeport的基础上，通过集成云服务商的基础设施，自动创建一个外部负载均衡器并将服务暴露在外网。主要作用就是不必再手动管理如何将流量引入集群，k8s通过与云厂商的api交互，自动完成繁重的任务。

简单来说他就是暴露服务的终点。当你创建一个loadBalancer的service后，他会自动分配一个clusterIp，然后分配NodePort,然后调用云厂商服务。这一系列都是自动完成。当外部流量来时，他会访问负载均衡器分配公网地址，当负载均衡器收到请求后根据健康检查机制，然后将转发到一个健康的k8s节点的Nodeport。后续过程就和Nodeport如出一辙。

ExternalName: 这是k8s中并比较特殊的service，他不代理或负责任何流量，也不会选择任何Pod,而是给集群内部的客户客户端提供一个DNS别名，指向一个集群外部的服务。

简单来说就是为集群内部为外部服务创建一个本地别名，让应用程序访问内部服务一样访问外部。

其工作原理就是当你创建一个ExternalName服务时，会指定一个外部服务的域名，当集群内的应用尝试连接这个DNS时候，CoreDNS为其返回一个CNAME记录，使内部应用指向刚才说的外部域名，客户端 Pod 根据这个 CNAME 记录，直接与外部服务建立连接。整个通信过程不经过 kube-proxy，也不经过 Service 的虚拟 IP。

而这个service也实现了内外访问的统一。

2.什么是 PersistentVolume (PV) 和 PersistentVolumeClaim (PVC)？它们的关系是什么？

PersistentVolume：PV使k8s集群中一块网络储存资源，又管理员事先创建或者storageclass动态创建。他是集群级别的资源，不属于任何命名空间，类似node一样。

PersistentVolumeClaim：pvc是用户对存储的请求和声明，它属于命名空间级别，在特定命名空间下创建。

开发者通过pvc申请资源，开发者集中管理PV资源并根据需要选择不同的存储后端，无需修改应用的配置。而这种设计的核心就在于解耦，开发者不需要关心底层存储的具体实现，他们只需要提交PVC，当提交后k8s会根据pvc的要求寻找和他满足的pv,然后将pv和pvc绑定在一起，此时pvc的状态就会变成bound。

 Pod 通过 PVC 使用持久化存储，而 PVC 通过与 PV 的绑定，将具体的存储提供给 Pod。这种设计实现了存储的消费与供给的解耦，是 Kubernetes 声明式 API 和资源抽象思想的完美体现。

ok今天就先写两问，内容也差不多了！感谢观看如有错误欢迎指出。