MySQL 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）一、redo log。

k8s是一个集群系统，允许开发人员在其上很容易的部署和管理容器化的应用。

1、定义k8s服务是一种为一组功能相同的pod提供单一不变的接入点的资源。看一个前后端例子：2、创建服务和RC、RS一样，服务也是用标签来管理pod的，创建服务有两种方式：（1）将RC或RS暴露为一个服务kubectl expose replicationcontroller rc名 --type=LoadBalancer --name 服务名（2）yamlmetadata:spec:ports:

转个图：1、以pod作为应用的最小运行单元，其中包括container和volume2、pod需要权限、拉镜像的密钥等3、卷可以是configmap、emptydir、gitrepo、PVC持久卷等类型4、方便其他应用或集群外访问pod，需要建立service5、label方便管理6、deployment方便高可用、多副本运行、滚动升级7、可能需要用到job等资源。

虽然一个pod可以管理多个容器，但是我们还是倾向于一个pod里只运行一个容器，原因有两点：1.两个不需要共享资源的容器在同一个pod中运行时，k8s不会对容器调度，而是对pod调度，这个pod永远都只会在某一个工作节点上运行，降低了基础设施的使用率；如果我们仅使用容器来运行这些进程，那么这些进程都需要在一个容器中运行，也就是单个容器多个进程，这其实是不合理的，我们倾向于一个容器一个进程，因为多个进

如果一个容器内的主进程挂了，也就是容器从内部挂了，kubelet自然能检测到容器的失败并重启容器，但试想一个java程序崩溃了，但JVM的程序还在运行，这个容器看起来依然在运行，但实际已经没有提供任何可用的服务了，这时候kubelet是不会重启容器的，所以要有一种从外部检测容器失败的机制，来保持pod的健康运行，即存活探针。（1）一定要检查应用程序的内部。如果将上述pod的app=kubia的标签

之前说RC的操作类似一个无限循环，比对pod期望数量和实际数量，但控制器实际上是监听pod数量的变更事件，并做出相应动作：增加pod副本时，RC不会直接创建pod，而是创建pod清单，发送到API服务器，让调度器和kubelet完成调度工作并运行pod。多实例API服务器：API服务器是无状态的，随便运行多少个都可以，通常一个etcd配一个API服务器，这样API服务器只需要和本地etcd实例通信

容器有个属性imagePullPolicy，默认是IfNotPresent，也就是说，当本节点有这个tag的镜像时，不会拉新的镜像，所以只改镜像内容并推送到镜像仓库是没用的，当然，将imagePullPolicy改为Always即可。（2）所有的请求都是由kubectl客户端发送给API服务器的，也就是说伸缩请求是由kubectl客户端执行的，不是k8s master，这带来的问题就是升级中间出现

创建一个pod时，可以指定容器对CPU和内存的资源请求量（即requests），以及资源限制量（即limits）。它们并不在pod里定义，而是针对每个容器单独指定。pod对资源的请求量和限制量是它所包含的所有容器的请求量和限制量之和。

横向伸缩：调大replicas副本数纵向伸缩：扩充pod的资源请求和限制，仅在创建时。