Prometheus 最初是 SoundCloud 构建的开源系统监控和报警工具，是一个独立的开源项目，于 2016 年加入了 CNCF 基金会，作为继 Kubernetes 之后的第二个托管项目。Prometheus 相比于其他传统监控工

前面通过 hostPath 或者 emptyDir 的方式来持久化数据，但是显然还需要更加可靠的存储来保存应用的持久化数据，这样容器在重建后，依然可以使用之前的数据。但是存储资源和 CPU 资源以及内存资源有很大不同，为了屏蔽底层的技术实现

nfs 的默认配置文件在 /etc/exports 文件下，在该文件中添加下面的配置信息

ingress-nginx 控制器主要是用来组装一个 nginx.conf 的配置文件，当配置文件发生任何变动的时候就需要重新加载 Nginx 来生效，但是并不会只在影响 upstream 配置的变更后就重新加载 Nginx，控制器内部会使

前面学习了在 Kubernetes 集群内部使用 kube-dns 实现服务发现的功能，那么部署在 Kubernetes 集群中的应用如何暴露给外部的用户使用呢？可以使用 NodePort 和 LoadBlancer 类型的 Service

前面可以通过 Service 生成的 ClusterIP(VIP) 来访问 Pod 提供的服务，但是在使用的时候还有一个问题：怎么知道某个应用的 VIP 呢？有两个应用，一个是 api 应用，一个是 db 应用，两个应用都是通过 Deplo

对于资源对象的操作都是通过 APIServer 进行的，那么集群是怎样知道请求就是合法的请求呢？这个就需要了解 Kubernetes 中另外一个非常重要的知识点了：RBAC（基于角色的权限控制）。

每个 Pod 都有自己的 IP 地址，但是如果 Pod 重建了的话 IP 很有可能也就变化了。这就会带来一个问题：比如有一些后端的 Pod 集合为集群中的其他应用提供 API 服务，在前端应用中把所有的这些后端的 Pod 的地址都写死，然后

对于应用的可变配置在 Kubernetes 中是通过一个 ConfigMap 资源对象来实现的，应用经常会有从配置文件、命令行参数或者环境变量中读取一些配置信息的需求，这些配置信息肯定不会直接写死到应用程序中去的，比如一个应用连接一个 re

一般情况下 ConfigMap 是用来存储一些非安全的配置信息，如果涉及到一些安全相关的数据的话用 ConfigMap 就非常不妥了，因为 ConfigMap 是明文存储的，这个时候我们就需要用到另外一个资源对象了：Secret，Secre