k8s-pod-初探2

Posted 2023-04-16

参考技术A

踩坑完毕，回到主线。

前面关于port的理解存在偏差，需要用实验来确认port配置的含义。

k8s官方文档对于对于这些配置项的解释还是没有很完善。下面是在其他博文中找到的解释。

已知：

从k8s集群内部的宿主机（物理机、虚拟机）可以直接访问pod的服务地址 ip:80

未知（需要测试）：

1、同一局域网内，但没有加入k8s集群的其他服务器能否访问pod的服务地址 ip:80---无法访问

2、能否跳过pod直接访问容器的服务地址 ip:80---没查到ip

首先要知道容器的IP地址

可以看到上面的命令查出的结果是 - 无法看出ip，尝试进入容器查看

然后我就没辙了，不过根据linux系统的精神，所有内容都是文件，但是我google了好久也没找到ip地址到底存在哪一个文件中。然后我就怀疑是不是一定要容器开放端口，ip地址才可以用docker inspect查询，起了一个不开端口的容器，结果也是有ip的。后来问了一个底层开发的朋友，据说ip是不写文件的。

那只能先认为通过k8s启动的容器其实是没有容器ip的。

从侧面看，也很有可能k8s启动的容器确实没有ip

3、访问pod所在的主机的80端口能否返回相同的响应---无法访问

从以上的信息来看，这个port配置应该和docker中暴露端口的意思是一样的，例如下面的例子

来做一下实验：

在我们之前的pod配置文件上增加配置，如下

结果和我们之前的猜测保持一致，增加ports的配置之后，访问宿主机的ip:80也可以访问到pod的内容了。

我这里pod ip 是 10.19.130.67，宿主机是 10.100.1.237。curl 10.19.130.67 和 curl 10.100.1.237 得到的结果是一样的。正当我想再仔细看看的时候，服务器又挂了，wc，只能明天找网管重启了。

---第二天

昨天，我还想看看

1、关了这个pod之后是否就不能访问了

启动了2个pod如下，mynginx1没有配置ports，mynginx2配置了ports。

当我关了pod-mynginx2之后访问宿主机10.100.2.167应该就不能通了，结果居然是---能访问到！

大吃一惊！结果ip弄错了，宿主机不是10.100.2.167，而是10.100.1.237，犯了个低级错误。

结果如下：这回和预期的结果终于一样了。

2、宿主机上是不是本身就开启了nginx，所以恰巧就能访问

确认宿主机上没有开启nginx

3、宿主机上的端口开放情况

使用netstat查看宿主机的端口开放，居然没有发现80端口开着，好奇怪。

那如果在10.100.1.237宿主机上启动一个nginx端口开在80，结果会是什么样子呢。

我居然启动了，没有端口已被占用的报错。现在把宿主机上的nginx的index页面的内容改一下，看访问10.100.1.237:80时，到底访问的是哪一个nginx。

分别从集群内部3台服务器和集群外部1台服务器的机器取访问10.100.1.237:80，访问到的都是pod中的nginx。

会不会跟启动顺序有关，因为现在的情况是先启动了pod-nignx，后启动 宿主机-nginx，那现在将pod-nginx关闭，访问10.100.1.237:80，看是啥。

集群内部3台服务器和集群外部1台服务器访问10.100.1.237:80，结果一致，都是宿主机-nginx。

再启动pod-nginx，查看结果。

访问结果又变回pod-nginx了，4台服务器结果一致。

再去看一下宿主机-nginx的日志，有没有报错信息-----------没有错误日志

现在基本可以得出结论了：当pod和宿主机同时使用某一个端口时，不会因为冲突而报错，但是pod会优先占用端口，而与启动顺序无关。

至于为什么会这样，就不去深究了，毕竟精力有限，作为运维实施，了解到这样子的程度应该够用了。

MySQL 日志初探

目录

• MySQL 日志初探
  • 零、概述
  • 一、Error Log(错误日志)
  • 二、General Query Log（通用查询日志）
  • 三、Slow Query Log （慢查询日志）
  • 四、Binary Log（BinLog）
  • 五、总结
  • 六、参考

MySQL 日志初探

零、概述

MySQL 的日志分为 Error Log（错误日志），General Query Log（通用查询日志）、Slow Query Log（慢查询日志）、Binary Log（BinLog），各种日志各有各的用处和配置方式，接下来进行简单的介绍。

---

一、Error Log(错误日志)

错误日志记录了数据库服务器的启停、故障或异常情况及警告等信息。Error Log 默认开启，并可以通过 log_error 来控制 日志文件路径 或 错误日志的启停。

• log_error =
• log_error = 0 / 1 控制启停，只能为 0 or 1,未作过实验，但建议错误日志应该随时打开。

日志级别

log_error_verbosity & log_warnings

以上两个系统变量都可以用来控制错误日志的输出级别，从MySQL 5.7.2开始，首选log_error_verbosity系统变量，而不是使用--log-warnings选项或log_warnings系统变量，这个参数从MySQL 8.0.3开始被移除了。

log_error_verbosity （新变量）

• log_error_verbosity 为 1 错误信息。
• log_error_verbosity 为 2 错误信息和告警信息。
• log_error_verbosity 为 3 错误信息、告警信息和通知信息。

log_warnings （旧变量）

• log_warnings 为0， 表示不记录告警信息。
• log_warnings 为1， 表示告警信息写入错误日志。
• log_warnings 大于1， 表示各类告警信息，例如有关网络故障的信息和重新连接信息写入错误日志。

---

二、General Query Log（通用查询日志）

通用查询日志包含对数据库操作的所有语句，默认 关闭 ，开启 General Query Log 会对数据库照成一定量的性能损失，慎重开启。

通过 general_log =

通过 general_log_file =

日志共分为 4 列：

• 时间（Time）:操作发生的时间，有一些不显示的原因是因为这些sql语句几乎是同时执行的,所以就不另外记录时间了.
• 链接ID(Id):数据库链接的Id，在Connect操作连接到数据库时生成。
• 命令类型(Command):Connect就是连接数据库，记录了谁（[email protected]）连接了那个数据库,Query就是查询数据库(增删查改都显示为查询),可以特定过虑一些操作.
• 详情(Argument):命令具体所做的操作详情，可能是SQL，也可能是指令或解释。

---

三、Slow Query Log （慢查询日志）

慢查询日志应该是非常常用的，特别是在进行慢SQL调优时。默认 关闭 。

• 通过 slow_query_log =
• 通过 slow_query_log_file =
• 通过 slow_launch_time = 系统变量控制记录的阈值，执行时间超过该阈值的SQL会被记录到慢查询日志中。
• 通过 log_slow_admin_statements =
• 通过 log_slow_slave_statements =

慢查询日志共分四列：

• 时间（Time）: SQL发生的具体时间
• 链接Id（Id）: 表示了 谁（[email protected]）及 链接Id。
• 概要（Command）: 统计了查询的耗时（Query_time），加锁时间（Lock_time），查询返回的行数（Rows_sent），查询检察过的行数（Rows_examined）。
• 详情(Argument):详情里记录了此次执行的指令或SQL。

---

四、Binary Log（BinLog）

BinaryLog,从名称里可以看出，他是一种二进制日志，它主要记录了对数据进行改动，包括表、数据改动等。也包括一些潜在改动，比如 UPDATE 或 DETELE 执行结果对任意一条数据都没影响的这种情况（DELETE FROM table WHERE 1 = 2）。除非使用 Row-based logging，否则会包含所有改动数据的 SQL Statement。

作用主要有：

• 复制:MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves并回放来达到master-slave数据一致的目的。
• 数据恢复：通过mysqlbinlog工具恢复数据
• 增量备份： 增量备份是指在一次全备份或上一次增量备份后，以后每次的备份只需备份与前一次相比增加或者被修改的文件。

Binary Log在Mysql中默认 关闭 。

• 通过 log_bin =
• 通过 log_bin_basename = < path / name > 系统变量控制Binlog文件的 主文件名 及路径，Log文件会根据切割条件自动切割为
• 通过 log_bin_index =

关于Binlog的其他内容，限于篇幅，这里不展开讨论。

五、总结

以上内容在 MySQL 5.7.19 下验证过，其他版本可能有细节差异，不再另表。

下表总结了几种日志类型的作用和默认开启情况。

类型	作用	默认情况
Error Log	记录了数据启停，故障，警告等信息。	ON
General Query Log	记录了所有的数据库链接、语句执行情况，开启会增加数据库负担。	OFF
Slow Query Log	记录了执行时间大于阈值的SQL，调试执行性能相关问题时很有用。	OFF
Binary Log	记录了对数据库进行改动的相关事件，主要用于复制、数据恢复、增量备份等。	OFF

六、参考

[1].初探 MySQL 的 Binlog

[2].mysql日志详细解析

[3].MySQL 通用查询日志(General Query Log)