今天遇到一个奇葩问题，废了大半天，原来是没有理解前端发送http请求传参方式，不同的content-type会进行不同传参，后台也要用不同的方式接受，在此记录一下；我们的程序使用的是前后端分离，前端使用vue，所有的请求都做的拦截的设置：// request拦截器设置service.interceptors.request.use(config => {switch (config.urlT

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

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

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

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

脏读、幻读、不可重复读与四种隔离级别