tonglei111的博客

容器中的进程看到的文件系统视图是由它们容器镜像的初始内容以及挂载在容器中的卷所组成的。容器中的文件在磁盘上是临时存放的，这给在容器中运行较重要的应用带来一些问题： 当容器崩溃或停止时，此时容器状态未保存， 因此在容器生命周期内创建或修改的所有文件都将丢失。这里的意思就是将nfs的/nfs/data/nginx-pv目录挂载到容器内的/usr/share/nginx/html目录，这样两边的目录文件就可以做到实时同步了；卷的核心是一个目录，其中可能存有数据，Pod 中的容器可以访问该目录中的数据。

前面也提到，Ingress资源要正常工作，集群必须有一个正在运行的 Ingress 控制器， Ingress 控制器不是随集群自动启动的，目前k8s项目中，支持和维护 AWS、 GCE 和 Nginx Ingress 控制器；当然也有一起其他三方的控制器可使用；注意：配置文件中除了镜像的地址改后，ingress-nginx-controller的Service默认的type、ingress-nginx-controller的Deployment的配置中的hostNetwork也按照需求改一下。

官方的解释是:k8s中最小的管理单元是pod；而service是 将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法;Kubernetes 中 Service 的一个关键目标是让你无需修改现有应用以使用某种服务发现机制。你可以在 Pod 集合中运行代码，无论该代码是为云原生环境设计的，还是被容器化的老应用。你可以使用 Service 让一组 Pod 可在网络上访问，这样客户端就能与之交互。

采用微服务架构部署的应用，部署方式都要用到容器化部署+k8s容器编排，最近我在公司负载的系统也是用的上述架构部署，但是随着系统的运行，用户提的需求就会越多，每次更新的话都要停机发布，最用户侧来说就不太方便了，传统的部署方式是使用nginx来做负载均衡，然后手动来做滚动发布，殊不知k8s也有自己的一套配置，来解决滚动发布的事情，并且系统发布时用户侧其实是无感知的；默认是 0 秒，最小值是 0。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。